Низкий балл PageSpeed и реальная скорость магазина Shopify

Меня заинтересовало обсуждение скорости Shopify-магазинов, потому что за техническим вопросом я увидел знакомую управленческую проблему. Есть число, которое выглядит неудовлетворительно. Есть желание его улучшить. И между ними очень быстро появляется решение потратить деньги, хотя ещё не выяснено, что именно мешает покупателю.

В обсуждении Shopify Community DanielBuilds сообщил о проверке 5 991 магазина. Медианный мобильный балл составил 56; у части магазинов низкая лабораторная оценка сочеталась с хорошими данными реальных посещений. Это наблюдения автора, а не репрезентативное исследование всей платформы. Но вопрос для меня вполне практический: что именно мы покупаем, когда заказываем ускорение?

Представим владельца, которому предлагают поднять оценку с 50 до 90. Ему трудно отказаться: цифра понятная, результат выглядит измеримым. Однако я бы сначала попросил показать, где человек ждёт. До появления фотографии? После выбора размера? При добавлении товара в корзину? Если ответ сводится к цвету индикатора, объём работ определён слишком рано.

Как я читаю два разных результата одного теста

В PageSpeed Insights соседствуют лабораторная проверка Lighthouse и данные реальных пользователей Chrome за предыдущие 28 дней. При недостатке наблюдений для страницы инструмент может показать сводные данные сайта, обозначенные Origin, либо не показать их вовсе. Поэтому первым делом я проверяю устройство, период и то, к какому набору страниц относится результат.

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

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

Для оценки реального опыта я смотрю на три Core Web Vitals: LCP показывает появление крупнейшего видимого элемента, INP — отзывчивость на взаимодействия, CLS — неожиданные смещения содержимого. Ориентиры хорошего результата: LCP не более 2,5 секунды, INP не более 200 миллисекунд, CLS не более 0,1. Оценивать их следует по 75-му процентилю, отдельно для мобильных и настольных устройств: как минимум 75 процентов наблюдений должны укладываться в соответствующий ориентир.

Я также использовал бы отчёты Shopify о производительности, чтобы сравнивать страницы и типы страниц, устройства и изменения во времени. Это помогает выбрать место для исследования. Проверять только главную страницу магазина, который получает покупателей

Почему я не спешу назначать виновником JavaScript

В ветке ecom-4all связал разрыв результатов с JavaScript. DanielBuilds возразил, сопоставив около 275 мс блокировки с LCP около 9,9 секунды. Затем разговор перешёл к составляющим LCP. Мне близок этот переход к проверяемой причине, хотя само сравнение двух величин её ещё не устанавливает.

Здесь я уточнил бы аргумент. Total Blocking Time складывает блокирующие части длительных задач в определённом интервале лабораторного измерения. Это не всё время работы JavaScript. Из небольшой величины TBT нельзя вывести, что сценарии никак не задерживают появление изображения. Например, код может поздно добавить его адрес в страницу, после чего браузеру ещё предстоит загрузка. Для такого вывода нужна запись выполнения конкретной страницы.

В методике разбора LCP время разделяется на ожидание первого байта HTML, задержку до начала загрузки нужного ресурса, саму загрузку и задержку до отображения. Я бы попросил разработчика показать, какая часть занимает время именно в нашем случае. Это намного полезнее общего обещания «почистить код».

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

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

Если крупнейшее изображение первого экрана загружается отложенно, я бы убрал lazy loading именно у него и сделал адрес доступным браузеру в исходном HTML. Изображения ниже первого экрана могут продолжать загружаться позже. Такой подход описан в рекомендациях Shopify по LCP. Сначала нужно определить фактический LCP-элемент на мобильном и настольном экране: он не обязан быть одинаковым.

Для подтверждённого кандидата LCP я проверил бы fetchpriority="high". Повышать приоритет всей галерее я не предлагаю. Если всё объявлено срочным, браузеру труднее выделить действительно нужный ресурс. Приёмка здесь конкретная: нужный запрос начинается раньше и элемент появляется быстрее в сопоставимых повторных замерах.

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

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

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

Почему число приложений не заменяет расследование

Мне понятна идея сократить приложения. Но простое правило «оставить не больше пяти» ничего не говорит о работе конкретного магазина. Приложение может заниматься внутренним процессом, а небольшой виджет — выполнять тяжёлую работу на каждой карточке. Я бы оценивал, что загружается и выполняется в нужном сценарии, какую задачу это решает и можно ли добиться той же пользы с меньшими затратами.

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

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

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

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

Что я считаю обоснованным бюджетом на скорость

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

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

Именно такой результат я ожидаю от диагностики Shopify-магазина: конкретный симптом, подтверждённые наблюдения, границы неопределённости и план проверки исправления. Диагностика и реализация — отдельные этапы. Объём доработки должен следовать из причины, которую удалось установить, а не из заранее выбранного способа продать ускорение.

Отдельно я бы обсудил аргумент про SEO. Google использует Core Web Vitals, но не обещает высокие позиции за хорошие показатели. Поэтому в работе над SEO и GEO Shopify-магазина я рассматриваю скорость вместе с доступностью страниц, содержанием и структурой. Обещать рост поискового трафика только за переход индикатора в зелёную зону было бы необоснованно.

Как я предложил бы принять выполненную работу

Чтобы спор о скорости не закончился обменом скриншотами, я заранее зафиксировал бы пять условий приёмки.

1. Выбраны конкретные страницы и действия, устройства, рынок и язык. Исходные замеры сохранены вместе с условиями теста и состоянием согласия на отслеживание.
   
2. Повторные лабораторные проверки выполнены в сопоставимых условиях. Показаны несколько запусков и их разброс, а улучшение связано с устранённой задержкой.
   
3. На телефоне и компьютере проверены выбор варианта, актуальная цена, добавление и изменение корзины, переход к оформлению. Если жалоба относится к оплате, она исследована отдельно.
   
4. Нужные функции и согласованные события аналитики сохранены. Для изменений определён способ возврата, проверенный в пределах затронутых настроек.
   
5. Назначена дата повторной оценки реальных посещений после накопления достаточных данных. Периоды и состав аудитории сопоставимы, ограничения сравнения указаны.
   

Свежую лабораторную проверку можно получить сразу. Полевое окно PageSpeed содержит и посещения до изменения, а данные отчётов Shopify могут запаздывать до 36 часов. Я поэтому не стал бы требовать мгновенного подтверждения эффекта в накопленной статистике. Но и откладывать проверку работающей корзины на месяц оснований нет.

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

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