«Сайт тормозит» - жалоба, за которой на самом деле стоят три разные метрики с разными причинами и разными способами исправления. Прежде чем что-то ускорять, стоит разобраться, что именно измерять и каким инструментом - иначе легко потратить время не на ту проблему.
Быстрый способ посмотреть техническое состояние сайта целиком, не только скорость - бесплатная проверка домена, в которой есть отдельная вкладка PageSpeed.
Чем измерить скорость сайта бесплатно
PageSpeed Insights официально описан так: «PageSpeed Insights (PSI) reports on the user experience of a page on both mobile and desktop devices, and provides suggestions on how that page may be improved». Показывает пользовательский опыт страницы на мобильных и десктопе и даёт рекомендации по улучшению. Инструмент бесплатный, доступен на pagespeed.web.dev, регистрация не нужна.
GTmetrix и WebPageTest устроены похоже: оба используют движок Google Lighthouse (тот же, что в PSI), дают детальный отчёт с рекомендациями. Первый известен наглядной сводкой по производительности и структуре страницы. WebPageTest даёт возможность выбрать географическую локацию теста и тип соединения (например, мобильная сеть), а также показывает waterfall-диаграмму - на каком именно ресурсе теряется время. Для быстрой проверки одного домена хватит любого из трёх - разница чувствуется, когда нужно тестировать из конкретного региона или сравнивать несколько сайтов подряд.
Что означают LCP, INP и CLS
Дословное определение Google: «LCP reports the render time of the largest image, text block, or video visible in the viewport, relative to when the user first navigated to the page». Пороги: до 2.5 секунды - хорошо, 2.5-4.0 секунды - нужно улучшить, больше 4.0 секунды - плохо. LCP «тянет» в себя задержки ответа сервера и установки соединения - то есть на эту метрику напрямую влияет и качество хостинга, не только вес контента на странице.
С метрикой отклика на действия связана распространённая путаница: если вы встречали аббревиатуру FID - это устаревшее название. INP официально заменил FID 12 марта 2024 года: «Today's the day! After years of work, we're finally ready to make Interaction to Next Paint (INP) a stable Core Web Vital metric». Если статья или инструмент до сих пор упоминает FID как основную метрику - она устарела. Пороги INP: до 200 мс - хорошо, 200-500 мс - нужно улучшить, больше 500 мс - плохо.
CLS считает не сам факт сдвига, а его масштаб: «CLS is a measure of the largest burst of layout shift scores for every unexpected layout shift that occurs during the entire lifecycle of a page». Порог «хорошо» - 0.1 или меньше, «плохо» - больше 0.25. Типичная причина высокого CLS - картинка или блок рекламы без заданных размеров, из-за которых текст «прыгает» вниз уже после того, как читатель начал его читать.
| Метрика | Что измеряет | Хорошо | Нужно улучшить | Плохо |
|---|---|---|---|---|
| LCP | Время появления крупнейшего элемента | ≤ 2.5 с | 2.5-4.0 с | > 4.0 с |
| INP | Отклик на клик/нажатие клавиши | ≤ 200 мс | 200-500 мс | > 500 мс |
| CLS | Насколько сильно «прыгают» элементы | ≤ 0.1 | 0.1-0.25 | > 0.25 |
| TTFB | Время до первого байта от сервера | ≤ 0.8 с | 0.8-1.8 с | > 1.8 с |
Лабораторные данные и реальные - в чём разница
Официальные определения из документации Google: лабораторные данные «determined by loading a web page in a controlled environment with a predefined set of network and device conditions» - получены в контролируемой среде с заранее заданными условиями сети и устройства. Полевые данные «determined by monitoring all users who visit a page and measuring a given set of performance metrics for each one of those users' individual experiences» - собраны из мониторинга всех реальных посетителей страницы. Источник полевых данных называется CrUX (Chrome User Experience Report).
Если у сайта мало посетителей, PageSpeed Insights покажет только лабораторный отчёт - полевых данных просто не наберётся за 28-дневное окно. Разовый лабораторный результат может колебаться от прогона к прогону из-за случайной сетевой задержки на стороне тестового сервера: для диагностики надёжнее сделать несколько замеров подряд, чем судить по одному.
Влияет ли скорость сайта на позиции в поиске
Дословная позиция Google (страница про page experience): «Google Search always seeks to show the most relevant content, even if the page experience is sub-par» - поиск всегда стремится показать наиболее релевантный контент, даже если технический опыт страницы неидеален. Там же: «Core Web Vitals are used by our ranking systems» - метрики действительно учитываются, просто не как единственный или решающий фактор. Часть индустрии интерпретирует это как «скорость важна при прочих равных, когда несколько страниц одинаково релевантны читателю» - разумное предположение, но дословно в официальных материалах Google такой формулировки нет. Это мнение отраслевых изданий, поисковик такой цитаты не давал.
Насколько скорость влияет на удержание и конверсию читателей - другой вопрос, не строго измеримый универсальной цифрой, но логика простая: странице, которая не успевает открыться за разумное время, часть посетителей просто не дожидается.
Посмотреть баллы своего сайта по всем трём метрикам можно прямо сейчас - дальше есть быстрый способ проверить.
WHOIS и возраст домена, CMS, SSL, SEO-теги, DNS, хостинг, чёрные списки и проверка по 152-ФЗ - на одной странице, без регистрации.
Запустить проверку →Быстрый интернет ≠ быстрый сайт: при чём тут TTFB
Официальное определение: «Time to First Byte (TTFB) refers to the time between the browser requesting a page and when it receives the first byte of information from the server» - время между запросом браузера и получением первого байта от сервера. В это время входят DNS-запрос, установка TCP-соединения и TLS-рукопожатие при HTTPS. Порог «плохо» - больше 1.8 секунды.
Рекомендация Google по снижению TTFB прямая: «Reducing latency in connection setup time and on the backend can lower your TTFB» - причина в задержке установки соединения и в работе сервера («backend»), не в канале пользователя. LCP включает в себя задержки TTFB, поэтому медленный сервер тянет вниз сразу обе метрики, сколько бы мегабит ни было у посетителя.
Что чаще всего тормозит сайт
Неоптимизированные изображения. Официальная рекомендация - сжимать изображения и использовать современные форматы (WebP, AVIF). Отдельное предупреждение касается самого крупного изображения на экране, часто это и есть LCP-элемент: «Never lazy-load your LCP image, as that will always lead to unnecessary resource load delay» - его нельзя загружать «лениво», вместо этого лучше пометить как приоритетный (fetchpriority="high").
Блокирующий рендеринг CSS и JS. «Style sheets loaded from the HTML markup will block rendering of all content that follows them». Подключённые стили блокируют отрисовку всего, что идёт после них в разметке, поэтому «критический CSS» (минимальный набор стилей, нужный для отрисовки видимой без прокрутки части страницы) рекомендуют встраивать прямо в HTML, а не грузить отдельным файлом.
Со скриптами похожая история: «It is almost never necessary to add synchronous scripts (scripts without the async or defer attributes) to the <head> of your pages». Синхронные скрипты - те, что браузер обязан выполнить сразу, прежде чем продолжить строить страницу, - в <head> почти никогда не нужны. Для этого есть атрибуты async (загрузить и выполнить скрипт, не дожидаясь остального) и defer (выполнить только после того, как страница построена).
Отсутствие сжатия текстовых файлов. Gzip и особенно Brotli уменьшают вес CSS, JS и HTML на 70-90% для крупных файлов - «both gzip and Brotli perform best on text-based content, often achieving compression rates of as high as 70-90% for larger files». Google прямо рекомендует Brotli как более эффективный вариант там, где он поддерживается сервером.
Медленный сервер и большое расстояние до пользователя. Это и есть TTFB - время до первого байта ответа сервера, решается качественным хостингом и настройкой кэширования.
Отсутствие CDN. Сеть доставки контента хранит копии статичных файлов на серверах в разных точках мира и отдаёт их с ближайшего к посетителю. Официальное объяснение: «Most CDNs have servers all over the globe, so CDN servers may be geographically nearer to your users than your own servers. Geographical distance affects latency proportionally». Это напрямую снижает и TTFB, и общую нагрузку на основной сервер.
Как проверить скорость своего сайта
- Откройте бесплатный анализ домена, перейдите на вкладку PageSpeed
- Посмотрите баллы отдельно для мобильной и десктопной версии - обычно мобильная хуже, это нормально, но не должна быть в зоне «плохо»
- Сравните LCP и CLS с официальными порогами из этой статьи - вкладка PageSpeed показывает именно их, а также TBT (Total Blocking Time), лабораторную метрику отклика; за самим INP, если он нужен отдельно, - на pagespeed.web.dev или в Search Console
- Проверьте список рекомендаций - обычно там сразу видно, что именно весит больше всего
- Если нужен более широкий взгляд на сайт, прогоните технический аудит
Подробнее о том, какую роль скорость и другие технические факторы играют в SEO 2026 года, можно почитать в отдельной статье блога.
Источники
- web.dev, «Largest Contentful Paint (LCP)», обновлено 04.09.2025, https://web.dev/articles/lcp
- web.dev, «Interaction to Next Paint (INP)», обновлено 02.09.2025, https://web.dev/articles/inp
- web.dev blog, «INP становится стабильной Core Web Vital», 12.03.2024, https://web.dev/blog/inp-cwv-launch
- web.dev, «Cumulative Layout Shift (CLS)», https://web.dev/articles/cls
- web.dev, «Lab data vs field data differences», https://web.dev/articles/lab-and-field-data-differences
- Google Search Central, «Understanding page experience in Google Search results», https://developers.google.com/search/docs/appearance/page-experience
- Google Search Central, «Core Web Vitals», https://developers.google.com/search/docs/appearance/core-web-vitals
- Google Developers, «About PageSpeed Insights», https://developers.google.com/speed/docs/insights/v5/about
- Google Search Console Help, «Core Web Vitals report», https://support.google.com/webmasters/answer/9205520
- MDN Web Docs, «Time to first byte», https://developer.mozilla.org/en-US/docs/Glossary/Time_to_first_byte
- web.dev, «Time to First Byte (TTFB)», https://web.dev/articles/ttfb
- web.dev, «Optimize LCP», https://web.dev/articles/optimize-lcp
- web.dev, «Reduce network payloads using text compression», https://web.dev/articles/optimizing-content-efficiency-optimize-encoding-and-transfer
- MDN Web Docs, «CDN (Content Delivery Network)», https://developer.mozilla.org/en-US/docs/Glossary/CDN
Проверьте техническую сторону своего сайта за один запуск - без регистрации и без установки чего-либо.
WHOIS и возраст домена, CMS, SSL, SEO-теги, DNS, хостинг, чёрные списки и проверка по 152-ФЗ - на одной странице, без регистрации.
Запустить проверку →