Чек-лист оптимизации скорости сайта для разработчика

Коротко: с чего начинать

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

1. Измерить — лабораторно и на реальных пользователях.
2. Найти самое узкое место — по метрикам LCP, INP, CLS и TTFB.
3. Исправить одно и перемерить.

Ниже — чек-лист по слоям. Для каждого пункта указано, чем его проверить.

Как измерять

• Lab-данные: Lighthouse и вкладка Performance в Chrome DevTools. Удобно для отладки, но это одна симуляция.
• Field-данные: отчёт Core Web Vitals в Google Search Console, CrUX или собственный сбор через библиотеку web-vitals. Это то, что видят реальные пользователи.
• Waterfall: вкладка Network в DevTools или WebPageTest — видно, что грузится, в каком порядке и что блокирует отрисовку.

Тестируйте с троттлингом сети и CPU: на быстром ноутбуке почти любой сайт кажется быстрым.

Сервер и ответ (TTFB)

• Кэшируйте HTML, где это возможно: статическая генерация, ISR, кэш на уровне CDN или reverse proxy.
• Проверьте медленные запросы к базе данных и внешним API на критическом пути рендера.
• Включите сжатие Brotli или gzip для текстовых ресурсов.
• Используйте HTTP/2 или HTTP/3 и CDN ближе к аудитории.

Чем проверить: TTFB в DevTools (Timing у документа), серверные логи и APM.

Сеть и кэширование

• Статика с хэшем в имени файла отдаётся с долгим Cache-Control: public, max-age=31536000, immutable.
• Для критичных сторонних доменов есть preconnect.
• Нет цепочек редиректов (http → https → www → итоговый URL).
• LCP-ресурс (обычно главное изображение) не обнаруживается поздно — при необходимости fetchpriority="high" или preload.

Изображения

• Современные форматы: WebP или AVIF.
• Адаптивные размеры через srcset и sizes.
• loading="lazy" для изображений ниже первого экрана — но не для LCP-картинки.
• Указаны width и height, чтобы не было сдвигов макета (CLS).

Чем проверить: Lighthouse («Properly size images», «Serve images in next-gen formats»).

JavaScript

• Проанализируйте бандл (bundle analyzer) и уберите тяжёлые и неиспользуемые зависимости.
• Code splitting: код страниц и тяжёлых виджетов грузится по требованию.
• Скрипты без критичной роли — с defer или async.
• Длинные задачи (long tasks) разбиты, тяжёлые вычисления вынесены на сервер или в Web Worker — это напрямую влияет на INP.

Чем проверить: Coverage и Performance в DevTools, отчёт «Reduce unused JavaScript».

CSS

• Неиспользуемые стили удалены (сборщик или инструменты вроде PurgeCSS/встроенный tree shaking фреймворка).
• Критический CSS для первого экрана не блокируется большим общим файлом.
• Нет тяжёлых анимаций свойств, вызывающих перерасчёт layout; анимируйте transform и opacity.

Шрифты

• Формат WOFF2, только нужные начертания и наборы символов (subsetting).
• font-display: swap или optional, чтобы текст не был невидим.
• Основной шрифт подгружается через preload или самохостинг.
• Подобраны fallback-метрики, чтобы подмена шрифта не давала CLS.

Сторонние скрипты

• Составьте список: аналитика, чаты, пиксели, виджеты. Удалите то, чем никто не пользуется.
• Загружайте их после основной отрисовки или по взаимодействию (например, чат — по клику).
• Встраиваемые видео и карты заменяйте лёгкой заглушкой-превью.

Чем проверить: «Reduce the impact of third-party code» в Lighthouse, группировка по доменам в Network.

Частые ошибки

• Оптимизировать по одному прогону Lighthouse вместо field-данных.
• Ставить loading="lazy" на главное изображение — LCP становится хуже.
• Менять десять вещей сразу и не понимать, что сработало.
• Забывать про мобильные устройства среднего уровня.