Маркетолог, аналітик, 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: не реклама зливає бюджет. Його зливає ваш сайтЧому реклама не витягне кривий сайт: два реальні CRO-розбори (лендинг медичного сенсора і картка товару) та чекліст першого екрана.
Де мене знайти
Пишіть у Telegram або на пошту — відповідаю швидко. Telegram канал і YouTube — для тих, хто хоче побачити реальні кейси перед зверненням та зрозуміти мій підхід в роботі.