Ответ сервера
Сколько времени проходит до начала получения HTML и нет ли периодических 5xx или таймаутов.
Практическое SEO · производительность
Скорость сайта: как понять, что тормозит и что исправлять в первую очередь
Медленная страница — не одна плохая цифра из теста. Задержка может появляться на сервере, в базе данных, сети, изображениях, CSS, JavaScript или внешних виджетах. Поэтому сначала разделяем путь загрузки на этапы, находим узкое место и только потом оптимизируем.
Основа
Скорость влияет прежде всего на возможность нормально пользоваться сайтом
Если страница долго отвечает или интерфейс появляется только после тяжёлой загрузки, пользователь может уйти раньше, чем увидит предложение. Для поискового робота нестабильность тоже важна: таймауты и серверные ошибки мешают получить документ.
Яндекс называет скорость загрузки одним из важных показателей качества сайта и рекомендует уменьшать число запросов, устранять блокирующие ресурсы, сжимать файлы и изображения, использовать кэширование, CDN и оптимизировать серверный код.
Рекомендации Яндекса по ускорению сайта.
Цель оптимизации — не «получить красивый балл», а сократить реальное ожидание пользователя и убрать нестабильные участки загрузки.
Шаг 1
Разделяем загрузку страницы на этапы
Чтобы не оптимизировать вслепую, смотрим путь запроса: DNS и соединение, ответ backend, получение HTML, загрузка CSS и JavaScript, изображения и шрифты, выполнение кода, появление первого полезного содержимого и готовность интерфейса к взаимодействию.
Передача ресурсов
Сколько данных пользователь скачивает и какие файлы занимают основную часть веса.
Отрисовка
Не блокируют ли CSS, шрифты или синхронные скрипты появление видимого контента.
Интерактивность
Не занят ли основной поток тяжёлым JavaScript после того, как страница уже выглядит загруженной.
Шаг 2
Если долго приходит HTML — начинаем с сервера, а не с картинок
Высокий TTFB может быть связан с медленной базой данных, тяжёлым PHP-кодом, внешними API, отсутствием серверного кэша, перегруженным процессором, диском или сетью. В таком случае сжатие изображений почти не влияет на задержку до первого ответа.
Проверяем одинаковый URL несколько раз и в разные моменты. Разовая быстрая загрузка не исключает периодических провалов под нагрузкой. Серверные логи и мониторинг полезнее среднего значения из одного теста.
Шаг 3
Изображения проверяем по фактическому весу, а не по размеру на экране
Картинка может занимать 300 пикселей в карточке, но браузер всё равно скачивает исходник шириной 4000 пикселей. Поэтому смотрим размер файла, реальные dimensions, формат и то, загружается ли изображение до попадания в видимую область.
Размеры
Не отдаём огромный оригинал в маленький контейнер.
Формат
Используем современный формат там, где он даёт меньший вес без заметной потери качества.
Lazy loading
Изображения далеко ниже первого экрана не должны конкурировать за сеть с критическим содержимым.
Габариты в HTML
Width и height помогают браузеру заранее зарезервировать место и уменьшают скачки макета.
Шаг 4
CSS и JavaScript: отделяем критическое от лишнего
Большие библиотеки и стили могут загружаться на всех страницах, хотя конкретному шаблону нужна только небольшая часть. Это увеличивает объём передачи, количество запросов и время обработки в браузере.
Проверяем блокирующие ресурсы, дубли библиотек, код от удалённых функций, тяжёлые компоненты первого экрана и скрипты, которые можно загрузить позже. Для JavaScript особенно важно смотреть не только размер файла, но и время выполнения.
Файл в 100 КБ может быть дешевле для браузера, чем файл в 50 КБ, если второй запускает тяжёлые вычисления и долго блокирует основной поток.
Шаг 5
Сторонние виджеты могут тормозить сильнее собственного кода
Чаты, карты, коллтрекинг, аналитика, рекламные пиксели, формы и внешние шрифты подключаются с других серверов. Владелец сайта не контролирует их скорость полностью, но каждый такой ресурс участвует в загрузке страницы.
Составляем список внешних доменов и проверяем, что действительно нужно загружать сразу. Часть виджетов можно инициализировать после основного контента или только после действия пользователя.
Чат
Не обязан блокировать первый экран, если пользователь ещё не собирается его открывать.
Карты
Тяжёлый интерактив можно заменить предварительным изображением до взаимодействия.
Видео
Встраиваемый плеер лучше не загружать полностью до того, как он реально понадобится.
Маркетинговые скрипты
Проверяем дубли и старые интеграции, которые уже не используются бизнесом.
Шаг 6
Кэш, сжатие и сеть уменьшают повторную стоимость загрузки
Статические ресурсы не должны скачиваться заново при каждом переходе, если их содержимое не изменилось. Проверяем HTTP-кэширование, сжатие текста, версионирование файлов и отсутствие лишних редиректов между ресурсами.
Для географически распределённой аудитории CDN может ускорить доставку статических файлов. Но CDN не исправит медленный backend или тяжёлый JavaScript — он решает только свою часть пути.
Шаг 7
Как измерять скорость без самообмана
Один тест одной страницы не описывает весь сайт. Сравниваем разные шаблоны, повторные загрузки и реальное поведение пользователей.
Несколько URL
Главная, категория, карточка, статья и тяжёлая форма могут иметь разные узкие места.
Холодная загрузка
Показывает поведение без уже прогретого браузерного кэша.
Повторная загрузка
Помогает проверить, работает ли кэширование ресурсов.
Мобильная сеть
Проблемы веса заметнее при ограниченной скорости и высокой задержке.
Логи сервера
Показывают 5xx, таймауты и нестабильность, которой нет в лабораторном тесте.
Network waterfall
Видно, какой ресурс реально задерживает цепочку.
Выполнение JS
Страница может быстро скачаться, но долго оставаться занята вычислениями.
Данные пользователей
Сравниваем устройства, браузеры и реальные сценарии, а не только тестовый компьютер.
Практический пример
Страница весит немного, но открывается четыре секунды
На первый взгляд хочется сжать изображения. Но сетевой профиль показывает, что HTML начинает приходить только через 2,8 секунды — проблема находится до загрузки картинок.
| Этап | Наблюдение | Вывод | Действие |
|---|---|---|---|
| TTFB | 2,8 с | Backend отвечает слишком поздно | Проверить БД, PHP, кэш и внешние API |
| HTML | 80 КБ | Вес умеренный | Не главный приоритет |
| Изображения | 450 КБ | Есть запас оптимизации | Сжать после backend |
| JS | 120 КБ | Нет длинных задач | Наблюдать, но не начинать с него |
Симптоммедленная страница
→
Кореньмедленный backend
→
Приоритетсервер до косметической оптимизации
Шаг 8
Исправляем по влиянию, а не по удобству задачи
Проще всего «оптимизировать» мелкие иконки или убрать несколько килобайт CSS, но это может почти не изменить пользовательское ожидание. Приоритет получают проблемы, которые задерживают первый полезный контент, ломают интерактивность или вызывают нестабильность.
После каждого крупного изменения повторяем измерение на тех же URL и условиях. Если показатель не изменился, значит гипотеза была слабой или узкое место находилось в другом месте.
Чек-лист
Диагностика скорости сайта
- Проверить несколько типов страниц: не ограничиваться главной.
- Разделить этапы: сервер, передача, отрисовка и выполнение JavaScript.
- Проверить TTFB: если HTML приходит поздно, искать причину на backend.
- Проверить изображения: фактический вес, dimensions, формат и lazy loading.
- Проверить CSS: блокирующие и неиспользуемые стили.
- Проверить JavaScript: вес, дубли библиотек и длительное выполнение.
- Проверить сторонние сервисы: чаты, карты, видео, аналитику и старые интеграции.
- Проверить кэш и сжатие: повторные загрузки не должны начинаться с нуля.
- Проверить редиректы ресурсов: ссылаться сразу на конечный адрес.
- Посмотреть серверные логи: 5xx и таймауты не видны в одном успешном тесте.
- Сравнить mobile и desktop: слабая сеть и устройство сильнее проявляют проблемы.
- Повторить измерение: подтвердить эффект каждого крупного исправления.
Вопросы
Короткие ответы
Какая скорость сайта считается хорошей?
Одной универсальной цифры недостаточно. Важно, когда пользователь видит полезный контент, когда интерфейс становится отзывчивым и насколько стабильно сайт ведёт себя на разных устройствах и сетях.
Что оптимизировать первым: сервер или изображения?
То, что создаёт основную задержку. Если HTML начинает приходить через несколько секунд, сначала backend. Если сервер быстрый, а страница скачивает мегабайты изображений — начинаем с медиа.
Поможет ли CDN ускорить любой сайт?
CDN сокращает путь доставки статических ресурсов, но не исправляет медленную базу, тяжёлый PHP или долгий JavaScript.
Нужно ли объединять все CSS и JavaScript в один файл?
Не всегда. Важнее минимизировать критическую цепочку и не заставлять страницу загружать код, который ей не нужен.
Почему сайт быстрый у разработчика, но медленный у клиентов?
У разработчика могут быть быстрый компьютер, локальный кэш и хорошая сеть. Поэтому нужны проверки на мобильных устройствах, слабой сети и данные реальных пользователей.
Практика NIC-SEO
Сначала измеряем путь загрузки — потом оптимизируем
Это позволяет не тратить время на косметические улучшения, когда реальная задержка находится в базе данных, внешнем API или тяжёлом JavaScript.