Карточка товара на мобиле: стабильные 92–93 балла без переделки сайта

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

Зачем это рекламе

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

Исходная точка

Мы смотрели два вида данных, и их важно различать.

Полевые данные (CrUX) собирает Google с настоящих посетителей в браузере Chrome за последние 28 дней. По ним мобильная страница товара не проходила проверку Core Web Vitals. Главная проблема была в LCP, то есть во времени, за которое на экране появляется основной элемент страницы, обычно крупное фото или заголовок: 3,8 секунды при норме до 2,5. Время ответа сервера (TTFB) составляло 1,4 секунды при норме до 0,8. Отзывчивость на нажатия и стабильность вёрстки были в норме.

Лабораторные данные (Lighthouse) получают одним искусственным прогоном с имитацией медленного мобильного интернета. Lighthouse выставляет общую оценку от 0 до 100. Здесь мы сразу столкнулись с разбросом: один прогон того же адреса дал 64 балла и LCP 5,2 секунды, другой дал 90 баллов. В подробном отчёте при 64 баллах LCP был 5,0 секунды, а страница весила около 2,8 МБ. Поэтому прежде чем что-то чинить, нужно было понять, почему результаты так прыгают.

Что тормозило на самом деле

Первая гипотеза была про кэш: будто сервер каждый раз собирает страницу заново из-за cookie у анонимных посетителей. Мы проверили её прямыми замерами на сервере, и она не подтвердилась. Кэш работал: готовая страница отдавалась примерно за 7 миллисекунд, в том числе посетителю с cookie. Эту линию мы закрыли и ничего в ней не меняли. Лишняя работа там создала бы риски и не дала бы результата.

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

• Виджет онлайн-чата весил около 1,6 МБ, больше всего на странице. Но он, как и счётчики аналитики, уже загружался после полной загрузки страницы через менеджер тегов. На момент появления основного контента его ещё нет, так что на LCP он не влияет.
• Просмотрщик 3D-моделей весил 286 КБ и занимал процессор примерно на 1,2 секунды. Проверка кода показала, что его уже оптимизировали раньше: он подключается только у товаров с 3D-моделью и грузится лениво. Мы его не трогали.

Настоящих причин нашлось две, и обе связаны с тем, что браузер обязан сделать до отрисовки страницы:

1. Блокирующие скрипты в начале страницы. В заголовке HTML стояли пять файлов JavaScript. Пока браузер их не скачает и не выполнит, он ничего не показывает. Lighthouse оценивал потерю в 1,08–1,28 секунды.
2. Лишний серверный запрос на каждой карточке. Страница отдельно запрашивала у сервера блок «С этим товаром покупают», и этот запрос занимал около 1,1 секунды. При этом блок оказался пустым у всех проверенных товаров: данных для него не было.

Что сделали, по шагам

Порядок работы был жёсткий: каждая правка сначала проверялась на копии сайта, потом проходила регрессию (проверку, что остальное не сломалось), и только после согласия владельца переносилась на рабочий сайт.

Шаг 1. Перенесли скрипты вниз страницы. На сайте был установлен, но выключен модуль, который управляет сборкой CSS и JavaScript. Мы включили его с одной настройкой: отправлять скрипты в конец страницы.

drush en advagg advagg_mod -y
drush vset --exact advagg_mod_js_footer 1
drush cc all

В заголовке осталось два скрипта вместо пяти: jQuery и ядро Drupal, от которых зависит остальной код. Более агрессивный вариант, отложенная загрузка всех скриптов, на копии сломал формы: встроенный код обращался к jQuery раньше, чем тот загружался. Мы откатили этот вариант и не стали переносить его на рабочий сайт. Перед выкаткой проверили главную, листинг категории, карточку, корзину и оформление заказа: товар добавлялся в корзину, всплывающие окна и 3D-модели работали, новых ошибок не появилось.

Шаг 2. Подсказали браузеру, какая картинка главная. На карточке это первое фото товара. Мы добавили ему высокий приоритет загрузки и предварительную загрузку в начале шаблона:

<link rel="preload" as="image" href="/путь/к/фото-товара.png" fetchpriority="high">
<img src="/путь/к/фото-товара.png" loading="eager" fetchpriority="high" alt="...">

Честно скажем: LCP от этого не изменился. Фото весило 3,3 КБ и грузилось мгновенно, так что узким местом оно не было. Правку мы оставили, потому что она корректна и защищает от ухудшений в будущем. Конвертировать фото в WebP при таком весе смысла не было.

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

Шаг 3. Убрали пустой серверный запрос. Для блока «С этим товаром покупают» мы отключили отдельную догрузку. На каждой карточке стало одно обращение к серверу вместо двух, контент не пропал, потому что блок и так был пуст. Скорость в лаборатории от этого не выросла, как мы и ожидали, зато сервер больше не выполняет полный цикл обработки ради пустого блока при каждом просмотре товара.

Результат и чего мы ещё не знаем

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

После остальных шагов оценка держалась на 92–93 балла, LCP на 3,2 секунды.

Теперь о том, чего эти цифры не доказывают:

• Это лабораторные замеры. Их снимают в искусственных условиях, и стартовые 64 балла были худшим из двух прогонов. Корректнее говорить о том, что результат стал высоким и стабильным, чем о росте «в полтора раза».
• Полевые данные после правок мы не подтвердили. Проходит ли теперь страница Core Web Vitals у реальных посетителей, пока неизвестно. CrUX копит данные 28 дней, и сверку с ним ещё нужно провести.
• 3,2 секунды всё ещё больше нормы в 2,5. Следующие рычаги мы видим: один CSS-файл в заголовке по-прежнему задерживает отрисовку, а оставшийся запрос к серверу за корзиной стоит на пути загрузки. Кроме того, разница между 7 миллисекундами ответа на сервере и 1,4 секунды в поле пока не объяснена до конца: это могут быть сеть, лишний редирект на старый адрес страницы и проверка посетителей при первом визите. Это гипотезы, их ещё предстоит измерить.

Короткий чек-лист для своего сайта

1. Отделите полевые данные от лабораторных. Решение принимают по полю, лаборатория помогает найти причину.
2. Прогоните одну страницу несколько раз. Если оценка скачет, разберитесь с разбросом, прежде чем что-то менять.
3. Не верьте самой большой цифре в отчёте на слово. Тяжёлый виджет может грузиться уже после показа страницы и никому не мешать.
4. Проверьте, сколько скриптов стоит в начале страницы до контента.
5. Найдите, какой элемент считается главным (LCP), и убедитесь, что браузер узнаёт о нём сразу.
6. Посмотрите, какие запросы страница делает к серверу, и нет ли среди них запросов за пустыми блоками.
7. Каждую правку сначала проверяйте на копии сайта вместе с корзиной и формами.
8. Через месяц сверьтесь с полевыми данными. До этого результат не подтверждён.