Скорость загрузки сайта: почему сайт тормозит и как его ускорить
Скорость загрузки сайта — не одна цифра, а цепочка: сервер готовит ответ, браузер скачивает HTML, стили, скрипты и картинки, отрисовывает первый экран и начинает реагировать на клики. Тормозить может любое звено, а плагин-«ускоритель» чинит в лучшем случае одно. Ниже — как измерить скорость, найти узкое место по метрикам и что ускорять на уровне сервера, CMS и фронтенда.
Как проверить скорость загрузки сайта: полевые и лабораторные данные
Инструменты делятся на два типа, и их путаница — источник большинства неверных выводов.
- Полевые данные (RUM) — замеры у реальных посетителей на их устройствах и их интернете. Показывают, как сайт работает на самом деле, но не объясняют, почему.
- Лабораторные данные — один прогон страницы в эмулированных условиях. Воспроизводимы, дают список проблем, но это модель, а не реальность.
PageSpeed Insights: CrUX против Lighthouse
В PageSpeed Insights два блока. Верхний — полевые данные Chrome UX Report (CrUX): реальные пользователи Chrome за 28 дней, 75-й процентиль (значение, в которое укладываются три четверти визитов); при малом трафике блока нет. Нижний — прогон Lighthouse на эмулированном смартфоне с медленным мобильным интернетом и балл от 0 до 100.
Для поиска Google важны полевые Core Web Vitals, а не балл Lighthouse. Поэтому «в лаборатории 45 баллов, а в поле всё зелёное» — нормальная ситуация. Бывает и обратное: лаборатория показывает 90, а у пользователей плохой INP, потому что Lighthouse не кликает по фильтрам и не открывает чат.
Яндекс Метрика и Вебмастер
Яндекс не использует термин Core Web Vitals и не публикует пороговых значений скорости. Свои инструменты у него такие:
- Метрика: Отчёты → Мониторинг → «Время загрузки страниц». Полевые данные посетителей по этапам загрузки: ответ сервера, отрисовка, загрузка DOM. Квантиль по умолчанию 50%, полезно смотреть и 90% — «хвост» медленных визитов. Можно выделить сегмент по URL или региону.
- Вебмастер. Отдельного отчёта о скорости в актуальной справке нет: оценка скорости, которую с 2020 года показывали среди достижений сайта, в разделе «Показатели качества» сейчас не описана. Справка Вебмастера о скорости даёт базовый список рекомендаций (меньше запросов и редиректов, асинхронные скрипты, кеш и gzip, сжатие изображений) и отправляет к отчётам Метрики.
WebPageTest и DevTools: инструменты для диагноза
WebPageTest строит водопад запросов (waterfall): видно, какой файл грузится, сколько ждёт и что блокирует отрисовку, плюс покадровое видео загрузки. Chrome DevTools (F12): Network с имитацией медленной сети, Performance с LCP, INP и CLS при работе со страницей, Lighthouse — тот же аудит локально. Для диагноза стороннего кода удобен «Block request URL» в Network: блокируете домен виджета и сравниваете метрики.
Метрики скорости: TTFB, FCP, LCP, INP, CLS
Пороговые значения ниже — «хорошая» зона по классификации Google для 75-го процентиля визитов. LCP, INP и CLS входят в Core Web Vitals; TTFB и FCP — вспомогательные, но именно они часто указывают на корень проблемы.
| Метрика | Что показывает | Хорошо | Частая причина плохого значения |
|---|---|---|---|
| TTFB (Time to First Byte) | Сколько сервер думает до первого байта ответа | до 0,8 с | Слабый хостинг, медленные запросы к БД, нет кеша страниц, редиректы |
| FCP (First Contentful Paint) | Когда на экране появилось хоть что-то | до 1,8 с | Долгий TTFB, блокирующие CSS и JS в <head>, шрифты |
| LCP (Largest Contentful Paint) | Когда отрисован главный элемент первого экрана: баннер, фото товара, заголовок | до 2,5 с | Тяжёлое изображение, lazy-load на главной картинке, слайдер на JS |
| INP (Interaction to Next Paint) | Как быстро страница реагирует на клики и ввод | до 200 мс | Тяжёлый JS, сторонние скрипты, перерисовка большого каталога при фильтрации |
| CLS (Cumulative Layout Shift) | Насколько «прыгает» вёрстка при загрузке | до 0,1 | Картинки без размеров, баннеры и виджеты, вставляемые сверху, подмена шрифта |
INP в марте 2024 года заменил FID: старая метрика учитывала только задержку первого клика, новая — отклик на взаимодействия за весь визит. Поэтому сайты с «задумчивыми» фильтрами и корзиной после замены нередко ушли из зелёной зоны.
Почему сайт долго грузится: причины на стороне сервера
Если TTFB больше секунды, начинайте отсюда: всё остальное ждёт ответа сервера.
Хостинг и ресурсы
Виртуальный хостинг делит процессор и диск с сотнями соседей: в пиковые часы ответ проседает без всяких изменений на сайте. Признак — TTFB «гуляет» в течение дня, а 90-й квантиль в Метрике в разы хуже медианы. Зарубежный дата-центр добавляет задержку каждому запросу российского посетителя. Как выбрать площадку — в статье про хостинг.
Тяжёлый бэкенд и база данных
Фильтр по свойствам без индексов, запросы в цикле, синхронный обмен с 1С или внешним API во время загрузки страницы — классические причины секундных ответов. Лечится профилированием: какой запрос медленный, сколько раз выполняется, можно ли его закешировать или вынести в фон.
Отсутствие кеша
Без кеша сервер на каждый визит заново собирает ту же страницу. Уровни кеша: OPcache (скомпилированный PHP-код), объектный кеш (Redis, Memcached), кеш готового HTML (fastcgi_cache или proxy_cache в nginx, композит в Битриксе, кеш-плагины WordPress) и браузерный кеш статики через заголовки Cache-Control.
Цепочки редиректов
http → https → www → слеш — каждый шаг это отдельный запрос с задержкой. Ссылки в меню, рекламе и карте сайта должны вести сразу на конечный адрес.
Причины на стороне фронтенда: картинки, скрипты, стили, шрифты
Изображения
Самая частая причина плохого LCP. Типовые ошибки: баннер 4000 px в JPEG на 2 МБ для экрана телефона в 390 px, нет WebP/AVIF, один файл для десктопа и мобильного, нет width и height (отсюда же CLS). Решение — srcset, современные форматы с фолбэком, loading="lazy" для всего ниже первого экрана и, наоборот, приоритетная загрузка главной картинки (fetchpriority="high", без lazy).
Сторонние скрипты
Онлайн-чат, обратный звонок, квиз, коллтрекинг, счётчики, пиксели, карта, внешнее видео — каждый приносит JavaScript, который выполняется в одном потоке с вашим интерфейсом. Это главный враг INP на коммерческих сайтах, и при разработке его не видно: скрипты добавляют уже после запуска. Нужна инвентаризация: кто поставил скрипт, приносит ли он заявки, можно ли грузить его отложенно.
JavaScript и CSS
Бандлы с библиотеками, нужными на одной странице, jQuery-плагины «на всякий случай», слайдеры на JS, стили всего сайта одним файлом в <head>. Помогают разделение кода по страницам, defer/async, критический CSS для первого экрана, удаление неиспользуемого кода (вкладка Coverage в DevTools показывает, сколько процентов файла реально выполняется).
Шрифты
Пять начертаний с внешнего сервиса задерживают отрисовку текста и сдвигают вёрстку при подмене. Достаточно 2–3 начертаний в WOFF2 со своего домена, font-display: swap и предзагрузки основного файла. Как выбрать шрифт без лишнего веса и проблем с лицензией — в статье о выборе шрифта для сайта.
Как ускорить сайт на уровне сервера
- Актуальная версия PHP 8.x — заметно быстрее 7.x, а старые версии без обновлений безопасности. Перед переходом проверьте совместимость модулей и шаблона.
- OPcache с достаточным объёмом памяти — иначе PHP компилируется на каждый запрос.
- HTTP/2 и HTTP/3 — параллельная загрузка ресурсов по одному соединению; HTTP/3 в nginx есть с версии 1.25.0, но модуль по-прежнему экспериментальный и собирается отдельно.
- Сжатие gzip и brotli для HTML, CSS, JS, SVG. Brotli в nginx — сторонний модуль ngx_brotli; обычно сжимает сильнее gzip.
- Кеш в nginx (fastcgi_cache / proxy_cache) для страниц, которые одинаковы для всех гостей, и долгий Cache-Control для статики с версией в имени файла.
- Ресурсы: память под буферы MySQL, NVMe-диски, при росте — отдельный сервер БД и Redis.
- CDN для статики при аудитории по всей стране — подробно в статье что такое CDN.
Эти работы относятся к администрированию: настройка сервера Linux и отдельно тюнинг веб-сервера — например, настройка кеширования и сжатия в nginx.
Ускорение на уровне CMS: Битрикс и WordPress
1С-Битрикс
- Монитор производительности (Настройки → Производительность → Панель производительности) — тест конфигурации сервера и отчёты по медленным страницам, компонентам и SQL-запросам. С него стоит начинать диагностику.
- Кеширование компонентов: автокеширование должно быть включено, а в кастомных компонентах — корректно настроено. Частая проблема — кеш отключили при отладке и забыли включить.
- Композитный сайт — отдаёт статическую копию страницы мгновенно и подгружает динамические блоки (корзина, авторизация) отдельно. Сильно снижает TTFB, но требует аккуратной разметки динамических областей.
- Объединение и сжатие CSS/JS в настройках главного модуля, хранение кеша в memcached или Redis вместо файлов.
WordPress
Кеш-плагин страниц (WP Super Cache, W3 Total Cache; кеш страниц LiteSpeed Cache работает только на сервере LiteSpeed), объектный кеш на Redis, ревизия плагинов — каждый подключает свои файлы и запросы. Визуальные конструкторы утяжеляют вёрстку, ключевые шаблоны иногда выгоднее переверстать вручную.
Быстрые победы и системные работы: с чего начать
| Работа | Тип | На что влияет |
|---|---|---|
| Сжать и перевести в WebP/AVIF главные изображения, проставить размеры | Быстрая | LCP, CLS |
| Убрать lazy-load с картинки первого экрана | Быстрая | LCP |
| Отложить загрузку чатов, квизов и пикселей, удалить неиспользуемые | Быстрая | INP, LCP |
| Включить сжатие, HTTP/2, кеш статики, убрать цепочки редиректов | Быстрая | TTFB, FCP |
| Обновить PHP, включить OPcache и кеш страниц | Средняя | TTFB |
| Профилирование и оптимизация запросов к БД, индексы | Системная | TTFB |
| Переезд с виртуального хостинга на VPS или выделенный сервер | Системная | TTFB, стабильность |
| Рефакторинг фронтенда: разделение JS, критический CSS, отказ от тяжёлых библиотек | Системная | INP, FCP, LCP |
Быстрые победы делаются за дни и часто закрывают основные проблемы с LCP. Системные работы нужны, когда проблема в архитектуре: тяжёлый каталог, самописное ядро, технический долг. Практичный формат — аудит скорости с оценкой эффекта и трудозатрат по каждому пункту, а затем доработка сайта в порядке «максимум эффекта за минимум часов». Ориентиры по цене: единичные правки — от 5 000 ₽, почасовая работа разработчика — около 2 500 ₽/час, настройка кеширования и сжатия в nginx — от 10 000 ₽; итог зависит от CMS, состояния кода и числа шаблонов.
Как скорость влияет на SEO и конверсию
Google в документации прямо пишет, что Core Web Vitals учитываются его системами ранжирования. Но релевантность важнее: быстрая бесполезная страница не обгонит полезную.
Яндекс в справке Вебмастера называет скорость загрузки одним из важных показателей качества сайта: медленная страница снижает доверие и посещаемость.
Конверсия. Наиболее известное исследование — Deloitte «Milliseconds Make Millions» (2020, по заказу Google): 37 брендов, около 30 млн сессий. Ускорение мобильного сайта на 0,1 секунды дало ритейлу рост конверсии на 8,4%, туристическим сайтам — на 10,1%. Это средние по выборке, а не гарантия для каждого сайта.
Ошибки при оптимизации скорости
- Гнаться за 100 баллами Lighthouse. Балл — лабораторная оценка, в ранжировании не используется, а путь с 85 до 100 часто требует отказа от виджетов, приносящих заявки. Цель — зелёные полевые Core Web Vitals.
- Лечить фронтенд при медленном сервере. При TTFB в 2 секунды хорошего LCP не получится при любой вёрстке.
- Не контролировать скорость после запуска. Сайт медленнеет постепенно: новые скрипты, тяжёлые фото, плагины. Без мониторинга это замечают по падению заявок.
Чек-лист: как ускорить загрузку сайта
- Снять полевые данные: CrUX в PageSpeed Insights, «Время загрузки страниц» в Метрике (квантили 50% и 90%)
- Прогнать Lighthouse и WebPageTest по URL каждого шаблона, мобильная версия в приоритете
- Проверить TTFB: если больше 0,8 с — начать с сервера, кеша и базы данных
- Убедиться, что PHP 8.x, OPcache, HTTP/2, gzip/brotli и кеш статики включены
- Включить кеш CMS: кеширование компонентов и композит в Битриксе, кеш-плагин и Redis в WordPress
- Оптимизировать изображения: WebP/AVIF, srcset, размеры, lazy-load ниже первого экрана, приоритет главной картинки
- Провести инвентаризацию сторонних скриптов: удалить лишние, остальные загружать отложенно
- Добавить defer/async для JS, вынести критический CSS, сократить шрифты до 2–3 начертаний в WOFF2
- Убрать цепочки редиректов во внутренних ссылках
- После изменений — проверить формы, корзину и оплату, затем повторный замер через 28 дней в полевых данных
Итог
Ускорение сайта — диагностика по метрикам, а не набор универсальных советов. TTFB указывает на сервер и бэкенд, LCP — чаще всего на картинки и первый экран, INP — на JavaScript и сторонние виджеты, CLS — на вёрстку без заданных размеров. Начинайте с полевых данных и самых посещаемых шаблонов, быстрые победы делайте первыми, системные работы планируйте по оценке эффекта. Цель — быстрые страницы, на которых удобно оставить заявку, а не 100 баллов в отчёте.