​​⚡️ Chrome 85 начнёт помечать быстрые сайты меткой «Быстрый»: https://blog.chromium.org/2020/08/highlighting-great-user-experiences-on.html

Скорость будет считаться на основе Core Web Vitals. А данные по Web Vitals, видимо, браться из Chrome UX Report.

Метка пока будет только в контекстном меню, но дальше стоит ждать большего.

Утечки памяти в Node.js

Неделю назад впервые отлаживал утечки памяти в Node.js-скрипте. Узнал несколько интересных флагов:

--max_old_space_size
Увеличивает размер old space в Node.js. Old space — это место, где Node.js хранит почти все объекты, созданные в приложении.

На 64-битных системах old space по умолчанию ограничен 1400 мб (--max_old_space_size=1400). Если вы попробуете занять 1405 мб, приложение просто упадёт.

Поэтому, если, например, webpack выедает слишком много памяти и падает, самый простой способ справиться с этим — это увеличить old space этим параметром. Вот так:

node --max_old_space_size=4096 ./node_modules/.bin/webpack

​​--expose_gc

С этим флагом в приложении появляется новая глобальная функция: gc(). Если вызвать gc(), то Node.js приостановится и принудительно соберёт весь мусор, скопившийся к моменту вызова.

Полезно, чтобы понять, это у вас реально память где-то течёт, или garbage collector просто слишком ленивый и ещё не собрал её.

​​--trace_gc

С --trace_gc Node.js начнёт логгировать все вызовы сборщика мусора. Так как они происходят часто, с этим флагом удобно следить за тем, как быстро увеличивается память:

Как ещё дебажить память в Node.js:
— Все Node.js-флаги, которые настраивают сборщик мусора → https://gist.github.com/listochkin/10973974
— Heap snapshot в девтулзах → https://developers.google.com/web/tools/chrome-devtools/memory-problems/heap-snapshots
— Allocation profiler в девтулзах → https://developers.google.com/web/tools/chrome-devtools/memory-problems/allocation-profiler

А также хочу напомнить, что я всегда открыт как-то помочь или что-то подсказать про перформанс или карьеру. Не стесняйтесь писать!

→ В чатик канала (там ваш вопрос может пригодиться кому-то ещё): @iamakulov_channel_chat
→ Или просто в личку: @iamakulov

💛

✨ Статья про <link rel=preload>-ы обновилась! Теперь, кроме preload, prefetch, preconnect, dns-prefetch и prerender, там ещё и modulepreload.

<link rel="modulepreload"> помогает предзагружать ES-модули. Это нужно, если вы используете ES-модули в продакшене. modulepreload помогает загрузить всё дерево модулей сразу же, а не водопадом:

Как <link rel="modulepreload"> работает и в чём отличие от обычного <link rel="preload"> → https://3perf.com/blog/link-rels/#modulepreload

​​Как ускорить билд в сто раз
Пару месяцев назад открыл для себя бандлер ESBuild. ESBuild умеет бандлить JS и TS и написан на Go. Это помогает ему быть во 50-100 раз быстрее, чем webpack.

Сейчас я помогаю клиенту перевести сборку с webpack на ESBuild, чтобы ускорить билд. И просто сравните ↓

(В обоих случаях один и тот же код, несколько энтри-поинтов, минификация и соурс-мапы)

​​Другой клёвый тул из этой же сферы — это компилятор swc (написан на Rust).

В отличие от ESBuild, swc не умеет бандлить, поэтому это скорее замена для Babel, чем для webpack. Это и минус, и плюс:
— заменить им весь build pipeline и ускорить сборку в сто раз не выйдет
— но попробовать его гораздо проще — достаточно поменять babel-loader на swc-loader

Недостаток — оба тула пока что сыроваты.
— ESBuild всё ещё не поддерживает CSS loader (хотя работа над этим уже началась)
— Swc, когда я его пробовал в мае, иногда генерировал некорректный код (пример). Не знаю, как с этим сейчас

Но, учитывая скорость развития, месяца через три они могут быть вполне production-ready.
→ ESBuild: github.com/evanw/esbuild
→ Swc: github.com/swc-project/swc

В чатике добавляют ссылки:

1) Как ESBuild достигает ускорения в 50-100 раз (TL;DR: минимум проходов по AST-дереву, минимум ненужной работы, максимум параллелизации): Architecture.md

2) Оказывается, swc работает и над бандлингом: ишью · код · бенчмарки

(И поправляют, что swc развивается сильно медленнее, чем мне показалось, и production-ready через три месяца — это вряд ли. Спасибо за поправку! За ESBuild я следил больше.)

Как растить JS-скиллы
В личке спросили, как вырастить свои навыки в JavaScript.

Мой любимый способ — это подписаться в GitHub на инструмент, который вы используете каждый день (типа Babel или webpack).

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

Года три назад я таким образом зафолловил репозитории React и Redux — и благодаря этому узнал кучу всего, чего не нашёл бы ни в документации, ни в статьях.

Third parties

Одна из вещей, которая влияет на балл в Lighthouse — это third parties (аналитика и реклама).

Third parties часто выполняют много JS-а. Это блочит главный поток и ухудшает JS-метрики в Lighthouse (Time to Interactice, Total Blocking Time, First Input Delay).

Что делать, если у вас много third parties, и они мешают вам быть быстрыми👇

​​1️⃣ Проверьте, все ли third parties реально нужны (серьёзно)

Очень часто случается, что маркетинг добавляет какую-то аналитику, использует её неделю-месяц-полгода, а потом перестаёт. А аналитика остаётся.

Чтобы увидеть все third parties, пройдите в DevTools → Network, отфильтруйте по -domain:ваш-домен и посмотрите, есть ли что-то ненужное в колонке Domain:

(А также посмотрите доклад Гарри Робертса про то, как обсуждать third parties с маркетинг-командой. Придётся вести переговоры!)

​​2️⃣ Оберните в таймер

Некоторые third parties можно спокойно загрузить позже — без потерь для бизнеса.

Например:

Маркетологам часто ок отложить загрузку Facebook Pixel на 10-20 секунд. (Facebook Pixel используется, чтобы показывать рекламу тем, кто побывал на сайте — и привести их на сайт снова.)

Посетители, которые закрыли сайт через 10 секунд, часто для такой рекламы неинтересны. Так что если Pixel не успеет их затрекать, бизнес ничего не потеряет.

​​3️⃣ Отложите до полной загрузки сайта

Бывает, что third-party-скрипт загружается раньше, чем приложение. Такой скрипт может начать выполнять много JS-а и забрать на себя главный поток страницы. Из-за этого приложению придётся дожидаться своей очереди.

Чтобы избежать этого, попробуйте загружать third parties после того, как приложение инициализируется. Например, если у вас Реакт, оберните их в useEffect: