2️⃣ На перформанс-балл в Lighthouse не влияют рекомендации. Перформанс-балл зависит только от метрик: https://github.com/GoogleChrome/lighthouse/blob/master/docs/scoring.md

Это значит, что рекомендации типа «удалите неиспользуемый CSS» — это просто рекомендации. Не надо оптимизировать специально под них.

А ещё, у TTI самый большой вес среди всех метрик. Из-за этого JS влияет на балл не меньше скорости рендера. В общем, SSR/статика — это хорошо, но не забывайте и про бандл

3️⃣ В Lighthouse 6 (который скоро выйдет) поменяется расчёт перформанс-балла: https://web.dev/performance-scoring/

Как это скажется на реальных сайтах, я пока не понимаю — покажет практика. Кажется, общий балл сильно поменяться не должен, но акцент на времени рендера станет чуть больше.

— В npm уже есть lighthouse@next с новым алгоритмом подсчёта
— А калькуляторе Пола Айриша можно поиграться с этим алгоритмом вживую: https://paulirish.github.io/lh-scorecalc/

***

4️⃣ В юникоде нет эмодзи маяка. Когда пишешь твиты про Lighthouse, приходится грустить.

Вышла запись моего доклада на fwdays’20 (на русском).

30 минут, 37 инструментов (200 не влезло!), webpack:

Підбили підсумки онлайн-конференції JavaScript fwdays'20 та готові поділитися топ 3 доповідей від 14 березня за голосуванням учасників 🤩

1️⃣Іван Акулов "Я перепробував 200 webpack-плагінів для перформансу"

2️⃣Вадим Макєєв "HTML: The Good Parts"

3️⃣Martin Splitt "How Google Search renders the web - a look behind the curtain"

Посилання на доповіді:
👉 https://www.youtube.com/playlist?list=PLPcgQFk9n9y97vTsPnvpzDXBTLe0l1JDI

​​Дэн Лу (инженер в NVIDIA) написал статью про скорость старых и новых компьютеров:

— Почему Apple 2E (1983) вводит текст в три раза быстрее, чем MacBook Pro (2014)
(Cпойлер: во многом потому, что компьютеры и ОС сегодня гораздо сложнее, чем 30 лет назад — но эта сложность полезная)

— Как обрабатывается ввод в современных устройствах (на примере iPhone) и где там появляются задержки

— Почему даже новые Android-телефоны скроллят контент медленнее, чем iPhone 4s
(Cпойлер: из-за монополиста-производителя CPU и плохих бенчмарков. Кстати, скоро это может измениться)

Пост хорошо читается после Software Disenchantment Никиты Прокопова — да, современные компьютеры медленные, но не столько потому, что «мы стали делать говно», сколько по вполне понятным причинам реального мира.

🔗 https://danluu.com/input-lag/

​​Coverage
Моя любимая фича в девтулзах Хрома: узнать, сколько кода в бандле используется при загрузке страницы.

Как запустить: открыть приложение → в девтулзах нажать Ctrl/⌘+Shift+P → набрать «coverage» → нажать «Start instrumenting»

У инстаграма, например, 49% JS-а при первой загрузке не используется:

Важно: не используется ≠ не нужен. Там может быть что-то, что понадобится через минуту после загрузки.

Но если у вас не используется 75+%, скорее всего, вам стоит сделать код-сплиттинг → https://3perf.com/talks/web-perf-101/#js-code-splitting-1

Читатели добавляют, что если кликнуть на сам файл, то видно, какой именно код не используется. Я не знал!

Lighthouse 6 вышел, ура! Пока только в npm и Chrome Canary, но скоро раскатится и на PageSpeed Insights → https://web.dev/lighthouse-whats-new-6.0/

Главные изменения:
— Перформанс теперь считается через другие метрики
— Для эмуляции мобильного используется Moto G4 вместо Nexus 5X
— Появились экспериментальные рекомендации на основе соурс-мапов

Сравнить перформанс сайта в v5 и v6:

# v5
npx -p lighthouse@5 lighthouse https://3perf.com --view
# v6
npx -p lighthouse@6 lighthouse https://3perf.com --view

Ю-ху, вышла новая большая кейс-стади про перформанс Notion-а!

Разбираемся, как ускорить запуск Реакт-приложения на ~30%, просто подтюнив конфиги и отсрочив часть кода.

Внутри:
— как переход на СommonJS-модули может (внезапно) ускорить инициализацию бандла
— как находить и удалять неиспользуемые зависимости
— как откладывать аналитику до полного запуска приложения (и почему requestIdleCallback тут не подходит)
и ещё много чего.

→ https://3perf.com/blog/notion/

Любимая находка: оказывается, если в вашем бандле 1100 модулей, то только __webpack_require__() — вебпаковская обёртка вокруг import — займёт 25% всего времени инициализации ↑

Фреймворки в веб-воркере

Веб поддерживает многопоточность (с помощью веб-воркеров) уже 10 лет. Тем не менее, весь JS, который мы пишем, по-прежнему обычно работает только в главном потоке. Из-за этого любые долгие операции блокируют всю страницу намертво.

Крутым решением было бы научить React, Vue, Svelte и т.п. работать из веб-воркеров — а в главном потоке оставить только обновление DOM. Шабхи Паникер из команды Chrome исследует этот подход (и другие) и пишет, почему сегодня это нереалистично: https://docs.google.com/document/d/1nu0EcVNC3jtmUVWL8Gs5eCj2p_984kamNhG2nS9gOC0/edit

webp в Safari

Если вы не используете webp из-за того, что он не поддерживается в Safari, то зря. Потому что есть целых два способа сделать так, чтобы все браузеры загружали webp, а Safari — jpeg/png.

1️⃣ Тег <picture>:

<picture>
  <source srcset="./image.webp" type="image/webp">
  <img src="./image.jpg" type="image/jpeg">
</picture>

↑ Такой код загрузит webp-файл везде, где он поддерживается (Chrome/Firefox) — и зафолбечится на jpeg-файл в остальных браузерах. (Больше про это)

2️⃣ CDN-ы

CDN-ы вроде Cloudflare или Cloudinary умеют конвертировать картинки в webp. Подключаете CDN — а он автоматически определяет, поддерживает ли браузер webp, и конвертирует картинку на лету. В Cloudflare это включается опцией Polish, в Cloudinary — параметром f_auto в урле.

<picture>
  <source srcset="./image.webp" type="image/webp">
  <img src="./image.jpg" type="image/jpeg">
</picture>

Кстати, а чтобы легко конвертировать картинки в webp (или просто сжимать png/jpeg), в чатике рекомендуют https://squoosh.app

Так, давайте про кеширование в браузерах.

🧊 Самые основы кеширования

Для управления кешированием есть аж 4 заголовка: Cache-Control, Expires, Last-Modified и ETag.

Как они работают? Какие выбрать? Как браузер общается с сервером, когда есть кеш? Про это — в моей старой (но всё ещё хорошей) статье: https://iamakulov.com/notes/caching/

​​💀 Что будет, если кеширование не настроить

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

И если вы не версионируете файлы — то есть ссылка на них у вас такая:

/static/script.js

а не такая:

/static/script.js?version=1.5.2
/static/script-a6c485.js

то это может сломать сайт:

Статья: https://paulcalvano.com/index.php/2018/03/14/http-heuristic-caching-missing-cache-control-and-expires-headers-explained/
Саммари: https://t.me/iamakulov_channel/304