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

Поскольку показатели эффективности Google скоро повлияют на нашу позицию в результатах поиска, мы хотели, чтобы страница поиска наставника появлялась в Google Search Console как можно быстрее. В частности, нас беспокоила метрика кумулятивного сдвига макета (CLS). У нас было около 0,4. Нам пришлось уменьшить его до 0,1 для 75% загрузки нашей страницы, что мы смогли сделать с помощью нескольких инструментов.

Отслеживание CLS в режиме реального времени

Во-первых, мы имитировали Отчет о пользовательском опыте Chrome с помощью web-vitals. Этот шаг был необходим, потому что CrUX не позволял нам запрашивать данные для определенных URL, агрегированных по дням.

Затем мы смогли отслеживать нашу CLS в режиме реального времени. Используя результаты, мы обнаружили несколько очевидных проблем, которые легко исправить. Эти оптимизации снизили наш CLS до 0,2.

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

Регистрация триггеров CLS

Web-Vitals позволили нам определить точные узлы DOM, вызывающие наибольшую CLS. Список выявил несколько областей, в которых мы могли бы попытаться воспроизвести проблемы:

Мы сделали еще одну серию исправлений, которые снизили наш CLS до желаемого 0,1. На этом мы думали, что наша работа закончена и можем перейти к более насущным вопросам.

Однако две недели спустя CLS вырос до 0,15. Хотя мы могли видеть, какие узлы DOM вызывали проблемы, мы изо всех сил пытались воспроизвести их на основе данных с наших информационных панелей.

HotJar спешит на помощь

Мы используем записи HotJar, чтобы лучше понимать поведение наших клиентов. Эти записи выглядят как реконструкции нашего реального DOM с нашим исходным CSS.

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

HotJar воспроизводит все записанные мутации DOM с применением нашего исходного CSS. Их проигрыватель также добавляет имя класса hotjar-css-hover к нашим корням DOM, чтобы переопределить события мыши, пока мы просматриваем пути пользователей:

Мы использовали это имя класса, чтобы начать выделять все сдвиги макета. Мы также отображали текущее значение CLS, обновляемое в режиме реального времени по мере взаимодействия пользователей со страницей. Вот пример.

Проблема:

Соответствующая запись HotJar:

Вот более подробно выделенные области:

Вот индикатор CLS:

Обратите внимание, что отладочная информация остается невидимой для наших пользователей!

Вот код, который это делает:

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

После того, как мы исправили обнаруженные проблемы, наш CLS снова стал зеленым, теперь он составляет 0,09 для 75% загрузки нашей страницы.