Эдди Османи написал статью про использование Puppeteer для анализа производительности сайта — "Web Performance Recipes With Puppeteer".

Puppeteer — это библиотека для автоматизированного управления браузерами (Chrome, Edge, Opera, Firefox). Её используют для пререндеринга страниц SPA-приложений, для тестирования, генерации скриншотов страницы и т.п.

В статье Эдди делится Puppeteer-скриптами, которые могут быть полезны для решения проблем производительности. Например, для оценки влияния стороннего кода, для получения метрик производительности (FCP, LCP, CLS), для поиска утечек памяти, для измерения FPS страницы и многого другого.

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

#performance

https://addyosmani.com/blog/puppeteer-recipes/

Лин Кларк опубликовала статью, посвящённую оптимизации работы JavaScript-кода в WebAssembly-окружении — “Making JavaScript run fast on WebAssembly”.

Некоторые платформы ограничивают набор оптимизаций, которые могут быть применены к JavaScript-коду. Например, на iOS и игровых консолях нельзя использовать JIT-компилятор, поэтому JS-движки там могут работать только в режиме интерпретатора. Это ограничивает спектр задач, который может быть решён с помощью JS. Участники Bytecode Alliance (Fastly, Mozilla, Igalia) работают над решением на базе WebAssembly, которое позволит ускорить выполнение JS-кода на таких платформах и достичь уровня производительности JIT-компиляторов ранних версий JavaScript-движков.

В разрабатываемом решении в качестве первой оптимизации будут использоваться снапшот памяти, который позволяют сократить время инициализации программы до нескольких микросекунд. В качестве второй оптимизации будет использоваться AOT-компиляция с генерацией стабов для внутренних кешей.

В статье говорится о том, что подобный подход может использоваться не только с JavaScript, но и с Python, Ruby, Lua.

#js #performance #webassembly

https://bytecodealliance.org/articles/making-javascript-run-fast-on-webassembly

Недавно вышел Lighthouse 8. Самым значимым изменением в релизе стало изменение оценки "Performance Score". Каролина Щур в статье "How Lighthouse 8 Changes Affect Your Metrics" рассказала, как именно поменялась эта оценка.

Были изменены веса метрик FCP, SI, TTI, TBT и CLS. Теперь наибольшее влияние будут оказывать TBT (Total Blocking Time, +30% от общего веса всех метрик) и CLS (Cumulative Layout Shift, +10%). Если на вашем сайте была хорошая оценка, но в новой версии Lighthouse она упала, это означает, что при открытии страницы много времени занимает инициализация и выполнение клиентского кода или из-за того, что на странице происходит сдвиг контента.

Также было изменено определение метрики CLS. Подсчёт общего сдвига контента теперь происходит на основе сгруппированных оценок сдвига за пять секунд. Это изменеие позволило устранить корреляцию между оценкой сдвига контента и количеством времени, проведённым на странице, улучшив общую оценку для долгоживущих страниц.

Lighthouse 8 уже доступен в PageSpeed Insights, а его поддержка в Chrome появится в версии 93.

#performance #release #lighthouse

https://calibreapp.com/blog/lighthouse-8

Джейк Арчибальд написал статью о том, кам добиться чёткого отображения фотографий на экранах с высокой плотностью пикселей, не теряя качества и сохранив разумный вес файлов — "Serving sharp images to high density screens".

Самый главный совет — не нужно использовать высокое качество сжатия для изображений, которые будут отображаться на ретина-экранах. На экранах с высокой плотностью пикселей изображения отображаются меньше своего фактического размера, скрывая артефакты сжатия.

Ещё можно использовать медиавырыжаение -webkit-min-device-pixel-ratio с тегом <source>, чтобы браузер смог выбрать подходящее изображение в зависимости о текущей ситуации.

Полезная статья. Рекомендую почитать.

#performance

https://jakearchibald.com/2021/serving-sharp-images-to-high-density-screens/

Лучшие практики использования виджетов сторонних сервисов

Лина Сохони, Эдди Османи и Кэти Хэмпениус написали статью о лучших практиках подключения сторонних виджетов — "Best practices for using third-party embeds".

В статье предлагается использовать ленивую загрузку содержимого iframe с помощью атрибута loading="lazy". Некоторые виджеты поддерживают ленивую загрузку из коробки, например, в социальных плагинах Facebook для этого можно использовать атрибут data-lazy="true". Есть хороший совет использовать фасады для сторонних виджетов, чтобы пользователи не загружали лишний код при открытии страницы. Затрагивается тема непредсказуемого сдвига контента (Layout Shift).

Ещё ребята рекомендуют использовать готовые библиотеки для ленивой загрузки виджетов (lazysizes), создания фасадов (lite-youtube-embed, lite-vimeo-embed, react-live-chat-loader) и уменьшения непредсказуемого сдвига контента (Layout Shift Terminator).

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

#performance #tool

https://web.dev/embed-best-practices/

Оптимизация прокрутки Google Search Console

Йохан Исакссон рассказал, как он улучшил производительность прокрутки большого списка Google Search Console — "How I made Google’s data grid scroll 10x faster with one line of CSS".

Йохан не работает в Google, но много работает с Google Search Console — SEO-инструмент Google. Он обратил внимание, что при прокрутке списка с 500 элементами производительность перерисовки страницы падает до 5-7 fps. Как оказалось, прокрутка большого списка приводит к перерасчёту раскладки тридцати тысяч DOM-элементов страницы.

Для решения этой проблемы Йохан воспользовался CSS-свойством contain, с помощью которого можно изолировать отдельные части страницы, чтобы их изменение не влияло на производительность рендеринга всей страницы:

table {
  contain: strict;
}

После внесённого изменения производительность рендеринга улучшилась в 10 раз.

Хорошая статья. Рекомендую почитать всем, кому интересен пример поиска и устранения проблем производительности рендеринга.

#performance

https://medium.com/@johan.isaksson/how-i-made-googles-data-grid-scroll-10x-faster-with-one-line-of-css-78cb1e8d9cb1

P.S. Благодарю @oleg_log за ссылку на статью

Подходы использования SVG и их производительность

Тайлер Ситка сравнил производительность разных методов использования SVG на HTML-страницах — "Which SVG technique performs best for way too many icons?".

Самым производительным способом добавления SVG стал элемент <img> c data URI — 72 мс для 1000 иконок. Но при таком подходе невозможно стилизовать SVG с помощью внешних стилей. Наиболее сбалансированным способом для оптимизированных SVG оказался инлайнинг — 87 мс для 1000 иконок. Самым медленным способом стала CSS-маска — 150 мс.

Тайлер также пишет о том, что не нужно сильно задумываться о выборе подходящего метода, если на странице используется менее сотни SVG-изображений. Используйте тот подход, который нравится.

#benchmark #performance #svg

https://cloudfour.com/thinks/svg-icon-stress-test/

Поиск причины деградации времени сборки Webpack 5

Оуэн Хэннесси поделился историей поиска бага, из-за которого время запуска dev-сервера Webpack замедлилось в пятнадцать раз — "Understanding why our build got 15x slower with Webpack 5".

Проблема возникла после добавления невинной тёмной темы. Первые подозрения упали на CSS-in-JS-библиотеку Linaria. С помощью профилировщика внутри библиотеки была найдена проблемная функция, в которой использовался метод массива .concat(). Переписывание кода без использования .concat() решило проблему. Однако оставались вопросы, из-за того что в оригинальном коде просадки скорости не было при сборке проекта с помощью Webpack 4. Надо было исследовать исходники V8.

В V8 у метода .concat() есть две ветки выполнения кода — медленная и быстрая. Медленная ветка начинает работать в том случае, если движок хотя бы один раз устанавливал Symbol.isConcatSpreadable. В Webpack 5 это происходило в коде, отвечающем за обратную совместимость с четвёртой версией. Для решения проблемы разработчики Webpack добавили экспериментальную опцию backCompat, которая полностью отключает обратную совместимость, избавляясь от ещё большего количества проблемного кода.

#v8 #performance #webpack

https://engineering.tines.com/blog/understanding-why-our-build-got-15x-slower-with-webpack

Не пишите квадраты

Степан Зубашев критикует современные тренды написания JavaScript-кода — "Обращение к Javascript-сообществу: перестаньте писать квадраты".

Популярность функциональных методов для работы с массивами и современные фичи JavaScript открыли двери для очень лаконичного кода. Но иногда чрезмерное увлечение лаконичностью приводит к падению производительности. В статье на примере использования .concat() внутри .reduce() рассказывается, почему это может оказаться серьёзной проблемой.

source.reduce(
  (acc, item) => acc.concat(func(item)),    
  [] 
);

В данном случае на каждую итерацию происходит копирование всех элементов старого массива в новый, который возвращается .concat(). Создание нового массива происходит для каждого элемента source, таким образом сложность кода получается квадратичной. С подобной проблемой столкнулись разработчики из вчерашней статьи.

Степан призывает не ставить в абсолют краткость кода и задумываться о производительности.

#js #algorithm #performance

https://habr.com/ru/post/590663/

Ускорение установки HTTPS-соединений

Саймон Харн рассказал о том, как HTTPS-сертификаты влияют на производительность сайта — "The Performance Cost of EV Certificates".

Есть три основных типа HTPS-сертификатов: Domain Validation (DV), Organisation Validation (OV), Extended Validation (EV). DV-сертификаты выдаются на основе факта принадлежности домена, как в Let's Encrypt. OV- и EV-сертификаты выдаются организациям за оплату.

EV-сертификат предоставляет большее количество информации для пользователя, но по-большому счёту он не сильно отличается от OV. Вы могли видеть, что сайт использует EV-сертификат, когда в адресной строке рядом с иконкой замка зелёным текстом отображался владелец сертификата. С версии Chrome 77 такие сертификаты отображаются обычным значком замка без зелёного текста.

OV-сертификаты валидируются на стороне веб-сервера отправкой запроса на сервер организации, выдавшей сертификат. EV-сертификаты не могут валидироваться на стороне веб-сервера, поэтому их валидация происходит на клиенте, замедляя установку HTTPS-соединения. Задержка наиболее заметна в странах бывшего СССР, в Восточной Австралии, Канаде и большинстве стран Африки. Некоторые организации сталкивались с минутной задержкой для пользователей в Китае. Эта проблема решается переходом на OV-сертификат.

#http #performance #security

https://simonhearne.com/2020/drop-ev-certs/

Сравнение вычислительной производительности WebGL и WebGPU

Денис Радин сравнил вычислительную производительность WebGL и WebGPU — "WebGPU computations performance in comparison to WebGL".

WebGPU API предоставляет доступ к возможностям современных видеокарт. Для поддержки вычислений в нём используются вычислительные шейдеры (compute shaders). В WebGL что-то подобное можно сделать с помощью хака преобразованием данных в текстуру и их дальнейшей обработкой с помощью пиксельного шейдера. Так как WebGPU разрабатывался с учётом поддержки произвольных вычислений, в задаче на перемножение матриц он работает в 3,5 раза быстрее WebGL.

WebGPU открывает доступ к машинному обучению в вебе, пост-процессингу в реальном времени и физическим симуляциям в 60 fps.

#webgl #webgpu #performance

https://pixelscommander.com/javascript/webgpu-computations-performance-in-comparison-to-webgl/
http://pixelscommander.com/ru/javascript/webgpu-computations-performance-in-comparison-to-webgl/ (на русском языке)

Браузер. Рендеринг. Производительность

Второй год я помогаю с поиском спикеров на CodeFest — крупнейшая конференция за Уралом. В прошлом году у нас выступал Сергей Ufocoder — автор канала @ufostation — с докладом "Браузер. Рендеринг. Производительность".

В докладе рассказывается о производительности рендеринга в Chromium с точки зрения архитектуры браузера. Подробно объясняется работа пайплайна рендеринга на примере about://tracing и профилировки страниц с помощью вкладки Performance в DevTools. Рассматриваются несколько случаев оптимизации производительности с объяснением, почему это работает именно так. При подготовке доклада Сергей консультировался с официальной документацией Chromium и с разработчиками браузера.

Доклад немного хардкорный, но полезный. Рекомендую посмотреть.

#performance #chromium #internals #talks

https://www.youtube.com/watch?v=tbDxm1hiEI4

Ускорение отрисовки комментарии Хабра

Станислав Лашманов поделился опытом ускорения отрисовки комментариев в web-версии Хабра — "Как мы ускоряли комментарии Хабра".

Фронтенд Хабра — это SPA-приложение, написанное на Vue.js. Самой большой проблемой после переписывания фронта Хабра стала производительность комментариев. Страницы с большим количеством комментариев рендерились медленно, а на слабых устройствах им не хватало памяти.

Для решения этой проблемы ребята реализовали стриминг. Благодаря ему комментарии рендерятся на сервере и по мере готовности передаются на клиент. Клиенту больше не приходится ждать загрузки всех комментариев. Однако с добавлением стриминга возникли другие проблемы: перестали работать якорные ссылки, надо было реализовывать восстановление скролла после перезагрузки страницы, были проблемы с переходами по истории. Все проблемы удалось решить.

Респект ребятам за то, что смогли дотащить эту фичу, но работы у них ещё осталось много. Хабр сейчас работает гораздо медленнее по сравнению со старой версией — оценка производительности в Lighthouse 25 баллов из 100. С точки зрения обычного пользователя кажется, что переход на SPA был не самой хорошей идеей.

#performance #spa #vue

https://habr.com/ru/company/habr/blog/590111/

Улучшилась ли скорость веба благодаря Web Vitals?

Барри Поллард опубликовал исследование влияния метрик Web Vitals на производительность веба в целом — "Have Core Web Vitals made the web faster?".

Внедрение метрик Core Web Vitals (CWV) по данным Google дало положительный эффект. По сравнению с прошлым годом количество сайтов, удовлетворяющих CWV, увеличилось более чем на 20%. Однако Барри пишет о том, что сложно судить о динамике изменения метрик, если их определения за последний год претерпели значительные изменения. Именно это произошло с метриками LCP и CLS.

Более непредвзятую оценку может дать HTTPArchive. Данные семи миллионов сайтов показывают небольшое падение производительности за прошедший год (вывод сделан на основе изменения SpeedIndex). Но и это то же не конец истории, так как HTTPArchive собирает данные заглавных страниц сайтов, что может значительно влиять на итоговую оценку.

Барри пишет про то, что ответ на вопрос про улучшение производительности веба лежит где-то посередине. Нельзя сказать, что благодаря CWV скорость веба улучшилась. Но введение CWV заставило владельцев крупных сайтов инвестировать ресурсы в улучшение производительности. Также крупные игроки (Wordpress, Wix) стали более серьёзно стали относиться к производительности благодаря добавлению показаний метрик CWV в алгоритм ранжирования поиска Google.

#performance #research

https://calendar.perfplanet.com/2021/have-core-web-vitals-made-the-web-faster/

Тюнинг производительности Next.js-приложений

Бен Шварц поделился рекомендациями по улучшению производительности Next.js-приложений — "Next.js Performance: Making a Fast Framework Even Faster".

Для загрузки сторонних скриптов рекомендуется использовать компонент next/script со стратегией lazyOnload, чтобы код начинал грузиться тогда, когда завершается загрузка основного кода приложения. Для вставки изображений рекомендуется использовать компонент next/image. Он берёт на себя конвертацию изображений, генерацию плейсхолдеров и поддержку ленивой загрузки. Для уменьшения размера основного бандла приложения можно использовать динамическую загрузку кода с помощью import(). Для динамической загрузки React-компонентов — хелпер next/dynamic.

Полезная статья. Рекомендую почитать, если работаете с Next.js.

#jsframeworks #performance #react

https://calibreapp.com/blog/nextjs-performance

Новые метрики для измерения отзывчивости сайтов

Разработчики Chrome уже более полугода работают над добавлением новых метрик, отвечающих за измерение отзывчивости сайтов. Хонгбо Санг рассказывает, как их можно подсчитать — "Hands On with the new Responsiveness Metrics".

В Core Web Vitals за отзывчивость страницы отвечает метрика First Input Delay. FID показывает величину задержки между пользовательским событием и временем, когда это событие начинает обрабатываться. У этой метрики много ограничений: оно показывает время задержки только первого события, оно не включает в себя время обработки события, с её помощью нельзя понять, лагает ли страница.

В новых экспериментальных метриках измеряется время обработки взаимодействий пользователя (interactions) на протяжении всей жизни страницы. Взаимодействие — это комбинация логически связанных DOM-событий. Например, для нажатия кнопки на клавиатуре такими событиями будут keydown, keypress и keyup.

На данный момент ещё нет окончательного списка метрик отзывчивости, так как у разных вариантов есть свои плюсы и минусы. В статье есть ссылка на код, который можно запустить в DevTools, чтобы получить все метрики, которые находятся на рассмотрении. Также есть экспериментальный плагин для Lighthouse для получения этих метрик.

Разработчики просят посмотреть результаты метрик на своих сайтах и оставить фидбек.

#performance #metrics

https://calendar.perfplanet.com/2021/hands-on-with-the-new-responsiveness-metrics/

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

Эрик Бейли призывает тестировать сайты на слабых устройствах — "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/