Какие действия по диагностике и оптимизации при долгой загрузке приложения?

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

Есть ли у вас системный подход: сначала по метрикам найти, что именно медленно, и только потом чинить. Следом обычно спрашивают про Core Web Vitals и про конкретный случай из вашей практики, где вы что-то ускорили.

Как отвечать

Разделите ответ на диагностику и меры. Диагностика:

• лаборатория и поле: Lighthouse и WebPageTest дают лабораторный замер, а реальных пользователей видно через RUM, библиотеку web-vitals или CrUX. Смотрят LCP (хорошо до 2,5 с), INP (до 200 мс), CLS (до 0,1) и TTFB;
• Network в DevTools: водопад запросов, блокирующие рендер CSS и скрипты, размер бандла, отсутствие сжатия и кэширующих заголовков;
• Performance: длинные задачи в главном потоке дольше 50 мс, гидратация, лишние ререндеры (React Profiler);
• анализ бандла: webpack-bundle-analyzer или аналог для Vite покажет, какая зависимость раздула сборку.

Меры по найденному:

• меньше JS: code splitting и import() для маршрутов и тяжёлых виджетов, tree shaking, замена громоздких библиотек;
• изображения: AVIF или WebP, srcset и sizes, loading="lazy" для того, что ниже первого экрана, и fetchpriority="high" для LCP-картинки;
• сеть: Brotli, HTTP/2 или HTTP/3, CDN, долгий Cache-Control для файлов с хэшем в имени, preconnect и preload для критичных ресурсов;
• рендер: SSR или SSG для первого экрана, критический CSS, шрифты с font-display: swap.

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

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

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

Опираются на один прогон Lighthouse с мощной машины. Лабораторная оценка и то, что видят пользователи на слабых телефонах, часто сильно расходятся.