Возможно, вам не нужен 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/