95 баллов в PageSpeed, а продажи стоят: разбираем миф о скорости сайта

PageSpeed на 95 баллов не гарантирует продажи: оценка Google измеряет техническую загрузку страницы, а не путь покупателя до оплаты. Деньги теряются в конкретных точках — форма зависает на мобильном интернете, каталог тормозит в час пик, раздел оплаты падает независимо от общего балла. Искать нужно не итоговую цифру, а место разрыва в воронке.

95 баллов в PageSpeed — это оценка Google, а не покупателя

Тест Google Lighthouse открывает страницу один раз, в лабораторных условиях, и меряет метрики загрузки: LCP, CLS, INP. Он ничего не знает про форму заявки, про то, что происходит после клика «добавить в корзину», про раздел оплаты. Тест по умолчанию мерит настольное подключение или смоделированное 4G, а не то, что реально происходит в лифте бизнес-центра или в метро, где сидит половина мобильной аудитории. Балл честно показывает, как быстро отрисовался первый экран, — и ничего не говорит о том, купит ли человек после этого.

Частый сценарий: подрядчик сжимает картинки, убирает лишние шрифты, чистит неиспользуемый CSS. Балл растёт с семидесяти до девяноста пяти за пару недель работы. Владелец сайта ждёт роста заявок. Проходит месяц — число обращений то же самое, что и до оптимизации. Причина проста: страница, с которой уходят покупатели, вообще не участвовала в этой работе, а отчёт с зелёными цифрами показать клиенту гораздо проще, чем разбирать логи сервера.

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

что видит покупатель, когда открывает карточку товара вечером

Магазин мебели в Подмосковье получил зелёный отчёт по Core Web Vitals в Search Console. Но в Яндекс.Метрике заметно: с восьми до десяти вечера, когда люди заходят с телефона после работы на домашнем 4G, время до отклика кнопки «в корзину» растёт — тяжёлый JS-бандл догружается на слабом канале, галерея фотографий подтягивается с задержкой.

Человек нажимает кнопку, ничего не происходит секунду-другую, он нажимает ещё раз или уходит смотреть тот же диван у конкурента в соседней вкладке. Владелец сайта в это время смотрит отчёт PageSpeed на рабочем компьютере с быстрым интернетом — там всё зелёное, потому что тест не воспроизводит вечернюю нагрузку и слабый мобильный канал реального покупателя.

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

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

где скорость решает, а где почти нет 📊

Свести это в таблицу проще, чем спорить абстрактно про важность скорости. Ниже — пять реальных ситуаций и то, бьёт ли конкретная задержка по продажам.

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

частая ошибка: правят фронт, а тормозит бэкенд

Интернет-магазин на 1С-Битрикс арендует недорогой общий хостинг — обычная экономия на старте, пока заказов немного. Раз в сутки, ночью, идёт синхронизация каталога и остатков с учётной базой 1С. По плану процесс укладывается в пару часов и заканчивается до открытия магазина. Но синхронизация иногда съезжает и захватывает утренние часы, когда открывается офис и одновременно идёт первый дневной всплеск покупателей с мобильных.

Сайт в этот момент формально проходит тест PageSpeed без проблем — HTML лёгкий, картинки оптимизированы, скрипты подключены асинхронно. Но каждый запрос к базе данных на сервере ждёт своей очереди, потому что процессор занят синхронизацией, и страница «крутится» по три-четыре секунды именно у тех, кто пришёл покупать прямо сейчас, а не у бота, который тестирует главную страницу ночью. Заметно это становится не по внешним метрикам, а по логам сервера и по временным меткам в системе мониторинга нагрузки на базу — обычные инструменты для проверки скорости сайта туда не заглядывают.

Дальше цена ошибки считается уже не в баллах, а в деньгах и времени: рекламный бюджет продолжает приводить трафик на страницу, которая в этот час технически не может её быстро обработать. Заявки теряются не потому что сайт «медленный» вообще, а потому что бэкенд и маркетинг работают несогласованно — и без замера именно этого момента проблему не видно ни в одном отчёте о скорости фронтенда. Три-четыре недели такой рассинхронизации — это не разовая накладка, а системная утечка бюджета на рекламу, которая приводит людей на страницу, где им технически нечего купить.

что делать: порядок действий, а не переделка всего сайта ⚙️

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

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

Быстро сориентироваться помогает несколько проверок ещё до заказа полноценного аудита:

• ✓сравнить время отклика формы утром и вечером, а не один раз днём с офисного интернета;
• ✓посмотреть в Метрике или аналогичной системе долю отказов именно на странице оплаты и корзины, а не на сайте в целом;
• ✓проверить, не совпадает ли всплеск жалоб на «тормоза» с расписанием ночной синхронизации или резервного копирования на сервере;
• ✓уточнить у хостинга или у команды сопровождения, растёт ли нагрузка на базу данных в часы пика продаж.

Для системной проверки удобнее не гадать по отдельным пунктам, а провести аудит сайта по девяти направлениям — там технику, скорость и путь покупателя смотрят вместе, и разрыв в воронке находится, а не предполагается. Если причина в бэкенде и слабом хостинге под нагрузкой 1С-Битрикс, диагностика сервера и сопровождение считаются по часам, от 3800 руб/час — конкретную стоимость под задачу видно в тарифах.

когда скорость всё-таки стоит денег

Не любая доля секунды экономически оправдывает переделку. Если тормозит форма заказа, корзина или оплата — вкладываться в скорость этого конкретного шага почти всегда окупается, потому что там человек уже готов заплатить и любая заминка стоит реальной заявки. Если медленно грузится статья в блоге или галерея на странице «о компании» — это влияет на позиции в поиске и на впечатление от сайта, но не останавливает продажу напрямую.

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

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

Стоит ли доводить PageSpeed до 100 баллов?

Практического смысла в баллах выше отметки, где страница открывается за пару секунд, обычно немного: 95 и 100 баллов покупатель на глаз не различит. Дороже поднять последние баллы, чем найти реальную точку разрыва в форме заявки или корзине — там отдача выше.

Как понять, что сайт тормозит на самом деле, а не по отчёту PageSpeed?

Смотрите Яндекс.Метрику по конкретным экранам: время до клика на «купить», процент отказов на странице оплаты, жалобы в переписке с покупателями. Отчёт Google Lighthouse этого не показывает — он тестирует одну загрузку без сценария покупки, а не поведение реального человека на сайте.

Всегда ли причина медленной работы в хостинге?

Не всегда. Часто дело в тяжёлых виджетах, чат-ботах и скриптах аналитики, которые накапливаются на сайте годами. Хостинг стоит проверять отдельно — когда тормозит именно бэкенд, запросы к базе данных, а не отрисовка страницы в браузере покупателя.

Сколько стоит разобраться, где реально теряются продажи?

Аудит сайта по девяти направлениям — техника, скорость, юзабилити и остальное — оценивается индивидуально под объём сайта, точную стоимость видно в тарифах на сайте. Отдельные работы по серверу и сопровождению считаются по часам, от 3800 руб/час.

Что делать в первую очередь: чинить скорость или воронку?

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