Чек-лист производительности интернет-магазина для mobile-first витрины: изображения, кэширование, выбор SSR или CSR, приоритеты Core Web Vitals.
Для покупателя «тормозит» не значит «долго грузится весь сайт». Чаще это про мелкие задержки, которые мешают действию: первый экран появился, но кнопки не нажимаются; карточка товара открылась, но фото догружаются рывками; корзина пересчитывается так долго, что кажется, будто ничего не произошло.
В интернет-магазине скорость напрямую влияет на простые вещи: сколько товаров успеют пролистать, найдут ли нужное через поиск, дойдут ли до оплаты. На телефоне терпения меньше: если страница дергается или клики не срабатывают, человек уходит без «второго шанса».
Проверка «у меня на Wi‑Fi быстро» почти ничего не доказывает. У реальных покупателей бывают слабая сеть, экономия трафика, старые смартфоны и фоновые приложения. Поэтому важно смотреть на поведение страницы при плохих условиях и на то, что видит пользователь в первые секунды.
Простой способ понять, где начинаются проблемы:
Дальше пригодится чек-лист производительности интернет-магазина: он поможет выбрать действия, которые улучшают Core Web Vitals и опыт покупателя без дорогих инструментов и долгих переделок.
Core Web Vitals можно перевести на простой вопрос: как быстро покупатель видит товар, как быстро реагирует интерфейс на тап, и не прыгает ли страница в процессе.
LCP (Largest Contentful Paint) для витрины и карточки товара - это момент, когда появляется главный контент: фото товара, крупный баннер, заголовок или блок с ценой. Если LCP медленный, человек смотрит на пустоту или серые заглушки и уходит, не дождавшись.
INP (Interaction to Next Paint) - про задержки при действиях: тап по фильтру, выбор размера, переключение фото, добавление в корзину. Типичный симптом - вы нажали, а кнопка «думает», и кажется, что сайт сломан.
CLS (Cumulative Layout Shift) - когда верстка скачет. Чаще всего виноваты изображения без заданных размеров, баннеры, которые догружаются сверху, и шрифты, из-за которых текст «переезжает». В магазине это особенно больно: человек целится в «Купить», а кнопка уезжает.
Если время и деньги ограничены, в чек-листе производительности интернет-магазина обычно важнее так расставить приоритеты:
Простой пример: в каталоге LCP портит тяжелое превью товара, а INP - фильтр, который пересчитывает список на каждом вводе. Исправьте это, и скорость будет ощущаться сразу, даже без полного переделывания сайта.
Когда времени мало, полезнее не «оптимизировать все», а быстро найти 2-3 узких места, которые заметно ухудшают загрузку на мобильных. Хорошая цель на старте: за неделю улучшить один показатель так, чтобы это увидели реальные покупатели.
Мини-аудит на 30 минут можно сделать даже без глубоких знаний. Пройдитесь по сайту с телефона на мобильном интернете и отметьте, где именно возникает ожидание или «дерганье».
Правило 80/20 в магазинах почти всегда про одно и то же: тяжелые изображения, лишний JavaScript на первом экране и отсутствие нормального кэша для статики. Если вы ведете список задач, помечайте те, что уменьшают вес первого экрана и время до первого полезного действия (например, выбрать размер, добавить в корзину).
Дальше расставьте приоритеты по страницам: карточка товара обычно влияет на конверсию сильнее всего, затем каталог, затем корзина и оформление, и только потом главная. Если бюджет совсем минимальный, начните с одной самой посещаемой категории и 3-5 топовых товаров.
Чтобы не распыляться, выберите «одно улучшение в неделю» по простому шаблону:
Так вы двигаетесь измеримо, и чек-лист производительности интернет-магазина превращается в реальный план, а не в бесконечный список пожеланий.
Если мобильная витрина тормозит, чаще всего виноваты картинки. Они занимают больше всего трафика, влияют на LCP (скорость появления главного контента) и могут вызвать скачки верстки (CLS), если размеры не заданы заранее. Даже самый аккуратный чек-лист производительности интернет-магазина обычно упирается именно в изображения.
Начните с форматов. AVIF дает лучший размер, WebP почти везде поддерживается, а JPEG/PNG оставьте как фолбэк. На практике это значит: отдавайте через picture, чтобы браузер сам выбрал лучший вариант.
Дальше размеры. Не грузите одну и ту же «большую» картинку везде. Для карточек, выдачи и галереи нужны разные версии, а на разных экранах разные ширины. Обязательно задавайте width и height (или aspect-ratio), чтобы страница не прыгала при загрузке.
Короткий контрольный список для одной страницы товара:
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 для первого фото, остальные можно лениво.
Первый экран на мобильном решают две вещи: сколько кода нужно скачать и сколько работы браузер делает до первого клика. Даже хороший дизайн может «тормозить», если на старте вы грузите весь каталог, все виджеты и тяжёлые шрифты.
Правило простое: на старте нужны шапка, поиск, корзина, несколько карточек и базовая аналитика. Всё остальное догружайте после первого рендера или по действию пользователя.
Проверьте себя по этому короткому чек-листу:
Шрифты легко съедают секунды. Используйте 1-2 начертания, формат WOFF2 и font-display: swap, чтобы текст появлялся сразу. Если бренд позволяет, начните с системных шрифтов, а фирменный подключайте позже.
Анимации делайте на transform и opacity, избегайте частых перерасчётов размеров и позиций. Если при прокрутке «дрожит» интерфейс, сначала отключите анимации на карточках и шапке и проверьте, ушли ли лаги.
Кэширование почти всегда дает самый дешевый прирост скорости, особенно на мобильной сети. В любом чек-листе производительности интернет-магазина начните с простого: статике нужен долгий кэш, а данным из API - короткий и предсказуемый.
Для статики (картинки, CSS, JS) задайте долгий HTTP-кэш и версионирование файлов. Тогда браузер не будет скачивать одно и то же при каждом заходе.
Cache-Control: public, max-age=31536000, immutableС API аккуратнее. Кэшируйте то, что не меняется каждую секунду: списки каталога, агрегированные фильтры, подсказки поиска. Для корзины, цен по персональным правилам и статуса наличия в реальном времени лучше не кэшировать или кэшировать на очень короткое время.
Хорошая «безопасная» стратегия для каталога и картинок - stale-while-revalidate: пользователь сразу видит сохраненную версию, а в фоне подтягивается свежая. Это снижает задержки без ощущения «устаревшего сайта».
Service worker полезен, но не превращайте магазин в офлайн-приложение. Достаточно кэшировать оболочку (иконки, базовые стили, шрифты) и часть изображений, но не кэшировать:
Чтобы не ломать обновления после релиза, держите один источник правды: версия сборки меняется - меняются имена файлов. Для service worker добавьте понятный сценарий обновления (новая версия активируется после перезагрузки), иначе пользователи могут неделями сидеть на старой витрине.
SSR (рендер на сервере) и CSR (рендер в браузере) - это не «правильно/неправильно». Это про то, что важнее именно вашему магазину: быстрый первый экран и SEO или сложная интерактивность после входа.
SSR обычно помогает, когда важны поисковые страницы и быстрый первый показ контента на слабых телефонах и медленной сети. Типичные кандидаты: главная, категории, листинг, карточка товара, контентные страницы. Вы чаще увидите улучшение LCP и более стабильное поведение при первом заходе.
CSR обычно достаточно там, где пользователь уже «внутри» и интерфейс постоянно меняется: личный кабинет, избранное, история заказов, админка, сложные формы. Тут важнее отзывчивость (INP) и размер бандла, а SEO почти не играет роли.
Ответьте «да/нет» и выбирайте без споров:
Если «да» хотя бы на 2-3 вопроса, чаще выигрывает SSR или гибрид.
Практичный вариант из чек-листа производительности интернет-магазина: SSR для листинга и карточки, а CSR для фильтров, сортировки, корзины и мелких интерактивных панелей. Так вы ускоряете вход и не усложняете динамику.
Чтобы не спорить «на глаз», замерьте до/после: LCP, INP, CLS и TTFB, плюс бизнес-метрики (конверсия в добавление в корзину и оформление). Если цифры не улучшаются, значит проблема не в SSR/CSR, а в весе ресурсов или логике загрузки.
Мобильная витрина чаще всего «умирает» не от тяжелых фич, а от плохого поведения на слабой сети и дерганого интерфейса. Проверьте сценарий: первый визит с 3G, холодный кеш, без авторизации. Покупатель должен увидеть бренд, название товара и цену раньше, чем загрузятся отзывы и рекомендации.
Хорошее правило: сначала показываем каркас страницы и ключевую покупательскую информацию, а уже потом «доклеиваем» второстепенные блоки. Скелетоны полезны там, где размер блока заранее известен (карточка товара, список). Если размер неизвестен, скелетон часто ухудшает CLS: контент скачет, кнопки уезжают, палец промахивается.
Мини-чек для mobile-first (подойдет как часть общего чек-листа производительности интернет-магазина):
Если после применения фильтра экран «прыгает», закрепите верхнюю панель и сохраняйте позицию прокрутки. Это маленькая деталь, но она напрямую влияет на ощущение скорости.
Проверка «вживую» часто ловит то, что не видно в лаборатории: подвисания при скролле, задержку открытия карточки, скачки макета из-за поздних картинок и баннеров. Вам не нужен парк устройств. Достаточно 2-3 реальных телефонов и повторяемого сценария.
Держите один и тот же маршрут и одинаковые условия сети, чтобы сравнение было честным. Для каждой сборки прогоняйте тест хотя бы в таких режимах:
Перед прогоном закройте все вкладки, очистите последние приложения и повторите тест дважды: первый раз «холодный» (после очистки кэша браузера), второй раз «теплый» (с кэшем).
Вам нужна не идеальная точность, а стабильные измерения. Записывайте секундомером и короткими заметками:
Сведите это в простую таблицу задач: экран, шаг (например, «каталог -> карточка»), устройство и сеть, факт (например, «5.8с до каталога, прыжок цены»), предполагаемая причина (картинки, шрифт, JS), приоритет. Если вы разворачиваете витрину на TakProsto, удобно делать отдельные снимки (snapshots) перед изменениями и сравнивать прогоны «до/после» на тех же телефонах.
Делайте такой прогон перед релизом и после любых изменений в картинках, шрифтах, аналитике и виджетах. Это как контрольный чек в магазине: быстро и сразу показывает, где теряется скорость и деньги.
Самое обидное, что магазин может быть «в целом быстрым», но проигрывать на ключевых страницах: главная, категория, карточка товара, корзина. Поэтому чек-лист производительности интернет-магазина нужно проверять не по ощущениям, а по реальным сценариям покупателя и на мобильной сети.
Чаще всего скорость и конверсию съедают вот такие промахи:
Простой способ поймать эти ошибки: выберите 3-5 целевых страниц и один сценарий (зайти из поиска, открыть карточку, добавить в корзину). Затем повторите на реальном смартфоне по LTE/3G и посмотрите, где именно «провисает» первый полезный контент, где дергается верстка, и что мешает клику.
Если вы собираете витрину на платформе вроде TakProsto, зафиксируйте базовую версию, а правки вносите по одной. Так проще увидеть, что реально ускорило загрузку, а что просто «красиво звучало».
Если времени мало, используйте этот чек-лист как «стоп-кран» перед релизом. Он помогает не спорить о вкусах, а быстро понять, не сломали ли вы скорость и удобство на мобильных.
Проверьте на реальном смартфоне и обычной мобильной сети (не на мощном ноутбуке по Wi-Fi). Дальше пройдитесь по пунктам:
После этого зафиксируйте решение SSR/CSR одним абзацем в документации: что рендерится на сервере и почему (например, карточка и категория ради SEO и скорости), а что можно на клиенте (личный кабинет, сложные фильтры). Это экономит часы споров при следующем изменении.
Повторяйте минимум:
Так чек-лист производительности интернет-магазина превращается в привычку, а не разовую «проверку перед праздниками».
Представьте бюджетный интернет-магазин на 500 товаров, где каждую неделю меняются акции. Реклама ведет в мобильную витрину, но люди уходят: первый экран грузится долго, фильтры дергаются, а баннеры выглядят красиво только на десктопе.
Что было: на главной стоит один и тот же баннер 2400px для всех экранов, карточки товаров тянут большие фото без сжатия, а фильтры отправляют запрос на каждое нажатие и пересчитывают список на слабых телефонах. В результате LCP уползает за 4-5 секунд, INP становится заметно хуже при прокрутке и фильтрации, CLS скачет из-за поздней подгрузки шрифтов и баннеров.
За 10 рабочих дней можно закрыть 6-8 задач из чек-листа производительности интернет-магазина, не меняя архитектуру целиком:
Оставшиеся задачи сделайте в тексте требований: SSR для страниц категории и товара (чтобы первый контент появлялся быстрее), а интерактив фильтров оставьте на клиенте. И обязательно уберите лишние запросы: дебаунс на фильтрах 200-300 мс и отмена предыдущих запросов.
До и после снимите: LCP, INP, CLS, TTFB, вес первого экрана (KB), число запросов и размер изображений в карточке. Сравнивайте в одинаковых условиях: один и тот же телефон или эмуляция, одинаковая сеть.
Чтобы скорость не «уплыла» после следующих правок, введите простой перф-бюджет (например, лимит на вес изображений и JS на главной) и правило: любые новые баннеры проходят сжатие и проверку размеров. Если вы собираете витрину на TakProsto, удобно делать снапшоты перед изменениями и быстро откатываться, если метрики ухудшились.
Чтобы чек-лист производительности интернет-магазина не остался файлом в заметках, превратите его в короткий бэклог с оценкой. Пройдитесь по пунктам и рядом запишите трудозатраты в часах (включая тестирование), а также риск (может ли это сломать корзину, оплату, аналитику).
Дальше разложите задачи по 3 релиза, чтобы получить эффект быстро и не распылиться:
Чтобы прогресс не зависел от памяти команды, автоматизируйте повторяемое. Сделайте один стандарт для картинок (форматы, размеры, качество) и один стандарт для кэша (что кэшируем, как долго, как обновляем). Добавьте простую проверку перед релизом: загрузка на 3G/4G, LCP/INP/CLS, вес первого экрана, количество запросов.
Если витрину собираете в TakProsto, начните с planning mode: зафиксируйте релизы и критерии готовности (например, LCP меньше 2.5с на мобильных). Для безопасных правок используйте snapshots и rollback, чтобы смело пробовать новые правила кэша или рендеринг, и быстро откатываться, если пошли ошибки.
Закрепите привычку: один замер скорости перед каждым релизом и один после. Так производительность перестает быть разовой задачей и становится частью процесса.
Лучший способ понять возможности ТакПросто — попробовать самому.