bootg.com »
United States »
Defront (при поддержке Зарплата.ру) — про фронтенд-разработку и не только » Telegram Web
Итамар Бен Закен поделился опытом оптимизации Node.js-сервиса — "6 Lessons learned from optimizing the performance of a Node.js service".
Итамар разрабатывал сервис для A/B-тестирования. Такие сервисы должны работать очень стабильно, поэтому много внимания было уделено оптимизации. Вот некоторые мысли из статьи.
Нагрузочное тестирование — полезный инструмент. Оно даёт гарантии, что новые фичи не будут ломать производительность сервиса. Некоторые проблемы могут вскрываться только на больших промежутках времени, поэтому стоит увеличить время прогона тестов. Если каждый запрос должен быть обработан внешним сервисом, то при большом траффике это может создать проблемы. В статье разбирался кейс с Kafka — при её интеграции возникала большая задержка при отправке запросов. Чтобы решить эту проблему, была изменена логика обработки запросов. Их стали собирать в батчи и отправлять на обработку каждую секунду.
Довольно неплохая статья. Рекомендую почитать всем, кто разрабатывает сервисы на Node.js.
#performance #nodejs
https://engineering.klarna.com/6-lessons-learned-from-optimizing-the-performance-of-a-node-js-service-f163cac20473
Итамар разрабатывал сервис для A/B-тестирования. Такие сервисы должны работать очень стабильно, поэтому много внимания было уделено оптимизации. Вот некоторые мысли из статьи.
Нагрузочное тестирование — полезный инструмент. Оно даёт гарантии, что новые фичи не будут ломать производительность сервиса. Некоторые проблемы могут вскрываться только на больших промежутках времени, поэтому стоит увеличить время прогона тестов. Если каждый запрос должен быть обработан внешним сервисом, то при большом траффике это может создать проблемы. В статье разбирался кейс с Kafka — при её интеграции возникала большая задержка при отправке запросов. Чтобы решить эту проблему, была изменена логика обработки запросов. Их стали собирать в батчи и отправлять на обработку каждую секунду.
Довольно неплохая статья. Рекомендую почитать всем, кто разрабатывает сервисы на Node.js.
#performance #nodejs
https://engineering.klarna.com/6-lessons-learned-from-optimizing-the-performance-of-a-node-js-service-f163cac20473
Medium
6 Lessons learned from optimizing the performance of a Node.js service
Mistakes we’ve made and the things we’ve learned while optimizing the performance of one of our Node.js services.
В блоге Cloudflare была опубликована статья со сравнением производительности HTTP/2 и HTTP/3 — "Comparing HTTP/3 vs. HTTP/2 Performance".
Cloudflare объявил об экспериментальной поддержке HTTP/3 в сентябре 2019 (подробнее про HTTP/3 можно почитать тут https://www.tg-me.com/defront/268). За прошедшие полгода протокол был обновлён до 27-ой версии черновика протокола, а также были получены живые данные, которые помогли рабочей группе, занимающейся разработкой HTTP/3.
0-RTT — фича HTTP/3, которая позволяет сократить время при установке соединения. В сравнении с HTTP/2 метрика time to first byte (TTFB) для HTTP/3 при включённом RTT-0 улучшилась на 12%. С текущей реализацией алгоритма управления потоком (спецификация не накладывает на него ограничений) нельзя корректно сравнить время загрузки, но эксперименты показывают, что она как мининмум не хуже HTTP/2.
Экспериментальная поддержка HTTP/3 есть во всех основных браузерах: Chromium-based (Crhome, Edge, Opera), Firefox Nightly, Safari Technology Preview.
#http #performance
https://blog.cloudflare.com/http-3-vs-http-2/
Cloudflare объявил об экспериментальной поддержке HTTP/3 в сентябре 2019 (подробнее про HTTP/3 можно почитать тут https://www.tg-me.com/defront/268). За прошедшие полгода протокол был обновлён до 27-ой версии черновика протокола, а также были получены живые данные, которые помогли рабочей группе, занимающейся разработкой HTTP/3.
0-RTT — фича HTTP/3, которая позволяет сократить время при установке соединения. В сравнении с HTTP/2 метрика time to first byte (TTFB) для HTTP/3 при включённом RTT-0 улучшилась на 12%. С текущей реализацией алгоритма управления потоком (спецификация не накладывает на него ограничений) нельзя корректно сравнить время загрузки, но эксперименты показывают, что она как мининмум не хуже HTTP/2.
Экспериментальная поддержка HTTP/3 есть во всех основных браузерах: Chromium-based (Crhome, Edge, Opera), Firefox Nightly, Safari Technology Preview.
#http #performance
https://blog.cloudflare.com/http-3-vs-http-2/
The Cloudflare Blog
Comparing HTTP/3 vs. HTTP/2 Performance
We announced support for HTTP/3, the successor to HTTP/2, during Cloudflare’s birthday week last year. Our goal is and has always been to help build a better Internet. Even though HTTP/3 is still in draft status, we've seen a lot of interest from our users.
Гари Бернхардт — автор проекта destroyallsoftware (и знаменитого доклада "Wat") — опубликовал серию статей про миграцию своего стартапа с JS и Ruby на TypeScript.
В первой статье "Porting a React Frontend to TypeScript" он пишет про миграцию фронтенд-кода. Добавление типов позволило статически проверять генерацию ссылок для роутера и кода, работающего с ответом из api.
Вторая статья "Porting to TypeScript Solved Our API Woes" рассказывает про миграцию Ruby-проекта на TypeScript. Один из главных плюсов перехода — статическая проверка api-хендлеров и упрощение масштабного рефакторинга. Немного рассказывается про кодогенерацию с помощью библиотеки
В статье "Are Tests Necessary in TypeScript?" разбирается вопрос, нужен ли TS для проекта с большим покрытием тестами. Основная мысль — использование TS позволяет избавиться от целого класса тестов, которые необходимы в JS-коде. Тесты, в случае Гари, покрывают логику только очень важных подсистем: биллинг, управление подпиской.
Последняя статья "Problems With TypeScript in 2020" рассказывает про проблемы TypeScript. Есть баги с вотчингом файлов — могут возникать фантомные ошибки, когда из проекта удаляются файлы или добавляются новые. Редко бывают проблемы с внешними библиотеками, типы для которых поддерживаются сообществом. Но в целом, все известные минусы перекрываются преимуществами.
Рекомендую почитать статьи всем, кто задумывается о переходе на TypeScript.
#typescript #migration
В первой статье "Porting a React Frontend to TypeScript" он пишет про миграцию фронтенд-кода. Добавление типов позволило статически проверять генерацию ссылок для роутера и кода, работающего с ответом из api.
Вторая статья "Porting to TypeScript Solved Our API Woes" рассказывает про миграцию Ruby-проекта на TypeScript. Один из главных плюсов перехода — статическая проверка api-хендлеров и упрощение масштабного рефакторинга. Немного рассказывается про кодогенерацию с помощью библиотеки
schemats
, которая по структуре базы данных генерирует d.ts
-файлы сущностей предметной области.В статье "Are Tests Necessary in TypeScript?" разбирается вопрос, нужен ли TS для проекта с большим покрытием тестами. Основная мысль — использование TS позволяет избавиться от целого класса тестов, которые необходимы в JS-коде. Тесты, в случае Гари, покрывают логику только очень важных подсистем: биллинг, управление подпиской.
Последняя статья "Problems With TypeScript in 2020" рассказывает про проблемы TypeScript. Есть баги с вотчингом файлов — могут возникать фантомные ошибки, когда из проекта удаляются файлы или добавляются новые. Редко бывают проблемы с внешними библиотеками, типы для которых поддерживаются сообществом. Но в целом, все известные минусы перекрываются преимуществами.
Рекомендую почитать статьи всем, кто задумывается о переходе на TypeScript.
#typescript #migration
Сегодня у канала @winterview день рождения. Поздравляю с этим достижением! По своему опыту знаю, что создание качественного материала иногда даётся очень непросто. Паша у себя в канале рассказывает про прохождение собеседований, soft skills и немного про психологию. Читаю посты с интересом. И да, это не реклама. Просто хочется немного поддержать дружественный канал.
Марк Ноттингэм — участвует в разработке http и других протоколов — написал статью про малоизвестный http-заголовок
Этот заголовок говорит о том, что в браузере включена опция "безопасного интернета" для упрощения механизма фильтрации контента со стороны владельцев сайтов, например, для родительского контроля. Тем не менее он поддерживается только в Firefox и Internet Explorer.
Заголовок
Cтатья интересная. В ней также немного рассказывается про процесс принятия новых фич на уровне IETF.
#http #musings
https://www.mnot.net/blog/2019/12/05/safe_hint
Prefer: Safe
— "On RFC8674, the safe preference for HTTP".Этот заголовок говорит о том, что в браузере включена опция "безопасного интернета" для упрощения механизма фильтрации контента со стороны владельцев сайтов, например, для родительского контроля. Тем не менее он поддерживается только в Firefox и Internet Explorer.
Заголовок
Prefer: Safe
не получил широкого распространения из-за того, что он может потенциально использоваться для идентификации пользователей. А также из-за того, что понятие "Safe" каждый воспринимает по-своему. В статье рассказывается про случай с youtube, который сделал похожую настройку в своём приложении. После её добавления пользователи стали массово жаловаться на то, что они не видят нужный контент. Как оказалось, понятие "Safe" очень субъективно. То что было "Non-Safe" для youtube, было вполне "Safe" для пользователей. Тем не менее Марк считает RFC8674 шагом в правильном направлении, так как он обеспечивает фильтрацию контента на стороне пользователя без участия третьих сторон.Cтатья интересная. В ней также немного рассказывается про процесс принятия новых фич на уровне IETF.
#http #musings
https://www.mnot.net/blog/2019/12/05/safe_hint
mark nottingham
On RFC8674, the safe preference for HTTP
It’s become common for Web sites – particularly those that host third-party or user-generated content – to make a “safe” mode available, where content that might be objectionable is hidden. For example, a parent who wants to steer their child away from the…
Ингвар Степанян из Google написал статью про ускорение сжатия png-изображений в Squoosh — "Bringing OxiPNG to Squoosh".
Squoosh.app, несмотря на то что работает в вебе, попадает в категорию лучших инструментов для сжатия изображений. Для работы с png в нём использовалась скомпилированная в WebAssembly C-библиотека OptiPNG. У неё есть продвинутая альтернатива — Rust-библиотека OxiPNG, основное преимущество которой поддержка многопоточности (планируют задействовать в будущих релизах Squoosh).
Первая попытка миграции на OxiPNG привела к увеличению размера сжимаемых png относительно OptiPNG. Проблема была в библиотеке miniz_oxide, которая реализует алгоритм сжатия без потерь deflate, использующийся в png. Проблемная библиотека в итоге была заменена на libdeflater. После миграции на OxiPNG скорость сжатия png в некоторых случаях ускорилась более чем в два раза, и на несколько процентов сократился объём генерируемых файлов.
Статья скорее всего будет интересна тем, кто работает с WebAssembly и кому интересно почитать про библиотеки для сжатия png.
#webassembly #tool #graphics
https://rreverser.com/bringing-oxipng-to-squoosh/
Squoosh.app, несмотря на то что работает в вебе, попадает в категорию лучших инструментов для сжатия изображений. Для работы с png в нём использовалась скомпилированная в WebAssembly C-библиотека OptiPNG. У неё есть продвинутая альтернатива — Rust-библиотека OxiPNG, основное преимущество которой поддержка многопоточности (планируют задействовать в будущих релизах Squoosh).
Первая попытка миграции на OxiPNG привела к увеличению размера сжимаемых png относительно OptiPNG. Проблема была в библиотеке miniz_oxide, которая реализует алгоритм сжатия без потерь deflate, использующийся в png. Проблемная библиотека в итоге была заменена на libdeflater. После миграции на OxiPNG скорость сжатия png в некоторых случаях ускорилась более чем в два раза, и на несколько процентов сократился объём генерируемых файлов.
Статья скорее всего будет интересна тем, кто работает с WebAssembly и кому интересно почитать про библиотеки для сжатия png.
#webassembly #tool #graphics
https://rreverser.com/bringing-oxipng-to-squoosh/
Rreverser
Bringing OxiPNG to Squoosh
How we brought OxiPNG to Squoosh.app to provide better PNG compression.
Барри Поллард — специалист в области web-производительности и автор книги “HTTP/2 in Action” — рассказал, почему совет про упаковку html-кода в первых 14kb не стоит воспринимать как жёсткое правило.
Дело в том, что цифра 14kb основана не на реальных данных, а на теоретических вычислениях. В первой транзакции передачи tcp-пактов можно отправить 10 пакетов. Каждый пакет весит 1500 байт, в каждом пакете 40 байт занимает служебная информация. На основе этих данных и получается 14kb (10 * (1500 - 40)). Барри на примере показывает, что в реальных условиях это не всегда так. При использовании HTTPS и HTTP/2 служебные данные могут занимать до 5 пакетов, то есть половину всего теоретического лимита. Но это не означает, что нужно пренебрегать размером отправляемых ресурсов. Всё также достаточно важно размещать в первых ~14kb отправляемого html ссылки на критические ресурсы, чтобы браузер начал их загрузку во время парсинга html.
Очень прикольная статья. Рекомендую прочитать всем, кто занимается производительностью.
#performance #http
https://www.tunetheweb.com/blog/critical-resources-and-the-first-14kb/
Дело в том, что цифра 14kb основана не на реальных данных, а на теоретических вычислениях. В первой транзакции передачи tcp-пактов можно отправить 10 пакетов. Каждый пакет весит 1500 байт, в каждом пакете 40 байт занимает служебная информация. На основе этих данных и получается 14kb (10 * (1500 - 40)). Барри на примере показывает, что в реальных условиях это не всегда так. При использовании HTTPS и HTTP/2 служебные данные могут занимать до 5 пакетов, то есть половину всего теоретического лимита. Но это не означает, что нужно пренебрегать размером отправляемых ресурсов. Всё также достаточно важно размещать в первых ~14kb отправляемого html ссылки на критические ресурсы, чтобы браузер начал их загрузку во время парсинга html.
Очень прикольная статья. Рекомендую прочитать всем, кто занимается производительностью.
#performance #http
https://www.tunetheweb.com/blog/critical-resources-and-the-first-14kb/
Tunetheweb
Critical Resources and the First 14 KB - A Review
Do you really need to optimise as much of your critical page into the first 14 KB of your HTML for TCP reasons? Or does that not hold true in an HTTPS world?
В блоге web.dev была опубликована статья про изолированные окружения — "Making your website "cross-origin isolated" using COOP and COEP".
В web-платформе есть потенциально небезопасные, но мощные API: SharedArrayBuffer (требуется для WebAssembly Threads), performance.measureMemory (будет доступно в Chrome 83) и JS Self-Profiling API (пока нет поддержки в браузерах). Чтобы понять насколько опасно может быть их использование, можно вспомнить 2018 год, когда SharedArrayBuffer использовался для реализации атаки Spectre. Как противодействие Spectre SharedArrayBuffer был по умолчанию отключён во всех браузерах.
Для получения возможности использовать эти API ребята из Google разработали концепцию изолированного окружения (cross-origin isolated environment). Чтобы его включить, нужно отправить с документом http-заголовки:
Изолированное окружение (cross-origin isolated environment) полностью запрещает доступ к странице сторонним скриптам через window.opener или iframe и отключает изменение свойства document.domain. Благодаря чему семейство атак по сторонним каналам (например, Spectre) перестают работать.
Включение COOP и COEP на больших сайтах может быть нетривиально, поэтому в статье есть инструкции, как найти и исправить возникшие проблемы. Поддержка изолированных окружений ожидается в Chrome 83.
#security #api
https://web.dev/coop-coep/
В web-платформе есть потенциально небезопасные, но мощные API: SharedArrayBuffer (требуется для WebAssembly Threads), performance.measureMemory (будет доступно в Chrome 83) и JS Self-Profiling API (пока нет поддержки в браузерах). Чтобы понять насколько опасно может быть их использование, можно вспомнить 2018 год, когда SharedArrayBuffer использовался для реализации атаки Spectre. Как противодействие Spectre SharedArrayBuffer был по умолчанию отключён во всех браузерах.
Для получения возможности использовать эти API ребята из Google разработали концепцию изолированного окружения (cross-origin isolated environment). Чтобы его включить, нужно отправить с документом http-заголовки:
Cross-Origin-Embedder-Policy: require-corp
Cross-Origin-Opener-Policy: same-origin
Изолированное окружение (cross-origin isolated environment) полностью запрещает доступ к странице сторонним скриптам через window.opener или iframe и отключает изменение свойства document.domain. Благодаря чему семейство атак по сторонним каналам (например, Spectre) перестают работать.
Включение COOP и COEP на больших сайтах может быть нетривиально, поэтому в статье есть инструкции, как найти и исправить возникшие проблемы. Поддержка изолированных окружений ожидается в Chrome 83.
#security #api
https://web.dev/coop-coep/
web.dev
Making your website "cross-origin isolated" using COOP and COEP | Articles | web.dev
Some web APIs increase the risk of side-channel attacks like Spectre. To mitigate that risk, browsers offer an opt-in-based isolated environment called cross-origin isolated. Use COOP and COEP to set up such an environment and enable powerful features like…
Сегодня вышел Node.js 14. На medium был опубликован пост с описанием основных изменений — "Node.js version 14 available now".
Node.js 14 переходит на текущую ветку поддержки "Current", вытесняя оттуда Node.js 13. По плану через 6 месяцев (октябрь 2020) 14-ая версия перейдёт в фазу LTS. Node.js 12 будет поддерживаться до апреля 2022 года, Node.js 10 — до апреля 2021 года.
В Node.js 14 стабилизирован Diagnostic Report. Это API позволяет получить много полезной информации для локализации утечек памяти, причин падений и проблем производительности. В канале было несколько постов про эту фичу, их можно почитать тут и тут.
В новой версии доступен экспериментальный Async Local Storage API (есть бэкпорт для Node.js 13.10). Благодаря ему в Node.js появляется готовый инструмент для сохранения данных на время жизни http-запросов и любых других асинхронных процессов.
Были сделаны мажорные исправления в Streams API для улучшения согласованности и устранения неоднозначности. Например,
Появилась экспериментальная поддержка Web Assembly System Interface (WASI), цель которого упростить работу с нативными модулями в Node.js. Про WASI также был пост в канале ранее, его можно найти тут.
Движок V8 обновлён до v8.1. Новая версия приносит улучшения производительности и поддержку новых спецификаций: Optional Chaining, Nullish Coalescing,
В Node.js 13 ECMAScript modules стали доступны без явной передачи флага
#nodejs #release
https://medium.com/@nodejs/node-js-version-14-available-now-8170d384567e
Node.js 14 переходит на текущую ветку поддержки "Current", вытесняя оттуда Node.js 13. По плану через 6 месяцев (октябрь 2020) 14-ая версия перейдёт в фазу LTS. Node.js 12 будет поддерживаться до апреля 2022 года, Node.js 10 — до апреля 2021 года.
В Node.js 14 стабилизирован Diagnostic Report. Это API позволяет получить много полезной информации для локализации утечек памяти, причин падений и проблем производительности. В канале было несколько постов про эту фичу, их можно почитать тут и тут.
В новой версии доступен экспериментальный Async Local Storage API (есть бэкпорт для Node.js 13.10). Благодаря ему в Node.js появляется готовый инструмент для сохранения данных на время жизни http-запросов и любых других асинхронных процессов.
Были сделаны мажорные исправления в Streams API для улучшения согласованности и устранения неоднозначности. Например,
http.OutgoingMessage
теперь подобен stream.Writable
, а net.Socket
ведёт себя точно также как stream.Duplex
. Ещё одно заметное изменение — включение по умолчанию опции autoDestroy
.Появилась экспериментальная поддержка Web Assembly System Interface (WASI), цель которого упростить работу с нативными модулями в Node.js. Про WASI также был пост в канале ранее, его можно найти тут.
Движок V8 обновлён до v8.1. Новая версия приносит улучшения производительности и поддержку новых спецификаций: Optional Chaining, Nullish Coalescing,
Intl.DisplayNames
, Intl.DateTimeFormat
( calendar
, numberingSystem
).В Node.js 13 ECMAScript modules стали доступны без явной передачи флага
--experimental-modules
. В 14-ой версии сделан следующий значимый шаг — убрано предупреждение при использовании ESM ExperimentalWarning: The ESM module loader is experimental.
Тем не менее формально ESM остаётся экспериментальной фичей, поэтому в будущем могут быть мажорные изменения.#nodejs #release
https://medium.com/@nodejs/node-js-version-14-available-now-8170d384567e
Medium
Node.js version 14 available now
This blog was written by Michael Dawson and Bethany Griggs, with additional contributions from the Node.js Community Committee and the…
Тим Кадлек опубликовал пост с анализом производительности современных js-фреймворков — "The Cost of Javascript Frameworks".
Для анализа были использованы данные HTTP Archive: ~4,3 миллиона традиционных сайтов и ~5,5 миллионов мобильных. Оценивался объём js-файлов и время исполнения кода, использующего React, Angular, Vue.js и jQuery (добавлен for fun). По объёму кода на последнем месте для 90-го перцентиля оказались React (~2,2Mb) и Angular (~3,3Mb). По времени исполнении кода ситуация похоже, но для 90-го перцентиля на последнем месте оказался React (7,4 секунды), Angular (4,2 секунды). Для мобильных сайтов время выполнения кода для React вырастает более чем в три раза (~25 секунд), для Angular — примерно в полтора раза (~12 секунд).
Полученные цифры не говорят о производительности самих фреймворков и библиотек. Это "среднее по больнице", которое отражает преобладающие подходы к разработке в разных экосистемах.
#peformance #jsframeworks
https://timkadlec.com/remembers/2020-04-21-the-cost-of-javascript-frameworks/
Для анализа были использованы данные HTTP Archive: ~4,3 миллиона традиционных сайтов и ~5,5 миллионов мобильных. Оценивался объём js-файлов и время исполнения кода, использующего React, Angular, Vue.js и jQuery (добавлен for fun). По объёму кода на последнем месте для 90-го перцентиля оказались React (~2,2Mb) и Angular (~3,3Mb). По времени исполнении кода ситуация похоже, но для 90-го перцентиля на последнем месте оказался React (7,4 секунды), Angular (4,2 секунды). Для мобильных сайтов время выполнения кода для React вырастает более чем в три раза (~25 секунд), для Angular — примерно в полтора раза (~12 секунд).
Полученные цифры не говорят о производительности самих фреймворков и библиотек. Это "среднее по больнице", которое отражает преобладающие подходы к разработке в разных экосистемах.
#peformance #jsframeworks
https://timkadlec.com/remembers/2020-04-21-the-cost-of-javascript-frameworks/
Timkadlec
The Cost of Javascript Frameworks - Web Performance Consulting | TimKadlec.com
Джастин Микауд в блоге WebKit написал статью про ускорение операции удаления свойства объекта в JavaScriptCore — "A Tour of Inline Caching with Delete".
Самая распространённая рекомендация для написания быстрого JS-кода — не использовать оператор
Инлайн-кэш — это техника оптимизации, использующаяся для ускорения операций работы с объектами, суть которой состоит в модификации генерируемого кода на основе результатов его предыдущего выполнения (интересный факт, эта оптимизация впервые появилась в Smalltalk). Информация, собранная при генерации инлайн-кэша, используется оптимизирующим компилятором. После всех исправлений в JavaScriptCore компилятор может производить дополнительные оптимизации оператора
Довольно хардкорная и интересная статья. Must read, если интересуетесь тем, как работают js-движки под капотом.
#performance #js #internals #webkit
https://webkit.org/blog/10298/inline-caching-delete/
Самая распространённая рекомендация для написания быстрого JS-кода — не использовать оператор
delete
. Как пример, в JavaScriptCore delete
приводил к деоптимизации, из-за того что при удалении свойства движок использовал внутреннее представление js-объекта, которое не использует информацию об уже созданных ранее объектах. Для исправления этой проблемы потребовалось адаптировать механизмы, которые используются для кеширования общих частей объектов (Structure и Transitions). Исправление этой части сделало возможным генерацию инлайн-кэша (inline cache) на уровне JIT при удалении свойств объекта.Инлайн-кэш — это техника оптимизации, использующаяся для ускорения операций работы с объектами, суть которой состоит в модификации генерируемого кода на основе результатов его предыдущего выполнения (интересный факт, эта оптимизация впервые появилась в Smalltalk). Информация, собранная при генерации инлайн-кэша, используется оптимизирующим компилятором. После всех исправлений в JavaScriptCore компилятор может производить дополнительные оптимизации оператора
delete
, например, полностью его удалять из генерируемого машинного кода, если он не влияет на работу программы.Довольно хардкорная и интересная статья. Must read, если интересуетесь тем, как работают js-движки под капотом.
#performance #js #internals #webkit
https://webkit.org/blog/10298/inline-caching-delete/
WebKit
A Tour of Inline Caching with Delete
If you search for any JavaScript performance advice, a very popular recommendation is to avoid the delete operator.
Дмитрий Малышев из команды Firefox написал пост-апдейт про текущий статус разработки WebGPU — нового API для работы с видеокартами — "A Taste of WebGPU in Firefox".
Возможности WebGL не позволяют утилизировать весь потенциал современных видеокарт. Решить эту проблему призвано новое WebGPU API, над которым работают инженеры всех основных браузеров.
WebGPU предоставляет собой абстракцию над графическими API (DirectX12, Vulkan, Metal), изменяя подход к написанию приложений, которые используют вычислительные ресурсы видеокарт. Его основное отличие от WebGL — предоставление разработчикам большего количества рычагов для планирования и управления вычислениями. Например, благодаря ему можно распараллелить ресурсоёмкие задачи в web-воркерах, эффективно задействуя многоядерные процессоры. Или переиспользовать пакеты команд рендеринга, что открывает возможность портирования игр с открытым миром на web-платформу.
На данный момент рабочая группа WebGPU решила большую часть архитектурных проблем. Окончание основных работ над спецификацией и её имплементацией в браузерах планируется на конец 2020 года.
#webgl #webgpu #future
https://hacks.mozilla.org/2020/04/experimental-webgpu-in-firefox/
Возможности WebGL не позволяют утилизировать весь потенциал современных видеокарт. Решить эту проблему призвано новое WebGPU API, над которым работают инженеры всех основных браузеров.
WebGPU предоставляет собой абстракцию над графическими API (DirectX12, Vulkan, Metal), изменяя подход к написанию приложений, которые используют вычислительные ресурсы видеокарт. Его основное отличие от WebGL — предоставление разработчикам большего количества рычагов для планирования и управления вычислениями. Например, благодаря ему можно распараллелить ресурсоёмкие задачи в web-воркерах, эффективно задействуя многоядерные процессоры. Или переиспользовать пакеты команд рендеринга, что открывает возможность портирования игр с открытым миром на web-платформу.
На данный момент рабочая группа WebGPU решила большую часть архитектурных проблем. Окончание основных работ над спецификацией и её имплементацией в браузерах планируется на конец 2020 года.
#webgl #webgpu #future
https://hacks.mozilla.org/2020/04/experimental-webgpu-in-firefox/
Mozilla Hacks – the Web developer blog
A Taste of WebGPU in Firefox
WebGPU is an emerging API, designed from the ground up within the W3C, to provide access to the graphics and computing capabilities of hardware on the web.
Гарри Робертс поделился своими мыслями по поводу влияния Brotli на производительность сайтов — "Real-World Effectiveness of Brotli".
Brotli — это алгоритм сжатия, который был представлен Google в 2013 году. На данный момент он поддерживается во всех актуальных браузерах. Использование Brotli вместо Gzip позволяет уменьшить объём передаваемых ресурсов до ~30%.
Внедрение Brotli иногда может быть гораздо сложнее, чем включение опции в панели CDN. Гарри провёл эксперимент, чтобы понять, стоит ли вкладывать в этом случае много сил для его поддержки, или можно обойтись обычным Gzip. Как оказалось, уменьшение объёма ресурсов на 30% не гарантирует, что на 30% улучшатся другие метрики. При сравнении работы разных сайтов переход с Gzip на Brotli не дал большого прироста производительности: общий объём передаваемых ресурсов снизился на 5.8%, а метрика First contentful paint (FCP) улучшилась всего лишь на 3.5%.
В конце статьи Гарри подводит итог. Если у вас есть возможность включить Brotli, этим стоит воспользоваться. Если же внедрение Brotli влечёт за собой недели разработки, то имеет смысл продолжать использовать Gzip.
#compression #performance #brotli
https://csswizardry.com/2020/04/real-world-effectiveness-of-brotli/
Brotli — это алгоритм сжатия, который был представлен Google в 2013 году. На данный момент он поддерживается во всех актуальных браузерах. Использование Brotli вместо Gzip позволяет уменьшить объём передаваемых ресурсов до ~30%.
Внедрение Brotli иногда может быть гораздо сложнее, чем включение опции в панели CDN. Гарри провёл эксперимент, чтобы понять, стоит ли вкладывать в этом случае много сил для его поддержки, или можно обойтись обычным Gzip. Как оказалось, уменьшение объёма ресурсов на 30% не гарантирует, что на 30% улучшатся другие метрики. При сравнении работы разных сайтов переход с Gzip на Brotli не дал большого прироста производительности: общий объём передаваемых ресурсов снизился на 5.8%, а метрика First contentful paint (FCP) улучшилась всего лишь на 3.5%.
В конце статьи Гарри подводит итог. Если у вас есть возможность включить Brotli, этим стоит воспользоваться. Если же внедрение Brotli влечёт за собой недели разработки, то имеет смысл продолжать использовать Gzip.
#compression #performance #brotli
https://csswizardry.com/2020/04/real-world-effectiveness-of-brotli/
Csswizardry
Real-World Effectiveness of Brotli – CSS Wizardry
How effective is Brotli, really?
Прочитал пост Видита Бхаргавы про проблемы тёмных тем на OLED дисплеях — "Designing a Dark Theme for OLED iPhones".
В темах, которые используют настоящий чёрный цвет (#000), возникает две проблемы при отображении на OLED-дисплеях: смазывание изображения и эффект халяции.
Изображение смазывается из-за того, что чёрные пиксели в OLED-дисплеях по сути отключены. При их включении проходит небольшой промежуток времени, что при движении контента приводит к смазыванию изображения. Для того, чтобы от него избавиться, нужно настоящий чёрный цвет заменить на почти чёрный серый цвет (#050505). Таким образом пиксели не будут выключаться и эффекта смазывания не будет. Такой подход вызывает немного большее потребление энергии, но эти затраты практически неотличимы от энергозатрат при отображении чёрного цвета.
Эффект халяции возникает, когда на чёрном фоне отображается белый цвет. Это приводит к засветлению фона за границами текста, ухудшая читабельность. Для решения этой проблемы белый текст заменяют на очень светлый серый цвет, а фон — на почти чёрный серый цвет.
Хорошая статья. Если на вашем сайте (или в приложении) есть чёрная тема, то статью стоит почитать.
#mobile #a11y #ux
https://medium.com/lookup-design/designing-a-dark-theme-for-oled-iphones-e13cdfea7ffe
В темах, которые используют настоящий чёрный цвет (#000), возникает две проблемы при отображении на OLED-дисплеях: смазывание изображения и эффект халяции.
Изображение смазывается из-за того, что чёрные пиксели в OLED-дисплеях по сути отключены. При их включении проходит небольшой промежуток времени, что при движении контента приводит к смазыванию изображения. Для того, чтобы от него избавиться, нужно настоящий чёрный цвет заменить на почти чёрный серый цвет (#050505). Таким образом пиксели не будут выключаться и эффекта смазывания не будет. Такой подход вызывает немного большее потребление энергии, но эти затраты практически неотличимы от энергозатрат при отображении чёрного цвета.
Эффект халяции возникает, когда на чёрном фоне отображается белый цвет. Это приводит к засветлению фона за границами текста, ухудшая читабельность. Для решения этой проблемы белый текст заменяют на очень светлый серый цвет, а фон — на почти чёрный серый цвет.
Хорошая статья. Если на вашем сайте (или в приложении) есть чёрная тема, то статью стоит почитать.
#mobile #a11y #ux
https://medium.com/lookup-design/designing-a-dark-theme-for-oled-iphones-e13cdfea7ffe
Medium
Designing a Dark Theme for OLED iPhones
Why using black backgrounds for your true-dark theme is a bad idea
25 апреля npm немного поштормило. Ошибка в пакете is-promise, привела к поломке трёх миллионов зависимых проектов. Форбс Линдсей — автор библиотеки — написал постмортем.
После добавления поддержки ESM новый файл index.mjs не был добавлен в секцию
С момента публикации сломанной библиотеки до её полного фикса прошло четыре часа. Для предотвращения проблем в будущем был удалён
#npm #postmortem #esm #nodejs
https://medium.com/@forbeslindesay/is-promise-post-mortem-cab807f18dcc
После добавления поддержки ESM новый файл index.mjs не был добавлен в секцию
files
в package.json. Также в секции exports
идентификатор модуля был без префикса ./
. Из-за опубликованного кода перестал работать require вида require('is-promise/index')
, require('is-promise/index.js')
, require('is-promise/package.json')
.С момента публикации сломанной библиотеки до её полного фикса прошло четыре часа. Для предотвращения проблем в будущем был удалён
.npmignore
и добавлен прогон тестов для Node.js 12 и 14, также были добавлены тесты, использующие npm pack для проверки публикуемого API и настроена публикация пакетов из CI. Разработчики Node.js в свою очередь обновили документацию, уточнив, что package.exports
должен явно включать в себя все необходимые точки входа.#npm #postmortem #esm #nodejs
https://medium.com/@forbeslindesay/is-promise-post-mortem-cab807f18dcc
Medium
is-promise post mortem
Last Saturday, I made the decision to try and catch up on some of the many contributions to my open source projects. One of the first pull…
В последней подборке новостей Web Platform News увидел небольшой пост про проблемы ленивой загрузки iframe — "The <iframe loading="lazy"> attribute is not ready".
В августе 2019 в Chrome появилась поддержка атрибута
На данный момент
#html #lazy #chrome #problem
https://webplatform.news/issues/2020-04-27
В августе 2019 в Chrome появилась поддержка атрибута
loading
для ленивой загрузки изображений и iframe'ов. Атрибут loading
для изображений уже стандартизирован, но loading
для iframe остаётся экспериментальной фичей. В статье “Native lazy-loading for the web” команда разработки Chrome не акцентировала на этом внимание (сейчас статью исправили), поэтому эта фича стала появляться на production-сайтах.На данный момент
<iframe loading="lazy">
работает только в Chromium. При этом в текущей реализации есть известные проблемы, исправление которых может поломать сайты, которые уже начали использовать iframe loading
Так как разработчики стандартов руководствуются принципом "don't break the web", есть риск, что эти баги будут увековечены в окончательном стандарте. Поэтому если вы уже начали использовать loading
для iframe, от него стоит временно отказаться.#html #lazy #chrome #problem
https://webplatform.news/issues/2020-04-27
webplatform.news
Web Platform News
Regular news content for web developers written by Šime Vidas
Forwarded from Монада Кедавра (Аееее)
команда chrome в своих маркетинговых статьях регулярно «забывает» упомянуть о том, что их экспериментальные фичи никем не одобрялись
https://www.tg-me.com/defront/491
многие привыкли называть safari ie за т.н. медлительность в принятии фич, между тем — это единственное, что спасает от падения в бездну монополии гугла
https://github.com/WICG/construct-stylesheets/issues/45#issuecomment-577839892
сама статья гугла, продвигающая нестандартный adoptedStylesheets
в тот раз пронесло, если же в этот раз им удастся навязать своё мнение, взяв пользователей в заложники, то это будет окончательной установкой монополии в вебе в самых худших её проявлениях
это недопустимо.
https://www.tg-me.com/defront/491
многие привыкли называть safari ie за т.н. медлительность в принятии фич, между тем — это единственное, что спасает от падения в бездну монополии гугла
https://github.com/WICG/construct-stylesheets/issues/45#issuecomment-577839892
сама статья гугла, продвигающая нестандартный adoptedStylesheets
в тот раз пронесло, если же в этот раз им удастся навязать своё мнение, взяв пользователей в заложники, то это будет окончательной установкой монополии в вебе в самых худших её проявлениях
это недопустимо.
В постмортеме инцидента с is-promise одна из проблем была в конфиге, в который не был добавлен новый файл. Это случилось из-за того, что автора библиотеки запутало наличие файла
В npm есть два механизма для исключения попадания ненужных файлов в пакет: файл
К советам из статьи стоит прислушаться. Как минимум, можно начать с подозрением относиться к
#npm
https://medium.com/@jdxcode/for-the-love-of-god-dont-use-npmignore-f93c08909d8d
.npmignore
. Когда писал пост про постмортем, нашёл статью Джефа Дики про вред .npmignore
— "For the love of god, don’t use .npmignore".В npm есть два механизма для исключения попадания ненужных файлов в пакет: файл
.npmignore
(blacklist) и секция files в package.json
(whitelist). По умолчанию npm игнорирует файлы, которые находятся в .gitignore
, но при добавлении в проект конфига .npmignore
.gitgnore
перестаёт учитываться. Из-за этого нюанса у автора статьи утекли данные для аутентификации в S3, поэтому он рекомендует использовать только белый список файлов в package.json
(явное лучше неявного). Но .npmignore
может быть полезен, когда надо исключить раскиданные по проекту юнит-тесты __test__
/ *.test.js
и т.п.К советам из статьи стоит прислушаться. Как минимум, можно начать с подозрением относиться к
.npmignore
.#npm
https://medium.com/@jdxcode/for-the-love-of-god-dont-use-npmignore-f93c08909d8d
Medium
For the love of god, don’t use .npmignore
.npmignore is a serious hazard in Node.js projects you should immediately quit using (except in one situation as outlined below). There is…
Вирендра Сингх опубликовал статью про анализ производительности CSS-анимаций — "Performance monitoring in CSS animations".
Анимации могут быть причиной притормаживающего интерфейса. Это происходит тогда, когда браузеру необходимо перевычислять стили (Recalculate Style), создавать слой с элементами (Layout), рендерить его (Paint) и совмещать с другими слоями (Composite Layers) на каждый кадр анимации. Распространённый трюк для снижения количества операций — вынос анимаций на GPU. Chrome делает это автоматически, если анимируются свойства
В большом проекте найти источник проблемы может быть сложно, поэтому тут очень могут помочь Chrome Dev Tools. С их помощью можно проанализировать стек слоёв и посмотреть, какая работа выполнялась. В статье это всё разбирается на примере анимации движения объекта.
Статью стоит почитать, если хотите узнать немного больше про возможности Chrome Dev Tools.
#performance #css #chrome
https://medium.com/chegg/performance-monitoring-in-css-animations-f11a21d0054f
Анимации могут быть причиной притормаживающего интерфейса. Это происходит тогда, когда браузеру необходимо перевычислять стили (Recalculate Style), создавать слой с элементами (Layout), рендерить его (Paint) и совмещать с другими слоями (Composite Layers) на каждый кадр анимации. Распространённый трюк для снижения количества операций — вынос анимаций на GPU. Chrome делает это автоматически, если анимируются свойства
transform
, opacity
, filter
.В большом проекте найти источник проблемы может быть сложно, поэтому тут очень могут помочь Chrome Dev Tools. С их помощью можно проанализировать стек слоёв и посмотреть, какая работа выполнялась. В статье это всё разбирается на примере анимации движения объекта.
Статью стоит почитать, если хотите узнать немного больше про возможности Chrome Dev Tools.
#performance #css #chrome
https://medium.com/chegg/performance-monitoring-in-css-animations-f11a21d0054f
Medium
Performance monitoring in CSS animations
Animation using JavaScript ? or Animation using CSS?
Нашёл в дизайн-доках Chromium статьи про создание форм авторизации: "Password Form Styles that Chromium Understands", "Create Amazing Password Forms".
Браузеры и менеджеры паролей помогают пользователям автоматически заполнять поля форм авторизации. Для того чтобы вся эта "магия" работала правильно, нужно использовать семантическую вёрстку и придерживаться определённых правил. Например, чтобы менеджеры паролей смогли подхватить отправленные данные, после успешного логина должен произойти переход на новую страницу или этот переход должен быть сэмулирован с помощью
В общем, полезные статьи, рекомендую почитать. На всякий случай можете проверить, дружит ли процесс логина на вашем сайте с менеджерами паролей.
#html #ux
https://www.chromium.org/developers/design-documents/form-styles-that-chromium-understands
https://www.chromium.org/developers/design-documents/create-amazing-password-forms
Браузеры и менеджеры паролей помогают пользователям автоматически заполнять поля форм авторизации. Для того чтобы вся эта "магия" работала правильно, нужно использовать семантическую вёрстку и придерживаться определённых правил. Например, чтобы менеджеры паролей смогли подхватить отправленные данные, после успешного логина должен произойти переход на новую страницу или этот переход должен быть сэмулирован с помощью
history.pushState
или history.replaceState
. Для ускорения заполнения формы, поля ввода пароля и логина нужно разметить атрибутами autocomplete="current-password"
и autocomplete="username"
. Если у поля стоит атрибут autocomplete="new-password"
браузер или менеджер паролей будут показывать интерфейс для создания пароля.В общем, полезные статьи, рекомендую почитать. На всякий случай можете проверить, дружит ли процесс логина на вашем сайте с менеджерами паролей.
#html #ux
https://www.chromium.org/developers/design-documents/form-styles-that-chromium-understands
https://www.chromium.org/developers/design-documents/create-amazing-password-forms