Скорость сайта и Core Web Vitals: как проверить сайт на скорость и что из этого видит нейросеть
Проверить сайт на скорость можно за пять минут: PageSpeed Insights покажет полевые данные Chrome UX Report и три метрики Core Web Vitals — LCP, INP и CLS. Google считает страницу быстрой, если у 75% визитов LCP укладывается в 2,5 секунды, INP — в 200 миллисекунд, а CLS не превышает 0,1. Для нейросетей эти цифры напрямую не работают: ChatGPT, Алиса и Perplexity не открывают браузер и не измеряют отрисовку. Им важно другое — как быстро сервер отдаёт HTML и остаётся ли в этом HTML текст без исполнения JavaScript. Ниже — чем проверять, что чинить первым и где скорость действительно влияет на попадание в нейроответ.
Core Web Vitals измеряют опыт живых пользователей, а не оценку Lighthouse
Core Web Vitals — три метрики, которыми Google описывает, каким сайт ощущается для человека. LCP (Largest Contentful Paint) — момент, когда отрисовался самый крупный видимый элемент: обычно это главная картинка или заголовок. INP (Interaction to Next Paint) — задержка между действием пользователя и реакцией интерфейса. CLS (Cumulative Layout Shift) — насколько макет прыгает, пока идёт загрузка. 12 марта 2024 года Google заменил в этой тройке FID на INP: FID мерил только первую реакцию страницы, INP смотрит на все взаимодействия за визит.
Пороги опубликованы в документации Google на web.dev. Страница считается быстрой, если значения укладываются в норму у 75-го перцентиля визитов — то есть у трёх четвертей пользователей, а не в среднем. Мобильные и десктопные данные считаются отдельно, и расходятся они почти всегда.
| Метрика | Что измеряет | Хорошо | Требует улучшения | Плохо |
|---|---|---|---|---|
| LCP | Отрисовка главного элемента экрана | до 2,5 с | 2,5–4,0 с | больше 4,0 с |
| INP | Отзывчивость на клик, тап, ввод | до 200 мс | 200–500 мс | больше 500 мс |
| CLS | Сдвиги макета во время загрузки | до 0,1 | 0,1–0,25 | больше 0,25 |
Источник порогов: Google, документация Core Web Vitals на web.dev (проверено в августе 2026).
Поле и лаборатория — это разные цифры
Полевые данные берутся из Chrome UX Report (CrUX): реальные визиты пользователей Chrome за последние 28 дней. Лабораторные — это Lighthouse: один прогон на эмулированном устройстве и искусственно замедленной сети. Оценка от 0 до 100, которую все привыкли называть «пейджспид», — вообще не Core Web Vitals, а взвешенная сводка лабораторных метрик. Поэтому сайт с зелёными 95 очками спокойно проваливается по полевому LCP: живые люди заходят с телефонов и мобильного интернета, а не из дата-центра.
В англоязычных инструментах то же самое называют page speed, site speed или website speed — терминология разная, метрики одни и те же. По-русски обычно говорят «скорость загрузки сайта» или «проверка скорости сайта», и дальше в статье я использую именно эти слова.
Обновлено: август 2026 — пересобрал раздел про инструменты: полевой блок в PageSpeed Insights берётся из CrUX и у сайтов с небольшим трафиком его просто нет, а отзывчивость с 2024 года меряется через INP, а не FID. Добавил разбор того, что из скорости вообще способен увидеть AI-краулер, — этого в прошлой версии не было.
Чем проверить сайт на скорость: шесть инструментов и их слепые зоны
Проверить сайт на скорость можно за пять минут, но одним инструментом не обойтись: каждый показывает свой срез. Полевые данные отвечают на вопрос «как у людей», лабораторные — «что именно тормозит», серверные — «сколько ждёт робот». Ниже — что реально даёт каждый и чего от него ждать не стоит.
| Инструмент | Тип данных | Что показывает | Слепая зона |
|---|---|---|---|
| PageSpeed Insights | Поле (CrUX) + лаборатория | LCP, INP, CLS по конкретному URL и по домену, плюс список причин | Полевого блока нет, если визитов мало |
| Lighthouse в Chrome DevTools | Лаборатория | Что именно тормозит отрисовку, по шагам | Эмуляция; результат скачет от прогона к прогону |
| Search Console, отчёт Core Web Vitals | Поле (CrUX) | Группы URL с плохими показателями по всему сайту сразу | Данные приходят с задержкой, нужен подтверждённый доступ |
| WebPageTest | Лаборатория | Замер из выбранного региона и на выбранном устройстве, waterfall запросов | Нужно уметь читать waterfall, иначе бесполезен |
| Яндекс Метрика, время загрузки страниц | Поле (ваши посетители) | Реальное время по всем браузерам, а не только по Chrome | Метрики Яндекса не совпадают с Core Web Vitals один в один |
| curl или вкладка Network | Сервер | TTFB и размер исходного HTML — то, что получает робот | Ничего не говорит про отрисовку и интерфейс |
Проверять скорость нужно не на одной странице. Берите 3–5 типов: главная, раздел каталога, карточка товара или услуги, статья, страница с формой. Главная почти всегда быстрее остальных — её вылизывают первой, и по ней легко сделать неверный вывод про весь сайт. Отдельно смотрите мобильную вкладку и делайте по три прогона: разброс лабораторных замеров нормален. Какой сервис под какую задачу и где у бесплатных инструментов заканчивается польза — разбирал отдельно в материале про бесплатные сервисы проверки сайта.
Очки — не метрика
Оценка 0–100 в Lighthouse не входит в Core Web Vitals и не является тем, что видят поисковые системы. Просьба «сделайте нам 100 из 100» почти всегда означает, что бюджет уйдёт на косметику, а сервер как отвечал долго, так и будет отвечать.
Нейросети не измеряют скорость сайта — они спотыкаются о её причины
Ни ChatGPT, ни Алиса, ни Perplexity не открывают ваш сайт в браузере и не считают LCP. Путь до нейроответа другой: модель формулирует поисковые запросы, забирает выдачу, скачивает несколько страниц и вытаскивает из них текст. Во всей этой цепочке от «скорости» остаётся ровно два места, где она что-то решает, — и оба они не про красивые очки.
Первое: сервер должен успеть отдать HTML
AI-краулеры — GPTBot и OAI-SearchBot у OpenAI, PerplexityBot, ClaudeBot, Google-Extended, боты Яндекса — ходят по сайту как обычные HTTP-клиенты. Если сервер думает над первым байтом слишком долго или под нагрузкой отдаёт 5xx, страница просто не попадает в набор источников: робот не будет ждать и не вернётся уговаривать. TTFB — единственная часть «скорости», которая касается краулера напрямую. Рядом лежит вопрос доступа: заблокированный в robots.txt бот не увидит и мгновенный сайт, об этом — отдельный разбор про robots.txt и AI-краулеров.
Второе: текст должен быть в исходном HTML
Публичных подтверждений, что AI-краулеры массово исполняют JavaScript, нет — в отличие от Googlebot, который рендерить умеет. В аудитах мы исходим из худшего сценария и называем это правилом голого HTML: если контент появляется только после исполнения скриптов, для нейросети его не существует. Проверяется бесплатно и за минуту — откройте исходный код страницы или отключите JavaScript в DevTools. То, что осталось, и есть ваш сайт глазами робота. Как боты вообще обходят и индексируют страницы, подробнее — в материале про индексацию сайта.
GEO и SEO отвечают на разные вопросы
SEO — про позиции в Яндексе и Google. GEO — про то, назовёт ли нейросеть ваш бренд в ответе пользователю. Скорость влияет на оба слоя, но по-разному: в SEO — как часть страничного опыта и поведения посетителей, в GEO — как условие того, что робот вообще дочитает страницу. GEO работает поверх SEO, а не вместо него: нейроответ чаще всего собирается из источников, которые уже видны в обычной выдаче.
Отсюда второй, косвенный канал влияния. Медленный сайт хуже удерживает людей и слабее ранжируется — значит, реже оказывается в том самом топе, из которого нейросеть набирает источники. Скорость тут не самостоятельный фактор доверия, а условие входа. Какие сигналы реально влияют на выбор источника, я разбирал в статье про алгоритмы доверия AI.
Шесть точек, где скорость ломается чаще всего
В техническом аудите мы начинаем не с картинок, а с двух замеров: сколько сервер думает над пустым запросом и сколько текста остаётся в HTML без JavaScript. Дальше идём по списку — он почти не меняется от проекта к проекту.
- Сервер и хостинг. Долгий TTFB на дешёвом shared-хостинге или тяжёлой CMS без кэша — самая частая причина. Сжатие картинок это не лечит: страница начинает грузиться позже, чем вы что-то оптимизировали.
- Рендеринг на клиенте. Каталоги, карточки и калькуляторы, которые собираются в браузере из API. Пользователь дождётся, робот — нет.
- Изображения. Оригиналы по несколько мегабайт, нет WebP или AVIF, не заданы width и height. Это сразу два провала: LCP и CLS.
- Шрифты. Кастомные шрифты без font-display: swap дают невидимый текст в первые секунды и сдвиг макета, когда шрифт наконец приехал.
- Сторонние скрипты. Чаты, коллбэк-виджеты, пиксели, счётчики, карты. Каждый добавляет запросы и, что важнее, забирает главный поток — от этого растёт INP.
- Кэш и CDN. Нет кэша на уровне веб-сервера и раздачи статики через CDN — каждый визит пересчитывает страницу с нуля, включая визит краулера.
Ещё одно наблюдение из практики: тяжёлые корпоративные сайты чаще проваливают INP, а не LCP. Главную страницу доводят до зелёного, а внутренние — со слайдерами, табами и формами подбора — никто не мерил ни разу. Между тем именно внутренние страницы отвечают на конкретные вопросы, и именно их скачивает AI-краулер. До них робот к тому же может просто не дойти, если путь обрывают битые ссылки и цепочки редиректов: каждое лишнее перенаправление — это дополнительный запрос и ещё один шанс потерять краулер на таймауте.
За 150+ аудитов я почти не встречал сайта, который медленный по одной причине. Обычно это связка: сервер долго думает над первым ответом, поверх висят несколько сторонних виджетов, а каталог дорисовывается скриптом уже в браузере. Самый показательный момент любого аудита — когда мы отключаем JavaScript и от страницы остаются меню и заголовок. Для человека сайт выглядит нормально. Для AI-краулера он пустой.
Что чинить первым: приоритет по эффекту, а не по очкам
Список работ по скорости легко раздувается до полугода. Чтобы этого не случилось, я развожу задачи по двум колонкам: что это даёт человеку и поисковику и что это даёт для попадания в нейроответ. Колонки совпадают далеко не всегда.
| Что чинить | Метрика | Эффект для пользователя и SEO | Эффект для GEO | Сложность |
|---|---|---|---|---|
| Серверный кэш и CDN | TTFB, LCP | Быстрее первый экран на всех страницах сразу | Высокий: робот стабильно получает HTML и успевает обойти больше страниц | Низкая — средняя |
| Серверный рендеринг или пререндер ключевых страниц | LCP | Контент виден сразу, без ожидания скриптов | Максимальный: текст попадает в голый HTML, без него цитировать нечего | Высокая |
| Современные форматы и сжатие картинок | LCP, вес | Заметно быстрее мобильная загрузка | Почти нулевой | Низкая |
| Размеры у изображений, резерв под баннеры | CLS | Макет перестаёт прыгать под пальцем | Нулевой | Низкая |
| Ревизия сторонних скриптов | INP | Интерфейс отзывчивее, меньше отказов | Косвенный: чище разметка, меньше мусора в HTML | Средняя |
| Шрифты: font-display и предзагрузка | LCP, CLS | Текст виден с первой секунды | Нулевой | Низкая |
Читается таблица просто: для GEO из шести строк работают две верхние. Всё остальное — про пользователя и классическое SEO, и это тоже нужно, но в другом порядке. Тратить месяц на шрифты, пока каталог не отдаётся в HTML, — потерянный месяц.
- Замерить TTFB на 5–10 URL разных типов, отдельно с мобильного профиля и в час пик.
- Включить серверный кэш и отдавать статику через CDN — это самая дешёвая по трудозатратам победа.
- Проверить голый HTML: остаётся ли основной текст без JavaScript. Если нет — серверный рендеринг или пререндер хотя бы для страниц, по которым вы хотите попадать в нейроответы.
- Привести в порядок изображения: форматы, реальные размеры, ленивая загрузка для всего, кроме главного изображения первого экрана.
- Разобрать сторонние скрипты: что грузится, когда и можно ли отложить до взаимодействия.
- Проверить машиночитаемый слой — разметку Schema.org и файл llms.txt: быстрый сайт без разметки нейросети всё равно читают хуже.
- Повторить замер не раньше чем через 28 дней — полевые данные обновляются скользящим окном, раньше вы увидите старую картину.
Классический выстрел в ногу
Ленивая загрузка главного изображения. Атрибут loading="lazy" на картинке первого экрана откладывает то самое изображение, по которому считается LCP, и метрика становится хуже, чем была до оптимизации. Ленивую загрузку ставят на всё, что ниже первого экрана, и только туда.
Если разбирать это самостоятельно некогда, весь технический слой мы закрываем за один заход — технический GEO-аудит из 42 пунктов, от 40 000 ₽: доступность для AI-краулеров, рендеринг, разметка и скорость в одном отчёте с приоритетами.
Что делать, если полевых данных нет вообще
Частая история у промышленных, юридических и B2B-сайтов: открываешь PageSpeed Insights, а блока с данными реальных пользователей нет. Это не поломка инструмента. CrUX набирает выборку только по сайтам, у которых достаточно визитов из Chrome с включённой отправкой статистики. Мало трафика — нет выборки, и никакие настройки этого не изменят.
Что делать в этой ситуации:
- Посмотреть данные на уровне домена, а не конкретного URL: иногда выборка набирается по сайту целиком, хотя по отдельной странице её нет.
- Опереться на Яндекс Метрику — отчёт по времени загрузки страниц строится по вашим посетителям и не зависит от доли Chrome.
- Считать TTFB и вес страницы напрямую: эти цифры не требуют никакой выборки и меряются одной командой.
- Использовать лабораторные прогоны как относительную шкалу. Важно не абсолютное число, а ответ на вопрос «стало быстрее или медленнее после релиза».
И трезвая мысль напоследок: если сайт нейросети ещё не цитируют, полевой LCP — не первая ваша проблема. Сначала голый HTML, разметка и наличие материалов, которые отвечают на вопросы аудитории. Скорость встаёт в очередь после них. С какой проверки начинать в такой ситуации, помогает решить разбор пяти видов GEO-аудита: экспресс-диагностика отвечает на вопрос, называют ли бренд вообще, а технический аудит — читается ли сайт роботами.
Когда скорость чинить не нужно
Скорость — гигиена, а не рычаг роста. Есть ситуации, где вкладываться в неё рано, и честнее сказать об этом прямо, чем продать оптимизацию.
- Сайта нет в топ-20 и нет контента под вопросы клиентов. Быстрая пустая страница не станет источником для нейроответа — цитировать в ней нечего.
- Проблема в упоминаниях, а не в технике. Если бренда нет в каталогах, отзовиках и отраслевых обзорах, ускорение сайта на это не влияет вообще никак.
- Показатели уже зелёные. Выжимать LCP с 2,0 до 1,6 секунды ради очков — работа ради отчёта. Порог у Google один, и вы за ним уже находитесь.
- Одностраничный лендинг под платный трафик. Там метрика — конверсия и цена заявки; их и надо смотреть, а Core Web Vitals пойдут прицепом.
Что точно не сработает
- Плагин-ускоритель на CMS. Обычно он склеивает и минифицирует скрипты, ломая половину интерфейса, и не трогает главную причину — сервер.
- Гонка за 100 из 100. Это лабораторная оценка одного прогона на эмулированном устройстве. На полевые метрики она влияет опосредованно, на цитируемость — никак.
- Отключение аналитики ради очков. Потеря данных стоит дороже выигранных миллисекунд, а решения потом принимать не на чем.
- Ускорение вместо контента. Мы регулярно видим сайты с идеальными показателями, на которых нет ни одного фрагмента, пригодного для цитирования. Что должно быть на сайте до разговора о скорости — в чек-листе GEO-аудита.
Скорость не компенсирует отсутствие ответа
Нейросеть цитирует место, где уже лежит готовый фрагмент ответа на вопрос пользователя. Скорость определяет только одно — дойдёт ли робот до этого фрагмента и успеет ли его забрать. Если фрагмента нет, ускорять нечего.
Как мы связываем скорость с AI-видимостью
В техническом аудите скорость — один из блоков, и мы всегда фиксируем «до» и «после» по одинаковому набору замеров. Иначе через два месяца невозможно понять, что дало эффект, а что было совпадением.
- TTFB по 5–10 URL разных типов, отдельно с мобильного профиля.
- LCP, INP и CLS по полевым данным, если они есть, и лабораторно — если выборки нет.
- Доля основного текста, которая остаётся в HTML без JavaScript. Это и есть правило голого HTML в цифрах: сколько процентов страницы видит робот.
- Доступность для AI-краулеров: ответы сервера на запросы ботов, правила в robots.txt, наличие llms.txt.
- AI Visibility Score — сколько ответов нейросетей по нашему списку запросов упоминают бренд и в какой формулировке.
Прямую связку «ускорили сайт — стали чаще цитировать» не покажет ни один инструмент, и обещать её было бы нечестно. Что мы видим в работе: когда текст начинает отдаваться в исходном HTML, а сервер перестаёт тормозить, страницы стабильнее попадают в набор источников, из которых собирается ответ. Дальше решают контент, разметка и репутация бренда — скорость только открывает дверь.
Практический минимум, с которого стоит начать: проверить сайт на скорость по пяти типовым страницам, посмотреть исходный код без JavaScript и сравнить два числа — TTFB и долю текста в голом HTML. Если второе число ниже половины, вопрос скорости для нейросетей у вас решается не на сервере, а в шаблонах.
FAQ
Как бесплатно проверить сайт на скорость?
Откройте PageSpeed Insights и введите адрес страницы — сервис бесплатно покажет полевые данные Chrome UX Report и лабораторный прогон Lighthouse. Дополнительно: отчёт Core Web Vitals в Google Search Console показывает проблемные группы URL по всему сайту, а Яндекс Метрика — время загрузки по вашим реальным посетителям. Проверять стоит 3–5 типов страниц, а не только главную: она почти всегда быстрее остальных.
Какие значения Core Web Vitals считаются нормой?
По документации Google на web.dev: LCP — до 2,5 секунды, INP — до 200 миллисекунд, CLS — до 0,1. Важное условие: значение должно укладываться в порог у 75-го перцентиля визитов, то есть у трёх четвертей пользователей, а не в среднем. Мобильные и десктопные данные оцениваются отдельно.
Влияет ли скорость загрузки сайта на попадание в ответы ChatGPT и Алисы?
Напрямую нет: нейросети не открывают сайт в браузере и не считают LCP или CLS. Косвенно влияет через две вещи — время ответа сервера (медленный или падающий сервер краулер просто пропускает) и позиции в обычной выдаче, из которой AI-платформы набирают источники. То есть скорость — условие входа, а не фактор ранжирования в нейроответе.
Что важнее для нейросети — скорость или разметка?
Разметка и наличие текста в исходном HTML важнее. Если контент дорисовывается JavaScript, для AI-краулера страница пустая независимо от того, за сколько миллисекунд она отрисовалась у человека. Из всей скорости критичен только один параметр — TTFB: сервер должен успеть отдать HTML. Подробный разбор технического слоя — на странице технического GEO-аудита.
Почему PageSpeed показывает 90+, а сайт всё равно кажется медленным?
Оценка 0–100 — это лабораторный прогон на эмулированном устройстве, а не то, что происходит у ваших посетителей. Полевые данные CrUX собираются по реальным визитам за 28 дней и часто выглядят хуже. Ещё одна причина — проверяют главную страницу, а тормозят внутренние: каталог, карточки, страницы с формами и калькуляторами.
Как часто проверять скорость сайта?
Раз в месяц для регулярного контроля и обязательно после каждого крупного релиза или установки нового виджета. Реже смысла нет, чаще — тоже: полевые данные обновляются скользящим окном в 28 дней, и изменения раньше этого срока в отчёте не появятся. TTFB и вес страницы при этом можно мерить хоть каждый день, они считаются мгновенно.