Важность тестирования сайтов на слабых устройствах

Эрик Бейли призывает тестировать сайты на слабых устройствах — "Test Your Product on a Crappy Laptop".

Если аналитические данные показывают преобладание пользователей с мощными устройствами, это не означает, что нужно ориентироваться только на состоятельную аудиторию, это означает, что нужно проверить работу сайта на недорогих ноутбуках или смартфонах. Пользователи слабых устройств часто не могут нормально пользоваться сайтом, поэтому они выпадают из аналитики. Такими пользователями могут быть состоятельные люди.

Чтобы контролировать доступность сайта для всех категорий устройств, Эрик предлагает проводить регулярные юзабилити-тесты на слабых устройствах. Также он предлагает купить дешёвый ноутбук (crapbook) и периодически вести на нём разработку.

У меня есть небольшая история на эту тему. Как-то мне пришлось работать на слабом ноуте, благодаря этому я нашёл редкую проблему с перформансом в React DevTools. Если бы работал на мощном ноуте, то проблема осталась бы незамеченной.

#performance #mobile

https://css-tricks.com/test-your-product-on-a-crappy-laptop/

Возможно, вам не нужен Rust и WASM, если у вас есть JavaScript

Увидел в канале @ufostation ссылку на статью Вячеслава Егорова про анализ проблем производительности библиотеки source-map — "Maybe you don't need Rust and WASM to speed up your JS".

Авторы source-map переписали основную логику библиотеки на Rust и WebAssembly, чтобы улучшить производительность. Егор решил проверить оригинальный код на предмет возможных оптимизаций. Там были найдены и исправлены проблемы, связанные с неоптимальной сортировкой, была уменьшена нагрузка на сборщик мусора заменой большого числа объектов типизированным массивом с ссылками на нужные данные, была испралвена проблема с деоптимизацией кода, связанной с передачей двух аргументов в функцию, которая ожидает на вход три аргумента.

В результате всех оптимизаций JavaScript-код стал уступать по скорости Rust и WebAssembly всего лишь на 15%.

Крутая статья. Рекомендую почитать всем.

#performance #js #internals #webassembly #rust

https://mrale.ph/blog/2018/02/03/maybe-you-dont-need-rust-to-speed-up-your-js.html
https://habr.com/ru/post/350018/ (перевод на русский)

Анализ производительности HTTP/3

В блоге requestmetrics была опубликована статья, посвящённая анализу производительности HTTP/3 — "HTTP/3 is Fast".

HTTP/3 — это новая версия протокола HTTP, работающая поверх транспортного протокола QUIC. Более подробно про HTTP/3 можно почитать в публикации HTTP/3: the past, the present, and the future.

В этой же статье проверялась скорость загрузки трёх видов сайтов: простой сайт, тяжёлый сайт, SPA. Ресурсы загружались с трёх разных серверов в Нью-Йорке, Лондоне и Бангалоре. Чем больше было расстоянее, тем лучше всего показывал себя HTTP/3. Если для передачи данных между Миннесотой и Нью-Йорком выйгрыш скорости состоавил более 200 мс, то для соединения между Миннесотой и Бангалором выйгрыш был уже 3-4 секунды. Такой значительный разрыв в скорости загрузки объясняется тем, что в HTTP/3 решена проблема с “head-of-line blocking” — блокировкой передачи данных из-за потери пакетов.

#http #performance #benchmark

https://requestmetrics.com/web-performance/http3-is-fast

Self-Profiling API на практике

Ник Джансма написал статью про новое экспериментальное API для профилировки производительности сайтов на устройствах пользователей — "JS Self-Profiling API In Practice".

Self-Profiling API предоставляет программный доступ к семплирующему профилировщику для получения детальной информации о выполнении JavaScript-кода у пользователей сайта. API можно использовать как для анализа производительности кода сайта, так и для анализа производительности скриптов внешних сервисов. Проанализировать выполнение кода можно на любом этапе жизни страницы. Доступ к Self-Profiling API включается с помощью HTTP-заголовка Document-Policy: js-profiling. Оно оказывает минимальный эффект на производительность сайта у пользователей.

Несмотря на экспериментальный статус Facebook и Microsoft уже начали использовать Self-Profiling API в своих сервисах для поиска проблем производительности.

На данный момент поддержка Self-Profiling API есть только в Chrome версии 94 и выше.

#performance #api

https://calendar.perfplanet.com/2021/js-self-profiling-api-in-practice/

Мониторинг производительности веб-компонентов. Кассондра Робертс объясняет, как User Timing API позволяет замерять этапы жизненного цикла, вычислять время апгрейда и понимать поведение компонентов на реальных устройствах. Подход с базовыми классами, миксины, аналитика и самые важные метрики, влияющих на пользователей. #performance #webcomponents

https://allons-y.llc/posts/2025-11-23/

Ускорение загрузки CSS с помощью словарей сжатия. Йоав Вейс объясняет, как использование словарей сжатия делает загрузку CSS почти мгновенной, сочетая подходы critical и full CSS. Метод снижает трафик и ускоряет переходы между страницами. Поддерживается в Chromium и имеет плавный откат. #performance #css

https://calendar.perfplanet.com/2025/how-to-load-css-fast/

Улучшение перфоманса с URL-параметрами. Барри Поллард объясняет, как ненужные параметры, такие как UTM-метки, создают дубликаты страниц и мешают кэшированию. Новый HTTP-заголовок No-Vary-Search позволяет указывать, какие параметры можно игнорировать, улучшая производительность и снижая нагрузку на сервер. Поддержка пока есть только в Chrome 141. #performance #http

https://calendar.perfplanet.com/2025/fixing-the-url-params-performance-penalty/

Отладка веб-перфоманса с Chrome DevTools. Жоан Леон показывает, как искать тяжелые ресурсы и слабое кеширование в Network, сравнивать локальные метрики с CrUX и разбирать LCP, CLS и INP в Performance Insights и трассировках. А также снипеты, content-visibility и оптимизация видео через HandBrake бонусом. #performance #devtools #chrome

https://calendar.perfplanet.com/2025/chrome-devtools-for-debugging-web-performance/

Расследование размера бандла. Надя Макаревич пошагово проходит анализ сборки в Vite, находит как wildcard-импорты ломают tree-shaking, почему lodash без ESM раздувает бандл и убирает дубликаты библиотек дат, чтобы сократить приложение на React с 5 МБ до 601 КБ. #js #performance

https://www.developerway.com/posts/bundle-size-investigation

Хватит превращать всё в массивы. Мэтт Смит показывает, как iterator helpers в JavaScript дают ленивые цепочки map, filter и take без промежуточных массивов и прекращают работу, когда UI получил нужные элементы. Это удобно для больших списков, потоков и пагинации, поддержка есть в современных браузерах и Node 22+. #js #performance

https://allthingssmitty.com/2026/01/12/stop-turning-everything-into-arrays-and-do-less-work-instead/

Практическое руководство по элементу <img>: от основ до LCP. Джоан Леон разбирает атрибуты srcset и sizes для адаптивных изображений, <picture> с AVIF и WebP, а также loading=lazy, width и height против CLS, decoding и fetchpriority. Отдельно о том, когда стоит добавить preload для LCP-картинок и почему иногда всё-таки нужны CDN. #performance #html

https://joanleon.dev/en/guia-practica-elemento-img/

Словарное сжатие наконец здесь, и результаты впечатляют. Тим Перри объясняет, как Compression Dictionary Transport работает с Zstandard и Brotli поверх HTTP: предыдущие ответы используются как словари для сжатия данных почти до размера дельт. JS-бандлы YouTube уменьшаются до 90% по сравнению с Brotli, HTML поиска Google — почти на 50%. Уже используется в Google, Shopify, Pinterest и Notion. Chrome 130+, Safari и Firefox на подходе. #performance #http

https://httptoolkit.com/blog/dictionary-compression-performance-zstd-brotli/

SVG в вебе: сравнение скорости в зависимости от способа загрузки. Джоан Леон сравнивает пять методов и то, как каждый влияет на кеширование, запросы и рендеринг: инлайн <svg>, <img>, <object>, CSS-фон и спрайты с <use>. Главный анти-паттерн: встраивание растровых изображений в base64 внутри SVG увеличивает размер файла на 33% и блокирует рендеринг. #svg #performance

https://joanleon.dev/en/svg-optimization/

Squarespace и веб-стандарты: как мы помогли добавить ленивую загрузку видео и аудио в HTML. Скотт Джел рассказывает, как инженеры Squarespace предложили loading="lazy" для элементов <video> и <audio>, работали с WHATWG, написали Web Platform Tests и сотрудничали с командами Mozilla, Apple и Chromium, чтобы фича стала официальным стандартом 23 марта 2026 года. #html #performance

https://engineering.squarespace.com/blog/2026/squarespace-and-web-standards-how-we-helped-bring-html-video-and-audio-lazy-loading-to-todays-browsers

Великое расширение CSS. Павел Лаптев рассматривает CSS-фичи, заменяющие JavaScript-библиотеки: anchor positioning вместо Floating UI, Popover API и <dialog> вместо Radix, scroll-driven animations вместо GSAP, view transitions вместо Motion и кастомизируемый <select> вместо React Select. Вместе они могут убрать до 322 КБ JavaScript. #css #performance

https://blog.gitbutler.com/the-great-css-expansion

Что такое CSS containment и как его использовать? Гарри Робертс объясняет недооценённую возможность CSS, позволяющую браузеру пропускать лишнюю работу по раскладке и отрисовке. Статья разбирает каждое значение contain (layout, paint, size, style), сокращения content и strict, а также content-visibility для ленивого рендеринга. Приводится пример OpenTable, где contain: strict сократил время раскладки с 11 до 2 мс, ограничив область с 4371 до 73 элементов. #css #performance

https://csswizardry.com/2026/04/what-is-css-containment-and-how-can-i-use-it/

Варианты предзагрузки изображений на JavaScript. Алекс Макартур сравнивает пять подходов: new Image(), <link rel="preload">, скрытый <div> с CSS-фоном, Cache API и fetch(). У каждого метода свои компромиссы в плане браузерного кеширования, обработки CORS и гибкости. Статья разбирает, когда лучше использовать каждый из них, чтобы избежать задержки при показе ещё не загруженных изображений. #js #performance

https://macarthur.me/posts/preloading-images/

Конец адаптивных изображений. Мэт Маркиз, бывший председатель Responsive Image Community Group, оглядывается на десять лет борьбы с атрибутом sizes и рассказывает, как sizes="auto" вместе с loading="lazy" наконец передают эту работу браузеру для большинства картинок. Поддержка уже есть в Firefox, Safari и Chrome, а длинные значения sizes можно оставлять только для картинок в первом экране. #html #performance

https://piccalil.li/blog/the-end-of-responsive-images/