Несколько месяцев работы над улучшением Core Web Vitals на главной странице Mail.ru привели к увеличению 75-го процентиля Cumulative Layout Shift (CLS) на 60%, увеличению среднего времени сеанса на 2,7% и коэффициента конверсии основных разделов более чем на 60%. более 10%.
С чего мы начали
Mail.ru — один из ведущих почтовых сервисов русскоязычного Интернета и входит в топ-5 сайтов России по посещаемости . Mail.ru – важный ресурс для многих людей. Его посещают несколько сотен миллионов человек в месяц, и это портал, с которого люди могут получить доступ к электронной почте, новостям, социальным сетям, эффективному поиску в Интернете и многому другому.
Mail.ru хотел предоставить своим посетителям высококачественный пользовательский опыт, поэтому началась работа над улучшением Core Web Vitals. Прежде чем обсуждать нашу стратегию оптимизации, следует отметить несколько технических деталей главной страницы Mail.ru.
Хотя проект уже давно разрабатывался с использованием нашего собственного шаблонизатора Fest , мы начали мигрировать на Svelte 3 в 2019 году.
Svelte реализует реактивность таким образом, чтобы не использовать Virtual DOM , что делает его менее ресурсоемким. Подход Svelte удаляет неиспользуемые функции из производственных пакетов, поскольку код, реализующий их, не генерируется компилятором, если функции не используются. Неиспользуемый код удаляется во время компиляции, в результате чего пакеты становятся меньше. Это может помочь сократить общее время блокировки (TBT) во время запуска страницы.
Отслеживание показателей производительности
Прежде чем оптимизировать Core Web Vitals, полезно оценить производительность на местах . До появления Core Web Vitals мы отслеживали другие показатели, такие как First Contentful Paint (FCP) , на нашей внутренней панели мониторинга производительности.
Наш сценарий сбора показателей был изменен для сбора основных веб-показателей и передачи их на нашу панель мониторинга производительности для визуализации. В соответствии с рекомендациями Google наш скрипт для получения метрик использует API PerformanceObserver , который является частью универсального фронтенда «Платформа» внутри Mail.ru.
На панели мониторинга для пользователей отображались следующие показатели (средние значения за неделю с 15 по 21 марта 2021 г.):
| Название группы показателей | Основные веб-показатели | Другие важные веб-показатели | |||||
|---|---|---|---|---|---|---|---|
| Название метрики | ЛКП | ПИД | ЦЛС | ФКП | ТБТ | ТТИ | |
| Доля пользователей в соответствии с пороговыми значениями Core Web Vitals | хороший | 52% | 92% | 33% | 35% | 42% | 43% |
| Требуется улучшение | 19% | 5% | 23% | 38% | 16% | 25% | |
| бедный | 29% | 3% | 44% | 27% | 42% | 32% | |
Улучшение основных веб-показателей
Несмотря на то, что существует множество рекомендаций по улучшению основных веб-показателей, каждый проект сталкивается с уникальными проблемами. Для главной страницы Mail.ru были выявлены следующие возможности:
- Реализация заполнителей для рекламных баннеров для уменьшения CLS .
- Использование рендеринга на стороне сервера (SSR) для уменьшения размера LCP .
- Разделение кода для уменьшения LCP и задержки первого ввода (FID) .
Скелеты для улучшения CLS
CLS оказался одним из худших показателей для главной страницы Mail.ru. Последующее профилирование этой страницы на панели «Производительность » инструментов разработчика Chrome показало, что источником проблемы была реклама. Чтобы повысить стабильность макета, наша команда решила использовать заполнители, чтобы зарезервировать место для рекламы перед ее загрузкой.
При внедрении заполнителей первым шагом является определение размеров контента, который их заменит. К счастью, в десктопной версии главной страницы Mail.ru строго задокументированы размеры рекламы. После разговора с командой дизайнеров в качестве заполнителей были использованы скелетоны пользовательского интерфейса, анимированные в формате SVG, поскольку они сокращают воспринимаемое время загрузки контента .
Возвращение ССР
Чтобы облегчить переход от Fest к Svelte, мы постепенно переписали существующий проект, а не начинали заново. К марту 2021 года мы перенесли большую часть клиентской части на Svelte и в конечном итоге перенесли SSR в наше производственное приложение после проверки и устранения проблем с производительностью серверной части.
После внедрения SSR команда обнаружила причину регрессии CLS, которая изначально осталась незамеченной: раздел новостей не был вставлен в момент отрисовки первого контента на странице. Между первоначальной отрисовкой разметки страницы, предоставленной сервером, и вставкой раздела новостей на клиенте произошла задержка. Такое поведение привело к изменению скелета рекламы, что ухудшило CLS.
Хотя DevTools Chrome отображал события Layout Shift, мы сначала не смогли найти причину этого. Хотя сама по себе реформа SSR не была проблемой, она помогла найти решение позже. Исправление кода, отвечающего за задержку отрисовки, улучшило стабильность макета новостного компонента.
Еще один эффект, который SSR может оказать на CLS, — это перемещение компонентов до и после гидратации, что может привести к дальнейшим изменениям компоновки. Мы столкнулись с этим, в частности, в мобильной версии, и это потребовало особого внимания к разметке гидратированных компонентов. Хорошим решением этой проблемы был перенос как можно большего количества логики отображения из JavaScript в CSS.
Разделение кода и неиспользуемые полифилы
Чтобы улучшить воспринимаемую скорость загрузки страницы, необходимо было уменьшить значения LCP и FID. Один из способов добиться этого — разделение кода . Помимо самой главной страницы Mail.ru, наша команда разрабатывает виджет для навигации по порталу. В настоящее время он встроен во многие проекты нашей компании .
По историческим причинам виджет вставляется в самое начало страницы как синхронно загружающийся скрипт. Доля полифилов в этом скрипте со временем росла. Чтобы ограничить негативное влияние загрузки этих полифилов на производительность, мы реализовали разделение кода как для современных, так и для устаревших браузеров.
Мы отказались от шаблона module / nomodule для загрузки пакетов JavaScript для современных или устаревших браузеров, поскольку атрибут type="module" элемента <script> не предназначался для браузеров, которые были достаточно современными для наших нужд. Для решения этой проблемы Mail.ru использует собственный инструмент для определения современных версий браузеров на серверной стороне и может соответствующим образом адаптироваться к этим браузерам.
Как только браузеры можно было идентифицировать в серверной части, мы реализовали разделение кода для современных и устаревших браузеров. В результате размер синхронно загружаемого виджета JavaScript для современных браузеров уменьшился на 43,3%. Эта практика была применена и к некоторым другим сценариям портала.
Помимо уменьшения размера пакета и положительного влияния на основные веб-показатели, разделение кода также улучшает работу разработчиков. Только 3,5% наших пользователей используют устаревшие браузеры, и эта доля имеет тенденцию к снижению, поэтому внедрение разделения кода позволило нашим разработчикам использовать новейшие API-интерфейсы браузера, не создавая для всех пользователей раздувания полифилов, необходимого для устаревших браузеров.
Полученные результаты
После усилий по оптимизации мы наблюдали средние значения за неделю с 24 по 30 мая 2021 года в наших полевых данных:
| Название группы показателей | Основные веб-показатели | Другие важные веб-показатели | |||||
|---|---|---|---|---|---|---|---|
| Название метрики | ЛКП | ПИД | ЦЛС | ФКП | ТБТ | ТТИ | |
| Доля пользователей в соответствии с пороговыми значениями Core Web Vitals | хороший | 58% (+6%) | 93% (+1%) | 93% (+60%) | 43% (+8%) | 49% (+7%) | 51% (+8%) |
| Требуется улучшение | 18% | 4% | 3% | 34% | 17% | 24% | |
| бедный | 24% | 3% | 4% | 23% | 34% | 25% | |
На графиках ниже показаны изменения значений показателей производительности веб-страницы в зависимости от «Платформы». Обратите внимание на две важные даты на графиках:
- 23 марта 2021 г.: выпуск итерации с переносом последних разделов страницы в Svelte;
- 19 апреля 2021 г.: выпуск итерации с возвращенным SSR и макетом, измененным для исправления регрессий CLS.
Снижение значений с 1 по 10 мая связано с майскими праздниками в России.
Результаты, полученные с помощью «Платформы», соответствуют росту значений метрик в Chrome UX Report (CrUX) .
Сравнение значений средней продолжительности пользовательских сессий за неделю до развертывания первоначальных улучшений и неделю после развертывания показывает рост на 2,7%. Более того, наблюдается общий значительный рост конверсии в большинстве разделов страницы. В частности, конверсия в почтовое приложение Mail.ru выросла на 11,6%, конверсия раздела новостей выросла на 13,5%.
181 %
Увеличение доли хороших порогов CLS
2,7 %
Более высокая средняя продолжительность сеанса
13,5 %
Увеличение конверсии новостного раздела
Самый неожиданный результат, который мы получили, — увеличение кликабельности (CTR) маркетингового баннера на 17,4% (время его рендеринга было значительно сокращено за счет внедрения тегов SSR и предварительной загрузки).
Проанализировав остальные разделы страницы, мы заметили значительное улучшение производительности в подавляющем большинстве из них. Даже по таким разделам, как «Погода» и «Коронавирус», которые не являются ключевыми на нашей странице, мы видим рост конверсии на 9,6% и 9,5% соответственно.
Заключение
Повышение производительности является сложной задачей, поскольку требуемая работа может затянуться. Вам следует регулярно отслеживать изменения показателей с течением времени и следить за тем, чтобы все новые функции продукта не вызывали регрессий в основных веб-показателях. Для достижения этой цели мы отслеживаем изменения основных веб-показателей в нашем бюджете производительности .
Самое главное, мы подчеркнули важность Core Web Vitals для всех членов нашей продуктовой команды, от менеджеров и дизайнеров до тестировщиков и специалистов по обеспечению качества. Каждый член команды должен знать показатели производительности и иметь возможность их улучшать. Мы также регулярно включаем цели оптимизации производительности в наши бизнес-процессы. Успешное обеспечение высокого качества пользовательского опыта возможно только благодаря совместным усилиям всех членов команды.