Швидкість лендінга: за що ви платите, поки вантажиться перший екран

3 вересня 20268 хвилин читання

Що робить товарний лендінг важким, як за 10 хвилин заміряти його в DevTools і на які пороги орієнтуватись на мобільному. З нашими замірами.

Візьміть свою ціну кліка з кабінету: витрачено поділити на кліки. Це число — вартість одного відвідувача, і вона однакова для того, хто дочитав до форми, і для того, хто закрив вкладку на білому екрані.

Далі арифметика, яку ви перевірите самі. Припустимо, з тисячі кліків сотня пішла раніше, ніж на екрані з'явився товар. Сто помножити на вашу ціну кліка — стільки ви заплатили за трафік, який фізично не долетів до оффера. Це не «недоотриманий прибуток», а списані з карти гроші. Частка у вас буде своя — підставте її, коли заміряєте.

Швидкість чиниться один раз і працює одразу на всіх оферах, креативах і гео — на відміну від правок тексту, які доводиться переписувати під кожен новий оффер.

Чому в товарці це болить сильніше

Основний трафік — телефон. Не телефон на офісному Wi-Fi, а телефон у маршрутці, у метро на переході, у селі на краю покриття. Десктопу мало, і ця частка вам однаково не цікава.

Плюс три речі, які роблять товарку окремим випадком:

Кеш порожній. У магазину з постійними покупцями частина людей приходить удруге, і шрифти зі скриптами в них уже збережені. У переважної більшості ваших візитів кеш порожній.
Трафік холодний. Людина не шукала ваш товар — вона тицьнула на креатив на імпульсі. Кілька секунд білого екрана — і імпульс закінчився разом з вашим бюджетом.
Немає бренду, заради якого чекають. Ніхто не чекатиме заради невідомого сайту з масажером для шиї.

Що робить сторінку важкою

Фото під десктоп на телефоні

Найтиповіше джерело зайвої ваги. Кадр із предметної зйомки — це кілька тисяч пікселів по ширині й кілька мегабайтів ваги. На екрані телефона він показується шириною приблизно 360–430 px залежно від моделі. Браузер спершу викачує всі мегабайти й лише потім зменшує картинку.

Що робити: перезберегти у WebP шириною 1080 px, якість близько 80. Основний виграш дає саме ширина — ви перестаєте возити пікселі, яких ніхто не побачить; формат додає зверху. Сторінка від цього помітно легшає: якщо в оригіналах були мегабайти, після перезбору лишаються сотні кілобайтів.

Чим тиснути, якщо ви ніколи не відкривали графічний редактор: squoosh.app просто в браузері (перетягнули файл, вибрали WebP, задали ширину 1080, скачали) або експорт із будь-якого редактора фото на телефоні.

Шрифти

Кожна гарнітура в кожній насиченості — окремий файл. Woff2 з кирилицею й латиницею — це зазвичай десятки кілобайтів на накреслення, а старі ttf чи otf важать помітно більше, і їх варто просто замінити. Гірше інше: поки шрифт вантажиться, текст може бути невидимим — людина дивиться на порожнє місце там, де мала б бути ціна.

Що робити: одна гарнітура, максимум дві насиченості. Ще краще — системний стек, який важить нуль байтів і виглядає рідним на кожному телефоні.

Пікселі й чужі скрипти

Найпоширеніша помилка тут — «повидаляти зайве». Піксель рекламного кабінету потрібен не для звітів: на ньому вчиться кампанія і будуються аудиторії ретаргету. Ви можете рік не заходити у звіт — але знесений піксель обвалить навчання і вб'є ретаргет. Такі пікселі не чіпають.

Важать вони, до речі, небагато. Проблема інша: кожен — це новий домен, DNS, TLS, завантаження й виконання коду. Поки скрипт працює, він займає той самий процесор телефона, що й відмальовування першого екрана. Через це перший екран приходить пізніше, ніж обіцяє вага сторінки.

Що робити:

Видалити те, що не бере участі в закупівлі: дублі пікселів, старі тестові ID, віджет чату, Hotjar, лічильники від попереднього підрядника.
Пікселі площадок, на яких зараз крутиться трафік, залишити — але вантажити відкладено, з async, після появи першого екрана.
Синхронних скриптів у <head> не має бути взагалі. Це правило важливіше за будь-яку кількість скриптів: кілька відкладених пікселів шкодять менше, ніж один синхронний.

Відео на першому екрані

Фонове відео з автоплеєм тягне мегабайти паралельно з головним фото й забирає в нього канал. На мобільному автоплей стартує лише з muted і playsinline, тобто без звуку — усі аргументи, які ви записали в озвучку, людина не почує.

Розмін тут чесний: постер-картинка плюс кнопка «Дивитись» означає, що частина людей відео не запустить, зате перший екран приходить одразу. На холодному трафіку цей обмін майже завжди вигідний.

Рушій конструктора

Універсальні конструктори тягнуть свій движок цілком: jQuery, бібліотеку слайдерів, бібліотеку анімацій, рантайм редактора. Код вантажиться під усі можливі блоки, а не під ваші п'ять, — ви платите вагою за функції, яких на сторінці немає.

Окремий випадок — сторінки, які малює скрипт уже в браузері. Поки JS не завантажився й не виконався, на екрані немає нічого; один збій — і людина бачить порожнечу. Готовий HTML із сервера поводиться інакше: перший екран існує ще до того, як браузер торкнувся скриптів.

«Сторінка відкрилася» і «людина побачила товар» — різні події

Подія Load спрацьовує, коли догрузилося все, включно з пікселями, і може настати вже після того, як людина залишила заявку. І навпаки: швидкий Load нічого не гарантує, якщо в цей момент на екрані сірі прямокутники.

LCP — момент, коли відмалювався найбільший елемент першого екрана: фото товару або великий заголовок. Це і є чесна відповідь на питання «коли людина побачила оффер».
CLS — сумарний зсув макета. Сторінка вже відкрилася, але стрибає: підвантажився шрифт, вліз банер, картинка без заданих розмірів розсунула текст. Людина цілиться в «Замовити» й потрапляє в сусідній блок. Це втрачені заявки, а не косметика.
Прихований перший екран. Блоки з анімацією появи на скролі стартують із прозорості 0: технічно швидко, візуально біло.

Загальновідомі пороги Core Web Vitals: LCP до 2,5 с — добре, до 4 с — терпимо; CLS до 0,1 — добре. Для ваги сторінки й кількості запитів універсальної норми немає — порівнюйте себе із собою: заміряли, полагодили, заміряли ще раз.

Заміряти за 10 хвилин

Chrome, F12, вкладка Network:

Увімкніть режим пристрою (Ctrl+Shift+M) і виберіть телефон.
Поставте галочку Disable cache — інакше заміряєте свій кеш, а не чужий перший візит.
У полі Throttling виберіть Slow 4G. Якщо такого пункту немає — беріть Fast 3G: у старіших складаннях цей пункт міг називатися так.
Перезавантажте з Ctrl+Shift+R.

Що записати:

Transferred унизу панелі — реальна вага сторінки, поруч кількість запитів.
Відсортуйте за Size: перші п'ять рядків і є ваша проблема. Майже завжди це фотографії.
Водоспад — що вантажиться раніше за головне фото. Якщо піксель стартує перед картинкою товару, порядок неправильний.

Профіль Slow 4G дає приблизно 200 КБ/с. Дуже грубо, без урахування затримки мережі й паралельних запитів: поділіть свою вагу в кілобайтах на 200 — отримаєте порядок секунд, які людина дивиться на недомальовану сторінку. У самому DevTools число вийде іншим — це прикидка, а не заміна заміру.

Якщо хочеться точніше

Вкладка Performance: спершу увімкніть галочку Screenshots, інакше стрічки кадрів просто не буде. Запишіть перезавантаження й прогорніть кадри. Домовтеся із собою заздалегідь, що вважати появою товару, — наприклад, перший кадр, де одночасно видно фото й ціну.

Lighthouse у режимі Mobile дасть LCP, CLS і TBT. Беріть медіану з трьох прогонів: розкид між запусками буває великий.

Фінальна перевірка — власний телефон на мобільному інтернеті, бажано там, де сигнал у дві поділки. Офісний Wi-Fi ховає рівно ті проблеми, за які ви платите.

Наші заміри

Вересень 2026, мобільний профіль Chrome, холодний кеш, без тротлінга мережі. Сторінка лендінга в LandEmpire: 244 КБ, перший екран — ~290 мс, зсув макета 0. До оптимізації на тій самій сторінці — та сама верстка й ті самі фото, тільки перезібрані ассети — було 381 КБ і 612 мс.

Одразу застереження: замір зроблено без тротлінга мережі, це не профіль Slow 4G — тому ділити тут 244 на 200 не можна, як і порівнювати ці ~290 мс із порогом 2,5 с напряму. Це заміри рушія, а не вашого майбутнього контенту: щойно ви додасте пікселі й фото на кілька мегабайтів, цифри стануть вашими. Спрацювали тут чотири речі: картинки у WebP під реальні розміри, готовий HTML із сервера замість малювання на клієнті, мінімум шрифтів і жодного стороннього скрипта за замовчуванням.

Що зробити сьогодні

Прогнати лендінг у DevTools на Slow 4G з вимкненим кешем і записати три числа: вагу, кількість запитів і секунду, коли з'явилося фото товару.
Взяти три найважчі картинки зі списку Size, перезберегти у WebP шириною 1080 px і замінити — це доступно в будь-якому конструкторі.
Прибрати автоплей-відео з першого екрана й вимкнути анімації появи для верхніх блоків.
Знести те, що не бере участі в закупівлі: дублі пікселів, старі тестові ID, чат, лічильники від попереднього підрядника. Робочі пікселі кабінетів не чіпати.
Те, що потребує коду: width і height на картинках, фіксована висота таймера й банерів, loading="lazy" нижче першого екрана, async на пікселях. Якщо в конструкторі такого поля немає — це вже готове питання в підтримку платформи.

Зберіть такий лендінг самі — за вечір

У LandEmpire є готові шаблони під товарку, заявки падають у Telegram, домен підключається за пару хвилин, а статистика за UTM показує, звідки прийшла кожна заявка. Стартовий тариф безкоштовний — картка на старті не потрібна.

Створити лендінг безкоштовно