Еще одно приложение, ещё один счетчик — и магазин уже тормозит

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

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

В ветке Shopify Community от 2 сентября 2026 года обсуждают скорость при использовании Meta, TikTok, Google, Klaviyo и приложений. На 7 сентября автор не подтвердил успешное исправление.

В IceStoreGroup мы сталкивались с подобными проблемами и решали их. Но начинать такой разбор я предпочитаю с вопроса: что именно замедлилось и чем мы можем это подтвердить?

Сначала нужно понять, что именно заставляет ждать

Фраза «магазин медленный» объединяет разные ситуации. Долго появляется основное изображение. Страница уже видна, но выбор размера подвисает. Корзина обновляется с задержкой. После перехода к оплате долго рассчитывается доставка. У этих симптомов могут быть разные причины.

Для первого приближения полезны три показателя: скорость появления основного содержимого (LCP), задержка реакции на действие (INP) и неожиданные смещения элементов (CLS). Они описывают разные стороны работы страницы. Shopify рекомендует проверять тему, приложения и сторонний код; удалённое приложение при этом может оставить код в теме. Рекомендации Shopify по производительности.

Я бы зафиксировал конкретную страницу, устройство, действие и момент задержки. Затем повторил один и тот же путь: карточка товара, выбор варианта, добавление в корзину, оформление заказа. В отчётах о производительности Shopify нужно смотреть опыт реальных посетителей, а в инструменте проверки скорости Google (PageSpeed Insights) — результаты для конкретных страниц. Смешивать лабораторный запуск и накопленную статистику посещений в одно «до и после» нельзя. Отчёты Shopify.

Здесь уместен подход, который мы уже описывали в статье о поиске настоящей причины проблем магазина: сначала восстанавливаем связь между симптомом и изменением. Иначе можно потратить бюджет на счётчики, когда задержку создаёт совсем другой компонент.

Список приложений ещё не показывает всю нагрузку

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

Практически я начал бы с четырёх мест. В настройках Shopify — раздел «События покупателей» (Settings → Customer events). В редакторе темы — «Встроенные модули приложений» (App embeds) и блоки на шаблонах страниц. В коде темы — основной файл макета (theme.liquid), подключённые фрагменты и файлы сценариев. В диспетчере тегов Google (Google Tag Manager) — теги и условия их запуска.

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

Затем открываем инструменты разработчика браузера (Chrome DevTools). На вкладке «Сеть» (Network) смотрим домены, повторяющиеся обращения и инициатора запроса (Initiator). На вкладке «Производительность» (Performance) — что выполнялось в момент задержки. Длинный сетевой запрос сам по себе ещё не доказывает, что именно он заблокировал кнопку. Проверка должна связать запрос или выполнение кода с наблюдаемым симптомом.

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

Объединить счётчики — значит разобраться в событиях

Рассмотрим условный пример. Одну покупку в одну рекламную систему передают приложение, вручную добавленный тег и старое подключение. Это ещё не три полезных измерения. Сначала нужно выяснить, какие отправки повторяют друг друга, а какие образуют предусмотренную интеграцией пару браузерных и серверных событий.

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

Именно так я понимаю сокращение счётчиков: один согласованный способ собирать нужное событие, понятные получатели и проверяемая доставка. У Meta, Google и других систем остаются собственные требования. Один контейнер диспетчера тегов не превращает все рекламные платформы в один универсальный счётчик.

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

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

Перенос на сервер помогает, когда понятно, что переносить

В той же ветке встречается обещание стопроцентной точности после переноса отслеживания на сервер. Оснований для такого обещания я не вижу. Обсуждение.

Серверная настройка позволяет принимать данные и распределять их между поддерживаемыми получателями вне браузера. Но источник событий всё равно нужно настроить. Если он зависит от отправки браузером, отсутствие этой отправки не исправляется самим наличием сервера. Как устроен серверный контейнер Google.

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

Есть и другой инструмент: механизм пикселей Shopify (Web Pixels). Он даёт доступ к событиям покупателей в изолированной среде. Но простая вставка старого кода может не сработать: доступ к содержимому страницы ограничен, а у пикселей приложений и пользовательских пикселей разные среды исполнения. Документация Shopify.

Поэтому перенос требует проверки событий, адресов страниц и параметров. Наличие изоляции также не означает отсутствия затрат на загрузку и выполнение. Shopify отдельно предупреждает о рисках производительности некорректных пикселей. Ограничения и риски пикселей.

Ускорение витрины не доказывает ускорение оформления заказа

У оформления заказа собственная конфигурация и редактор, отдельный от редактора темы. Поэтому проверку карточки товара нельзя считать проверкой оплаты. Устройство настройки оформления заказа.

Если задержка появляется после нажатия кнопки покупки, я бы отдельно проверил переход, расчёт доставки, доступные способы оплаты и установленные расширения. Сравнивать нужно одинаковый товар, адрес и сценарий. Оптимизация рекламного кода не устраняет автоматически медленный внешний расчёт доставки или проблему отдельного расширения.

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

Как убедиться, что вместе с нагрузкой не исчезли данные

Отложить всё на несколько секунд технически несложно. Но посетитель может уйти раньше, чем начнётся сбор. Поэтому задержку запуска я считаю хорошим решением только для тех функций, которые допускают её без потери нужного измерения. Условие запуска должно соответствовать задаче; Google рекомендует ограничивать ненужные срабатывания по страницам и событиям. Рекомендации по тегам.

До изменений мы фиксируем, какие события и параметры нужны бизнесу. Для электронной торговли это обычно просмотр товара, добавление в корзину, начало оформления и покупка. Для покупки проверяем идентификатор операции, сумму, валюту и товары; дополнительно — параметры, используемые для определения источника перехода. Требования Google к событиям электронной торговли.

Проверка после изменений должна отвечать на несколько конкретных вопросов:

• Проходит ли прежний путь покупателя на телефоне: вариант товара, корзина, доставка и оплата?
  
• Стало ли быстрее то действие, которое тормозило, при сопоставимых условиях и повторных замерах?
  
• Появляются ли нужные события у получателей, с правильными товарами, суммой и валютой?
  
• Не учитывается ли одна покупка несколько раз и не пропускаются ли покупки в проверяемом сценарии?
  
• Сохранилась ли работа с согласием покупателя и корректное поведение при отказе от отслеживания?
  

В разделе «События покупателей» можно запустить проверку пикселя приложения (Test) и пройти сценарий с помощником Shopify (Shopify Pixel Helper). Зелёный статус подтверждает успешное выполнение обработчика, но сам по себе не доказывает приём данных рекламной системой. Проверяем и принимающую сторону. Проверка пикселей Shopify.

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

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

Что в итоге нужно исправлять

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

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

Аудит и внедрение — отдельные этапы. Это позволяет оценить объём работ до переделки и не продавать сложную архитектуру там, где достаточно устранить лишнее подключение.
Такую проблему можно решить. Но новое приложение, обновление темы или дополнительный рекламный канал способны вернуть нагрузку. Поэтому вместе с исправлениями нужны журнал изменений, ответственный за подключение счётчиков и повторная проверка после существенных изменений. О том, какие сигналы стоит замечать раньше, мы писали в статье о предупреждающих признаках проблем магазина.

Если магазин уже заставляет ждать, начните с диагностики IceStoreGroup. Мы поможем установить причину, оценить стоимость исправлений и проверить результат. Для меня завершённая оптимизация — это магазин, которым удобно пользоваться, и данные, на основании которых по-прежнему можно принимать решения.