Перейти к содержимому

Ювелирные украшения (DTC)Работа для клиента

PageSpeed 97: поддельный результат теста скорости

Оценку PageSpeed ювелирного магазина в Великобритании подогнали под тестового робота. Без подмены она составила 78. Я поднял её до 92 и сократил LCP с 3,4 с до 1,2 с.

Задача

Контекст

Ювелирный DTC-бренд в Великобритании продаёт через Shopify. Владелец попросил ускорить магазин и разобраться с высокими CPM в Meta. Я был единственным подрядчиком. Сначала проверил скорость, затем трекинг: работу рекламного аккаунта и витрины.

Знакомо?

Что видел клиент

Ситуация Ювелирные украшения (DTC)
Отметьте, что про вас

Расследование

Как я искал причину

  1. Расшифровал скрипт без его выполнения. В head темы был обфусцированный фрагмент с двумя блоками eval(atob(...)). Я расшифровал оба и прочитал код.

  2. Проверил выполнение в браузере. Открыл одну страницу товара с параметрами двух устройств и сравнил число отложенных скриптов.

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

  4. Провёл сравнение A/B/C на одной странице товара в трёх состояниях: как было, клоакинг убран, честная оптимизация.

  5. Проверил настройку Meta на уровне наборов данных и событий: какие интеграции подключены, статус дедупликации, история зависимостей. Затем разложил CPM по кампаниям по данным самого рекламного аккаунта.

Находки

Что я нашёл

  1. Finding 01

    Тестовый робот получал другую загрузку страницы

    Один блок проверял, содержит ли navigator.platform значение x86_64, второй искал X11 и GTmetrix. При совпадении скрипт менял тип динамически добавленных скриптов на lazyload и удалял URL ресурсов. Измерительный инструмент видел быструю страницу, потому что часть ресурсов не загружалась.

    Проверка в браузере подтвердила подмену: на настоящем телефоне отложено 0 скриптов, у тестового робота отложено 75 скриптов. Телефон загружал полную неоптимизированную страницу примерно на уровне оценки 78. В отчёте при этом было 97. После удаления фрагмента оценка составила 78.

  2. Finding 02

    Сбой трекинга Meta не подтвердился

    В обоих наборах данных работали пиксель Meta и Conversions API. В проверенных разделах активных ошибок дедупликации не было. События из нескольких доменов избыточно собирались параллельно в два набора. Для их объединения сначала нужно разделить данные по доменам и проверить дедупликацию отдельных событий. Срочного исправления трекинга не требовалось.

  3. Finding 03

    Предположение про CPM не подтвердилось

    Высокие CPM в США были сосредоточены в отдельных кампаниях. Ни витрина, ни трекинг как причина не подтвердились. Чтобы назвать точную причину, нужно сравнить кампании по аудиториям, плейсментам, ставкам и частоте показов, а это вопрос медиабаинга, а не измерений.

Передача

Что я исправил

Акт передачиСдано июль 2026

  1. Убрал клоакинг-фрагмент из рабочей темы, сохранив снимок исходной темы и заметку об откате.
  2. Добавил предзагрузку LCP-изображения (fetchpriority=high), чтобы главное изображение отрисовывалось раньше.
  3. Отложил некритичные приложения (таблицу размеров и запись сессий) до первого взаимодействия или свободного времени браузера. Обработчик отложенной загрузки исключал весь трекинг, приложения корзины и выбора цвета (swatch). Измерения не задерживались, работа чекаута сохранялась.
  4. Сдал клиентский отчёт, основной технический отчёт и ответы на восемь вопросов клиента, а также план объединения наборов данных: обратимый, с шагами, которые идут только после согласования.
  5. Изменений в рабочем трекинге я не вносил. Переключение наборов данных оставил открытым намеренно, пока не подтвердятся атрибуция по доменам и дедупликация на уровне событий.

До → после

Результаты с датами

Работа для клиента Сделано для реальных клиентов. Данные клиентов обезличены.

Оценка PageSpeed при подмене загрузки для тестового робота

июль 2026

97 to 78

До
97 (подделка: скрипты откладывались только для тестовых роботов)
После
78 (честный исходный уровень после удаления клоакинга)

Оценка PageSpeed после честной оптимизации

июль 2026

78 to 92

До
78
После
92

LCP (мобильная версия, страница товара)

июль 2026

3,4 с to 1,2 с

До
3,4 с
После
1,2 с

Общее время блокировки (мобильная версия, страница товара)

июль 2026

200 мс to 50 мс

До
200 мс
После
50 мс

Отложенные скрипты: настоящий телефон и бенчмарк-бот

июль 2026

0 отложено на настоящем телефоне vs 75 отложено для бота

Полная таблица результатов
ЧтоДоПослеДата
Оценка PageSpeed97 (подделка)78 честных → 92 после оптимизациииюль 2026
LCP (мобильная версия, страница товара)3,4 с1,2 сиюль 2026
Общее время блокировки200 мс50 мсиюль 2026
Отложено скриптов0 (настоящий телефон)75 (бенчмарк-бот)июль 2026

Заметка Данииладо того, как вы решите

Что это значит для похожего бизнеса

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

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

Даниил

Daniil Maximkin

Здравствуйте, я Даниил.

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

Есть похожая задача?

Опишите задачу

Отвечу в течение одного рабочего дня. Первый ответ бесплатный. Или напишите напрямую: next@taskfordaniel.com

Обсудить задачу

Расскажите, что нужно разработать, исправить или подключить.

Описать задачу next@taskfordaniel.com