Скорость лендинга: за что вы платите, пока грузится первый экран

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 показывает, откуда пришла каждая заявка. Стартовый тариф бесплатный — карта на старте не нужна.

Создать лендинг бесплатно