Page Speed: комплексная оптимизация скорости загрузки сайта

Page Speed — одна из самых выгодных инвестиций сразу в SEO и конверсию. Amazon подсчитал: каждые 100 мс дополнительной задержки стоят 1% продаж. Google учитывает скорость как фактор ранжирования для десктопа с 2010 года и для мобильных с 2018, а в 2021 году ввёл Core Web Vitals как прямой сигнал Page Experience.

zoom_in

Что такое Page Speed и как его измеряют

Page Speed — это не одно число, а набор метрик. Каждая описывает свой аспект загрузки. PageSpeed Insights от Google объединяет лабораторные данные (Lighthouse) и полевые данные реальных пользователей (Chrome User Experience Report). Итоговый балл от 0 до 100 — взвешенная сумма нескольких метрик. Не делайте его единственной целью оптимизации.

Для SEO важны полевые данные (CrUX). Google оценивает Core Web Vitals по 75-му перцентилю реальных пользователей Chrome. Lighthouse помогает найти проблемы, но не является прямым входом в алгоритм ранжирования.

Ключевые метрики скорости

Каждая метрика отвечает за свой аспект пользовательского опыта. Чтобы верно поставить диагноз, нужно понимать разницу между ними.

Диагностика: с чего начать оптимизацию

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

1. Откройте PageSpeed Insights и проверьте 5–10 ключевых страниц: главную, категории, карточки товаров, лендинги. Смотрите на Field Data, а не только на оценку Lighthouse.
2. В Google Search Console откройте раздел Core Web Vitals. Он покажет, у каких URL статус «Poor» или «Needs improvement» по LCP, INP и CLS по реальным данным пользователей.
3. Для глубокого анализа запустите WebPageTest: waterfall загрузки, filmstrip, TTFB, влияние CDN. Выберите регион тестирования, ближайший к основной аудитории.
4. Откройте Chrome DevTools → Performance и запишите загрузку страницы. Flame chart покажет, какой скрипт занимает основной поток и блокирует рендеринг.
5. Проверьте Coverage (DevTools → Coverage): неиспользуемый CSS и JS — прямые кандидаты на удаление или отложенную загрузку.

Оптимизация сервера и TTFB

TTFB (Time to First Byte) — основа всей скорости. Если сервер отвечает медленно, любые последующие оптимизации упираются в искусственный потолок. Цель: TTFB < 200 мс для окружений с CDN и < 400 мс для динамических серверов.

Хостинг и инфраструктура

Выбор хостинга

Shared-хостинг делит ресурсы между тысячами сайтов, и это физически ограничивает TTFB. VPS или выделенный сервер с Nginx/Caddy и правильным кэшированием даёт TTFB 20–80 мс для статики.

CDN (Content Delivery Network)

Cloudflare, BunnyCDN, Fastly: ближайший edge-узел отвечает вместо вашего origin-сервера. Для статики и закэшированного контента TTFB падает до 10–50 мс. Для динамического контента всё зависит от настроек edge-кэша.

HTTP/2 и HTTP/3 (QUIC)

HTTP/2 устраняет head-of-line blocking и поддерживает мультиплексирование. HTTP/3 поверх QUIC ускоряет установку соединения (0-RTT) и устойчив к потерям пакетов в мобильных сетях.

Геолокация сервера

Физическое расстояние между пользователем и сервером добавляет около 1 мс на каждые 100 км (round trip). Для аудитории из Европы сервер во Франкфурте или Амстердаме заметно быстрее, чем в US-East.

Сжатие и кодирование

• Включите Brotli (br): он экономит 15–25% по сравнению с gzip при сопоставимой скорости распаковки. Поддерживается всеми современными браузерами.
• Оставьте gzip как запасной вариант для старых клиентов. Минимальный уровень сжатия — 6.
• Настройте сжатие для HTML, CSS, JS, JSON, XML и SVG. Изображения и бинарные файлы уже сжаты, и gzip к ним не даст эффекта.
• Передавайте заголовок Vary: Accept-Encoding, чтобы CDN хранил отдельные версии для разных клиентов.

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

Динамические страницы (PHP, Node.js, Python) при каждом запросе обращаются к базе данных. Кэш позволяет отдавать готовый HTML без повторных вычислений.

• Кэш всей страницы: Nginx FastCGI Cache, Varnish, Redis. Они хранят готовый HTML и отдают его, не обращаясь к приложению.
• Объектный кэш: Redis или Memcached для результатов запросов к БД, сессий и вычисленных данных.
• Правила инвалидации: кэш нужно сбрасывать при изменении контента (вебхук CMS или истечение по TTL).
• Stale-while-revalidate: сразу отдать устаревший кэш и обновить его в фоне. Пользователь не ждёт пересборки.

Оптимизация активов: изображения, шрифты, CSS

Изображения

Изображения обычно самая тяжёлая часть веса страницы. Правильная оптимизация даёт экономию трафика 30–70% и напрямую влияет на LCP.

Используйте элемент <picture>, чтобы отдавать нужный формат: AVIF — поддерживающим браузерам, WebP — как запасной вариант, JPEG/PNG — старым браузерам. Компонент Next.js Image делает это автоматически.

Шрифты

• Self-host шрифтов: отдавайте .woff2 со своего домена. Так уходят DNS-запрос, TCP-рукопожатие и зависимость от CDN Google Fonts.
• Preload критичных шрифтов: <link rel="preload" as="font" type="font/woff2" crossorigin> в <head>. Браузер начнёт загрузку до разбора CSS.
• font-display: swap — браузер показывает системный шрифт, пока загружается свой. Так исчезает FOIT (невидимый текст).
• Subset шрифта: грузите только нужные глифы (латиница и кириллица). Инструменты: glyphhanger или fonttools.
• Variable fonts — один файл вместо нескольких начертаний (regular, bold, italic). Экономия 30–50% суммарного размера шрифтов.

CSS

Критический CSS (inline)

Стили «выше сгиба» встраиваются прямо в <head> внутри тега <style>. Браузер отрисовывает первый экран без ожидания внешнего CSS-файла, а остальной CSS грузится асинхронно.

Минификация

Удаление пробелов и комментариев, сокращение свойств. Инструменты: Cssnano или LightningCSS. Типичная экономия — 10–30% исходного размера.

Удаление неиспользуемого CSS

PurgeCSS, UnCSS или встроенный механизм фреймворка (purge в Tailwind). Особенно важно, когда подключены Bootstrap или Material UI: они тянут тысячи неиспользуемых правил.

Не используйте @import в CSS

CSS @import создаёт последовательные запросы: браузер загружает файл, находит @import и только потом начинает загружать следующий. Для параллельной загрузки используйте теги <link>.

JavaScript: блокировка рендеринга и основной поток

JavaScript — главный враг скорости загрузки на современных сайтах. Он блокирует рендеринг, занимает основной поток и откладывает интерактивность. Цель: минимум JS в критическом пути и максимум defer, async и динамического import.

Стратегии загрузки

Бандл и разбиение кода

• Code splitting: разбивайте JS на чанки и грузите только то, что нужно текущей странице. В Next.js это происходит автоматически для каждой страницы.
• Dynamic import: import('module') для компонентов, которые не нужны при первой загрузке (модальные окна, вкладки, фильтры).
• Tree shaking: в бандл попадает только реально используемый код. Webpack и Rollup делают это для ESM-пакетов. Проверьте, нет ли CommonJS-зависимостей, которые ломают tree shaking.
• Анализ бандла: bundlephobia.com показывает вес npm-пакетов, @next/bundle-analyzer — для Next.js. Видно, что именно занимает место.
• Избегайте крупных монолитных библиотек: moment.js (67 КБ) → day.js (2 КБ), lodash → отдельные утилиты, jQuery → нативный JS.

SPA и серверный рендеринг

Клиентские SPA (React без SSR, Angular, Vue с CSR) отдают пустой HTML и формируют контент в браузере. Из-за этого LCP растёт, а Time to Interactive ухудшается.

SSR (Server-Side Rendering)

Полный HTML формируется на сервере, и браузер сразу получает готовый контент. LCP, FCP и Lighthouse Score заметно улучшаются. Нужна гидратация на клиенте, поэтому учитывайте TTI (Time to Interactive).

SSG (Static Site Generation)

HTML формируется на этапе сборки. Максимальная скорость TTFB и LCP. Подходит для контента, который меняется редко: блог, документация, лендинги.

PPR (Partial Prerendering)

Новинка Next.js 15: статическая оболочка страницы и потоково подгружаемые динамические части. Оболочка отдаётся с CDN мгновенно, а динамические данные доходят по мере готовности.

Кэширование: браузер и CDN

Правильно настроенный кэш — самая дешёвая оптимизация с максимальным эффектом для повторных визитов. Цель: все статические активы кэшируются на год, а HTML кэшируется минимально или не кэшируется вовсе.

• Content-based hashing (fingerprinting): Webpack, Vite и Next.js автоматически добавляют к имени файла хеш содержимого. Изменился код — новый хеш, и старый кэш не используется.
• ETag и Last-Modified: если у клиента уже есть ресурс, сервер отвечает 304 Not Modified без тела. Трафика меньше, но сетевая задержка всё равно есть.
• Service Worker: программируемый кэш в браузере. Позволяет строить сложные стратегии (Cache-First, Network-First, Stale-While-Revalidate) для PWA и офлайн-работы.
• CDN Cache-Control: используйте s-maxage, чтобы управлять кэшем CDN отдельно от браузерного max-age. CDN кэширует дольше, браузер — меньше.

Сторонние скрипты: главный скрытый тормоз

Сторонние скрипты (аналитика, чат-боты, пиксели, A/B-тестирование, виджеты) часто становятся главной причиной высокого TBT и INP. В среднем коммерческая страница загружает 15–30 сторонних скриптов.

Частые вопросы