Большинство витрин тормозят не там, где показывает отчёт. Работа начинается с Chrome UX Report по вашему origin, потому что именно его оценивает Google и именно это высидели ваши покупатели, а лабораторный прогон рядом показывает причину. Иногда честный ответ — что скорость вам не узкое место, и вы услышите это до того, как потратите на неё хоть что-то. Когда узкое место всё-таки она, чинить надо тот слой, куда уходит время: ответ сервера на Adobe Commerce, приложения и тему на Shopify, конвейер картинок и скрипты, за которые никто не отвечает.
Где обычно лежит время
Ответ сервера, раньше всего остального
Time to First Byte задаёт нижнюю границу для каждой метрики после себя. На Adobe Commerce это поведение полностраничного кэша, Varnish и запросы за страницей категории. Никакая работа на фронтенде не вытащит медленный origin, а оценка Lighthouse не скажет вам, что время ушло именно туда.
LCP: первый экран и конвейер картинок
Приоритет для главного изображения, шрифты, которые не блокируют отрисовку, и критический CSS инлайном. Цель — 75-й перцентиль ваших реальных мобильных посетителей, то самое число, которое оценивает Search Console, а не балл одного прогона на одной машине.
INP: скрипты, которые писали не вы
Тег-менеджеры, виджеты чатов, приложения отзывов и пиксели. Они приходят через маркетинг, они работают в главном потоке, и на Shopify это обычно главная причина. Фасады и отложенная загрузка там, где скрипт себя оправдывает, и аргумент за его удаление там, где нет.
CLS, и это не мелочь
Зарезервированное место под всё, что подгружается позже, и размеры у каждой картинки. В лучшем по дизайну коммерческом эксперименте моего реестра CLS сдвинулся на 92,72%, тогда как LCP не сдвинулся вообще, а выручка на посетителя выросла на 53,37%. Это не доказывает, что причина в CLS. Это значит, что стабильность вёрстки нельзя оставлять напоследок.
Проверяется на ваших пользователях, а не на моей машине
web-vitals на странице отдаёт реальные сессии, и они сверяются с Chrome UX Report и отчётом Core Web Vitals в Search Console. Полевые данные — единственное доказательство, что деплой помог, а 28-дневное окно решает, засчиталось ли это.
Как идёт работа
- 1
Диагноз - полевые данные по origin, лабораторный прогон ради причины и слой, в котором лежит время
- 2
Цена - сколько стоит закрыть разрыв на вашем собственном трафике, по рандомизированным экспериментам, а не по цифре, которой пользуется рынок
- 3
Чиним ту часть, которая окупается, по порядку, и каждое изменение измеримо отдельно
- 4
Проверка в поле - мониторинг реальных пользователей и те самые 28 дней, которые решают, засчиталось ли
Чем меряю и с чем работаю
Что у вас есть, когда работа закончена
Это результаты работы, а не прогнозы. Каждый из них можно проверить в день сдачи.
- Ваши собственные полевые данные из Chrome UX Report, прочитанные на 75-м перцентиле, по которому вас и оценивает Google.
- Цена разрыва, посчитанная по опубликованным экспериментам, с названными источниками и указанной неопределённостью.
- Список того, куда уходит время, упорядоченный по стоимости исправления, включая пункты, которые чинить не стоит.
Связанные материалы
Этот маршрут поможет оценить глубину имплементации до старта проекта.