Что такое критичные ресурсы при загрузке страницы и как они загружаются
Что проверяют
Представляете ли вы критический путь рендеринга: что именно задерживает первый показ, а что только кажется важным. Это база для разговора о метриках загрузки и о том, зачем в проекте preload, defer и инлайн стилей.
Как отвечать
Критичные ресурсы это то, без чего браузер не может отрисовать первый экран: сам документ, CSS, которым он размечен, синхронные скрипты и шрифты видимого текста. Порядок такой: приходит HTML, парсер строит DOM и по пути натыкается на ссылки.
CSS блокирует рендеринг: пока таблица стилей не загружена и не разобрана, дерево рендеринга не строится, иначе страница мигнула бы нестилизованным текстом. Заодно CSS задерживает выполнение скриптов, потому что скрипт вправе спросить вычисленный стиль.
Обычный script блокирует парсер целиком. С атрибутом defer файл качается параллельно, а выполняется после окончания разбора документа и в порядке объявления. С async тоже качается параллельно, но выполняется сразу по готовности, прерывая парсер, поэтому async годится независимым счётчикам, а не коду приложения.
Дальше называем рычаги: критический CSS инлайном в head, остальное отложить, preload для шрифта и картинки первого экрана, preconnect до чужого домена, font-display со значением swap, разрезание бандла вместо одного файла.
Где спотыкаются
Записывают изображения в блокирующие. Картинка не задерживает первую отрисовку, но именно она обычно и есть LCP, поэтому ей поднимают приоритет, а ленивую загрузку вешают только на то, что ниже первого экрана.
Считают, что defer откладывает загрузку до конца отрисовки. Скачивание идёт параллельно с разбором документа, откладывается только выполнение, и на этом различии держится вся разница с async.
Сводят оптимизацию к минификации и склейке всего в один файл. Современный протокол тянет много запросов параллельно, а огромный общий бандл ломает кеширование и втаскивает в первый экран код, который там не нужен: порядок и приоритеты важнее суммарного веса.