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

Коротко

Что такое скорость загрузки: пять величин вместо одной

Фраза «сайт грузится медленно» может означать разные вещи. Вот величины, которые встретятся в отчётах:

• Ответ сервера. Сколько проходит от запроса страницы до первого ответа сервера. В английских инструментах это TTFB (time to first byte). В Яндекс Метрике такая метрика называется «Ответ сервера», у неё есть собственное определение, поэтому с TTFB из документации Google она может не совпасть.
• Время до отрисовки. По справке Метрики, это время от начала перехода на страницу до момента, когда страница начинает отрисовываться в браузере. Справка добавляет, что посетитель воспринимает именно его как скорость загрузки и что обычно оно занимает не более двух секунд.
• LCP (Largest Contentful Paint). Время, за которое появляется самый крупный элемент первого экрана: картинка или большой блок текста. Показатель Google, ориентир - до 2,5 секунды.
• INP (Interaction to Next Paint). Как быстро страница реагирует на нажатия и ввод. Ориентир - до 200 миллисекунд. С 12 марта 2024 года INP заменил показатель FID, поэтому в старых инструкциях может стоять FID.
• CLS (Cumulative Layout Shift). Насколько «прыгает» вёрстка, пока страница загружается. Ориентир - до 0,1.

Три последних показателя Google называет Core Web Vitals. Для самой первой проверки хватает двух вопросов: быстро ли отвечает сервер и быстро ли появляется главное на экране.

Что Яндекс и Google говорят о влиянии скорости на поиск

Яндекс. Справка Вебмастера «Как сделать сайт быстрее» называет скорость одним из важных показателей качества сайта. Из-за низкой скорости посетитель может не дождаться страницы. Это снижает доверие к сайту и посещаемость, а также влияет на другие статистические показатели. Слов о ранжировании в справке нет. В материале «Какие аспекты влияют на ранжирование» ускорение сайта стоит среди важных аспектов технической оптимизации, а среди ранжирующих аспектов (экспертность, полезность, оригинальность, содержательность) скорость не названа. Отдельно справка про ошибку «Долгий ответ сервера» связывает медленный сервер с задержкой индексирования: страницы могут появляться в поиске позже.

Google. Справка Search Central пишет, что Core Web Vitals используются ранжирующими системами, и рекомендует добиваться хороших значений. Там же сказано: хорошие результаты в отчётах верхних позиций не гарантируют. Погоня за идеальной оценкой только ради SEO может оказаться не лучшим вложением времени. Единого «сигнала page experience» нет: ранжирующие системы смотрят на разные сигналы, связанные с удобством страницы.

Ускорять сайт стоит ради посетителей и стабильной работы с поисковым роботом (это вывод автора). Сколько позиций это даст, не подтверждает ни один из источников, которые мы открывали, и в этой статье мы такого не обещаем.

Полевые и лабораторные данные: откуда берутся цифры

Основная причина расхождений между сервисами - разный способ сбора данных.

• Полевые данные (field data) - измерения у реальных посетителей. К ним относятся отчёт Метрики «Время загрузки страниц» и данные CrUX (Chrome User Experience Report, отчёт Google о реальных пользователях Chrome), на которых построены блок реального опыта в PageSpeed Insights и отчёт Core Web Vitals в Search Console. Окно данных CrUX - 28 дней. Оценка считается по 75-му процентилю (значению, в которое укладываются 75 процентов загрузок): страница её проходит, если 75-й процентиль каждого из трёх показателей попадает в зелёную зону.
• Лабораторные данные (lab data) - один запуск Lighthouse (бесплатного инструмента Google, который автоматически проверяет страницу) в контролируемых условиях. Для мобильной версии он имитирует телефон среднего уровня в мобильной сети, для десктопа - проводное соединение. Лаборатория подходит, чтобы искать причины, но Google прямо пишет, что хорошая лабораторная оценка не обязательно означает хорошего опыта реальных пользователей.

Отсюда знакомая по обсуждениям ситуация: мобильная оценка в PageSpeed сильно ниже десктопной. Ошибки сервиса тут нет: условия измерения разные. Яндекс говорит об этом в блоге для вебмастеров: результаты измерений скорости разными сервисами могут существенно отличаться, и это не говорит об ошибках. Оценка одного и того же адреса меняется и от запуска к запуску из-за сети и нагрузки на компьютер, поэтому один прогон ничего не доказывает.

Как проверить скорость: порядок проверки

Порядок ниже предлагаем мы: он идёт от самых простых проверок к тем, где нужен накопленный трафик. Названия разделов даны по справкам, в живом интерфейсе они могут отличаться, а интерфейс кабинетов при подготовке статьи мы не сверяли.

1. Диагностика сайта в Яндекс Вебмастере. Откройте «Оптимизация сайта», затем «Диагностика сайта», вкладку «Ошибки». Если робот при обходе увидел страницы, которые загружаются дольше 3 секунд, в списке будет ошибка «Долгий ответ сервера» с перечнем таких страниц. Проверки идут ежедневно. Справка советует сначала проверить время ответа сервера сейчас: если ответ быстрый, сообщение можно проигнорировать: при следующем обходе оно исчезнет.
2. «Проверка ответа сервера» в Вебмастере. Инструмент показывает, как сервер отвечает на запрос, и ждёт ответа три секунды. Справка предупреждает: у инструмента другой IP-адрес, поэтому результат может отличаться от реального ответа роботу.
3. Отчёт «Время загрузки страниц» в Яндекс Метрике. Путь: «Отчеты», «Мониторинг», «Время загрузки страниц». В отчёте есть метрики «DNS», «Редиректы», «Продолжительность установки соединения», «Ответ сервера», «Время загрузки и парсинга HTML», «Время до загрузки DOM» и «Время до отрисовки». По умолчанию выбран квантиль 50 процентов, то есть половина загрузок не дольше указанного времени; для оценки худших случаев выберите 90 процентов. Справка советует оптимизировать в первую очередь самый затратный по времени этап. Для мониторинга нужно более 100 просмотров страниц сайта в неделю, при меньшей посещаемости работа отчёта не гарантируется.
4. PageSpeed Insights. Вставьте адрес страницы на сайте pagespeed.web.dev. Вверху будут полевые данные CrUX за 28 дней, ниже - лабораторная диагностика Lighthouse. Если у страницы мало данных, сервис покажет данные по сайту целиком, а если и их нет, полевой блок останется пустым. Это нормально для небольших и новых сайтов.
5. Отчёт Core Web Vitals в Google Search Console. Он работает только по индексированным адресам и группирует их по типам страниц. Если данных CrUX мало, отчёт покажет «No data available» («нет данных»). Это нехватка данных, а не ошибка. Минимальный объём данных Google не раскрывает.
6. Проверка сервера из командной строки. Подходит, чтобы увидеть время ответа и заголовки без кабинетов. Пример - в разделе про curl ниже.

Если данных в кабинетах нет, начинайте с шагов 1, 2 и 6, а лабораторный прогон PageSpeed используйте как подсказку, где искать причину. При проверке не опирайтесь на один запуск: сделайте несколько и сравнивайте медианы (серединные значения).

Какие цифры считать нормой: Яндекс и Google

Для TTFB в PageSpeed Insights Google указывает границы 800 и 1800 мс и помечает показатель как экспериментальный. У Яндекса единственная граница, по которой Вебмастер выдаёт ошибку скорости, - три секунды ответа сервера. Справка Метрики отдельно называет обычное время до отрисовки: не более двух секунд. Какую именно метрику робот сравнивает с этой границей и какая доля страниц должна её превысить, справка не уточняет.

Проверка сервера командой curl: цифры блога genseo.ru

Команда curl - программа командной строки, которая запрашивает адрес и показывает параметры ответа. Она есть в Windows 10 и 11, macOS и Linux. В Windows PowerShell пишите curl.exe, потому что слово curl там может означать другую команду. Вот проверка, которую можно повторить на любом сайте:

curl -sS -L -o /dev/null -D - -H "Accept-Encoding: gzip, deflate, br" -w "code=%{http_code} redirects=%{num_redirects} dns=%{time_namelookup} connect=%{time_connect} tls=%{time_appconnect} ttfb=%{time_starttransfer} total=%{time_total} size=%{size_download}\n" https://genseo.ru/

В Windows вместо /dev/null пишите NUL. Замеры времени в curl накопительные: connect включает DNS, tls включает connect, ttfb включает всё предыдущее. Параметр size показывает число байт на проводе, то есть уже сжатых.

Мы запустили эту команду из скрипта с теми же параметрами 28 октября 2026 года около 12:00 по московскому времени, по пять раз на каждую из трёх страниц блога с паузой в секунду, с одного ноутбука. Ответ везде был 200, редиректов не было.

Самое долгое время до первого байта из пятнадцати запросов - 673 мс (весь HTML в этом запросе - 701 мс). Сжатие gzip включено и уменьшает HTML примерно на 74-79 процентов, а brotli на запрос Accept-Encoding: br сервер не отдал. Скрипты и стили хранятся в кэше браузера год (max-age=31536000, immutable), HTML отдаётся без кэширования.

Эти цифры описывают время получения HTML через curl. LCP и время загрузки в браузере они не показывают: curl не выполняет скрипты и ничего не рисует. Замер сделан с одного компьютера в одной точке сети и не заменяет данные посетителей. Разброс заметен: повторный запуск для статьи про robots.txt дал 295 и 363 мс против 211-257 мс в основной серии, поэтому читайте цифры как порядок величины. Попытка получить оценку PageSpeed Insights через программный интерфейс без ключа закончилась ошибкой 429 (квота запросов без ключа исчерпана). Поэтому лабораторных оценок и полевых данных Core Web Vitals для этого блога в статье нет.

Что ускорять и в каком порядке

Меры взяты из справки Яндекса «Как сделать сайт быстрее» и документов web.dev и Lighthouse. Порядок и привязка к симптомам наши. Точного эффекта ни один источник не называет, а web.dev замечает, что быстрая правка одной детали редко даёт заметное улучшение LCP.

Справка Яндекса перечисляет десять мер:

1. Сократить число HTTP-запросов, например с помощью CSS-спрайтов для картинок и объединения JavaScript и CSS.
2. Убрать ресурсы, блокирующие отрисовку: скрипты и стили, которые не нужны для отрисовки, разместить внизу страницы или подключать асинхронно или отложенно.
3. Уменьшить размер CSS, JavaScript и HTML минификацией.
4. Использовать CDN (сеть серверов, которая отдаёт файлы с ближайшего к посетителю сервера) для картинок, JavaScript и CSS.
5. Настроить кэширование и Gzip-сжатие.
6. Использовать сжатие картинок.
7. Отложить загрузку картинок, которые не попали в видимую область экрана.
8. Оптимизировать серверный код и доступные системные ресурсы.
9. Использовать только быстрые CSS-анимации.
10. Сократить число редиректов: ссылаться на ресурс напрямую.

В таблице ниже «п.» означает номер пункта этого списка.

Редиректы часто возникают при переезде или смене адресов. Как выбрать между 301 и 302, объясняет статья про редиректы 301 и 302, а про страницы, которых больше нет, - материал о странице 404 и битых ссылках.

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

• Гнаться за 100 из 100. Google называет зелёной оценку от 90, а полевые пороги относятся к 75-му процентилю загрузок. Идеальная оценка только ради SEO, по словам самого Google, может быть не лучшим использованием времени.
• Проверять только у себя. У вас в офисной сети страница открывается быстро, у посетителей на телефоне может быть иначе. Для этого и нужны полевые данные.
• Включить отложенную загрузку для главной картинки. Для картинки, которая видна сразу, web.dev рекомендует обычную загрузку, а loading="lazy" оставляет для картинок вне первого экрана.
• Ориентироваться на показатель «скорость сайта» из Вебмастера 2020 года. В 2020 году Яндекс запускал в Вебмастере бета-показатель «скорость сайта». В актуальной справке он видимым текстом не описан, поэтому полагаться на него не стоит. Показывает ли его интерфейс сегодня, мы проверить не смогли.
• Менять много всего сразу. Тогда непонятно, что именно помогло. Правьте по одной причине и замеряйте до и после.

Когда ускорение не поможет

Скорость - лишь одно из технических условий. Если страницы открываются быстро, но их нет в поиске, причина обычно в индексации: смотрите проверку индексации сайта. Если нужен общий маршрут по всем техническим проверкам, он собран в статье про технический аудит сайта. Ускорение не создаёт спрос на ваши страницы и не гарантирует позиций.

О Head Promo

Head Promo - агентство поискового маркетинга. Подробнее об услуге - на странице SEO-продвижения на нашем сайте.

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