Скорость загрузки сайта: как ускорить и что измерять

Одна лишняя секунда загрузки — минус 7% конверсии. Это не теория, а данные Google/Deloitte по e-commerce. Скорость сайта влияет на ранжирование через Core Web Vitals и напрямую — через отказы: если страница не загрузилась за 3 секунды, 53% мобильных пользователей её покидают. Для большинства бизнесов ускорение сайта — одно из немногих SEO-улучшений, которое одновременно повышает трафик и продажи.

В этой статье — конкретные шаги ускорения: от изображений и кеширования до шрифтов, Critical Rendering Path, WordPress-плагинов, серверной оптимизации и мониторинга. Если нужен аудит производительности в рамках полного SEO-продвижения — обращайтесь к команде SEO-Factory.

Где измерять скорость сайта

PageSpeed Insights

Бесплатный инструмент от Google (pagespeed.web.dev). Показывает оценку от 0 до 100 для мобильной и десктопной версий, метрики Core Web Vitals (LCP, INP, CLS), и конкретные рекомендации. Использует реальные данные CrUX и лабораторные данные Lighthouse.

Google Search Console → Core Web Vitals

Показывает реальное состояние страниц сайта по данным реальных пользователей Chrome. Делит страницы на «хорошие», «требуют улучшения», «плохие». Наиболее точный индикатор того, как Google видит скорость вашего сайта — именно эти данные влияют на ранжирование. Полный гайд по работе с инструментом — в статье Google Search Console для SEO.

GTmetrix и WebPageTest

Детальный waterfall-анализ: видите каждый запрос, его размер и время загрузки. Полезно для поиска конкретных «тяжёлых» ресурсов — JavaScript бандлов, CSS файлов, изображений без lazy loading.

Оптимизация изображений

Изображения — самая частая причина медленной загрузки. На большинстве сайтов они занимают 60–80% от общего объёма страницы.

Формат

Переводите изображения в WebP. По сравнению с JPEG — меньший размер при том же качестве (на 25–35%). По сравнению с PNG — ещё большая экономия. Поддерживается всеми современными браузерами.

Размер

Не загружайте изображения шириной 2400px туда, где отображается 600px. Используйте атрибут srcset для адаптивной подачи разных версий под разные экраны.

Lazy loading

Добавьте атрибут loading="lazy" к изображениям ниже первого экрана. Браузер загрузит их только когда пользователь доскроллит до них.

Кеширование и сжатие

Gzip / Brotli сжатие

На уровне сервера включите сжатие текстовых ресурсов: HTML, CSS, JavaScript. Brotli (поддерживается Nginx, Apache) даёт лучший результат чем Gzip. Типичный эффект — уменьшение объёма JS/CSS-файлов на 60–70%.

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

Установите заголовки Cache-Control и Expires для статических ресурсов. Для CSS/JS-файлов, которые редко меняются — кеш на 1 год.

Минимизация файлов (minification)

Удалите пробелы, комментарии и лишние символы из CSS, JS и HTML. Autoptimize для WordPress, Webpack для JS-проектов. Уменьшение размера файлов — 10–30%.

Загрузка JavaScript и CSS

CDN и хостинг

CDN (Content Delivery Network) — сеть серверов по всему миру. Когда пользователь открывает ваш сайт, он получает файлы с ближайшего узла сети. Для сайтов с аудиторией в разных регионах — CDN сокращает TTFB на 40–60%.

Если CDN ещё не подключён — минимальный шаг: перейти на хостинг с SSD-дисками и Nginx вместо Apache.

Приоритеты: что ускоряет больше всего

Мобильная версия медленнее десктопной почти всегда. Но Google оценивает именно мобильный опыт — через Mobile-First индексацию. Оптимизируйте под мобильный в первую очередь.

Оптимизация шрифтов и иконок

Шрифты и иконочные наборы — один из наиболее часто упускаемых источников «лишнего» веса страницы. Они не бросаются в глаза как огромный баннер, но систематически замедляют рендеринг и ухудшают LCP.

font-display: swap — обязательный параметр

Без явного указания font-display браузер использует значение auto — в большинстве браузеров это означает block: текст невидим до 3 секунд, пока шрифт не загрузится. Это называется FOIT (Flash of Invisible Text) и напрямую ухудшает LCP, потому что Google считает текстовый блок «отрисованным» только когда он видим.

Решение — добавить в правило @font-face параметр font-display: swap. Браузер сразу показывает текст системным шрифтом, затем заменяет на кастомный после загрузки. Небольшой FOUT (Flash of Unstyled Text) при этом приемлем — текст читабелен с первой миллисекунды.

Альтернатива для минимального CLS — font-display: optional: браузер даёт шрифту очень короткий шанс (100ms), и если не успел — показывает системный навсегда при этом посещении. При повторных визитах шрифт берётся из кеша и подставляется без задержки. Это лучший выбор для показателей Core Web Vitals.

Preload для критических шрифтов

Даже при font-display: swap браузер обнаруживает шрифтовые файлы поздно — только при парсинге CSS. Чтобы загрузка шрифта начиналась как можно раньше, добавьте директиву preload в <head>:

<link rel="preload" href="/fonts/inter-v13-latin-regular.woff2" as="font" type="font/woff2" crossorigin>

Важно: preload только для шрифтов, реально используемых на странице (обычно 1–2 начертания). Preload всех шрифтов подряд создаёт конкуренцию за пропускную способность и может ухудшить LCP.

SVG-иконки против иконочных шрифтов

Icon fonts — FontAwesome, Material Icons — популярное решение, но с заметными недостатками для производительности. Каждый иконочный шрифт весит 50–200 KB, загружается как блокирующий ресурс, и на самом деле вы используете 10–20 иконок из тысячи доступных. Остальные — мёртвый груз.

SVG-иконки инлайном или через <use> из SVG-спрайта решают эту проблему:

• Inline SVG: иконка вшита прямо в HTML — нет дополнительного HTTP-запроса, нет блокировки рендеринга. Подходит для часто используемых иконок.
• SVG-спрайт: все иконки в одном SVG-файле, подключаемом через <use xlink:href="/icons.svg#icon-name">. Один запрос для всех иконок, браузерное кеширование.
• Subset иконочного шрифта: если FontAwesome всё же нужен — используйте только нужные иконки через FontAwesome Subsetting или IcoMoon для генерации минимального набора.

HTTP/2 и HTTP/3: влияние на скорость

Протокол передачи данных между браузером и сервером — не деталь инфраструктуры, а прямой фактор скорости. Разница между HTTP/1.1 и HTTP/2 в реальных условиях составляет 15–40% на время загрузки страниц с многочисленными ресурсами.

Проблема HTTP/1.1: очередь запросов

В HTTP/1.1 браузер может держать не более 6 параллельных TCP-соединений на один домен. Если страница загружает 50 ресурсов — CSS, JS, шрифты, изображения — они выстраиваются в очередь. Пока один запрос не завершён, следующий ждёт.

Разработчики обходили это через domain sharding (распределение ресурсов по нескольким поддоменам) — неэлегантно и с дополнительными DNS-запросами.

HTTP/2: мультиплексирование

HTTP/2 кардинально меняет модель: одно TCP-соединение, неограниченное количество параллельных запросов внутри него. Ресурсы загружаются без очереди. Дополнительные преимущества:

• Сжатие заголовков (HPACK): HTTP-заголовки в 1.1 передаются в текстовом виде при каждом запросе. HPACK сжимает повторяющиеся заголовки — экономия особенно заметна при множестве мелких запросов.
• Server Push: сервер может отправить клиенту ресурсы ещё до того, как тот их запросил. На практике Server Push используется редко из-за сложности настройки и риска отправки уже закешированных ресурсов.
• Приоритизация потоков: критические ресурсы (CSS, шрифты) могут получить более высокий приоритет, чем фоновые запросы.

HTTP/3 (QUIC): следующий уровень

HTTP/3 работает поверх QUIC — протокола на основе UDP вместо TCP. Это решает проблему «head-of-line blocking» в TCP: при потере пакета TCP блокирует весь поток до повторной передачи. QUIC изолирует потоки — потеря пакета в одном запросе не блокирует остальные.

Практические последствия:

• Более быстрое установление соединения (0-RTT для повторных посещений — данные отправляются с первым пакетом)
• Лучшая работа на нестабильных мобильных сетях (LTE → WiFi без разрыва соединения)
• Ощутимо более высокая скорость при packet loss выше 1–2%

Как проверить, работает ли HTTP/2 или HTTP/3

Самый простой способ — DevTools → Network → правый клик на заголовке таблицы → включить столбец «Protocol». Если видите h2 — HTTP/2 активен, h3 — HTTP/3. Также можно использовать WebPageTest.org — в деталях запроса отображается используемый протокол.

Для включения HTTP/2 на Nginx: параметр listen 443 ssl http2;. HTTP/3 требует отдельной конфигурации с quic и http3 в директивах listen, а также заголовка Alt-Svc для уведомления браузера. LiteSpeed Web Server поддерживает HTTP/3 из коробки без ручной конфигурации — это одна из причин его популярности для WordPress-хостинга.

Оптимизация шрифтов

Шрифты — часто недооценённый фактор скорости. Google Fonts удобны для подключения, но в стандартном варианте могут блокировать рендеринг — особенно на мобильных с медленным соединением.

Проблема Google Fonts и render-blocking

Стандартное подключение через <link> выполняет два внешних запроса: сначала к fonts.googleapis.com за CSS, затем к fonts.gstatic.com за файлами шрифтов. На медленном соединении это задерживает отображение текста. Эффект: FOIT (Flash of Invisible Text) — текст невидим до загрузки шрифта, что ухудшает LCP.

Self-hosting шрифтов

Размещение шрифтов на собственном сервере устраняет зависимость от внешнего CDN. Вместе с <link rel="preload"> браузер загружает шрифт как можно раньше:

<link rel="preload" href="/fonts/inter-v13-regular.woff2" as="font" type="font/woff2" crossorigin>

font-display: swap vs optional vs block

Минимизация начертаний и variable fonts

Каждое начертание — отдельный файл 15–50 KB. Regular 400 + Bold 700 — минимальный набор для большинства сайтов. Variable fonts (переменные шрифты) — один файл вместо нескольких начертаний. Например, Inter Variable охватывает все веса от 100 до 900 в одном файле ~60–80 KB — экономия до 50% объёма шрифтовых файлов при большем числе используемых начертаний.

Критический путь рендеринга (Critical Rendering Path)

Critical Rendering Path — последовательность шагов, которую браузер выполняет от получения HTML до отображения пикселей. Понимание этой последовательности позволяет целенаправленно оптимизировать первые секунды загрузки.

Последовательность: DOM → CSSOM → Render Tree → Layout → Paint

1. DOM — браузер парсит HTML и строит дерево элементов. Блокируется если встречает <script> без async/defer.
2. CSSOM — строится из CSS файлов. Рендеринг заблокирован до полной загрузки и парсинга всех CSS.
3. Render Tree — объединение DOM и CSSOM. Содержит только видимые элементы.
4. Layout — браузер вычисляет размеры и позиции всех элементов.
5. Paint — отрисовка пикселей. После этого — First Contentful Paint (FCP).

Render-blocking resources

Любой <link rel="stylesheet"> в <head> является render-blocking по умолчанию. Любой <script> без async или defer — тоже. Lighthouse показывает эти ресурсы в разделе «Eliminate render-blocking resources» с оценкой экономии времени.

Critical CSS для Above The Fold

Встройте минимальный набор стилей для Above The Fold прямо в <style> в <head>. Остальные стили загружайте асинхронно:

<link rel="stylesheet" href="/css/main.css" media="print" onload="this.media='all'">

Для WordPress — WP Rocket и LiteSpeed Cache имеют встроенную генерацию Critical CSS. Для других платформ — npm-пакет critical или penthouse.

First Contentful Paint (FCP)

FCP — время от начала навигации до отображения первого текстового или графического контента. Хороший FCP: менее 1.8s. Влияет на восприятие скорости и поведенческие метрики — особенно на мобильных с медленным соединением.

Above The Fold оптимизация

• LCP-изображение (обычно hero) — загружайте через <link rel="preload"> в head, не loading="lazy"
• Critical CSS для этой зоны — встроенный, не во внешнем файле
• Шрифты для заголовка и основного текста — preload
• Сторонние скрипты (аналитика, чаты) — defer или загрузка после взаимодействия

Оптимизация для WordPress

WordPress — самая популярная CMS в мире. Сам по себе WordPress не медленный — его делают медленным плохо настроенные плагины, тяжёлые темы и отсутствие кеширования.

Топ плагины для скорости: сравнение

Database optimization

WordPress накапливает мусор в базе данных, замедляющий запросы:

• wp-cron — псевдо-cron запускается при каждом запросе. При большом трафике создаёт паразитную нагрузку. Отключите через wp-config.php (define('DISABLE_WP_CRON', true);) и настройте реальный cron на сервере.
• Transients — временные данные в wp_options. Со временем накапливаются устаревшие записи. Очистка — плагин Transients Manager или WP-Optimize.
• Revision cleanup — WordPress хранит неограниченное количество ревизий. Ограничьте: define('WP_POST_REVISIONS', 3);. Старые ревизии удалите через WP-Optimize.

Отключение ненужных функций WordPress

• Emoji-скрипт — WordPress автоматически загружает wp-emoji-release.min.js. Если не используете emoji — отключите через functions.php или плагин Disable Emojis.
• Dashicons на фронтенде — иконки админ-панели загружаются даже для неавторизованных пользователей если плагин на них ссылается. Проверьте через DevTools → Network.
• jQuery Migrate — библиотека для совместимости старых плагинов. Если все плагины современные — jQuery Migrate лишняя. Отключите через WP Rocket.

Дополнительные настройки WP Rocket и LiteSpeed Cache

Базовая активация плагина — это половина работы. Конкретные настройки, дающие ощутимый эффект:

• WP Rocket → Preload Cache: включите прогрев кеша — плагин сам обойдёт сайт и закеширует страницы до прихода первого посетителя. Без этого первый после очистки кеша пользователь получает медленный некешированный ответ.
• WP Rocket → Delay JS Execution: откладывает выполнение JavaScript до первого взаимодействия пользователя. Эффективно снижает TBT и улучшает INP на страницах со множеством сторонних скриптов.
• LiteSpeed Cache → Object Cache: подключите Redis через настройки плагина — TTFB для динамических страниц WordPress падает до 30–80ms. Требует поддержки на уровне хостинга.
• Imagify / ShortPixel → Bulk Optimization: запустите массовую конвертацию всех существующих изображений в WebP. Для больших медиатек (1000+ изображений) обрабатывайте партиями по 200–300, чтобы не перегружать сервер.

Серверная оптимизация

TTFB (Time to First Byte)

TTFB — время от запроса до получения первого байта ответа. Норма по Google: менее 200ms. TTFB > 600ms — сигнал в Lighthouse и прямое ухудшение LCP. Причины: медленный хостинг, отсутствие серверного кеширования, тяжёлые SQL-запросы, большое физическое расстояние до сервера.

HTTP/2 и HTTP/3

HTTP/1.1 допускает только 6 параллельных соединений на домен. HTTP/2 добавляет мультиплексирование — несколько запросов и ответов в одном соединении. HTTP/3 (QUIC) использует UDP вместо TCP — быстрее стартует соединение и лучше восстанавливается при packet loss. Особенно заметно на мобильных сетях. Проверьте поддержку: большинство современных хостингов с Nginx 1.25+ поддерживают HTTP/3.

Серверное кеширование: Redis и Memcached

Redis Object Cache для WordPress хранит результаты запросов к БД в оперативной памяти. При правильной настройке TTFB падает с 200–400ms до 20–50ms для кешированных запросов.

Принцип работы: при первом запросе PHP выполняет SQL-запрос к базе данных, формирует объект (например, список постов категории), сохраняет его в Redis. При повторных запросах PHP берёт объект из Redis — в 5–10 раз быстрее, чем новый запрос к MySQL. Ключи кеша автоматически инвалидируются при обновлении контента.

Redis vs Memcached:

• Redis — поддерживает более сложные структуры данных, персистентность (данные сохраняются при перезапуске), встроенную репликацию. Рекомендован для большинства WordPress-проектов.
• Memcached — проще, немного быстрее для базового key-value хранения, нет персистентности. Подходит для высоконагруженных сайтов с горизонтальным масштабированием.

Целевые значения TTFB по типу страниц: статические страницы с page cache — 50–150ms; динамические страницы с object cache (Redis) — 80–200ms; некешированные тяжёлые страницы (поиск, фильтры) — 300–600ms. TTFB выше 600ms на любой странице — повод для немедленного расследования.

Shared vs VPS vs Cloud хостинг

Регион сервера для UA-аудитории

Для сайтов с украинской аудиторией ближайший регион — Варшава (AWS eu-central-1, Azure Poland Central) или Франкфурт. Разница между сервером в Варшаве и Сингапуре для UA-пользователя — 200–400ms TTFB только за счёт RTT. Всегда проверяйте через WebPageTest.org с тестовым узлом в Варшаве или Амстердаме.

Самая частая ошибка при выборе хостинга — ориентация на цену, а не географию. Хостинг за $3/мес в США для сайта с UA-аудиторией даёт TTFB 400–600ms — и никакие другие оптимизации не компенсируют этот базовый lag.

Измерение и мониторинг скорости

Как отслеживать деградацию после обновлений

Скорость сайта деградирует незаметно: новый плагин, обновление темы, добавление сторонних скриптов — каждое изменение может ухудшить PageSpeed на 5–15 баллов. Минимальный подход: после каждого значимого обновления — проверка PageSpeed Insights для 3–5 ключевых страниц с фиксацией результатов в таблице.

Lighthouse CI в CI/CD

Lighthouse CI — интеграция автоматического Lighthouse-теста в pipeline деплоя. При каждом deploy или PR автоматически запускается Lighthouse и результаты сравниваются с baseline. Если Performance Score падает ниже порога — build можно заблокировать. Настройка для GitHub Actions: npm-пакет @lhci/cli + конфиг lighthouserc.js.

SpeedCurve и DataDog RUM

SpeedCurve — платформа мониторинга скорости в реальном времени. Отслеживает Core Web Vitals для реальных пользователей, строит графики и алертит при деградации. Сравнивает с конкурентами. Оптимально для e-commerce где скорость напрямую конвертируется в деньги.

DataDog RUM включает Web Performance метрики с сегментацией по устройствам, браузерам, географии.

WebVitals.js для полевого сбора

Библиотека web-vitals от Google позволяет собирать реальные Core Web Vitals и отправлять в Google Analytics 4:

import {onLCP, onINP, onCLS} from 'web-vitals'; onLCP(metric => sendToAnalytics(metric));

Это даёт реальные данные по реальным устройствам и соединениям — в отличие от лабораторных данных Lighthouse.

GSC Core Web Vitals report — как читать

Звіт Core Web Vitals в GSC (Experience → Core Web Vitals) показывает статус URL-групп. Важно: данные агрегируются за 28-дневный rolling window — изменения видны с лагом. URL-группы — GSC кластеризует похожие страницы, проблема в одной группе может касаться сотен страниц. После исправления — GSC перепроверит через 28 дней.

На практике

Киевская сеть пиццерий с онлайн-заказом прямо со страницы меню столкнулась с проблемой, о которой узнала из данных GSC: LCP страницы меню составлял 7,4 секунды на мобильных. Анализ через PageSpeed Insights и GTmetrix показал причину — 34 фотографии блюд в формате JPEG суммарным весом 9,2 MB, каждая загружалась без lazy loading. Одновременно скрипт корзины блокировал рендеринг: он загружался синхронно в <head> и задерживал появление кнопки «Заказать» на 3,1 секунды.

По данным Hotjar, 67% пользователей покидали страницу до того, как кнопка заказа становилась кликабельной.

Решение заняло одну рабочую неделю. Все 34 фотографии блюд конвертировали в WebP через ShortPixel — размер медиатеки упал с 9,2 MB до 2,6 MB, изображения ниже первого экрана получили loading="lazy". Скрипт корзины перенесли в defer: кнопка «Заказать» стала доступна ещё до его полной инициализации.

LCP упал с 7,4 до 1,8 секунды, PageSpeed mobile вырос с 31 до 87 баллов. Конверсия со страницы меню выросла на 28% за первые 4 недели — отслеживали через Google Analytics 4 по событию begin_checkout.

Когда LCP определяется изображением товара или блюда, а не текстом — WebP-конвертация меняет цифры радикально. Мы видели случаи, где одна эта правка давала больше, чем все остальные оптимизации вместе. Но ключевое — проверить, что именно является LCP-элементом на мобильном: Lighthouse прямо показывает этот элемент в разделе Diagnostics.

Часто задаваемые вопросы

Какая скорость загрузки считается хорошей для SEO?

По стандартам Google Core Web Vitals: LCP (Largest Contentful Paint) должен быть до 2,5 секунды, FID/INP — до 200 мс, CLS — до 0,1. Оценка PageSpeed Insights от 90+ считается хорошей. Для мобильных устройств эти пороги важнее, так как Google ранжирует по мобильной версии.

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

Наиболее частые причины: несжатые изображения в устаревших форматах (JPEG/PNG вместо WebP/AVIF), отсутствие кеширования, блокирующий JavaScript и CSS в верхней части страницы, медленный хостинг с большим TTFB (более 600 мс), отсутствие CDN, загрузка сторонних скриптов (чаты, пиксели) без defer/async.

Как бесплатно проверить скорость сайта?

Три основных бесплатных инструмента: Google PageSpeed Insights (pagespeed.web.dev) — данные от реальных Chrome-пользователей и лабораторный анализ; Google Search Console → раздел «Core Web Vitals» — агрегированные данные по всему сайту; GTmetrix — детальный каскадный анализ запросов. Проверяйте мобильную и десктопную версию отдельно.

Влияет ли хостинг на скорость загрузки и ранжирование?

Да, напрямую. TTFB (Time To First Byte) — время ответа сервера — полностью зависит от хостинга. Хороший TTFB: до 200 мс. Если хостинг даёт TTFB 800+ мс, никакая фронтенд-оптимизация не компенсирует это полностью. Переезд с shared-хостинга на VPS или облачный сервер (AWS, Google Cloud) снижает TTFB в 2–5 раз.