Почему «скорость» — это не баллы в отчёте
Владельцы сайтов часто приходят с одной и той же картиной: «PageSpeed показывает 85–95, а пользователи жалуются, что «тормозит»». Это не парадокс и не «каприз пользователей». PageSpeed (и Lighthouse) — полезный инструмент, но он измеряет не то же самое, что ощущает человек и что влияет на конверсию.
Если говорить простым языком, реальная скорость — это время до полезного результата в конкретном сценарии: открыть карточку товара, найти нужный фильтр, добавить в корзину, авторизоваться, оплатить. И именно эти сценарии чаще всего не попадают в «красивые» тесты.
Типовые симптомы, которые выглядят как «медленный сайт», даже когда баллы PageSpeed приличные:
- Страница визуально появилась, но кнопки и поля реагируют с задержкой, «не кликается».
- На Wi‑Fi всё нормально, а в мобильной сети 4G/5G — заметно хуже.
- Главная и статьи быстрые, а корзина, поиск, личный кабинет — «вязнут».
- В часы пик сайт заметно медленнее, хотя утром «летает».
- После добавления чата/коллтрекинга/пикселей внезапно выросли отказы.
Из чего складывается производительность: 4 слоя
Чтобы не спорить «про баллы», удобно разложить производительность в рамках поддержки сайта на 4 слоя. Это упрощает диагностику и помогает понять, что чинить первым.
-
Сеть и доставка контента
Время загрузки зависит не только от «сайта», но и от пути до пользователя: DNS, TLS, качество канала, расстояние до сервера, наличие CDN. Один и тот же сайт может быть быстрым в офисе и медленным в дороге.
-
Сервер и бэкенд
Это всё, что происходит до того, как браузер получит первый «осмысленный» ответ: обработка запроса, работа CMS, PHP/Node, очереди, база данных, внешние API, кэш. Если сервер долго «думает», фронтенд не спасёт.
-
Фронтенд и рендеринг
Даже если сервер отдал страницу быстро, браузер ещё должен построить интерфейс: скачать CSS/JS, выполнить скрипты, отрисовать контент. Тяжёлый JS часто превращает «страница загружена» в «страница не готова к работе».
-
Сторонние скрипты и внешние сервисы
Аналитика, пиксели, чаты, коллтрекинг, антифрод, виджеты доставки, карты — всё это может замедлять загрузку и отклик. Проблема в том, что эти части «не ваши», но отвечать перед пользователем всё равно вам.
Что измеряет PageSpeed и почему этого недостаточно
PageSpeed Insights и Lighthouse дают лабораторную оценку: симулируют устройство и сеть, прогоняют страницу по набору правил и метрик и собирают рекомендации. Это полезно, но важно понимать ограничения.
Ключевые ограничения лабораторного теста:
- Тест обычно запускается для одной страницы, а бизнес «живёт» в цепочке страниц и действий.
- Часто не учитывается авторизация, динамика, работа с корзиной, фильтрами, поиском, личным кабинетом.
- В реальной жизни устройства слабее, сеть нестабильнее, а на странице больше «маркетинговых» скриптов.
- Лабораторная «зелень» не покажет деградацию в часы пик и проблемы под нагрузкой.
Поэтому правильная позиция такая: PageSpeed — это индикатор и подсказка, а «истина» — в реальных замерах на ваших пользователях и в ваших сценариях.
Метрики, которые реально связаны с ощущением скорости
Чтобы говорить о скорости предметно, нужны метрики двух типов: пользовательские (что чувствует человек) и технические (что должен лечить инженер).
Пользовательские метрики:
- LCP: когда на экране появился основной контент (для пользователя это «страница показалась»).
- CLS: насколько сильно «прыгает» макет при загрузке (раздражает и приводит к мискликам).
- INP: как быстро интерфейс отвечает на действие (клик, ввод, выбор фильтра).
- Время до результата: сколько секунд нужно, чтобы завершить ключевое действие: найти товар, добавить в корзину, оплатить.
Технические метрики:
- TTFB: время до первого байта: показывает задержку на стороне сервера/сети.
- Время ответа API: задержка и стабильность сервисов (поиск, фильтры, цены, наличие, доставки).
- Ошибки и таймауты: даже редкие сбои «размазывают» скорость и ломают конверсию.
- Размер и число ресурсов: сколько весит страница и сколько запросов делает браузер.
- Cache hit ratio: насколько часто кэш реально срабатывает, а не «настроен на бумаге».
Диагностика без магии: как быстро понять, где узкое место
Ниже — практичный алгоритм, который экономит время и бюджет. Суть: сначала фиксируем сценарии и базовые замеры, затем определяем слой, где «тормозит».
Шаг 1. Выберите «денежные» страницы и сценарии
Сфокусируйтесь на 5–10 точках, которые делают результат:
- страницы входа из рекламы (лендинги, категории, акции);
- категории/фильтры и поиск;
- карточка товара/услуги;
- корзина/оформление/оплата;
- авторизация и личный кабинет (если есть).
Шаг 2. Разделите проблему на «до HTML» и «после HTML»
Это главный разворот мышления. Если браузер долго ждёт первый ответ — проблема в сети/сервере. Если ответ пришёл быстро, но интерфейс «не живой» — проблема на фронтенде или в сторонних скриптах.
Простая подсказка по симптомам:
| Симптом | Чаще всего причина | Что проверить первым |
| Высокий TTFB | сервер, CMS, БД, кэш, внешние API | логи/профилирование, медленные запросы БД, кэширование, таймауты API |
| «Не кликается», лаги при вводе | тяжёлый JS, долгие задачи в main thread, сторонние скрипты | INP, нагрузка JS, порядок загрузки, defer/async, отключение скриптов по одному |
| Плохо в мобильной сети | слишком тяжёлая страница, много запросов, нет CDN | вес изображений, шрифты, количество запросов, CDN, кэш |
| Тормозит поиск/фильтры | медленное API/БД, отсутствие индексов, перегрузка логики | время ответа API, индексы, лимиты, пагинация, кэш результатов |
| В часы пик медленно | нагрузка, очереди, блокировки БД, внешний сервис «плавает» | метрики нагрузки, очереди, p95/p99 latency, rate limiting, деградационные режимы |
Шаг 3. Снимите реальные замеры (RUM) и сравните с лабораторией
Лаборатория отвечает на вопрос «как было бы в идеальных условиях». RUM (Real User Monitoring) отвечает на вопрос «как у ваших пользователей на самом деле». Для бизнеса второй ответ важнее.
Что чинить первым: приоритеты, которые дают быстрый эффект
Ниже — практическая очередь работ. Она построена так, чтобы сначала убрать «ножницы» конверсии (когда страница вроде грузится, но взаимодействовать невозможно), затем стабилизировать бэкенд и API, и только потом заниматься тонкой полировкой.
Приоритет 1. Сторонние скрипты и «маркетинговая нагрузка»
Самый частый источник деградации в 2026 году — не сервер, а скрипты: чат, коллтрекинг, рекламные пиксели, виджеты, антибот. Они грузятся рано, блокируют поток, добавляют запросы и тяжёлый JS.
Что делать в первую очередь:
- перенести не критичные скрипты на позднюю загрузку (после взаимодействия или после первого экрана);
- проверить, какие скрипты реально нужны, а какие «по привычке»;
- включить асинхронную загрузку, отложенные инициализации, загрузку по событию;
- замерить влияние: отключать по одному и смотреть INP/время до интерактивности.
Приоритет 2. Изображения, шрифты и вес страницы
В мобильной сети цена каждого мегабайта выше, чем кажется. Почти всегда есть быстрый выигрыш на изображениях и шрифтах.
Что даёт эффект обычно быстрее всего:
- правильные размеры картинок под реальные контейнеры (а не «всё 2000px на всякий случай»);
- современные форматы и сжатие без потери качества, lazy-load ниже первого экрана;
- ограничение количества подключаемых шрифтов и начертаний;
- предзагрузка критичных ресурсов там, где это оправдано.
Приоритет 3. Критический CSS и рендер-блокирующие ресурсы
Если CSS блокирует отрисовку, пользователь видит «белый экран», даже если сервер быстрый. Цель — быстро показать первый экран и сделать макет стабильным.
Приоритет 4. JS: меньше, позже, дробнее
Тяжёлый JavaScript — главный враг интерактивности. Он может сделать так, что «страница загружена», но браузер занят вычислениями и не отвечает.
Типовые действия:
- убрать лишние библиотеки и дубли;
- включить code splitting и грузить код по маршрутам/виджетам;
- перевести часть логики на сервер там, где это уместно;
- проверить long tasks и оптимизировать обработчики событий (INP).
Приоритет 5. Бэкенд и база данных: лечим TTFB и p95/p99
Если TTFB высокий или «плавает», надо идти в бэкенд: профилирование, логи, трассировка. Важны не средние значения, а хвосты распределения (p95/p99): именно они дают ощущение «то быстро, то тормозит».
Частые причины и быстрые улучшения:
- медленные запросы БД и отсутствие индексов;
- N+1 запросы и лишние выборки;
- отсутствие кэша на результатах, которые повторяются;
- внешние API без таймаутов и деградационного режима;
- тяжёлые операции в синхронном пути (их лучше уводить в очередь/фон).
Приоритет 6. CDN и кеширование как инженерная система, а не галочка
CDN и кэширование работают, только если их правильно «подпитывать»: версионирование статики, грамотные заголовки кеша, контролируемая инвалидация. Неправильный кэш создаёт ложное ощущение скорости и приносит баги.
Чек-лист «ускорить за неделю»: 12 действий с максимальной отдачей
- Составить список 5–10 ключевых сценариев и URL, которые влияют на деньги.
- Снять базовые замеры: TTFB, LCP, INP, процент ошибок и таймаутов по API.
- Проверить список сторонних скриптов: что можно убрать, что отложить.
- Отложить инициализацию чатов/виджетов до взаимодействия пользователя.
- Оптимизировать изображения: размер под контейнер, сжатие, lazy-load.
- Ограничить шрифты: меньше семейств и начертаний.
- Убрать рендер-блокирующий CSS/JS, вынести критический CSS.
- Разрезать JS по маршрутам, убрать тяжёлые библиотеки, проверить long tasks.
- Настроить кэширование статики и повторяющихся данных, проверить cache hit ratio.
- Профилировать «денежные» запросы: медленные SQL, индексы, N+1.
- Ограничить и стабилизировать внешние API: таймауты, ретраи, деградационные режимы.
- Проверить поведение в часы пик: p95/p99 задержек, очереди, лимиты.
FAQ
Почему PageSpeed 90, а пользователи жалуются на тормоза?
Потому что лабораторный тест оценивает страницу «в среднем», а пользователи сталкиваются с конкретными сценариями: авторизация, фильтры, корзина, нестабильная сеть, слабые устройства и сторонние скрипты. Баллы могут быть зелёными, а интерфейс — неинтерактивным из-за тяжёлого JS или виджетов.
Что важнее: TTFB или Core Web Vitals?
Зависит от симптома. Высокий TTFB лечится бэкендом/БД/кэшем и влияет на всё сразу. Core Web Vitals (LCP/CLS/INP) чаще указывают на фронтенд, вес страницы и отклик интерфейса. В идеале вы контролируете оба слоя, но приоритизируете по «денежным» сценариям.
Нужно ли сразу покупать более мощный сервер?
Часто нет. Сначала стоит убедиться, что тормоза не в JS, картинках, сторонних скриптах, медленных запросах БД и внешних API. Апгрейд сервера помогает, когда доказана серверная проблема под нагрузкой (по метрикам и логам), а не «на ощущениях».
Как понять, что тормозит: сервер или фронтенд?
Если долго растёт TTFB — это сеть/сервер. Если TTFB нормальный, но «не кликается» и ввод лагает — это фронтенд/JS/сторонние скрипты. Практический тест: временно отключить часть скриптов и сравнить INP/время до интерактивности.
Что чаще всего замедляет интернет-магазин?
Корзина и оформление: внешние интеграции (доставка/оплата), тяжёлые скрипты, медленный поиск/фильтры, отсутствие кэширования и индексов в БД, а также пиковая нагрузка в «горячие» часы.
С чего начать, если времени мало?
Снять базовые замеры на 5 ключевых страницах, собрать список сторонних скриптов и оптимизировать изображения. Это три действия, которые чаще всего дают быстрый измеримый прирост без переработки архитектуры.
Вывод
PageSpeed полезен, но он не равен реальной скорости. Производительность — это стабильное и быстрое выполнение ключевых сценариев у реальных пользователей. Чтобы улучшения давали эффект, нужно: (1) измерять сценарии, (2) понимать слой проблемы, (3) чинить по приоритету — сначала интерактивность и внешние скрипты, затем вес страницы и фронтенд, затем бэкенд/БД и устойчивость под нагрузкой.
Если делать одно действие сегодня: выберите 5–10 ключевых страниц, снимите TTFB + LCP/INP по реальным пользователям и составьте список сторонних скриптов. Этого достаточно, чтобы зафиксировать «карту проблем» и начать чинить то, что действительно влияет на скорость и конверсию.
