Как получить готовый план по оптимизации лагающего сайта с помощью аудита фронтенда
Привет! Я Рома Игнатович, лид фронтенд-разработки в Далее. Обычно задача «ускорить сайт» без конкретики превращается в перебор гипотез вслепую. PageSpeed тут не спасет, потому что он показывает только симптомы — например, низкую скорость загрузки, нестабильную вёрстку, задержку кликов, — но не причины. За одинаковыми цифрами может стоять что угодно, от тяжёлых картинок до медленного бэкенда. Поэтому вместо точечных проверок я использую аудит фронтенда — он сразу сужает область поиска и помогает быстро составить план по доработкам.
Как проходит аудит
Смотреть можно без доступа к коду, во вкладке Performance в DevTools. Берём ключевой сценарий (например, флоу покупки) и записываем performance trace: скролл, клики, переходы, ввод — ищем долгие таски, блокировки потока, просадки анимаций. Параллельно смотрим Network waterfall (какие запросы блокируют остальные), рантайм и три метрики Web Vitals: LCP, TTFB, CLS. Для мультирегиональных продуктов пригодится WebPageTest — показывает поведение сайта из разных точек и с разным качеством соединения.
Проверять стоит не только на мощной машине: CPU throttling (4–6x) имитирует медленное устройство и вскрывает лаги, а network throttling на 3G/4G показывает, насколько критичны тяжёлые изображения и порядок загрузки. Сценарии прогоняем дважды — в норме и с throttling; если с throttling сайт деградирует критично, это уже не техдолг, а прямые потери конверсии.
После прогона получаем список проблем — и они часто бывают типовыми. Задача не просто найти лаг, а быстро понять, в какой зоне он лежит: в загрузке, в интерфейсе или в логике приложения.
Типичные проблемы и варианты их решений
Загрузка и контент:
весь код в одном бандле → браузер грузит и парсит всё сразу, плюс изображения по 20–30 МБ. Фикс: разбить на смысловые чанки, грузить по страницам и сценариям;
устаревшие форматы вместо WebP/AVIF, нет адаптивных размеров (srcset), грузятся элементы за пределами вьюпорта. Фикс: современные форматы + lazy loading;
высокий TTFB значит, что тормозит бэкенд, высокий LCP может быть где угодно. Фикс: проверяем бэкенд, настраиваем отправку первичного запроса при монтировании страницы.
Интерфейс и рендеринг:
расчёт анимаций на CPU вместо GPU, свойства вроде width/height/top/left вместо transform — браузер пересчитывает layout. Фикс: transform/opacity, но без перебора с will-change;
main thread перегружен синхронными операциями и тяжёлыми вычислениями. Фикс: распределять задачи параллельно, выносить тяжёлые операции из основного потока;
layout shift — не зарезервировано место под контент, не заданы размеры изображений и блоков. Фикс: фиксировать размеры заранее, skeleton-заглушки.
От аудита к бэклогу
Такой аудит даёт гипотезы, которые ещё нужно перевести на язык задач. Формулирую каждую находку как цепочку: проблема → гипотеза → действие. Например:
интерфейс подвисает при открытии карточки → долгие JS-задачи → разбить выполнение;
анимация лагает → расчёты идут на CPU → перевести на GPU через transform;
страница долго грузится → тяжёлые изображения → оптимизировать формат и размер.
У любой оптимизации — измеримая цель: например, LCP < 2.5 с, CLS < 0.1, снижение веса страницы на 30–40% и т. п.
Из действий собираю план: задачи ранжирую по эффекту и затраченным ресурсам — в приоритете то, что влияет на ключевые сценарии, конверсию и быстро чинится.
В итоге получается приоритизированный план с обоснованными гипотезами и задачами на доработку, который потом проверяется повторно — тестированием, бизнес-командой или новым техническим анализом.
Подробнее обо всех этапах пишу в большой статье на Workspace: читать здесь.