Итамар Бен Закен поделился опытом оптимизации 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

В блоге 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/

Гари Бернхардт — автор проекта destroyallsoftware (и знаменитого доклада "Wat") — опубликовал серию статей про миграцию своего стартапа с JS и Ruby на TypeScript.

В первой статье "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-заголовок 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

Ингвар Степанян из 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/

Барри Поллард — специалист в области 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/

В блоге 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-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/

Сегодня вышел 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 для улучшения согласованности и устранения неоднозначности. Например, 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

Тим Кадлек опубликовал пост с анализом производительности современных 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/

Джастин Микауд в блоге WebKit написал статью про ускорение операции удаления свойства объекта в JavaScriptCore — "A Tour of Inline Caching with 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/

Дмитрий Малышев из команды 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/

Гарри Робертс поделился своими мыслями по поводу влияния 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/

Прочитал пост Видита Бхаргавы про проблемы тёмных тем на 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

25 апреля npm немного поштормило. Ошибка в пакете is-promise, привела к поломке трёх миллионов зависимых проектов. Форбс Линдсей — автор библиотеки — написал постмортем.

После добавления поддержки 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

В последней подборке новостей Web Platform News увидел небольшой пост про проблемы ленивой загрузки iframe — "The <iframe loading="lazy"> attribute is not ready".

В августе 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

команда chrome в своих маркетинговых статьях регулярно «забывает» упомянуть о том, что их экспериментальные фичи никем не одобрялись

https://www.tg-me.com/defront/491

многие привыкли называть safari ie за т.н. медлительность в принятии фич, между тем — это единственное, что спасает от падения в бездну монополии гугла

https://github.com/WICG/construct-stylesheets/issues/45#issuecomment-577839892
сама статья гугла, продвигающая нестандартный adoptedStylesheets

в тот раз пронесло, если же в этот раз им удастся навязать своё мнение, взяв пользователей в заложники, то это будет окончательной установкой монополии в вебе в самых худших её проявлениях

это недопустимо.

В постмортеме инцидента с is-promise одна из проблем была в конфиге, в который не был добавлен новый файл. Это случилось из-за того, что автора библиотеки запутало наличие файла .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

Вирендра Сингх опубликовал статью про анализ производительности CSS-анимаций — "Performance monitoring in CSS animations".

Анимации могут быть причиной притормаживающего интерфейса. Это происходит тогда, когда браузеру необходимо перевычислять стили (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

Нашёл в дизайн-доках Chromium статьи про создание форм авторизации: "Password Form Styles that Chromium Understands", "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