Короткий ответ: скорость — не техническая метрика, а множитель для всей воронки. Она действует одновременно на конверсию, на позиции в поиске и на стоимость платного клика. Это единственное улучшение, которое нельзя «сделать только для одного канала» — оно работает везде сразу.
Что именно измеряет Google
С 2020 года есть три метрики, которые Google собирает у реальных пользователей вашего сайта, а не в лаборатории. Они называются Core Web Vitals, и пороги такие:
| Метрика | Что означает по-человечески | Порог «хорошо» |
|---|---|---|
| LCP | Когда появился главный блок страницы — фото товара, заголовок | до 2,5 с |
| INP | Насколько быстро страница отвечает на нажатия | до 200 мс |
| CLS | Насколько сильно контент прыгает при загрузке | до 0,1 |
Важная деталь, которую регулярно упускают: зачёт идёт по 75-му перцентилю. То есть недостаточно, чтобы «у меня на ноутбуке открывается быстро» — нужно, чтобы три четверти реальных визитов, включая старые Android-телефоны на мобильном интернете, укладывались в порог.
В магазинах на WordPress чаще всего проваливается INP: страница успевает нарисоваться, но потом ещё секунду не реагирует на нажатия, потому что в фоне выполняются скрипты плагинов, чата, пикселей и корзины. Пользователь читает это не как «медленный сайт», а как «сайт сломался» — и жмёт назад.
Сколько это стоит в деньгах
Самая честная публичная иллюстрация — кейс Vodafone на web.dev: A/B-тест на двух визуально идентичных версиях страницы показал, что улучшение LCP на 31% дало 8% роста продаж. Не редизайн, не новая акция — только скорость.
Переведите это на свои цифры так же, как в первой теме: если магазин делает 40 000 € в месяц, 8% — это 3200 € ежемесячно. Работа по ускорению — разовая.
Дополнительный эффект, который редко считают: скорость влияет на стоимость рекламы. Медленная посадочная страница ухудшает показатель качества в рекламных системах и повышает цену клика. Вы платите дважды: за то, что меньше людей доходит, и за то, что каждый пришедший обошёлся дороже.
Почему тормозит именно WooCommerce
WooCommerce сам по себе не медленный. Медленным его делает типичная сборка вокруг него. По моему опыту аудитов, порядок виновников почти всегда такой:
1. Тема-конструктор. Многоцелевая тема с визуальным билдером тянет за собой десятки CSS- и JS-файлов на каждой странице — включая те, что нужны только на главной. Это самая частая и самая недооценённая причина.
2. Плагины, которые грузятся везде. Плагин слайдера, формы, отзывов и калькулятора доставки подключают свои скрипты на всех страницах магазина, а не только там, где используются.
3. Отсутствие кэша страниц. Каждый заход в категорию — это полный цикл PHP + запросы к базе. На виртуальном хостинге за 5 €/мес это 1,5–3 секунды до первого байта.
4. Фрагменты корзины. WooCommerce по умолчанию дёргает wc-ajax=get_refreshed_fragments на каждой странице, чтобы обновить счётчик корзины. На кэшированном сайте это единственный некэшируемый запрос, который тормозит всё.
5. Картинки в оригинальном размере. Фотограф отдал JPEG на 4000 px и 3 МБ, их залили как есть. Браузер тянет 3 МБ ради картинки шириной 600 px.
6. Скрипты третьих сторон. Чат, пиксели, карты, виджеты отзывов. Каждый выглядит безобидно, вместе они съедают INP.
Что чинить в порядке отдачи
Порядок именно такой — от самого дешёвого и самого результативного:
- Картинки — конвертировать в WebP/AVIF, отдавать в нужном размере, ленивая загрузка для всего ниже первого экрана, но не для главного фото товара (иначе портится LCP)
- Кэш страниц + object cache — статический кэш категорий и карточек, Redis или Memcached для запросов к базе
- Отключить фрагменты корзины там, где они не нужны, или заменить на лёгкое обновление счётчика
- Почистить плагины — удалить неиспользуемые, ограничить загрузку скриптов страницами, где они реально нужны
- Отложить сторонние скрипты — чат и пиксели грузить после взаимодействия, а не в
<head> - Шрифты — самостоятельный хостинг,
font-display: swap, только используемые начертания - Хостинг — если после всего этого TTFB всё ещё больше 600 мс, дело в железе, а не в коде
Первые три пункта обычно дают 70% результата и занимают несколько дней. Технические детали по каждому есть в соседнем гайде: Core Web Vitals, картинки, шрифты, скрипты и кэширование.
Врезка для разработчика
- Включите HPOS. High-Performance Order Storage переносит заказы из
wp_posts/wp_postmetaв отдельные таблицы. На магазине с десятками тысяч заказов это радикально ускоряет и админку, и запросы к заказам. - Мерьте поле, а не лабораторию. PageSpeed Insights в лабораторном режиме удобно для отладки, но зачёт идёт по полевым данным CrUX. Смотрите отчёт Core Web Vitals в Search Console — там правда.
- Ищите долгие задачи, а не «вес страницы». INP убивают конкретные обработчики: перерисовка корзины, скрипт слайдера, синхронный код аналитики. Профилируйте вкладку Performance, а не только считайте килобайты.
- Проверьте автозагружаемые опции.
SELECT SUM(LENGTH(option_value)) FROM wp_options WHERE autoload='yes'— если там мегабайты, каждый запрос к сайту тянет этот мусор. Обычно это следы удалённых плагинов. - Оптимизацию проверяйте на мобильном профиле с троттлингом сети и CPU. На вашем MacBook всё быстро всегда.
Когда оптимизация темы уже не помогает
Есть граница, за которой дальше улучшать нечего: тема и плагины дают тот минимум работы, который нельзя убрать, не сломав магазин. Признаки, что вы её достигли:
- LCP на мобильных застрял на 3–4 секундах, хотя картинки и кэш уже сделаны
- Каждый новый плагин заметно ухудшает метрики
- Между «быстро» и «нужный функционал» приходится выбирать
В этой точке остаётся два пути. Первый — урезать функционал: убрать билдер, переписать шаблоны, отказаться от части плагинов. Второй — разделить витрину и бэкенд: оставить WooCommerce для товаров, заказов и админки, а фронтенд собрать отдельно на быстром стеке. Как это устроено и когда оправдано — на странице WooCommerce и headless; там же честно описано, когда переход не окупается. Готовое решение такого типа — NextWoo, витрина на Next.js поверх существующего WooCommerce.
Практическая проверка
- Открыл отчёт Core Web Vitals в Google Search Console и посмотрел мобильные URL
- Знаю LCP, INP и CLS по полевым данным, а не только по лабораторному тесту
- Проверил вес главного фото товара — не больше 150–200 КБ
- Проверил TTFB на странице категории — меньше 600 мс
- Отключил или ограничил фрагменты корзины
- Список плагинов пересмотрен: каждый либо нужен, либо удалён
- Посчитал, сколько 8% роста продаж стоят в моих деньгах
Что дальше
Быстрый магазин — это условие, а не причина покупки. Дальше человек попадает на карточку товара и решает, доверяет ли он вам достаточно, чтобы отдать деньги: карточка товара, которая продаёт.
Если хотите передать это в работу: ускорение сайта — аудит, список работ по приоритету и фиксированная цена на внедрение.