Чек-лист производительности интернет-магазина: быстрый mobile-first

С чего начинаются тормоза мобильной витрины

Для покупателя «тормозит» не значит «долго грузится весь сайт». Чаще это про мелкие задержки, которые мешают действию: первый экран появился, но кнопки не нажимаются; карточка товара открылась, но фото догружаются рывками; корзина пересчитывается так долго, что кажется, будто ничего не произошло.

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

Проверка «у меня на Wi‑Fi быстро» почти ничего не доказывает. У реальных покупателей бывают слабая сеть, экономия трафика, старые смартфоны и фоновые приложения. Поэтому важно смотреть на поведение страницы при плохих условиях и на то, что видит пользователь в первые секунды.

Простой способ понять, где начинаются проблемы:

• Откройте главную и карточку товара на мобильном интернете и засеките: когда появляется контент и когда можно нажимать.
• Пролистайте список товаров: есть ли «подвисания» и поздняя подгрузка изображений.
• Нажмите «Добавить в корзину»: есть ли мгновенная обратная связь.
• Поверните экран или смените вкладку: не «прыгает» ли верстка.

Дальше пригодится чек-лист производительности интернет-магазина: он поможет выбрать действия, которые улучшают Core Web Vitals и опыт покупателя без дорогих инструментов и долгих переделок.

Core Web Vitals на языке магазина

Core Web Vitals можно перевести на простой вопрос: как быстро покупатель видит товар, как быстро реагирует интерфейс на тап, и не прыгает ли страница в процессе.

LCP (Largest Contentful Paint) для витрины и карточки товара - это момент, когда появляется главный контент: фото товара, крупный баннер, заголовок или блок с ценой. Если LCP медленный, человек смотрит на пустоту или серые заглушки и уходит, не дождавшись.

INP (Interaction to Next Paint) - про задержки при действиях: тап по фильтру, выбор размера, переключение фото, добавление в корзину. Типичный симптом - вы нажали, а кнопка «думает», и кажется, что сайт сломан.

CLS (Cumulative Layout Shift) - когда верстка скачет. Чаще всего виноваты изображения без заданных размеров, баннеры, которые догружаются сверху, и шрифты, из-за которых текст «переезжает». В магазине это особенно больно: человек целится в «Купить», а кнопка уезжает.

Если время и деньги ограничены, в чек-листе производительности интернет-магазина обычно важнее так расставить приоритеты:

• Сначала LCP на главной, в каталоге и на карточке товара (первый экран и главный товарный блок).
• Затем INP на фильтрах, сортировке, выборе варианта, корзине.
• Потом CLS на страницах с баннерами, сетками товаров и длинными списками.
• И только после этого полировать второстепенные страницы (о нас, блог).

Простой пример: в каталоге LCP портит тяжелое превью товара, а INP - фильтр, который пересчитывает список на каждом вводе. Исправьте это, и скорость будет ощущаться сразу, даже без полного переделывания сайта.

Приоритизация работ, если бюджет и время ограничены

Когда времени мало, полезнее не «оптимизировать все», а быстро найти 2-3 узких места, которые заметно ухудшают загрузку на мобильных. Хорошая цель на старте: за неделю улучшить один показатель так, чтобы это увидели реальные покупатели.

Мини-аудит на 30 минут можно сделать даже без глубоких знаний. Пройдитесь по сайту с телефона на мобильном интернете и отметьте, где именно возникает ожидание или «дерганье».

• Откройте главную и карточку товара в новом окне: что появляется первым, и сколько секунд до клика по кнопке.
• Пролистайте каталог и карточку: есть ли скачки макета, «прыгают» ли цены, фото, кнопки.
• Проверьте изображения: грузятся ли большие фото там, где достаточно миниатюр.
• Оцените количество запросов: не дергается ли API по 5-10 раз на один экран.
• Сравните поведение с и без кэша (повторный заход): стало ли быстрее.

Правило 80/20 в магазинах почти всегда про одно и то же: тяжелые изображения, лишний JavaScript на первом экране и отсутствие нормального кэша для статики. Если вы ведете список задач, помечайте те, что уменьшают вес первого экрана и время до первого полезного действия (например, выбрать размер, добавить в корзину).

Дальше расставьте приоритеты по страницам: карточка товара обычно влияет на конверсию сильнее всего, затем каталог, затем корзина и оформление, и только потом главная. Если бюджет совсем минимальный, начните с одной самой посещаемой категории и 3-5 топовых товаров.

Чтобы не распыляться, выберите «одно улучшение в неделю» по простому шаблону:

• Неделя 1: сжать и правильно отдавать изображения на карточке.
• Неделя 2: убрать лишние скрипты и стили с первого экрана.
• Неделя 3: настроить кэш статики и безопасные заголовки для повторных заходов.
• Неделя 4: сократить лишние API-запросы и задержки.

Так вы двигаетесь измеримо, и чек-лист производительности интернет-магазина превращается в реальный план, а не в бесконечный список пожеланий.

Изображения: самый частый источник медленной загрузки

Если мобильная витрина тормозит, чаще всего виноваты картинки. Они занимают больше всего трафика, влияют на LCP (скорость появления главного контента) и могут вызвать скачки верстки (CLS), если размеры не заданы заранее. Даже самый аккуратный чек-лист производительности интернет-магазина обычно упирается именно в изображения.

Начните с форматов. AVIF дает лучший размер, WebP почти везде поддерживается, а JPEG/PNG оставьте как фолбэк. На практике это значит: отдавайте через picture, чтобы браузер сам выбрал лучший вариант.

Дальше размеры. Не грузите одну и ту же «большую» картинку везде. Для карточек, выдачи и галереи нужны разные версии, а на разных экранах разные ширины. Обязательно задавайте width и height (или aspect-ratio), чтобы страница не прыгала при загрузке.

Короткий контрольный список для одной страницы товара:

• AVIF/WebP с фолбэком на JPEG/PNG через picture.
• srcset и sizes для responsive-картинок, без «универсального 2000px».
• Заданы width/height или aspect-ratio для всех изображений.
• Компрессия под роль: превью, карточка, галерея.
• Ленивая загрузка включена внизу страницы, но не на первом экране.

По весу держите ориентиры: превью до 10-20 КБ, изображение карточки товара до 30-60 КБ, главное фото на странице товара часто укладывается в 120-200 КБ при хорошем качестве. Если у вас 4-6 фото в галерее, лучше подгружать их по запросу (свайп, открытие).

Ленивая загрузка (loading="lazy") полезна почти везде, кроме hero-картинки и главного фото товара, которые участвуют в LCP. Для них используйте предзагрузку: rel="preload" и fetchpriority="high" на одном ключевом изображении. Пример: в каталоге lazy для всех карточек, а на странице товара без lazy для первого фото, остальные можно лениво.

JS, CSS и шрифты: как облегчить первый экран

Первый экран на мобильном решают две вещи: сколько кода нужно скачать и сколько работы браузер делает до первого клика. Даже хороший дизайн может «тормозить», если на старте вы грузите весь каталог, все виджеты и тяжёлые шрифты.

Минимум для первого экрана

Правило простое: на старте нужны шапка, поиск, корзина, несколько карточек и базовая аналитика. Всё остальное догружайте после первого рендера или по действию пользователя.

Проверьте себя по этому короткому чек-листу:

• Разбейте JS на части (code splitting): на первом экране только то, без чего нельзя показать витрину. Для React приложений (в том числе собранных в TakProsto) это обычно ленивые импорт и отдельные чанки для фильтров, личного кабинета, отзывов.
• Ограничьте сторонние скрипты: чат, пиксели, тепловые карты. Оставьте 1-2 самых нужных, остальные включайте после согласия на cookies или после взаимодействия.
• Порядок загрузки: не блокируйте рендер. То, что можно, грузите с defer/async, а тяжёлые виджеты откладывайте.
• CSS: выделите критические стили для первого экрана, остальной CSS подключайте позже. Следите, чтобы один большой файл не тормозил старт.
• Уберите «лишнюю динамику» на старте: слайдеры, сложные тени, большие эффекты наведения. Они часто дают рывки на слабых устройствах.

Шрифты и анимации

Шрифты легко съедают секунды. Используйте 1-2 начертания, формат WOFF2 и font-display: swap, чтобы текст появлялся сразу. Если бренд позволяет, начните с системных шрифтов, а фирменный подключайте позже.

Анимации делайте на transform и opacity, избегайте частых перерасчётов размеров и позиций. Если при прокрутке «дрожит» интерфейс, сначала отключите анимации на карточках и шапке и проверьте, ушли ли лаги.

Кэширование: статика, API и безопасные стратегии

Кэширование почти всегда дает самый дешевый прирост скорости, особенно на мобильной сети. В любом чек-листе производительности интернет-магазина начните с простого: статике нужен долгий кэш, а данным из API - короткий и предсказуемый.

Для статики (картинки, CSS, JS) задайте долгий HTTP-кэш и версионирование файлов. Тогда браузер не будет скачивать одно и то же при каждом заходе.

• Для файлов с хэшем в имени (app.8f3c1.js): Cache-Control: public, max-age=31536000, immutable
• Для HTML и «точек входа» без хэша: короткий кэш или без кэша, чтобы обновления приходили сразу
• Если хэша нет, используйте версию в query-параметре или внедрите сборку с хэшированием

С API аккуратнее. Кэшируйте то, что не меняется каждую секунду: списки каталога, агрегированные фильтры, подсказки поиска. Для корзины, цен по персональным правилам и статуса наличия в реальном времени лучше не кэшировать или кэшировать на очень короткое время.

Хорошая «безопасная» стратегия для каталога и картинок - stale-while-revalidate: пользователь сразу видит сохраненную версию, а в фоне подтягивается свежая. Это снижает задержки без ощущения «устаревшего сайта».

Service worker полезен, но не превращайте магазин в офлайн-приложение. Достаточно кэшировать оболочку (иконки, базовые стили, шрифты) и часть изображений, но не кэшировать:

• корзину и оформление заказа
• персональные цены и промокоды
• любые запросы с токенами и личными данными

Чтобы не ломать обновления после релиза, держите один источник правды: версия сборки меняется - меняются имена файлов. Для service worker добавьте понятный сценарий обновления (новая версия активируется после перезагрузки), иначе пользователи могут неделями сидеть на старой витрине.

SSR или CSR: простое решение без религиозных споров

SSR (рендер на сервере) и CSR (рендер в браузере) - это не «правильно/неправильно». Это про то, что важнее именно вашему магазину: быстрый первый экран и SEO или сложная интерактивность после входа.

SSR обычно помогает, когда важны поисковые страницы и быстрый первый показ контента на слабых телефонах и медленной сети. Типичные кандидаты: главная, категории, листинг, карточка товара, контентные страницы. Вы чаще увидите улучшение LCP и более стабильное поведение при первом заходе.

CSR обычно достаточно там, где пользователь уже «внутри» и интерфейс постоянно меняется: личный кабинет, избранное, история заказов, админка, сложные формы. Тут важнее отзывчивость (INP) и размер бандла, а SEO почти не играет роли.

Простое дерево решений: 5 вопросов

Ответьте «да/нет» и выбирайте без споров:

• Страница должна хорошо ранжироваться в поиске?
• Пользователь часто приходит на нее с рекламы и ожидает мгновенный первый экран?
• На ней есть «тяжелые» блоки (галерея, отзывы, рекомендации), которые можно догружать позже?
• Контент меняется редко и одинаков для всех (кроме цены/наличия)?
• Вы готовы поддерживать кеширование на сервере и контролировать TTFB?

Если «да» хотя бы на 2-3 вопроса, чаще выигрывает SSR или гибрид.

Гибрид, который почти всегда подходит

Практичный вариант из чек-листа производительности интернет-магазина: SSR для листинга и карточки, а CSR для фильтров, сортировки, корзины и мелких интерактивных панелей. Так вы ускоряете вход и не усложняете динамику.

Чтобы не спорить «на глаз», замерьте до/после: LCP, INP, CLS и TTFB, плюс бизнес-метрики (конверсия в добавление в корзину и оформление). Если цифры не улучшаются, значит проблема не в SSR/CSR, а в весе ресурсов или логике загрузки.

Mobile-first поведение: сеть, интерфейс и стабильность

Мобильная витрина чаще всего «умирает» не от тяжелых фич, а от плохого поведения на слабой сети и дерганого интерфейса. Проверьте сценарий: первый визит с 3G, холодный кеш, без авторизации. Покупатель должен увидеть бренд, название товара и цену раньше, чем загрузятся отзывы и рекомендации.

Хорошее правило: сначала показываем каркас страницы и ключевую покупательскую информацию, а уже потом «доклеиваем» второстепенные блоки. Скелетоны полезны там, где размер блока заранее известен (карточка товара, список). Если размер неизвестен, скелетон часто ухудшает CLS: контент скачет, кнопки уезжают, палец промахивается.

Мини-чек для mobile-first (подойдет как часть общего чек-листа производительности интернет-магазина):

• На 3G первыми появляются: шапка, фото-превью, название, цена, кнопка «Купить», доставка или наличие (в упрощенном виде).
• Убирайте лишние цепочки запросов: не тяните данные «ступеньками» (категория -> товар -> цена -> остатки) если можно одним ответом.
• Минимизируйте редиректы, особенно на старте (www или без, http/https, слэш). Один лишний переход на мобильной сети ощущается как «сайт завис».
• Делайте верстку стабильной: резервируйте место под баннеры, промо, счетчики, блоки рекомендаций. Для изображений задавайте размеры заранее.
• Отдельно замерьте скорость фильтров и сортировки: панель должна открываться сразу, а применение фильтра не должно блокировать прокрутку и кнопки.

Если после применения фильтра экран «прыгает», закрепите верхнюю панель и сохраняйте позицию прокрутки. Это маленькая деталь, но она напрямую влияет на ощущение скорости.

Быстрый тест-план: проверяем как реальный покупатель

Проверка «вживую» часто ловит то, что не видно в лаборатории: подвисания при скролле, задержку открытия карточки, скачки макета из-за поздних картинок и баннеров. Вам не нужен парк устройств. Достаточно 2-3 реальных телефонов и повторяемого сценария.

Минимальный набор условий

Держите один и тот же маршрут и одинаковые условия сети, чтобы сравнение было честным. Для каждой сборки прогоняйте тест хотя бы в таких режимах:

• Android среднего или слабого уровня (2-3 года), сеть 3G
• Android нормальный, сеть 4G
• iPhone, сеть 4G
• Любое устройство, но с включенным режимом экономии данных (если есть)

Перед прогоном закройте все вкладки, очистите последние приложения и повторите тест дважды: первый раз «холодный» (после очистки кэша браузера), второй раз «теплый» (с кэшем).

Что фиксировать и как

Вам нужна не идеальная точность, а стабильные измерения. Записывайте секундомером и короткими заметками:

• Время до первого полезного экрана (каталог или первый блок главной)
• Время до клика по карточке без заметной паузы
• Лаги при скролле (есть или нет, где именно)
• «Прыжки» интерфейса: сдвигаются ли цены, кнопки, фото
• Ошибки: пустые блоки, долго грузящиеся фильтры, спиннер без конца

Сведите это в простую таблицу задач: экран, шаг (например, «каталог -> карточка»), устройство и сеть, факт (например, «5.8с до каталога, прыжок цены»), предполагаемая причина (картинки, шрифт, JS), приоритет. Если вы разворачиваете витрину на TakProsto, удобно делать отдельные снимки (snapshots) перед изменениями и сравнивать прогоны «до/после» на тех же телефонах.

Делайте такой прогон перед релизом и после любых изменений в картинках, шрифтах, аналитике и виджетах. Это как контрольный чек в магазине: быстро и сразу показывает, где теряется скорость и деньги.

Типичные ошибки, которые съедают скорость и конверсию

Самое обидное, что магазин может быть «в целом быстрым», но проигрывать на ключевых страницах: главная, категория, карточка товара, корзина. Поэтому чек-лист производительности интернет-магазина нужно проверять не по ощущениям, а по реальным сценариям покупателя и на мобильной сети.

Чаще всего скорость и конверсию съедают вот такие промахи:

• Перегруженный первый экран: тяжелые слайдеры, видео, несколько промо-баннеров и анимаций. Пользователь еще не увидел товар, а браузер уже занят декором.
• Lazy-load там, где он вреден: логотип, главное фото товара и крупный hero-баннер не должны подгружаться «когда-нибудь потом». Это бьет по LCP и создает ощущение пустого экрана.
• Кэш без правил: закэшировали все подряд и получили старые цены, неактуальные остатки или баннеры вчерашней акции. Пользователь теряет доверие, а поддержка получает жалобы.
• Сторонние скрипты без контроля: чаты, виджеты, пиксели, A/B тесты, «умные» рекомендации. Один неудачный скрипт может блокировать поток, задерживать ввод и ухудшать INP.
• Оптимизация «в вакууме»: ускорили абстрактную страницу в тесте, но не тронули самые посещаемые входные точки. В итоге метрики Core Web Vitals на боевых страницах почти не меняются.

Простой способ поймать эти ошибки: выберите 3-5 целевых страниц и один сценарий (зайти из поиска, открыть карточку, добавить в корзину). Затем повторите на реальном смартфоне по LTE/3G и посмотрите, где именно «провисает» первый полезный контент, где дергается верстка, и что мешает клику.

Если вы собираете витрину на платформе вроде TakProsto, зафиксируйте базовую версию, а правки вносите по одной. Так проще увидеть, что реально ускорило загрузку, а что просто «красиво звучало».

Короткий чек-лист перед запуском и после изменений

Если времени мало, используйте этот чек-лист как «стоп-кран» перед релизом. Он помогает не спорить о вкусах, а быстро понять, не сломали ли вы скорость и удобство на мобильных.

Перед запуском

Проверьте на реальном смартфоне и обычной мобильной сети (не на мощном ноутбуке по Wi-Fi). Дальше пройдитесь по пунктам:

• Первый экран: главный блок и ключевое фото/заголовок появляются быстро, без пустого «скелета» дольше пары секунд (ориентир для LCP).
• Реакция: фильтры, кнопка «Купить», открытие карточки и ввод в поиск отвечают сразу, без «залипания» интерфейса (ориентир для INP).
• Стабильность: карточки, цены и кнопки не прыгают при подгрузке баннеров, отзывов и изображений (ориентир для CLS).
• Картинки: отдаются в подходящем размере под экран, в современном формате, а загрузка ниже первого экрана включается только по месту (lazy-load).
• Кэш и версии: статика живет долго, но обновления приходят предсказуемо (версионирование файлов, аккуратная инвалидация, без «у меня старая корзина»).

После этого зафиксируйте решение SSR/CSR одним абзацем в документации: что рендерится на сервере и почему (например, карточка и категория ради SEO и скорости), а что можно на клиенте (личный кабинет, сложные фильтры). Это экономит часы споров при следующем изменении.

После любых изменений

Повторяйте минимум:

• Прогон 3-5 ключевых сценариев: каталог - карточка - добавление в корзину - оформление.
• Сравнение метрик до/после (LCP, INP, CLS) и веса страницы.
• Проверка кэша: новая версия реально приходит на телефон после обновления.

Так чек-лист производительности интернет-магазина превращается в привычку, а не разовую «проверку перед праздниками».

Пример: как ускорить витрину без полного переписывания

Представьте бюджетный интернет-магазин на 500 товаров, где каждую неделю меняются акции. Реклама ведет в мобильную витрину, но люди уходят: первый экран грузится долго, фильтры дергаются, а баннеры выглядят красиво только на десктопе.

Что было: на главной стоит один и тот же баннер 2400px для всех экранов, карточки товаров тянут большие фото без сжатия, а фильтры отправляют запрос на каждое нажатие и пересчитывают список на слабых телефонах. В результате LCP уползает за 4-5 секунд, INP становится заметно хуже при прокрутке и фильтрации, CLS скачет из-за поздней подгрузки шрифтов и баннеров.

План на 2 недели

За 10 рабочих дней можно закрыть 6-8 задач из чек-листа производительности интернет-магазина, не меняя архитектуру целиком:

• Пережмите баннеры и фото товаров, включите адаптивные размеры (отдельные версии для 360-420px, 768px, десктопа).
• Включите lazy-load для изображений ниже первого экрана, а для первого экрана задайте приоритет загрузки.
• Зафиксируйте размеры медиа (width/height или aspect-ratio), чтобы убрать скачки макета.
• Разделите тяжелый JS: вынесите фильтры и сортировку в отдельный чанк, отложите неважные виджеты.
• Добавьте кэширование: статика с долгим сроком, API с ETag и коротким TTL, плюс осторожный stale-while-revalidate для списков.

Оставшиеся задачи сделайте в тексте требований: SSR для страниц категории и товара (чтобы первый контент появлялся быстрее), а интерактив фильтров оставьте на клиенте. И обязательно уберите лишние запросы: дебаунс на фильтрах 200-300 мс и отмена предыдущих запросов.

Как измерить и не откатиться

До и после снимите: LCP, INP, CLS, TTFB, вес первого экрана (KB), число запросов и размер изображений в карточке. Сравнивайте в одинаковых условиях: один и тот же телефон или эмуляция, одинаковая сеть.

Чтобы скорость не «уплыла» после следующих правок, введите простой перф-бюджет (например, лимит на вес изображений и JS на главной) и правило: любые новые баннеры проходят сжатие и проверку размеров. Если вы собираете витрину на TakProsto, удобно делать снапшоты перед изменениями и быстро откатываться, если метрики ухудшились.

Следующие шаги: как превратить чек-лист в план работ

Чтобы чек-лист производительности интернет-магазина не остался файлом в заметках, превратите его в короткий бэклог с оценкой. Пройдитесь по пунктам и рядом запишите трудозатраты в часах (включая тестирование), а также риск (может ли это сломать корзину, оплату, аналитику).

Дальше разложите задачи по 3 релиза, чтобы получить эффект быстро и не распылиться:

• Сегодня: быстрые победы без риска (сжатие изображений, выключение лишних скриптов, базовый кэш статики)
• На неделе: задачи средней сложности (lazy-load ниже первого экрана, корректные заголовки Cache-Control, критический CSS)
• В этом месяце: изменения архитектуры (SSR или CSR решение для каталога и карточки, оптимизация API, переразметка под CWV)

Чтобы прогресс не зависел от памяти команды, автоматизируйте повторяемое. Сделайте один стандарт для картинок (форматы, размеры, качество) и один стандарт для кэша (что кэшируем, как долго, как обновляем). Добавьте простую проверку перед релизом: загрузка на 3G/4G, LCP/INP/CLS, вес первого экрана, количество запросов.

Если витрину собираете в TakProsto, начните с planning mode: зафиксируйте релизы и критерии готовности (например, LCP меньше 2.5с на мобильных). Для безопасных правок используйте snapshots и rollback, чтобы смело пробовать новые правила кэша или рендеринг, и быстро откатываться, если пошли ошибки.

Закрепите привычку: один замер скорости перед каждым релизом и один после. Так производительность перестает быть разовой задачей и становится частью процесса.