Марк Ноттингэм — участвует в разработке 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 Javanoscript 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-javanoscript-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://news.1rj.ru/str/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

Команда разработчиков Chrome активно контрибьютит в инструменты js-экосистемы и фреймворки. Хуссейн Джирде написал статью про один из таких кейсов сотрудничества — "Improved Next.js and Gatsby page load performance with granular chunking".

В Next.js и Gatsby в бандл commons попадал код, который использовался более чем на 50% страниц. Такая настройка была не очень эффективна, так как общий код оставшихся 50% страниц не разделялся между чанками. Для решения этой проблемы была адаптирована стратегия, в которой с помощью SplitChunksPlugin:
— все модули больше 160kb выносятся в индивидуальные чанки;
— создаётся отдельный чанк frameworks с кодом, который используется на всех страницах ( react, react-dom и т.п.);
— создаётся столько общих чанков, сколько webpack посчитает нужным создать, но не более 25.

Такие настройки позволяют улучшить скорость загрузки и улучшить утилизацию кеша при переходе между страницами. При переходе на новую стратегию разделения чанков общий размер генерируемого js-кода на production-сайтах уменьшился в среднем на 20%.

Рекомендую почитать статью, если интересуетесь темой производительности.

#webpack #performance

https://web.dev/granular-chunking-nextjs/

Мне регулярно присылают предложения о размещении рекламы в канале. Но я буду продолжать считать (глупо наверное звучит), что Defront будет лучше, если он будет без рекламы.

Тем не менее канал существует в том числе благодаря вашей поддержке на патреоне. Хочу выразить благодарность моим патронам: Андрею, Артёму, bafonins, brqte, Роману, Сергею, Владу, Денису и Дмитрию. Ребята, большое вам спасибо! И ещё хочу поблагодарить всех за то, что читаете канал и рассказываете про него своим друзьям и коллегам.

Если вам нравится то, что я делаю, и хотите поддержать канал, то это можно сделать тут https://www.patreon.com/myshov.

#спасибо

Колин Эберхарт — участвует в разработке многих проектов — написал статью про использование D3 для визуализации очень больших объёмов данных — "Rendering One Million Datapoints with D3 and WebGL".

Колин разрабатывает D3FC (набор компонентов для создания интерактивных диаграмм поверх D3). Недавно туда была добавлена поддержка WebGL. В статье на примере визуализации данных из репозитория цифрового контента научных библиотек HathiTrust рассказывается, как использовать эти компоненты.

Датасет HathiTrust состоит из одного миллиона объектов и занимает 70Mb. Если его читать полностью перед отрисовкой, то пользователь некоторое время не будет видеть график. Гораздо лучше рендерить график по мере получения данных. Для этого можно использовать Streams API. При наведении курсора мыши на каждую точку желательно показывать описание. Но опять же из-за большого объёма данных будут тормоза, если использовать линейный поиск для получения нужной точки. Для оптимизации поиска в примере используется структура данных Quadtree (идёт из коробки с D3).

Довольно большая и подробная статья. Cоветую почитать, если у вас возникнет задача визуализации очень большого количества данных.

#d3 #dataviz #webgl

https://blog.scottlogic.com/2020/05/01/rendering-one-million-points-with-d3.html

Пару недель назад Брайан Ким представил сообществу новый фреймворк Crank.js — "Introducing Crank".

Crank.js был вдохновлён React. Он использует JSX для создания компонентов. Компоненты могут создаваться с помощью генераторов function * (), такой подход позволяет использовать нативные конструкции языка для работы с жизненным циклом компонента. Также благодаря тому, что компоненты могут быть асинхронными, из коробки становятся доступны возможности, которые даёт Suspense в React.

Потыкал его час. Работа с асинхронными запросами в компонентах выглядит органично. Для работы с событиями Crank использует интерфейс EventTarget, который используется в DOM. Работа с событиями императивна, в принципе нормально, но после React выглядит непривычно.

Брайан сделал очень большой упор на работу с нативными возможностями платформы. Один из пунктов его критики React, как раз заключается в том, что React старается переизобрести рантайм для UI, когда браузер уже им и является. Дэн Абрамов на Reddit написал пост с объяснением, почему React использует такой подход.

Пока рано говорить о судьбе Crank.js, но тем не менее это очень интересный эксперимент, отголоски которого мы, возможно, увидим в других фреймворках/библиотеках.

#jsframeworks #announcement

https://bit.ly/3deCWYj (пост Дэна)
https://crank.js.org/blog/introducing-crank

Стефан Джудис написал небольшую статью про использование альтернативного текста с псевдоэлементами — "The CSS "content" property accepts alternative text".

Псевдоэлементы before и after часто используются для стилизации элементов на странице с помощью свойства content. Но content может негативно влиять на доступность, так как он озвучивается скринридерами. Для решения этой проблемы можно задавать альтернативный текст прямо в CSS.

/* css */
.new-item::before {
  content: "★" / '';
}

/* html */
<a href="new-things">go to new things</a>

В примере выше альтернативный текст для символа звезды пустая строка. Без него скринридеры озвучили бы html как "black star go to new things".

Поддержка этой фичи есть только в Chromium-based браузерах. В Safari есть поддержка экспериментального и устаревшего свойства alt. Только в Firefox на данный момент невозможно задать альтернативный текст для content.

#css #a11y

https://www.stefanjudis.com/today-i-learned/css-content-accepts-alternative-text/