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

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

Ниже — три метрики и их пороги, разница между лабораторными и полевыми данными, где смотреть скорость в Вебмастере и Метрике, как накручивают баллы PageSpeed и в каком порядке вообще что-то чинить.

Влияет ли скорость на позиции

Самый частый спор в чате сообщества, и позиции там сформулированы жёстко:

«Скорость сайта никак не влияет на позиции. Только на поведенческие факторы».

«Топ переполнен сайтами в зоне 15–40 по PageSpeed, и много сайтов с оценкой 90+ тусуется за топ-30. Скорость нужна, но она вторична».

Что на эту тему говорит сам Google:

• «Единого сигнала нет. Наши системы ранжирования учитывают различные сигналы, связанные с удобством страницы в целом».
• «Цель Google Поиска — предлагать пользователям наиболее актуальный контент, даже если он располагается на не очень удобных страницах». Но если по запросу много одинаково полезного контента, удобство «может стать залогом вашего успеха».
• И прямым текстом: хорошие результаты в отчётах не гарантируют высоких позиций, и «не нужно стремиться к высоким показателям исключительно в целях поисковой оптимизации».

Яндекс в рекомендациях по скорости тоже не обещает позиций: там сказано, что скорость влияет на уровень доверия к сайту, посещаемость и статистические показатели.

Правильный вывод не «скорость не важна», а другой: скорость — это не рычаг ранжирования, это условие, при котором всё остальное работает. Медленная страница теряет часть людей до первого экрана, и уже это видно в поведении. А при прочих равных она проигрывает соседу.

Что именно измеряют

Это Core Web Vitals — набор, которым Google описывает удобство страницы. INP заменил прежний FID: теперь считается отклик на все действия, а не только на первое.

Отдельно стоит развести два разных «медленно», которые в разговорах путают. В чате это сформулировали точно:

«Я хоть сто картинок накидаю, по одному или сто мегабайт — время ответа не изменится, изменится скорость загрузки страницы для браузера».

Время ответа сервера (TTFB) — как быстро сервер отдал первый байт. Лечится хостингом, кэшем, серверным кодом. Скорость отрисовки — что успело показаться человеку. Лечится картинками, скриптами, шрифтами. Это разные работы и разные подрядчики.

Чем мерить

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

Отсюда частая картина: в PageSpeed зелёные 95 на десктопе, а в отчёте Search Console та же страница в красной зоне. Ошибки нет: проверяли на разном.

Как накручивают баллы

Отдельный сюжет, о котором в чате рассказывали прямо:

«Некоторые поднимают скорость отключением плагинов и кода от PageSpeed: по показателям скорость будет в космосе, а на деле… ну вы поняли».

«В основном делают топорно: отключают всё, и по отчёту скорость в космосе, но на сайте голый HTML».

Механика простая: часть скриптов не исполняется, когда страницу запрашивает известный инструмент проверки. Балл растёт, сайт не меняется.

Как распознать: сравнить оценку PageSpeed с полевыми данными в Search Console и со временем загрузки в Метрике. Если в отчёте 95, а живые посетители ждут четыре секунды — вас оптимизировали для отчёта. И отдельно — просто открыть сайт с телефона на обычном интернете.

Что чинить и в каком порядке

Порядок — от дешёвого и безопасного к дорогому. Список рекомендаций Яндекса совпадает почти построчно.

1. Изображения. Сжать, перевести в современные форматы, задать размеры в вёрстке. Картинка на мегабайт вместо двухсот килобайт — самая частая и самая дешёвая в исправлении причина. Заданные размеры заодно лечат CLS.
2. Отложенная загрузка. Lazy load для всего, что ниже первого экрана, включая видео и карты.
3. Сторонние скрипты. Чаты, пиксели, виджеты, калькуляторы, карусели. Каждый тянет своё, и три чата на сайте — это три чужих сайта внутри вашего. Самая болезненная, но и самая результативная уборка.
4. Шрифты. Подключать только нужные начертания, включить предзагрузку и показ текста до загрузки шрифта.
5. Кэширование и сжатие. Gzip или brotli, заголовки кэширования для статики.
6. CDN для картинок, стилей и скриптов.
7. Минификация и устранение блокирующих ресурсов — то, что мешает отрисовке первого экрана.
8. Серверная часть. Код, запросы к базе, ресурсы хостинга. Сюда идут, когда TTFB высокий, и это уже работа разработчика.
9. Редиректы. Сократить цепочки: каждый шаг — отдельный запрос.
10. Анимации. Только лёгкие, без перерисовки всей страницы.

Что делать не нужно: гнаться за сотней баллов. После зелёной зоны улучшения стоят дорого, а дают всё меньше.

Мерить нужно на телефоне

Очевидная вещь, которую пропускают: большинство людей приходит с телефона, по мобильной сети, на среднем устройстве. Проверка на рабочем ноутбуке с проводным интернетом показывает картину, которой не существует.

В Яндекс Вебмастере индекс скорости считается именно по переходам из мобильного поиска в Яндекс Браузере — то есть по тому, как сайт открывается у живых людей с телефонов.

Случай из чата: когда дальше ломается UX

Реальный вопрос участника: сайт на Тильде, галереи и карусели кейсов, LCP удалось довести до 3,8–4,0 секунды, дальнейшая оптимизация ломает интерфейс. Позиции при этом низкие.

Честный ответ: если упёрлись в ограничения платформы, а LCP около четырёх секунд — это не причина низких позиций, и дальше воевать за десятые доли бессмысленно. Что умеет и чего не умеет Тильда, разобрано отдельно; а низкие позиции при нормальной скорости означают, что дело в другом: в структуре, семантике, содержании страниц.

Правило, которое из этого следует: скорость доводят до «не мешает», а дальше занимаются содержанием. Обратный порядок — самый популярный способ потратить бюджет на красивую цифру.

Чек-лист

1. Открыть сайт с телефона на мобильном интернете. Засечь время до первого экрана.
2. Посмотреть полевые данные: отчёт Core Web Vitals в Search Console, индекс скорости в Яндекс Вебмастере, «Время загрузки страниц» в Метрике.
3. Прогнать через PageSpeed Insights три типа страниц: главную, категорию, карточку или статью.
4. Сравнить лабораторные баллы с полевыми: сильное расхождение — повод проверить, не «оптимизировали» ли отчёт.
5. Найти самые тяжёлые элементы: обычно это картинки и сторонние скрипты.
6. Проверить TTFB: если он высокий, картинками делу не поможешь.
7. Задать размеры изображений и зарезервировать места под баннеры — это CLS.
8. Отключить то, чем не пользуетесь: старые виджеты, дубли счётчиков, неиспользуемые плагины.
9. Перемерить через неделю по полевым данным, а не по лаборатории.
10. Зафиксировать результат в регламенте: скорость легко уезжает обратно после первого же релиза с новым виджетом.

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

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

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

Что такое Core Web Vitals и какие пороги?

Три метрики: LCP — отрисовка самого крупного элемента первого экрана, хорошо при значении менее 2,5 секунды; INP — отклик страницы на действия пользователя, менее 200 миллисекунд; CLS — визуальная стабильность, менее 0,1. INP заменил прежнюю метрику FID и учитывает все взаимодействия, а не только первое.

Чем лабораторные данные отличаются от полевых?

Лабораторные — это один прогон в эмуляторе с заданными условиями, их показывает PageSpeed Insights. Полевые — данные о реальных загрузках у живых пользователей за период; они в отчёте Search Console, в Метрике и в индексе скорости Яндекс Вебмастера. Расхождение между ними нормально, и опираться нужно на полевые.

У меня 95 баллов в PageSpeed, а сайт медленный. Как так?

Чаще всего проверяли десктопную версию на хороших условиях, а люди приходят с телефонов. Второй вариант — страницу «оптимизировали» под инструмент: часть скриптов не исполняется при проверке, балл растёт, сайт не меняется. Проверяется сравнением с полевыми данными и обычным открытием сайта с телефона.

Сколько баллов PageSpeed нужно для SEO?

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

Что чинить в первую очередь?

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

Что такое TTFB и чем он отличается от скорости страницы?

TTFB — время до первого байта, то есть насколько быстро ответил сервер. Скорость страницы — сколько ушло на то, чтобы человек увидел содержимое. Сто тяжёлых картинок не изменят время ответа сервера, но испортят загрузку страницы. Высокий TTFB лечится хостингом, кэшем и серверным кодом, а не оптимизацией изображений.

Где смотреть скорость в Яндексе?

В Яндекс Вебмастере, в разделе «Качество сайта», есть индекс скорости сайта и достижение «Скорость сайта» — он считается по переходам из мобильного поиска в Яндекс Браузере. Дополнительно в Метрике есть отчёт «Мониторинг → Время загрузки страниц» и отчёт о нагрузке на сайт.

Влияет ли скорость на индексацию?

Косвенно. Медленный сайт робот обходит медленнее, и важные изменения дольше попадают в поиск. На больших сайтах это ощутимо; на сайте из тридцати страниц — нет. Скорость обхода у Яндекса настраивается в Вебмастере, директива Crawl-delay для этого больше не работает.

Нужно ли убирать чаты и виджеты ради скорости?

Не убирать, а считать. Каждый виджет — это чужой код, который тянет свои файлы. Если на сайте три способа написать в мессенджер, два счётчика-дубля и забытый калькулятор — это и есть ваши лишние секунды. Оставьте то, чем реально пользуются, и проверьте, можно ли загружать это по клику.

Сайт на конструкторе — можно ли ускорить?

До определённого предела. Конструкторы по умолчанию отдают картинки через CDN с отложенной загрузкой, но тяжёлые зеро-блоки, анимации и видеофоны испортят любую платформу. Когда упёрлись в ограничения и дальше ломается интерфейс — лучше остановиться и заняться содержанием.

Как не растерять результат?

Записать в регламент: новые изображения сжимаются, новые виджеты обсуждаются, после каждого релиза проверяются три типовые страницы. Скорость — не разовая работа: она уезжает обратно с первым же баннером на весь экран.

← Все материалы