Какие способы оптимизации приложения кроме изменения размеров элементов

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

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

Как отвечать

Начните с измерения: Lighthouse и панель Performance в DevTools для лабораторных замеров, данные реальных пользователей через Core Web Vitals. Порог «хорошо»: LCP до 2,5 с, INP до 200 мс, CLS до 0,1. Дальше приёмы по группам.

Загрузка:

• меньше JavaScript: разделение кода по маршрутам через динамический import(), tree shaking, анализ бандла (webpack-bundle-analyzer, rollup-plugin-visualizer), замена тяжёлых библиотек;
• сжатие и кэш: Brotli или gzip на сервере, имена файлов с хэшем и Cache-Control: max-age=31536000, immutable, CDN для статики;
• приоритеты: preload для критичного шрифта, fetchpriority="high" для картинки LCP, defer для скриптов, font-display: swap;
• картинки: AVIF и WebP, srcset, loading="lazy" для всего ниже первого экрана, явные width и height против сдвигов вёрстки.

Работа в рантайме:

• без принудительного layout: не чередовать чтение offsetHeight и запись стилей в цикле, анимировать transform и opacity;
• длинные списки: виртуализация, content-visibility: auto;
• главный поток: дробить длинные задачи, тяжёлые вычисления уносить в Web Worker, частые события обрабатывать с debounce или throttle;
• фреймворк: лишние перерисовки в React показывает Profiler, лечатся они memo, useMemo или React Compiler.

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

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

Вешают loading="lazy" на главную картинку первого экрана. Браузер откладывает её загрузку, и LCP становится хуже, а не лучше.

Оптимизируют вслепую, без замера до и после. Без цифр нельзя ни доказать эффект, ни заметить, что useMemo на каждой строке только добавил работы.