Маркетолог, аналитик, ex-CMO — фокус на экосистеме Google (Ads, Merchant Center, GA4, GTM). Google Partner. 150+ проектов, 100+ положительных отзывов на Freelancehunt, 12+ стран.
- Работаю напрямую, без менеджеров и субподрядчиков
- Считаю результат в продажах, а не в конверсиях кабинета
- Максимальная экспертиза в экосистеме Google
Старый сайт доставки еды на OpenCart, который создавался больше 8 лет назад. Мобильная версия была в «красной» зоне скорости Google. После двух этапов правок медиана LCP главной страницы упала с 5,1 до 1,8 с, балл PageSpeed вырос с 73 до 98. Дизайн, контент и админка остались прежними.
Содержание статьи
| Показатель (мобильный, медиана 10 замеров) | До | После |
|---|---|---|
| LCP главной | 5,1 с | 1,8 с |
| LCP категории «Пицца» | 3,0 с | 2,0 с |
| PageSpeed главной | 73 | 98 |
| PageSpeed категории «Пицца» | 83 | 93 |
| PageSpeed главной, компьютер | — | 100 |
Почему мобильная версия — это почти весь сайт
По данным GA4, 88,6% активных пользователей (17 258 из 19 484) и 89,7% вовлечённых сеансов — с телефонов. На компьютеры приходится лишь 10,4% пользователей. Для доставки еды это логично: человек заказывает с дивана или по дороге домой.
Голодный человек с телефоном не будет ждать 5 секунд, пока появится меню. Он уйдёт к конкуренту. Плюс Google ранжирует с учётом Core Web Vitals — трёх показателей реального опыта пользователей Chrome:
- LCP — как быстро появляется главный элемент страницы, норма до 2,5 с;
- CLS — «прыгает» ли страница во время загрузки, норма до 0,1;
- INP — как быстро сайт реагирует на действия, норма до 200 мс.
Цель: вывести мобильную версию в «зелёную» зону Core Web Vitals и ничего не сломать в заказах и аналитике.
Стартовая точка
На старте мобильная версия была в «красной» зоне: около 390 адресов в отчёте Core Web Vitals в Search Console. Десктоп — в «жёлтой».
Первый этап правок я сделал в рамках SEO-оптимизации сайта: размеры изображений, WebP, убранный лишний jQuery. Отчёт от 04.11.2026 показал:
| Устройство | Неэффективные | Нужно улучшить | Эффективные |
|---|---|---|---|
| Мобильный | 0 | 390 | 28 |
| ПК | 0 | 0 | 418 |
Десктоп перешёл в «зелёную» зону, мобильный — из «красной» в «жёлтую». Остались две проблемы: CLS выше 0,1 и LCP выше 2,5 с.
SEO · Доставка едыSEO сайта доставки еды: что я сделал и зачем — разбор реального отчётаСайт доставки пиццы на OpenCart: 15 категорий, 53 статьи, 29 страниц районов и сёл, Ahrefs 20 → 100, чистые карты сайта, микроразметка, CLS 0,383 → 0 и причина 6-секундного оформления заказа.
Реальные пользователи (CrUX)
Полевые данные Chrome — p75 реальных мобильных пользователей за 28 дней, снятые 07.11.2026 через PageSpeed Insights API. Этот период почти полностью приходится на время до правок.
| Показатель (p75) | Главная UA | Главная RU | «Пицца» UA | Сайт в целом |
|---|---|---|---|---|
| Оценка Google | медленно | медленно | быстро | быстро |
| LCP, с | 3,21 | 3,25 | 0,95 | 1,13 |
| CLS | 0,39 | 0,39 | 0,01 | 0 |
| INP, мс | 152 | 161 | 163 | 154 |
| FCP, с | 1,66 | 1,64 | 0,85 | 0,89 |
| TTFB, с | 1,02 | 1,14 | 0,50 | 0,49 |
Самая слабая страница — главная. Интересный момент: в лабораторных замерах CLS главной — 0,022, а в реальных данных — 0,39. CrUX считает сдвиги за весь визит: прокрутку, попапы, догрузку блоков. Лабораторный тест видит только момент загрузки.
Что тормозило
Я разобрал мобильные отчёты PageSpeed Insights для главной и категории «Пицца». Картинки были лишь частью проблемы. Основное торможение давало то, что загружалось вместе со страницей и блокировало её показ.
| Фактор | Объём | Влияние |
|---|---|---|
| Google Tag Manager + GA4 | 350 КБ | 377 мс работы браузера при загрузке |
| Facebook Pixel | 225 КБ | 218 мс |
| Microsoft Clarity | 28 КБ | 75 мс |
| Старый jQuery 2.1.1 в шапке (дубль) | 87 КБ | ~0,9 с белого экрана |
| main.css в шапке | 232 КБ | ~0,45 с белого экрана |
| Фото блюд в JPG/PNG | ~1,1 МБ на категорию | тяжёлое главное фото экрана |
| Мобильные слайды 990×1024 | 58 КБ на слайд | больше, чем нужно для экрана ~720 px |
| Картинки без размеров | — | страница «прыгала» (CLS) |
Ещё одна особенность: результаты PageSpeed сильно скачут от замера к замеру. LCP одной и той же страницы — от 1,5 до 11 с. Поэтому решения я принимал по медиане 10 замеров.
Что я сделал
Этап 1: стабильная вёрстка и лёгкие фото
- Размеры изображений. Карточкам блюд, превью статей, логотипу и иконкам добавил ширину и высоту. Браузер заранее резервирует место, и контент не сдвигается.
- Фото блюд в WebP. Сайт сам создаёт и отдаёт WebP-копии, оригиналы не менялись. Тест на 10 фото показал −73% веса, категория «Пицца» стала весить 537 КБ вместо 1 089 КБ. Старые браузеры по-прежнему получают JPG.
- Убрал дубль jQuery. Старая версия 2.1.1 в шапке только задерживала показ страницы. Единственный зависимый от неё скрипт — выбор бортика пиццы — перенёс на основную версию 3.3.1.
Этап 2: быстрый первый экран
- Встроенные стили первого экрана. ~49 КБ стилей, нужных для первого экрана, встроил прямо в страницу. Полный main.css (232 КБ) догружается после показа страницы.
- Приоритет первых фото. Первые 2 фото в каждой категории браузер загружает раньше остальных файлов. Главное фото экрана начинает грузиться на ~190 мс раньше.
- Лёгкие мобильные слайды. Обычные телефоны получают слайд 750 px — 38 КБ вместо 58 КБ. Очень чёткие экраны и планшеты, как и раньше, получают 990 px.
- Отложенный запуск Google Tag Manager. GTM теперь запускается после показа страницы или при первом действии человека: прокрутке, касании, клике. Событие gtm.js добавляется сразу, поэтому порядок событий в dataLayer такой же, как раньше, и ecommerce-события не теряются. Facebook Pixel уже стоял на триггере «Window Loaded», Clarity отключён.
Решение об отложенном GTM я принял сознательно: в статистику не попадают визиты короче ~1 секунды. Для аналитики и рекламы такие визиты ценности не имеют.
Как я работал, чтобы ничего не сломать
Сайт принимает заказы каждый день, поэтому ни одна правка не попадала к посетителям, пока не была проверена в тестовом режиме и замерена.
- Сначала диагностика. Перед изменениями — проверка, которая ничего не меняет на сайте: поддерживает ли сервер WebP, сколько весят файлы, как сделан слайдер.
- Каждое изменение с откатом. Каждую правку можно было сначала просмотреть, затем применить с резервной копией файлов и откатить одним кликом. Перед отправкой код проверялся на копии сайта.
- Тестовый режим. Новое поведение сначала работало только для страниц с отдельным тестовым параметром. Обычные посетители ничего не замечали.
- Проверка функций. Главная, категории, отзывы, корзина, RU-версия, выбор бортика и пересчёт цены, тестовый заказ, теги в предпросмотре GTM. Для встроенных стилей — автоматическое сравнение расположения элементов первого экрана с полным main.css и без него.
- Замеры по 10 тестов. Один замер PageSpeed ничего не доказывает. Я сделал инструмент, который запускает PageSpeed Insights API с сервера. Каждый вариант — 10 мобильных замеров без кеша PageSpeed, затем медиана.
- Запуск для всех. Только после этого правка включалась для всех посетителей, и я перепроверял всё повторно.
Результаты
После этапа 2 мобильный LCP обеих ключевых страниц опустился ниже границы 2,5 с: главная — с 5,1 до 1,8 с, категория «Пицца» — с 3,0 до 2,0 с.
| Показатель (мобильный, медиана 10 замеров) | Главная, до | Главная, после | «Пицца», до | «Пицца», после |
|---|---|---|---|---|
| Балл PageSpeed | 73 | 98 | 83 | 93 |
| TBT, мс | 255 | 136 | 381 | 264 |
| Speed Index, с | 2,1 | 1,5 | 2,0 | 1,8 |
| FCP, с | 0,93 | 0,93 | 0,94 | 0,94 |
| CLS | 0,022 | 0,022 | 0,012 | 0,024 |
«До» здесь — состояние после этапа 1, «после» — после этапа 2.
Контрольный замер главной в PageSpeed Insights после запуска для всех: мобильный — 98 баллов (LCP 1,7 с, TBT 140 мс, CLS 0,022), компьютер — 100 баллов (LCP 0,3 с).
Повторный замер реальных данных Google запланирован на 20-е числа ноября, когда в 28-дневном окне будет преобладать новая версия сайта, и на начало декабря, когда окно полностью перейдёт на неё. Тогда дополню кейс.
Ключевая мысль: скорость старого сайта редко упирается только в картинки. Наибольший выигрыш здесь дали отложенные сторонние скрипты и стили первого экрана, встроенные в страницу.
Бонус: меню на iPhone открывалось со второго касания
В мобильном меню на iPhone категорию приходилось нажимать дважды. Первое касание по «Пицца» или «Суши» ничего не делало, переход срабатывал только со второго. На компьютере и в эмуляции телефона баг не воспроизводился.
Диагностика на реальном телефоне. Я добавил на сайт скрытую панель, которая включалась только по отдельному параметру, записывала все события касания и сохраняла их между страницами. Один скриншот с iPhone показал причину.
Причина. Если палец попадал на SVG-иконку категории, Safari отправлял touchend и mouseover, но не click. Это известная особенность iOS с SVG внутри ссылок. К тому же старый код раскрывал десктопное меню при «наведении» даже на телефонах.
Исправление. Одно CSS-правило: SVG-иконки в ссылках не перехватывают касание (pointer-events: none), и касание попадает на саму ссылку. Раскрытие меню при наведении теперь работает только на компьютерах с мышкой.
Результат. На iPhone с iOS 18.7 категории открываются с первого касания — и по тексту, и по иконке.
Баги телефонов ищут на телефонах: в эмуляции этой проблемы просто не было видно.
Google Ads · МаркетингCRO для Google Ads: не реклама сливает бюджет. Его сливает ваш сайтРеклама приводит на страницу, а продаёт сайт. Два разбора: лендинг и карточка товара. Что мешает конверсии и как удешевить заявки без смены рекламы.
Где меня найти
Пишите в Telegram или на почту — отвечаю быстро. Telegram-канал и YouTube — для тех, кто хочет увидеть реальные кейсы перед обращением и понять мой подход к работе.