Сайт в PageSpeed зелёный, а заявки падают: как проверить скорость по-настоящему

Проверить скорость сайта можно за 10 минут: прогоните главную, карточку товара и страницу с формой через PageSpeed Insights и читайте блок с данными реальных пользователей: LCP, INP, CLS. Рядом замерьте время ответа сервера. Общий балл мало что говорит, потому что его считает лабораторный тест на эмулированном среднем телефоне.

💸 Что теряет бизнес, пока все смотрят на балл

Клик в Яндекс Директе оплачен в тот момент, когда человек нажал на объявление. Если первый экран не появился за пару секунд, он закрывает вкладку. Вы заплатили за визит, которого фактически не было, а в отчёте он числится отказом. Дальше начинается самое неприятное: маркетолог переписывает объявления и меняет ставки, хотя проблема в странице.

Вторая потеря тише. Форма заявки на смартфоне не откликается, пока грузится чат. Клиент не станет писать претензию, он вернётся в выдачу и откроет сайт конкурента. Когда заявок в неделю немного, каждая потерянная заметна в выручке отдела продаж.

Третья потеря идёт через поиск. Google включает Core Web Vitals в оценку качества страницы, а поисковики следят за поведением посетителей: человек, который быстро ушёл, подаёт плохой сигнал. Медленный сайт одновременно дороже в рекламе и слабее в органике.

🔬 Лабораторные данные и реальные визиты: чем что измерять

Замеры бывают двух типов. Лабораторные снимают одну загрузку в контролируемых условиях, их удобно повторять до и после правок. Полевые собирают данные с реальных визитов и показывают, что видели клиенты. Нужны оба типа, но складывать их в один балл нельзя.

Google оценивает страницу по трём метрикам Core Web Vitals. LCP — время появления самого крупного элемента первого экрана, обычно главной картинки или заголовка; порог «хорошо» до 2,5 с. INP — задержка реакции на клик или касание, порог до 200 мс. CLS — насколько вёрстка прыгает, пока страница грузится, порог до 0,1. Оценка идёт по 75-му перцентилю: в пороги должны укладываться три визита из четырёх.

Четвёртый показатель, TTFB, в Core Web Vitals не входит, но задаёт потолок для остальных: пока сервер отвечает медленно, ни одна сжатая картинка не поможет. Ориентир Google для «хорошо» — до 800 мс.

Для первой проверки хватает четырёх инструментов.

Порядок работы такой: PageSpeed Insights даёт общую картину, Метрика подтверждает её на ваших визитах, WebPageTest и DevTools объясняют причину. Если реальных данных в PageSpeed нет, потому что у страницы мало трафика, опирайтесь на Метрику и помните, что лабораторный балл остаётся оценкой, а не фактом.

Когда лаборатория и реальные данные расходятся, верьте реальным. Лаборатория подсказывает, что чинить, реальные данные подтверждают, что починка сработала. Если после правок лабораторный балл вырос, а реальный LCP через месяц прежний, вы ускорили не то, что тормозило у клиентов.

🧭 Проверка за час: семь шагов

Разработчик для этого не нужен, хватит часа времени и доступа к Метрике.

1. ✓Выберите 3–5 страниц: главную, самую посещаемую посадочную, карточку товара или услуги, страницу с формой заявки. Проверять только главную — частая ошибка: над ней обычно трудились больше всего.
2. ✓Откройте PageSpeed Insights и перейдите на вкладку «Мобильные». Десктоп смотрите вторым, а долю мобильного трафика уточните в Метрике.
3. ✓Начните с блока реальных пользователей. Если его нет, запишите это: остальные цифры будут только лабораторными.
4. ✓Выпишите LCP, INP, CLS и TTFB по каждой странице и сравните с порогами из предыдущего раздела.
5. ✓Повторите замер три раза с перерывами и возьмите серединное значение. Лабораторные результаты скачут от запуска к запуску, особенно если сервер занят.
6. ✓Откройте страницу в Chrome DevTools, вкладка Network, включите ограничение скорости сети и обновите страницу. В водопаде запросов видно, какие файлы самые тяжёлые и что блокирует первый экран.
7. ✓Сохраните таблицу с датой, значениями и адресами страниц. Без исходных цифр через месяц после правок сравнивать будет не с чем.

🔧 Что показали замеры и что чинить первым

Порядок правок зависит от того, какая метрика не прошла порог.

Высокий LCP

Чаще всего виновата тяжёлая картинка первого экрана. Её сжимают, переводят в WebP или AVIF и задают размеры. Ленивую загрузку на эту картинку ставить нельзя: она откладывает появление главного элемента. Вторая причина — шрифты и стили, которые блокируют отрисовку.

Высокий TTFB

Если сервер долго отвечает, сжатие картинок ничего не изменит. Причины лежат ниже: дешёвый общий хостинг, где соседние сайты делят процессор, отсутствие серверного кеша, тяжёлые запросы к базе при каждом открытии страницы. Это работа для системного администратора, а не для верстальщика.

Прыгающий CLS

Вёрстка скачет, когда у картинок и баннеров не заданы размеры, а шрифт подменяется уже после загрузки. Ещё одна причина — cookie-баннер или чат, которые появляются поверх контента и сдвигают его. Правка обычно локальная: задать размеры и зарезервировать место.

Плохой INP

За залипающие кнопки отвечает JavaScript. Виджеты консультантов, пиксели, карусели и тяжёлые формы занимают основной поток браузера, и клик ждёт своей очереди. Отключайте сторонние скрипты по одному и смотрите, как меняется отклик: так находится тот, что тормозит больше остальных.

Для сайта на пять страниц этих правок хватит. Когда страниц сотни, а причины перемешаны, ручная проверка отнимает много времени, и тогда её проще поручить аудиту сайта: скорость там разбирается вместе с остальными направлениями проверки.

🛠 Как мы проверяем скорость и сколько стоит исправление

Проверку скорости мы делаем как часть аудита сайта по 9 направлениям. Разбор не заканчивается скриншотом PageSpeed. Мы меряем мобильную и десктопную версии ключевых страниц, сверяем лабораторные цифры с реальными визитами из Метрики и записываем замеры с датой, чтобы после правок было с чем сравнивать.

На выходе заказчик получает список правок по порядку важности. Верстальщику уходят картинки, шрифты и сторонние скрипты, хостинг-провайдеру или администратору — ответ сервера и кеш. Каждая находка привязана к конкретной странице и метрике, поэтому подрядчику не приходится гадать, что имел в виду аудитор.

Серверную часть (кеширование, сжатие, настройку веб-сервера и базы данных) делает наш системный администратор. Его час стоит 3800 руб, условия и остальные расценки собраны на странице цен и тарифов. Стоимость конкретных правок мы называем после замеров: пока не видно, где тормозит, любая смета остаётся догадкой.

Компаниям, которые платят за рекламу, проверка окупается быстрее всего: скорость первой страницы определяет, сколько оплаченных кликов дойдёт до формы заявки. Начните с шагов из четвёртого раздела, запишите цифры и приходите с ними: разговор с аудитором по готовой таблице замеров идёт быстрее.

❓ Частые вопросы

Какая скорость загрузки сайта считается нормальной?

Ориентиры Google для оценки «хорошо»: LCP до 2,5 с, INP до 200 мс, CLS до 0,1, время ответа сервера до 800 мс. Оценка идёт по 75-му перцентилю, то есть три визита из четырёх должны укладываться в пороги. Смотрите мобильные значения: они обычно хуже десктопных, и на них чаще теряются заявки.

Почему PageSpeed показывает высокий балл, а сайт всё равно медленный?

Балл считает лабораторный тест: одна загрузка на эмулированном телефоне, чистый браузер, без кликов. Реальные посетители приходят с разных устройств и сетей, а сторонние скрипты у них грузятся в разном порядке. Проверьте блок данных реальных пользователей в PageSpeed и отчёт о скорости в Яндекс Метрике, они ближе к тому, что видят клиенты.

Как часто нужно проверять скорость сайта?

Минимум раз в квартал и после каждого заметного изменения: нового виджета, счётчика, редизайна, смены хостинга или большого обновления каталога. Скорость деградирует незаметно, потому что каждый новый скрипт добавляет немного. Храните таблицу замеров с датами, тогда ухудшение видно по цифрам, а не по жалобам клиентов.

Можно ли проверить скорость сайта бесплатно?

Да, базовых бесплатных инструментов хватает: PageSpeed Insights, Lighthouse в Chrome DevTools, WebPageTest и отчёты Яндекс Метрики. Платная часть начинается там, где нужно найти причину и исправить её: разобрать водопад запросов, настроить сервер, переписать загрузку скриптов. Это уже работа аудитора, разработчика и системного администратора.

Сколько стоит ускорить сайт?

Цена зависит от причины, поэтому называть её до замеров нельзя. Картинки и шрифты правит верстальщик, медленный ответ сервера лечит системный администратор. У нас час сисадмина стоит 3800 руб. Сначала проводим аудит и выясняем, где тормозит, потом считаем объём правок в часах.