Скорость сайта — это не одна цифра
Медленный сайт теряет не только баллы в PageSpeed Insights. Пользователь не дожидается первого экрана, не открывает карточку, не отправляет форму и не доходит до оплаты.
Когда говорят «сайт загружается медленно», в одну фразу часто смешивают несколько проблем: сервер долго отдаёт первый байт, изображения весят больше нужного, JavaScript блокирует поток, шрифты двигают макет, а сторонний чат загружается раньше контента.
Поэтому скорость нужно оценивать на трёх уровнях:
- Инфраструктура: DNS, TLS, сервер, протокол, CDN, кеш и сжатие.
- Архитектура: SSR, SSG, ISR, клиентский JavaScript, API и бандлы.
- Опыт пользователя: LCP, INP, CLS, TTFB и реальные данные посетителей.
Какие показатели проверять в первую очередь
LCP — когда появляется главный контент
Largest Contentful Paint показывает, когда в видимой области появился самый крупный элемент: заголовок, hero-изображение или обложка. Хороший LCP — не более 2,5 секунды на 75-м перцентиле отдельно для мобильных и десктопных пользователей.
INP — насколько быстро сайт реагирует
Interaction to Next Paint измеряет задержку между действием пользователя и следующим визуальным обновлением. Хороший INP — 200 миллисекунд или меньше. Его ухудшают длинные JavaScript-задачи, тяжёлые React-компоненты и лишние перерисовки.
CLS — стабильность макета
Cumulative Layout Shift показывает, насколько элементы сдвигаются во время загрузки. Хороший CLS — 0,1 или меньше. Главные причины — изображения без размеров, поздние баннеры, шрифты и виджеты без зарезервированного места.
TTFB — как быстро отвечает сервер
Time to First Byte — диагностический сигнал, который помогает понять, есть ли проблема в серверном коде, базе, внешнем API, кеше или сетевой цепочке. В PageSpeed до 800 мс считается хорошим ориентиром.
По данным Google, Core Web Vitals проходят, когда LCP, INP и CLS находятся в хорошей зоне на 75-м перцентиле. Подробнее о порогах ↗
Лабораторные и реальные данные
Лабораторный тест Lighthouse загружает страницу в эмулированной среде. Он удобен для разработки: условия повторяемы, а отчёт показывает диагностику и возможный выигрыш.
Полевые данные CrUX и RUM собирают показатели реальных пользователей. Их результат зависит от устройств, сетей, географии, браузеров, рекламных скриптов и поведения посетителей.
10 сервисов для проверки скорости сайта
PageSpeed Insights
Точка входа для публичной страницы: объединяет Lighthouse и реальные данные CrUX, если есть достаточная выборка.
Lighthouse
Проверка локальных, тестовых и закрытых страниц до релиза: Performance, SEO, Accessibility и Best Practices.
Chrome Performance
Показывает длинные JS-задачи, перерисовки, layout shift и работу обработчиков событий.
WebPageTest
Подробный waterfall: DNS, TLS, ожидание ответа, загрузка каждого ресурса и повторный визит.
Яндекс.Вебмастер
Проверка проблем по сайту, мобильной пригодности и группам URL с учётом российского поиска.
Search Console
Core Web Vitals по группам похожих URL. Помогает понять, где нужно исправлять шаблон, а не отдельную страницу.
GTmetrix
Сравнительные тесты, waterfall, история изменений и контроль размера страницы после релизов.
Uptrends
Регулярный мониторинг доступности и скорости из разных локаций. Дополняет, но не заменяет CWV.
Sitespeed.io
Автоматические performance-тесты в CI/CD, чтобы не выпускать версию с регрессией.
RUM-мониторинг
Связывает скорость с URL, устройством, регионом, формой, звонком, покупкой и рекламным источником.
Какой сервис выбрать под задачу
| Сервис | Что проверяет | Данные | Когда использовать | Ограничение |
|---|---|---|---|---|
| PageSpeed Insights | Lighthouse + CrUX | Lab + field | Публичная страница и первичная диагностика | Полевые данные есть не для каждого URL |
| Lighthouse | Performance, SEO, Best Practices | Lab | Локальные и тестовые страницы | Не показывает полный реальный опыт |
| Chrome Performance | Runtime, JS, rendering | Lab | Поиск причин плохого INP и долгих задач | Нужны технические знания |
| WebPageTest | Waterfall, сеть, кеш | Lab | Глубокий анализ загрузки и регионов | Интерфейс сложнее для новичка |
| Search Console | Core Web Vitals по URL-группам | Field | Контроль SEO-шаблонов в динамике | Не подходит для разового теста |
| Яндекс.Вебмастер | Качество и технические сигналы | Field / crawl | Проекты с трафиком из Яндекса | Меньше деталей по frontend runtime |
| GTmetrix | Waterfall и история | Lab | Сравнение версий и регрессии | Результаты зависят от локации |
| Sitespeed.io | Автотесты performance | Lab / CI | Контроль в CI/CD | Нужна техническая настройка |
| Uptrends | Доступность и скорость | Monitor | Регулярный контроль регионов | Не заменяет Core Web Vitals |
| RUM | Реальные действия пользователей | Field | Связь скорости с лидами и продажами | Нужно внедрение и объём данных |
Как проверять скорость правильно
Пошаговый гайд по PageSpeed Insights
- Откройте PageSpeed Insights. Используйте публичный URL конкретной страницы, а не только домен.
- Проверьте Mobile. Затем повторите тест для Desktop и сравните сценарии.
- Посмотрите полевые данные. Отсутствие CrUX означает недостаток выборки, а не автоматически хороший или плохой сайт.
- Проверьте Core Web Vitals. Смотрите LCP, INP и CLS на 75-м перцентиле, а TTFB используйте как диагностический ориентир.
- Откройте Opportunities. Изучите изображения, кеш, JavaScript и критическую цепочку запросов.
- Откройте Diagnostics. Найдите длинные задачи, неиспользованный JS/CSS, блокирующие ресурсы и проблемы с размерами изображений.
- Запишите baseline. Зафиксируйте дату, устройство, результат, URL и ключевые предупреждения.
- Повторите тест после релиза. Сравнивайте не только балл, но и метрики, вес страницы, запросы и конверсии.
Сначала проверяем типовые шаблоны. Если плохой LCP повторяется на сотнях страниц, нужно исправлять компонент или архитектуру, а не вручную оптимизировать отдельные URL.
Что ускоряем на уровне Next.js
От запроса пользователя до отрисовки страницы
Next.js даёт инструменты для SSR, SSG, ISR, кеширования, оптимизации изображений, шрифтов и метаданных. Но сам фреймворк не делает сайт быстрым автоматически: архитектуру нужно спроектировать и измерить.
Rendering
Для каждого типа страницы выбираем статическую генерацию, серверный рендеринг, ISR/revalidation или клиентский компонент. Интерактивность оставляем там, где она действительно нужна.
JavaScript
Переносим контент в Server Components, разделяем клиентские компоненты, используем dynamic import для тяжёлых модулей и уменьшаем JS первого экрана.
Изображения
next/image формирует responsive-версии, поддерживает sizes, lazy loading, placeholder и preload для LCP-изображения. Параметр sizes важен: без него браузер может скачать изображение шире, чем нужно экрану. Документация Next.js ↗
Шрифты и metadata
next/font позволяет self-host шрифты и сократить внешние сетевые запросы. В Next.js также централизуем title, description, canonical, Open Graph, robots, sitemap и JSON-LD. Документация по шрифтам ↗
HTTPS, HTTP/2 и HTTP/3
HTTPS — это не только замок в браузере. Проверяем TLS-сертификат, редиректы, HSTS, mixed content и то, как CDN соединяется с origin.
HTTP/2 уменьшает задержки благодаря мультиплексированию запросов и сжатию заголовков. Проверяем, что сервер и CDN действительно договариваются по HTTP/2, а не просто имеют HTTPS. MDN об HTTP/2 ↗
HTTP/3 работает поверх QUIC и может быть полезен в условиях потерь пакетов и мобильных сетей. Мы не обещаем, что он ускорит любую страницу в два раза: сначала анализируем waterfall, географию и конфигурацию CDN.
Дополнительно настраиваем Brotli, кеш для статических файлов, отдельную политику для HTML и API, CDN-кеш, stale-while-revalidate и условные запросы.
Ускоряем сайт до зелёных Core Web Vitals и 95–100 Lighthouse
Перестраиваем путь от запроса до отрисовки: rendering, JavaScript, изображения, шрифты, сервер, кеш, CDN и сетевой слой. Затем проверяем результат по лабораторным и полевым данным.
Фиксируем URL, устройства, условия теста и исходные метрики до начала работ.
Переносим согласованные шаблоны на SSR, SSG, ISR и управляемый deployment.
Проверяем HTTPS, HTTP/2/3, CDN, TLS, Brotli и кеширование.
Ставим контроль, чтобы новые страницы и виджеты не вернули старые проблемы.
Как проходит работа STOMP
- Baseline-аудит. Проверяем типовые URL на мобильном и десктопе.
- Карта узких мест. Разделяем сеть, сервер, HTML, assets, JavaScript и сторонние сервисы.
- Архитектурное решение. Определяем, что исправить на текущей CMS, а где нужен Next.js.
- Реализация. Настраиваем rendering, кеш, CDN, протоколы, изображения, JS и виджеты.
- Повторный замер. Сравниваем те же URL в тех же условиях.
- Защита от регрессий. Добавляем performance-budget, RUM и релизный чек-лист.
FAQ: 17 вопросов о скорости сайта
Здесь собраны вопросы, которые возникают до, во время и после проверки скорости: от самостоятельного теста в PageSpeed до выбора архитектуры и заказа ускорения.
Откройте PageSpeed Insights, вставьте полный URL и запустите проверку. Сначала выберите Mobile, затем Desktop. Смотрите не только Performance Score, но и LCP, INP, CLS, TTFB, полевые данные и список диагностик. Проверяйте главную и типовые коммерческие страницы отдельно.
Откройте PageSpeed Insights в мобильном браузере, вставьте URL и выберите мобильный отчёт. Для бизнеса важен именно этот сценарий: слабее CPU, медленнее сеть и дороже загрузка тяжёлых изображений и JavaScript. Сравнивайте Mobile и Desktop, но не смешивайте их результаты.
Проверяйте не только главную страницу. В baseline должны попасть категория, карточка товара, поиск, фильтры, корзина и оформление заказа. Отдельно замеряйте действия пользователя: открытие фильтра, добавление в корзину и переход к оплате, потому что скорость клика и INP могут быть плохими даже при быстрой загрузке HTML.
Возьмите публичные URL конкурента и прогоните в PageSpeed Insights или WebPageTest. Сравнивайте одинаковые типы страниц: услугу с услугой, карточку с карточкой. Не делайте вывод по одной главной и учитывайте, что у конкурента может не быть достаточных полевых данных CrUX.
Лабораторный тест зависит от сетевых условий, загрузки сервера, региона Google, кеша, версии Lighthouse и сторонних ресурсов. Поэтому отдельные запуски могут отличаться. Для сравнения сохраняйте одинаковый URL и условия, делайте несколько измерений и смотрите не только балл, но и причины изменения.
PageSpeed Performance Score — лабораторная оценка конкретного запуска. Core Web Vitals — показатели пользовательского опыта: LCP, INP и CLS. Для бизнеса важны оба слоя: Lighthouse помогает отлаживать код, а полевые Core Web Vitals показывают, как сайт работает у реальных людей на 75-м перцентиле.
Ориентиры Google: LCP — до 2,5 секунды, INP — до 200 миллисекунд, CLS — до 0,1. Для TTFB хороший ориентир — до 800 миллисекунд. Lighthouse 90+ считается хорошим лабораторным результатом, но высокий балл не заменяет полевые данные.
Мобильный тест эмулирует более слабое устройство и сеть. Большие изображения, клиентский JavaScript, шрифты, карты и чаты сильнее влияют на такой сценарий. Оптимизация должна начинаться с мобильного первого экрана, а Desktop нужно использовать как отдельный контроль.
Могла проверяться не та страница, у сайта может не быть достаточных полевых данных, а проблема может возникать после загрузки: медленный фильтр, форма, калькулятор, чат или личный кабинет. Проверяйте действия в Chrome Performance и связывайте скорость с реальными событиями в RUM.
Сохраните baseline до работ, протестируйте те же URL в тех же условиях, сравните LCP, INP, CLS, TTFB, вес страницы и количество запросов. После релиза добавьте мониторинг и дождитесь обновления полевых данных. Одного удачного запуска сразу после публикации недостаточно.
Можно оптимизировать изображения, кеш, CDN, Brotli, CSS и JavaScript, отложить виджеты, настроить сервер и базу данных. Сначала проводим аудит. Если узкое место находится в архитектуре рендеринга, ручные оптимизации дадут ограниченный эффект и тогда рассматриваем миграцию.
Да, если проблема в кеше, сервере, шаблоне, изображениях, базе данных или JavaScript. Не нужно переносить сайт только ради самого Next.js. Но если текущая архитектура ограничивает TTFB, SEO-шаблоны, programmatic SEO, rendering и дальнейшее развитие, миграция может быть рациональнее.
HTTPS обеспечивает защищённую передачу и современную сетевую базу. HTTP/2 снижает задержки при загрузке множества ресурсов за счёт мультиплексирования и сжатия заголовков. HTTP/3 поверх QUIC может быть полезен в нестабильных мобильных сетях. Протоколы не исправят тяжёлый JavaScript или медленный backend без комплексной оптимизации.
Не удалять их вслепую. Для каждого скрипта определяем, нужен ли он на первом экране, можно ли загрузить его позже, ограничить по страницам или подключить с подходящей стратегией. Сохраняем необходимые события и уменьшаем влияние на LCP и INP.
Стоимость зависит от CMS, количества шаблонов, состояния сервера, числа интеграций и необходимости миграции. Поэтому сначала делаем Performance Baseline и формируем смету по приоритетам: точечная оптимизация, комплексный Fix, Next.js Migration или постоянный Performance OS.
Аудит обычно занимает несколько рабочих дней. Точечная оптимизация может занять от одной до трёх недель, комплексное ускорение — от трёх до шести недель. Миграция на Next.js рассчитывается отдельно по количеству шаблонов, интеграций, контента и требований к SEO.
Мы фиксируем целевой лабораторный диапазон на согласованных URL и условиях теста, но не обещаем одинаковый балл для любой страницы и любого внешнего сервиса. После релиза контролируем LCP, INP, CLS, TTFB, performance-budget и полевые данные, чтобы новые страницы, виджеты и рекламные интеграции не вернули старые проблемы.