Массовая проверка PageSpeed: как контроль скорости всех страниц помогает ранжированию

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

Что поисковики на самом деле делают со скоростью

Начнём с официальной картины. Google использует Core Web Vitals — LCP, INP и CLS — в своих системах ранжирования: это подтверждено документацией по page experience. Метрики считаются по полевым данным CrUX: 75-й перцентиль реальных пользователей Chrome за скользящие 28 дней. С марта 2024 года метрику FID заменил INP — отзывчивость страницы на взаимодействия, и именно INP сегодня самая частая причина «жёлтых» оценок. Что означает каждая метрика и какие у них пороги, мы подробно разбирали в статье про Core Web Vitals.

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

Утечка внутренней документации Google (ContentWarehouse, 2024) добавила деталей, которых нет в официальных справках. В индексных структурах существует модуль VOLT, который хранит для каждого документа поля mobileCwv и desktopCwv с пометкой «данные используются для изменений ранжирования». И самое интересное: у поля desktopCwv стоит примечание, что в serving-систему оно не передаётся. Если утечка отражает реальность, вывод практический: в ранжировании участвует мобильная скорость — десктопную стоит мониторить, но приоритет оптимизации всегда у мобильной версии.

Яндекс о факторах традиционно молчит («влияние конкретных факторов на ранжирование мы не комментируем»), но действия говорят сами: в Вебмастере есть индекс «Скорость сайта» с пятибалльной шкалой, и считается он по реальным данным — скорости загрузки страниц в Яндекс Браузере при переходах из мобильного поиска. То есть оба поисковика смотрят на полевые мобильные данные реальных людей — не на ваш локальный тест.

Три канала, по которым скорость влияет на позиции

Канал 1 — прямой сигнал. Описан выше: CWV страницы хранятся в индексе и участвуют в ранжировании. Вклад умеренный, но постоянный.

Канал 2 — поведенческий, и он сильнее, чем кажется. Медленная страница порождает «плохие клики»: пользователь кликнул в выдаче, не дождался загрузки, вернулся и выбрал соседний результат. Системы кликовых сигналов Google (в утечке — NavBoost/Craps с полями goodClicks, badClicks и lastLongestClicks) учитывают ровно это: быстрый возврат на выдачу — отрицательный сигнал, «последний долгий клик» — сильнейший положительный. Скорость здесь работает не как «фактор скорости», а как условие, без которого хорошие поведенческие не появятся физически. Медленный сайт проигрывает дважды: чуть-чуть напрямую и сильно — через поведение.

Канал 3 — краулинговый, самый недооценённый. Скорость ответа сервера управляет скоростью обхода: по утечке, механизм ThrottleClient снижает интенсивность сканирования всего домена, когда сервер отвечает медленно (ориентир — TTFB заметно выше полусекунды). Медленный сервер → реже обход → медленнее индексация нового и обновлённого контента. Для новостных разделов и больших каталогов это прямые потери. Что такое TTFB и как его снижать — в отдельном разборе.

Кейсы с цифрами: что даёт ускорение на практике

Коллекция кейсов web.dev — самое честное, что есть по теме: компании публикуют замеры «до и после». Выборка самых показательных:

Обратите внимание на кейс Nykaa: рост именно органического трафика на 28% после работы только над скоростью — это то, что канал 1 и канал 2 дают вместе. Остальные кейсы — про конверсию и поведение, но для SEO они не менее важны: CTR, отказы и глубина — это сырьё поведенческих сигналов. А про цену каждой миллисекунды у нас есть отдельная история — как одна миллисекунда стоила Amazon 1,6 миллиарда.

Почему разовая проверка главной ничего не решает

Теперь к главной ошибке. Типичный «контроль скорости» — прогнать главную через PageSpeed Insights после жалобы или перед отчётом. У этого подхода три фатальных слепых зоны.

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

Деградация ползучая и привязана к релизам. Скорость не падает сама — её роняют: новый баннер, обновлённый плагин, лишний скрипт аналитики, неоптимизированная пачка изображений от контент-менеджера. Каждое изменение стоит «всего» 100–300 миллисекунд, никто не замечает — а через полгода LCP шаблона уполз с 1,8 до 3,5 секунды. Разовая проверка ловит состояние, но не момент падения, а без момента не найти причину.

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

Методика: массовый PageSpeed-контроль за пять шагов

Шаг 1. Инвентаризация шаблонов. Выпишите типы страниц, которые собирают трафик и деньги: главная, категория, карточка товара, статья блога, посадочные рекламы, страница услуги. У типового магазина выходит 5–8 шаблонов, у контент-проекта — 3–5.

Шаг 2. По 1–3 представителя на шаблон. Мерить все 10 000 карточек не нужно — внутри шаблона скорость почти одинакова. Берите типовую страницу, самую тяжёлую (много фото, длинное описание) и самую трафиковую по данным аналитики. Получается список из 10–20 URL — это и есть ваш скоростной портфель.

Шаг 3. Поставить регулярные замеры на весь список разом. Каждому URL — лабораторный PageSpeed-замер по расписанию: раз в сутки — рабочий стандарт (чаще смысла нет — скорость меняется релизами, а не минутами). Обязательно мобильный профиль как приоритетный; десктоп — отдельной проверкой, если аудитория десктопная: оценки Mobile и Desktop считаются по разным профилям сети и CPU и не сравниваются между собой. В Пруфене это тип проверки «Скорость страницы»: массовый импорт позволяет завести весь список одной операцией, а не кликать двадцать форм.

Шаг 4. Пороги и уведомления вместо дашборда, на который никто не смотрит. Контроль работает, только когда о падении сообщают, а не когда его нужно искать. Задайте каждому замеру порог Performance score, ниже которого открывается инцидент, — и уведомление придёт само: «PageSpeed (Mobile): 48 из 100 при пороге 50» говорит всё необходимое. Полезно получать сигнал и о заметной просадке без пробития порога — score 85 → 65 формально «зелёный», но это уже чей-то релиз, который стоит найти. Ориентир для порогов: у Google 90+ считается «хорошо», ниже 50 — «плохо»; стартуйте с порога чуть ниже вашего текущего уровня и подтягивайте по мере оптимизации.

Шаг 5. Реагировать по истории, сверяться с полем. Пришёл сигнал о просадке — открывайте историю замеров: дата падения почти всегда совпадает с релизом, обновлением плагина или новой рекламной вставкой, и виновник находится за минуты, пока изменение ещё свежо в памяти. Список «Что ускорит страницу» из того же Lighthouse-замера сразу показывает, что именно потяжелело. Раз в месяц сверяйтесь с полевыми CWV: лаборатория отвечает «на что способна страница», поле — «что получают люди»; если лаборатория зелёная, а поле жёлтое — у вашей аудитории условия хуже лабораторных, и оптимизировать нужно глубже.

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

Когда массовый контроль покажет, какие шаблоны проседают, лечение обычно сводится к короткому списку. LCP: предзагрузка hero-изображения (rel="preload"), современные форматы вроде WebP, быстрый TTFB. CLS: зарезервированные размеры под баннеры, изображения и рекламные слоты — классический источник сдвигов на коммерческих страницах. INP: меньше JavaScript на старте, тяжёлые виджеты — по требованию, а не при загрузке. Развёрнутые рецепты по каждой метрике — в статье про Core Web Vitals.

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

Как массовая проверка PageSpeed устроена в Пруфене

Всю описанную методику мы собрали в отдельный тип проверки — «Скорость страницы» (группа «Доступность и скорость» в форме создания). Вот как пять шагов из методики ложатся на продукт.

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

Замер. Каждый запуск — полный лабораторный Lighthouse-прогон страницы с выбором устройства: Мобильные или Десктоп. Это осознанно разные проверки, потому что Google меряет два профиля по разным настройкам сети и CPU и оценки между собой не сравниваются; для приоритета достаточно мобильной, для полной картины ставят пару. Интервалы — от 12 часов до недели: скорость меняется релизами, а не минутами, и ежесуточный ритм ловит любую регрессию в день появления.

Пороги и уведомления. У каждой проверки есть настройка «Мин. Performance score»: опустилась страница ниже — открывается инцидент, и приходит сообщение вида «PageSpeed (Mobile): 48 из 100 при пороге 50» в Email, Telegram, Макс или звонком. Отдельный тип уведомления срабатывает на заметную просадку даже без пробития порога — тот самый случай «было 85, стало 65, формально зелёный»: система сообщит и об этом, и о восстановлении. Никакого дашборда, который нужно не забывать открывать.

Разбор. Дашборд проверки показывает всё, что нужно для пятого шага методики, в одном месте: кольцо Performance с дельтой к прошлому замеру, блок полевых Core Web Vitals по реальным пользователям (LCP, CLS, INP со светофорными шкалами — сверка «лаборатория против поля» происходит на одном экране), лабораторные метрики от FCP до TTFB, список «Что ускорит страницу» с оценкой выигрыша по каждому пункту и историю замеров со спарклайном — клик по любой строке истории показывает, каким был отчёт в тот день. Ступенька на спарклайне плюс дата — и виновный релиз находится за минуты. Бонусом тот же замер отдаёт остальные категории Lighthouse: Доступность, Лучшие практики и SEO.

Для команды. У проверки есть гостевая ссылка — отчёт можно отдать разработчику или подрядчику без доступа к кабинету, а кнопка «Перезапустить проверку» позволяет сразу после фикса убедиться, что score вернулся, не дожидаясь планового запуска.

Резюме

Скорость влияет на позиции по трём каналам: прямой CWV-сигнал (мобильный — в приоритете), поведенческие сигналы кликов и скорость обхода роботом. Кейсы показывают отдачу вплоть до +28% органики. Но выигрывает не тот, кто раз в полгода героически «оптимизирует скорость», а тот, кто не даёт ей незаметно деградировать: 10–20 представителей шаблонов, ежесуточный лабораторный замер по каждому, пороги с уведомлениями и ежемесячная сверка с полевыми данными. Скорость — это не проект, а процесс; массовая проверка PageSpeed превращает его из ручного подвига в фоновую рутину.