Где применяется знание critical rendering path и как оно влияет на производительность

Что проверяют

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

Как отвечать

Сначала коротко этапы: HTML разбирается в DOM, CSS в CSSOM, из них собирается дерево рендеринга, затем layout (геометрия), paint (пиксели по слоям) и composite (сборка слоёв на GPU). Затем главное, что блокирует:

• CSS: блокирует отрисовку. Браузер не покажет страницу, пока не построит CSSOM из стилей в <head>;
• классический <script>: блокирует парсер, а если перед ним подключён CSS, ещё и ждёт загрузки стилей;
• defer и type="module": качаются параллельно и выполняются по порядку после разбора документа; async выполняется сразу по загрузке, порядок не гарантирован;
• шрифты: без font-display: swap текст может остаться невидимым, пока шрифт грузится.

Где это применяется на практике: критический CSS инлайнится в <head>, остальное грузится отдельно; LCP-картинке ставят fetchpriority="high" и не вешают на неё loading="lazy"; к сторонним доменам делают preconnect; тяжёлые скрипты откладывают. Результат видно по Core Web Vitals: LCP (хорошо до 2,5 с), CLS и INP, который заменил FID. Смотрят в Lighthouse, во вкладке Performance в DevTools и в полевых данных CrUX.

Понимание пути нужно и после загрузки: чтение offsetHeight сразу после записи стилей вызывает принудительный синхронный layout, а анимация transform и opacity обходит layout и paint, остаётся только composite.

Где спотыкаются

Советуют склеить все файлы в один ради меньшего числа запросов. При HTTP/2 и HTTP/3 это уже не главное, а огромный общий бандл хуже кэшируется и дольше блокирует.

Ставят loading="lazy" на всё подряд, включая главную картинку первого экрана, и LCP проседает.

Путают async и defer, а зависимые друг от друга скрипты с async потом падают из-за порядка выполнения.