Но количество случаев, когда оно медленное, повысится:

И, причём, понять, в какие именно моменты времени приложение затормозит, сложно.

В следующий раз вместо styled-components попробуйте, например, Linaria. У Linaria похожее API, но она генерирует стили во время билда и от таких проблем не страдает. (В комментариях часто жалуются на какие-то проблемы с Linaria, но мне последние версии нравятся.)

Ещё по теме: https://calendar.perfplanet.com/2019/the-unseen-performance-costs-of-css-in-js-in-react-apps/

Как пользоваться реакт-профайлером

Профайлер можно сделать ещё полезнее.

Откройте настройки React DevTools → Profiler и включите «Record why each component rendered while profiling». После этого профайлер начнёт записывать и показывать, почему каждый компонент перерисовался:

<link rel="preload"> и шрифты

Если используете <link rel="preload"> для шрифтов, проверьте, чтобы у вас не грузилось лишнего.

Вот пример, где всё хорошо:

<style>
@font-face {
 font-family: "Roboto";
 font-weight: 400;
 src: url("./roboto-400.woff2") format("woff2");
}
@font-face {
 font-family: "Roboto";
 font-weight: 500;
 src: url("./roboto-500.woff2") format("woff2");
}
</style>

С такими стилями (без <link rel="preload">) браузер загрузит только те файлы шрифта, которые ему нужны. Если на странице не используется Roboto с насыщенностью 500, браузер его просто не загрузит.

Вот пример, где, может, всё хорошо, а, может, и нет:

<link rel="preload" href="./roboto-400.woff2" as="font" />
<link rel="preload" href="./roboto-500.woff2" as="font" />
<style>
@font-face {
 font-family: "Roboto";
 font-weight: 400;
 src: url("./roboto-400.woff2") format("woff2");
}
@font-face {
 font-family: "Roboto";
 font-weight: 500;
 src: url("./roboto-500.woff2") format("woff2");
}
</style>

С таким кодом браузер начнёт грузить шрифты раньше, чем разберётся, какие именно ему шрифты нужны. Из-за этого, даже если страница не использует Roboto 500, этот файл всё равно скачается (и заберёт трафик у более важных ресурсов).

«А зачем вообще <link rel="preload"> в этом случае? Тут же инлайн-стили, разве браузер не начнёт загружать шрифты сразу же?»

Не начнёт. Чтобы начать загружать шрифты, браузеру нужно сначала понять, какие шрифты используются на странице. Для этого ему приходится:
— скачать все внешние стили (если они есть)
— построить CSSOM (= дерево стилей)
— разобраться, к каким элементам на странице какие стили применимы

Это занимает от 50-100 мс (если внешних стилей нет) до 1000+ (если они есть). В итоге шрифты начинают грузиться позже.

В отличие от этого, <link rel="preload"> ставится в очередь на загрузку сразу же, как только распарсится HTML-парсером (даже немного раньше).

«Окей, а что тогда использовать, если <link rel="preload"> не ок?»

Если вы пытаетесь загрузить шрифт поскорее, потому что он скачет и повышает CLS, попробуйте вместо этого font-display: optional

Любимая Вебня пишет, что в браузерах скоро появится функция window.structuredClone(), но не поясняет, почему это классно.

TL;DR: structuredClone — это как _.cloneDeep(), но из коробки и быстрее.

Структурное клонирование
Сейчас есть плюс-минус два способа склонировать объект:
— _.cloneDeep(obj) и
— JSON.parse(JSON.stringify(obj))

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

В то же время браузеры уже много лет умеют клонировать объекты внутри себя. Например, если сделать

const a = { b: { c: 5 } }
history.pushState(a, document.title)
a.b.c = 6

то в истории всё равно останется объект { b: { c: 5 } }. Браузер склонирует объект a перед тем, как сохранить его в историю. Это называется «структурное клонирование» («structured clone»).

Хаки
Получается, сейчас структурное клонирование доступно в разных браузерных API типа history.pushState или postMessage, но нигде не выставлено наружу. В итоге, если вам надо склонировать объект, но вы не можете подключить lodash, приходится писать что-то такое:

const oldState = history.state;
history.replaceState(obj, document.title);
const copy = history.state;
history.replaceState(oldState, document.title);
return copy;

(Плиз, не делайте так.)

Что теперь
Теперь в спеке есть функция structuredClone(). Она делает то же, что и _.cloneDeep(), но без подключения внешних библиотек и (как минимум в Deno) быстрее.

В браузерах прогресс реализации можно отслеживать по implementation-багам. А в Deno self.structuredClone() реализовали уже вчера ↓

First Input Delay (FID) в двух картинках

Понадобилось объяснить, как работает FID. Вышло две картинки:

1) Что такое Input Delay

2) Почему First

«А что это вообще такое?»
First Input Delay — это один из Core Web Vitals. Если у страницы плохой FID¹, страница будет хуже ранжироваться в Google.

У Google есть самый подробный референс по этой теме: https://web.dev/fid/

¹ — Плохой FID, правда, встречается очень редко. Свой FID можно посмотреть в PageSpeed Insights → раздел Field Data или в Search Console

Оказывается, Shadow DOM ускоряет перевычисление стилей (но только если селекторы в стилях сложнее, чем просто ID или класс): https://nolanlawson.com/2021/08/15/does-shadow-dom-improve-style-performance/

(А ведь когда-то похожее делал <style scoped>. Помянем.)