Как работает Core Web Vitals Checker
Core Web Vitals Checker подходит для первичной проверки страницы, контроля после технических изменений и сравнения мобильной и десктопной версии. Чтобы проверить скорость сайта онлайн, достаточно указать нужный URL, запустить анализ и разобрать результат по отдельным показателям, а не ориентироваться только на итоговый балл.
Core Web Vitals Checker проверяет показатели, связанные со скоростью отображения контента, отзывчивостью интерфейса и стабильностью макета. Такой core web vitals test помогает понять, насколько комфортно страница работает для пользователя и на каком этапе возникает заметная задержка.
Проверка core web vitals особенно полезна вместе с анализом дополнительных метрик производительности. Итоговый отчёт стоит читать последовательно: сначала Core Web Vitals, затем серверный ответ, загрузку критических ресурсов, изображения, CSS, JavaScript и другие элементы, которые могут влиять на результат.
Что показывает проверка Core Web Vitals?
Текущий набор Core Web Vitals включает Largest Contentful Paint, Interaction to Next Paint и Cumulative Layout Shift. Каждая метрика отвечает за отдельную часть пользовательского опыта, поэтому хороший результат по одному показателю не исправляет проблему по другому.
Если доступны реальные данные пользователей, оценку лучше смотреть по 75-му перцентилю. Лабораторный тест удобнее использовать для поиска причины, повторной диагностики после исправлений и сравнения двух версий одной страницы в похожих условиях.
Largest Contentful Paint – LCP
Largest Contentful Paint показывает момент появления крупнейшего видимого элемента основного контента. Чаще всего им становится изображение первого экрана, крупный баннер, заголовок или другой заметный блок.
Хорошим ориентиром считается LCP до 2,5 секунды. Показатель может ухудшаться из-за медленного серверного ответа, тяжёлого hero-изображения, поздней загрузки критических ресурсов, лишнего CSS или неправильного приоритета загрузки основного элемента.
Interaction to Next Paint – INP
Interaction to Next Paint показывает, насколько быстро страница визуально отвечает после клика, касания или другого действия пользователя. Хорошим считается значение INP до 200 мс на 75-м перцентиле.
Задержки часто связаны с большим объёмом JavaScript, длинными задачами основного потока, тяжёлыми обработчиками событий и сторонними библиотеками. Чем дольше браузер занят вычислениями, тем позже пользователь увидит реакцию интерфейса.
Cumulative Layout Shift – CLS
Cumulative Layout Shift оценивает визуальную стабильность страницы. Высокий CLS возникает, когда текст, кнопки, изображения или баннеры неожиданно меняют положение уже после начала загрузки.
Хорошим считается CLS до 0,1. Типичные причины проблемы – изображения без заданных размеров, поздняя подгрузка шрифтов, динамические вставки и блоки, для которых заранее не зарезервировано место в макете.
Как читать результаты PageSpeed и Core Web Vitals?
Итоговый Performance Score удобен для быстрого сравнения, но одной цифры недостаточно для технического вывода. Производительность сайта лучше оценивать по конкретным показателям, данным реальных пользователей и рекомендациям, связанным с причиной проблемы.
Page speed checker стоит использовать как начало диагностики. После отчёта нужно определить проваленные метрики, понять происхождение данных и только затем составлять порядок технических исправлений.
Что означают хорошие, средние и плохие показатели?
Для основных Core Web Vitals применяются пороговые значения, по которым результат делится на хороший, требующий улучшения и плохой. Для field data ориентируются на 75-й перцентиль реальных загрузок страницы.
| Метрика | Хорошо | Требует улучшения | Плохо |
|---|---|---|---|
| LCP | до 2,5 с | более 2,5 до 4 с | более 4 с |
| INP | до 200 мс | более 200 до 500 мс | более 500 мс |
| CLS | до 0,1 | более 0,1 до 0,25 | более 0,25 |
Таблица помогает быстро определить направление работы, но одинаковое значение может иметь разные причины. Например, плохой LCP бывает связан с сервером, изображением, CSS, JavaScript или последовательностью загрузки ресурсов.
Чем Field Data отличается от Lab Data?
Field Data отражает работу страницы у реальных посетителей на разных устройствах и соединениях. Источником могут быть Chrome User Experience Report, собственный Real User Monitoring или другая система сбора фактических пользовательских измерений.
Lab Data получают в контролируемой среде через synthetic test или другой лабораторный сценарий. Такой лабораторный тест удобно запускать сразу после правки, поскольку не приходится ждать накопления новой статистики реальных пользователей.
Что такое Chrome User Experience Report – CrUX?
Chrome User Experience Report, или CrUX, содержит агрегированные реальные данные пользователей Chrome. Они помогают оценить пользовательский опыт и сравнить фактические показатели страницы с результатом лабораторной проверки.
CrUX доступен не для каждого URL, поскольку отдельной странице может не хватать объёма данных. В таком случае проверка core web vitals продолжается с помощью лабораторных измерений, но такой результат нужно воспринимать именно как диагностический срез.
Почему результаты разных тестов отличаются?
Результаты зависят от устройства, сети, географии тестового сервера, состояния кеша, текущей нагрузки серверной части и работы сторонних сервисов. Один и тот же ресурс способен отвечать с разной скоростью даже при двух последовательных запусках.
Поэтому website speed test и pagespeed checker иногда показывают разные цифры для одинакового URL. Сравнивать полезнее несколько тестов, выполненных по одинаковой методике, особенно если цель состоит в оценке результата технической доработки.
я не ориентируюсь только на общий балл PageSpeed. Сначала я смотрю реальные Core Web Vitals – LCP, INP и CLS на 75-м перцентиле, затем использую лабораторный отчёт для поиска причины. Высокий лабораторный балл сам по себе не гарантирует хороших показателей у реальных посетителей.
Что влияет на скорость загрузки страницы?
Проверка скорости загрузки страницы даёт пользу только тогда, когда после цифр понятна причина задержки. На производительность страницы одновременно воздействуют сервер, изображения, стили, сценарии, шрифты, сторонние сервисы и последовательность загрузки ресурсов.
Анализ скорости сайта лучше проводить от серверного ответа к отображению и интерактивности. Такой порядок помогает сначала убрать крупные проблемы, а потом заниматься рекомендациями с небольшим влиянием.
Сервер и TTFB
Медленный серверный ответ задерживает начало всей загрузки. Причиной могут быть сложные запросы к базе данных, отсутствие кеширования, перегруженный сервер, медленный серверный рендеринг или большое расстояние до пользователя.
Для диагностики проверяют серверную часть, кеш, CDN, базу данных и время формирования HTML. Если сервер отвечает слишком долго, оптимизация изображений не устранит главную задержку, поскольку браузер поздно получает исходный документ.
Изображения и медиаконтент
Крупные изображения часто увеличивают общий вес страницы и ухудшают LCP. Стоит использовать реальные размеры отображения, responsive images, форматы WebP или AVIF и оптимизированные файлы без лишнего качества.
Lazy loading подходит для контента ниже первого экрана, но его нельзя механически применять к LCP-изображению. Критическому изображению иногда требуется preload или более высокий приоритет, чтобы браузер начал загрузку раньше.
CSS и JavaScript
Render-blocking resources могут задерживать отображение страницы, а большой объём JavaScript увеличивает нагрузку на основной поток. Во время проверки стоит искать unused CSS, ненужный код, крупные bundle и длительные задачи браузера.
Defer и async помогают переносить выполнение некоторых сценариев, если это безопасно для логики страницы. Любые изменения необходимо проверять после внедрения, чтобы оптимизация не нарушила формы, меню, аналитику или другие функции.
Шрифты
Большое количество начертаний увеличивает число запросов и объём загружаемых файлов. Для оптимизации шрифтов сокращают ненужные варианты, используют font-display, а для критических файлов при необходимости применяют preload.
Шрифты влияют и на визуальную стабильность. Если после загрузки меняются размеры текста, соседние элементы могут смещаться, поэтому работу шрифтов следует проверять вместе с CLS.
Сторонние скрипты
Аналитика, реклама, онлайн-чаты, карты, коллтрекинг и другие внешние сервисы добавляют сетевые запросы и JavaScript. При большом количестве интеграций страница может дольше загружаться и медленнее реагировать на действия.
Удалять каждый сторонний сервис не требуется. Сначала нужно проверить его фактическое влияние, затем изменить момент загрузки, убрать дубли или заменить слишком тяжёлое решение более подходящим вариантом.
Что именно мы делали
Стоматология · Киев и Чернигов
+44% кликов из поиска
Домен без истории, сайт на конструкторе. Собрали семантику под услуги и оба города, переработали посадочные страницы, с нуля построили ссылочный профиль. За четыре месяца: 34,8 тыс. кликов, показы 1,32 → 1,76 млн, DR 0 → 41.
E-commerce · международный рынок
+96% кликов за два месяца
Каталог цифровых 3D-моделей. Кластеризовали семантику, перестроили хабовые страницы, закрыли дубли и ошибки индексации. Пользователи из Google 247 → 532, CTR 2,4% → 4%.
Медицинский центр · Украина
+68,75% видимости за первый месяц
Узкая видимость и малая семантика на старте. Семантика, структура посадочных, метаданные и перелинковка, постепенное усиление ссылками.
Ответы на ваши вопросы
Как проверить скорость сайта онлайн?
Введите полный URL страницы и запустите проверку. После анализа сравните LCP, INP, CLS и дополнительные показатели, затем отдельно посмотрите мобильную и десктопную версию.
Если нужно проверить скорость сайта онлайн после технической правки, используйте тот же URL и сопоставимые условия. Тогда результат легче связать с внесённым изменением.
Что такое Core Web Vitals?
Core Web Vitals – набор метрик Google для оценки загрузки основного контента, отзывчивости интерфейса и визуальной стабильности. Текущий набор включает LCP, INP и CLS.
Прежний First Input Delay, или FID, больше не относится к действующим Core Web Vitals. Его место в текущей оценке отзывчивости занимает INP.
Какие показатели Core Web Vitals считаются хорошими?
Хорошими ориентирами считаются LCP до 2,5 секунды, INP до 200 мс и CLS до 0,1. Для полевых данных эти значения рассматриваются на 75-м перцентиле пользовательских загрузок.
Если одна метрика выходит за допустимый диапазон, сначала нужно искать причину именно этого отклонения. Одновременное исправление всех рекомендаций усложняет проверку результата.
Чем Core Web Vitals отличаются от PageSpeed Score?
Core Web Vitals измеряют отдельные составляющие пользовательского опыта, а PageSpeed Performance Score представляет итоговую лабораторную оценку нескольких показателей.
Высокий общий балл не означает автоматически хорошие field data у реальных посетителей. Поэтому показатели следует анализировать раздельно.
Почему скорость сайта на мобильном ниже, чем на компьютере?
Мобильные устройства сильнее чувствительны к мощности процессора, качеству соединения и объёму JavaScript. Адаптивная версия также может загружать другие изображения, меню или элементы интерфейса.
Если разница заметна, нужно проверить ресурсы первого экрана, сторонние сценарии и работу интерфейса именно в мобильном режиме.
Почему PageSpeed показывает разные результаты при повторной проверке?
Результат зависит от сети, кеша, нагрузки сервера, сторонних сервисов и момента запуска теста. Поэтому небольшие различия между последовательными лабораторными измерениями считаются нормальными.
Для выводов лучше смотреть несколько сопоставимых запусков и устойчивую тенденцию. Один тест не описывает работу страницы во всех условиях.
Почему для страницы нет данных Core Web Vitals?
Для отдельных URL может не хватать пользовательских данных в Chrome User Experience Report. Такая ситуация часто встречается у новых или редко посещаемых страниц.
Страницу всё равно можно проверить в лабораторных условиях и подключить Real User Monitoring при необходимости. Просто эти данные нельзя полностью приравнивать к CrUX.
Влияют ли Core Web Vitals на SEO?
Core Web Vitals учитываются Google в рамках общей оценки пользовательского опыта, но сами по себе не гарантируют высокие позиции. Для органического трафика также нужны релевантный контент, нормальная индексация и технически чистый сайт.
Поэтому проверка скорости остаётся частью технического SEO. Она дополняет остальные работы, а не заменяет их.
Смежные услуги
CMS Detector / Определить CMS сайта
Определите CMS сайта онлайн по домену или URL. CMS Detector проверяет признаки движка, популярных платформ и веб-технологий и показывает результат за несколько секунд.
Проверка индексируемости
Проверьте, доступна ли страница для индексации Google: robots.txt, noindex, canonical, HTTP-статус и другие технические сигналы. Онлайн-проверка индексируемости URL.
Проверка индексации в Google
Проверьте, проиндексирован ли URL или страница сайта в Google. Способы через Search Console, site:, массовый чекер и причины отсутствия страниц в индексе.
Проверка кодов ответа HTTP
HTTP Status Checker от Seo-Gen: проверьте код ответа URL, редиректы и ошибки 4xx/5xx онлайн. Подходит для одной страницы и массовой проверки URL.
Проверка «битых» ссылок
Broken Link Checker от Seo-Gen: найдите битые и неработающие ссылки, 404 ошибки и проблемные URL на сайте. Онлайн-проверка внутренних и внешних ссылок.
Проверка robots.txt
Robots.txt Checker для проверки и анализа файла robots.txt онлайн. Найдите ошибки Allow, Disallow и User-agent, проверьте доступ URL для Googlebot и других поисковых роботов.
Проверка sitemap.xml
Sitemap Checker от Seo-Gen проверяет XML Sitemap онлайн: ошибки структуры, URL, sitemap index, lastmod, лимиты и доступность. Найдите проблемы до отправки карты сайта в Google.
Проверка meta robots
Meta robots Checker проверяет Meta Robots и X-Robots-Tag, находит noindex, nofollow и конфликты директив. Вставьте URL и проверьте настройки страницы.
Проверка canonical
Canonical Checker онлайн: проверьте rel=canonical, целевой URL, HTTP-статус и типовые ошибки канонизации страницы. Быстрая проверка canonical для SEO.
Проверка hreflang
Hreflang Checker от Seo-Gen: проверьте hreflang, x-default, canonical, языковые и региональные коды, обратные ссылки и ошибки URL онлайн.
Core Web Vitals Checker помогает быстро оценить производительность конкретной страницы, проверить LCP, INP, CLS и дополнительные показатели, а затем перейти к технической диагностике причины. Наиболее полезную картину даёт сочетание лабораторной проверки, CrUX и реальных пользовательских данных, когда они доступны.
Укажите URL страницы, запустите проверку скорости сайта и сравните результаты для телефона и компьютера. Исправление лучше начинать с метрик и проблем, которые сильнее всего влияют на реальный пользовательский опыт.
Отвечаем в течение рабочего дня. Без рассылок и звонков «просто напомнить».
Посмотрит сайт сам, а не передаст менеджеру.
Подробнее: Core Web Vitals Checker – проверка скорости сайта
Как проверить скорость сайта онлайн?
Для первичной диагностики не требуется сразу проводить полный технический аудит. Можно выполнить page speed test online, получить основные значения и посмотреть, какие ресурсы или этапы загрузки создают самую заметную задержку.
Такой тест скорости сайта полезен после редизайна, смены шаблона, переноса на новый сервер, подключения аналитики или оптимизации изображений. Повторная проверка позволяет сравнить состояние страницы до и после конкретной доработки.
Как запустить PageSpeed test?
Укажите полный URL нужной страницы и запустите pagespeed test online. После завершения анализа сравните основные показатели, отдельно проверьте мобильную и компьютерную версию, затем откройте рекомендации по найденным проблемам.
Рабочий порядок проверки:
- Введите полный адрес нужной страницы с правильным протоколом и языковой версией.
- Запустите анализ и дождитесь формирования результатов по основным метрикам.
- Сравните мобильную и десктопную версию, если отчёт разделяет эти данные.
- Найдите проблемы, которые сильнее всего влияют на загрузку и взаимодействие.
- После исправлений повторите тест скорости сайта и сравните новые значения.
Один pagespeed checker показывает состояние страницы в конкретных условиях запуска. Для важных URL лучше смотреть несколько сопоставимых измерений и проверять, сохраняется ли улучшение после внесённых изменений.
Что именно проверяет website speed test?
Website speed test рассматривает несколько этапов загрузки страницы, а не одну абстрактную скорость. Website speed checker помогает определить, где возникает проблема: на стороне сервера, во время первого отображения контента или после запуска JavaScript.
Кроме Core Web Vitals, в отчётах могут встречаться First Contentful Paint, Time to First Byte, Total Blocking Time и другие метрики. Они описывают разные этапы загрузки, поэтому каждый показатель нужно интерпретировать отдельно.
First Contentful Paint – FCP
First Contentful Paint показывает момент, когда браузер впервые выводит заметную часть содержимого страницы. Это может быть текст, изображение или другой визуальный элемент, который сообщает пользователю, что загрузка началась.
FCP не входит в текущий набор Core Web Vitals. Высокое значение может указывать на медленный серверный ответ, блокирующий CSS, задержку загрузки шрифтов или другие ресурсы, мешающие раннему отображению содержимого.
Time to First Byte – TTFB
Time to First Byte показывает время до получения первого байта ответа от сервера. На TTFB влияют производительность серверной части, база данных, кеширование, CDN, сеть и географическое расположение сервера.
Высокий TTFB способен ухудшить дальнейшую загрузку, включая LCP. Поэтому анализ скорости сайта стоит начинать с серверной части, если задержка появляется ещё до отображения первого содержимого.
Total Blocking Time – TBT
Total Blocking Time показывает, сколько времени основной поток браузера был занят длинными задачами. В лабораторной диагностике TBT помогает находить тяжёлые JavaScript-сценарии и вычисления, которые мешают странице быстро реагировать.
TBT не относится к текущим Core Web Vitals. Высокое значение обычно требует проверки крупных JavaScript-bundle, сторонних библиотек, ненужных вычислений и сценариев, которые слишком долго занимают основной поток.
Проверка мобильной и десктопной версии
Одинаковая страница может показывать заметно разные результаты на телефоне и компьютере. Мобильные устройства обычно имеют менее производительный процессор, другое соединение и сильнее реагируют на тяжёлый JavaScript, крупные изображения и сторонние виджеты.
Проверка скорости сайта должна учитывать обе версии. Если мобильная версия заметно проигрывает компьютерной, стоит проверить адаптивные изображения, объём сценариев, последовательность загрузки критических ресурсов и работу адаптивных элементов интерфейса.
Как улучшить Core Web Vitals после проверки?
После core web vitals test лучше работать с конкретной проваленной метрикой, а не пытаться одновременно выполнить все рекомендации. Сначала определяется главная причина, затем проверяется масштаб проблемы и только после этого вносятся изменения.
После каждой существенной группы правок полезно снова выполнить тест скорости сайта. Такое сравнение показывает, какая оптимизация действительно повлияла на результат и какие проблемы остаются активными.
Как улучшить LCP?
Сначала нужно определить элемент, который считается Largest Contentful Paint. После этого проверяют TTFB, размер ресурса, приоритет его загрузки, критический CSS, кеширование и наличие блокирующих запросов.
Если LCP связан с hero-изображением, обычно проверяют вес файла, формат и момент начала загрузки. Если задержка начинается на сервере, основной приоритет получают серверная часть, кеш и время формирования HTML.
Как улучшить INP?
Для улучшения INP нужно найти длинные задачи, которые занимают основной поток во время взаимодействия. Частые причины связаны с большим JavaScript, тяжёлыми обработчиками событий, сложным рендерингом и внешними библиотеками.
Крупные задачи разделяют, ненужные вычисления сокращают, а обработчики пользовательских действий проверяют отдельно. Особенно внимательно стоит тестировать формы, фильтры, меню и другие элементы, с которыми посетители взаимодействуют регулярно.
Как уменьшить CLS?
Изображениям и видео следует заранее задавать размеры, а для рекламы и динамического контента резервировать место в макете. Тогда появление нового элемента не заставляет уже показанный контент резко менять положение.
Дополнительно нужно проверить шрифты, уведомления, баннеры и блоки, которые добавляются выше существующего содержимого. Если элемент загружается позже, его будущая область должна быть предусмотрена заранее.
В каком порядке исправлять ошибки?
Сначала исправляют проваленные Core Web Vitals и проблемы, которые повторяются на большом количестве страниц. Затем переходят к медленному серверному ответу, критическим ресурсам, изображениям, JavaScript и сторонним сервисам.
Оптимальный порядок работы:
- Исправить критичные проблемы LCP, INP и CLS на основных посадочных страницах.
- Проверить шаблонные ошибки, которые одновременно затрагивают большое количество URL.
- Устранить задержки сервера, кеширования и загрузки критических ресурсов.
- Оптимизировать изображения, стили, JavaScript и тяжёлые сторонние интеграции.
- Повторить анализ скорости сайта и сравнить результат с исходными значениями.
После такого цикла проще понять реальный эффект правок. Второстепенные рекомендации стоит выполнять после проблем, которые заметно влияют на пользователя и повторяются на ключевых страницах.
Core Web Vitals и SEO
Core Web Vitals учитываются системами Google и связаны с качеством page experience, однако поисковая оценка страницы зависит от множества сигналов. Хорошая скорость не заменяет релевантный контент, корректную индексацию, структуру сайта и внутреннюю перелинковку.
Для SEO производительность особенно важна на страницах, которые получают органический трафик или участвуют в конверсионных сценариях. Техническая оптимизация должна улучшать реальный пользовательский опыт, а не преследовать максимальное число в отдельном тесте.
Влияет ли скорость сайта на позиции в Google?
Скорость и Core Web Vitals могут учитываться при ранжировании, но хорошие показатели не гарантируют первое место. Performance Score нельзя рассматривать как отдельный фактор, который способен компенсировать слабое содержание или несоответствие поисковому запросу.
Проверка скорости сайта входит в технический SEO-контроль и помогает убрать явные проблемы пользовательского опыта. После этого страницу всё равно нужно оценивать по интенту, содержанию, индексации и другим факторам продвижения.
Почему скорость важна кроме SEO?
Быстрая страница раньше показывает содержимое, быстрее реагирует на действия и реже раздражает неожиданными сдвигами. Это влияет на просмотр каталога, заполнение форм, работу фильтров, оформление заявки и другие действия после перехода.
Особенно заметны задержки на мобильных устройствах и нестабильном соединении. Поэтому тест скорости сайта полезен для контроля качества продукта после релизов, независимо от текущих позиций страницы в поисковой выдаче.
PageSpeed Insights, Lighthouse и Search Console – в чём разница?
Google PageSpeed Insights, Lighthouse и Search Console показывают производительность с разных сторон. Первый удобен для проверки конкретного URL, второй помогает проводить лабораторную диагностику, а третий показывает состояние групп страниц по данным Google.
Собственный Core Web Vitals Checker удобно использовать для быстрого первого анализа. После обнаружения проблемы можно переходить к более глубокой диагностике и сравнивать результаты разных источников.
PageSpeed Insights
Google PageSpeed Insights сочетает field data, когда они доступны, с лабораторной диагностикой Lighthouse. Сервис подходит для быстрой проверки страницы и помогает увидеть Core Web Vitals, Performance Score и технические рекомендации.
Page speed test online удобно запускать после доработок или при первичном аудите URL. Для долгосрочной оценки результат лучше дополнять историей реальных пользовательских данных.
Lighthouse
Lighthouse проводит лабораторный аудит и рассчитывает Performance Score на основе набора метрик. Его удобно использовать разработчику для воспроизводимой проверки страницы после изменений в коде, шаблоне или загрузке ресурсов.
Лабораторные данные хорошо подходят для поиска причин, но не заменяют CrUX или собственный RUM. Для полноценной оценки лучше сравнивать оба типа измерений.
Google Search Console
Google Search Console показывает Core Web Vitals report для групп похожих страниц. Отчёт помогает увидеть масштабные проблемы, которые повторяются на шаблонах категорий, карточек, статей или других типов URL.
Для точечной диагностики конкретной причины Search Console недостаточно. Проблемную страницу затем проверяют через специализированный инструмент и разбирают отдельные метрики.
Когда нужен собственный Core Web Vitals Checker?
Собственный инструмент полезен, когда нужно быстро проверить URL, получить основные показатели и определить дальнейшее направление диагностики. Такой сценарий удобен для SEO-специалиста, разработчика или владельца сайта после изменения страницы.
Website speed checker можно использовать перед техническим аудитом, после релиза или при проверке проблемного шаблона. Он сокращает путь от обнаружения медленной страницы до постановки конкретной задачи разработчику.
Когда нужно повторно проводить тест скорости сайта?
Повторная проверка нужна после редизайна, обновления шаблона, переноса на другой сервер, подключения новых скриптов, изменения изображений или крупных правок в клиентской части. Любое такое изменение способно повлиять на загрузку и взаимодействие со страницей.
Проверку стоит запускать после исправления найденной проблемы и сравнивать результат с исходными данными. Для ключевых страниц разовый тест скорости сайта желательно дополнять регулярным мониторингом, потому что один успешный запуск не показывает состояние сайта за длительный период.