Оптимизация основных веб-показателей на веб-сайте The Economic Times значительно улучшила пользовательский опыт и существенно снизила показатель отказов на всем веб-сайте.
С ростом скорости интернета с каждым днем пользователи ожидают, что веб-сайты будут реагировать и вести себя быстрее, чем когда-либо. Economic Times обслуживает более 45 миллионов активных пользователей в месяц. Оптимизировав Core Web Vitals по всему домену, на страницах AMP и не-AMP, нам удалось значительно снизить показатели отказов и улучшить процесс чтения.
Измерение воздействия
Мы сосредоточились на Largest Contentful Paint (LCP) и Cumulative Layout Shift (CLS) , поскольку они имеют наибольшее значение, когда дело доходит до предоставления нашим пользователям отличного опыта чтения. После внедрения различных исправлений производительности, описанных ниже, The Economic Times удалось значительно улучшить показатели отчета Chrome User Experience (CrUX) в течение нескольких месяцев.
В целом CLS улучшился на 250% с 0,25 до 0,09. В целом LCP улучшился на 80% с 4,5 секунд до 2,5 секунд.
Кроме того, значения LCP в диапазоне «Плохо» снизились на 33% с октября 2020 года по июль 2021 года:
Кроме того, значения CLS в диапазоне «Плохо» снизились на 65%, а значения CLS в диапазоне «Хорошо» увеличились на 20% за тот же период времени:
В результате The Economic Times, которая ранее не достигала пороговых значений Core Web Vitals, теперь превысила пороговые значения Core Web Vitals по всему своему источнику и снизила показатели отказов на 43% в целом .
Что такое LCP и как мы его улучшили?
Самый большой элемент является наиболее важным для улучшения пользовательского опыта и распознавания скорости загрузки. Метрики производительности, такие как First Contentful Paint (FCP), фиксируют только самый начальный опыт загрузки страницы. С другой стороны, LCP сообщает время рендеринга самого большого изображения, текста или видеораздела, видимого пользователю.
Помимо переключения на более быстрого провайдера DNS и оптимизации изображений, вот некоторые из методов, которые мы применили для улучшения LCP.
Сначала критические запросы
Поскольку все современные браузеры ограничивают количество одновременных запросов, разработчикам необходимо в первую очередь загружать критически важный контент. Чтобы загрузить сложную веб-страницу, нам нужно загрузить такие ресурсы, как элементы заголовка, CSS, ресурсы JavaScript, главное изображение, текст статьи, комментарии, другие связанные новости, нижний колонтитул и рекламу. Мы оценили, какие элементы требуются для LCP, и предоставили предпочтение для загрузки этих элементов в первую очередь, чтобы улучшить LCP. Мы также отложили вызовы, которые не были частью первоначального рендеринга страницы.
Внешний вид текста
Мы экспериментировали со свойством font-display , поскольку оно влияет как на LCP, так и на CLS. Мы попробовали font-display: auto; а затем переключились на font-display: swap; . Это изначально отображает текст в наиболее подходящем и доступном шрифте, а затем переключается на шрифт, когда он загружен. Это привело к быстрой визуализации текста, независимо от скорости сети.
Лучшее сжатие
Brotli — это альтернативный алгоритм сжатия Gzip и Deflate, разработанный Google. Мы заменили наши шрифты и активы и изменили сжатие сервера с Gzip на Brotli, чтобы добиться меньшего размера:
- Файлы Javascript на 15% меньше, чем при использовании Gzip.
- Файлы HTML на 18% меньше, чем при использовании Gzip.
- Файлы CSS и шрифтов на 17% меньше, чем при использовании Gzip.
Предварительное подключение к сторонним доменам
preconnect следует использовать с осторожностью, поскольку она может отнимать ценное процессорное время и задерживать другие важные ресурсы, особенно в защищенных соединениях.
Однако если известно, что произойдет выборка ресурса на стороннем домене, preconnect хорош. Если это происходит только изредка на сайте с высоким трафиком, preconnect может запустить ненужную работу TCP и TLS. Таким образом, dns-prefetch лучше подходит для сторонних ресурсов, например, социальных сетей, аналитики и т. д., чтобы выполнять DNS-поиск заранее.
Разбейте код на части
В заголовке сайта мы загрузили только те ресурсы, которые либо содержат существенную часть бизнес-логики, либо были критически важны для рендеринга страницы выше сгиба. Кроме того, мы разделили наш код на куски с помощью code splitting . Это помогло нам еще больше улучшить LCP страницы.
Лучшее кэширование
Для всех маршрутов front-end мы добавили слой Redis , который обслуживал шаблоны из кэша. Это сокращает время вычислений на сервере и создает весь UI в каждом запросе, тем самым уменьшая LCP в последующих запросах.
Подведение итогов LCP Цели и достижения
Перед началом проекта по оптимизации команда оценила свой показатель LCP на уровне 4,5 секунд (для 75-го процентиля своих пользователей, на основе полевых данных отчета CrUX). После проекта по оптимизации он сократился до 2,5 секунд .
Что такое CLS и как мы его улучшили?
Вы когда-нибудь замечали неожиданное перемещение содержимого страницы при просмотре веб-сайта? Одной из причин этого является асинхронная загрузка медиа (изображений, видео, рекламы и т. д.) на странице с неизвестными размерами. Как только загружаются медиаресурсы, они смещают макет страницы.
Мы собираемся рассказать о мерах, которые мы предприняли для улучшения CLS, на сайте The Economic Times.
Используйте заполнители
Мы использовали стилизованный плейсхолдер для рекламных блоков и медиа-элементов известных размеров, чтобы избежать сдвигов макета при загрузке и отображении рекламной страницы библиотекой. Это гарантирует устранение сдвигов макета путем резервирования места для рекламы.
Определенные размеры контейнера
Мы указали явные размеры для всех изображений и контейнеров, чтобы движку браузера не нужно было вычислять ширину и высоту элементов DOM, как только они станут доступны. Это позволило избежать ненужных сдвигов макета и дополнительной работы по рисованию.
Подведение итогов целей и достижений CLS
Перед началом проекта по оптимизации команда оценила свой показатель CLS на уровне 0,25 . Нам удалось значительно снизить его на 90% до 0,09 .
Что такое задержка первого входа (FID) и как мы ее улучшили?
First Input Delay — это метрика, которая отслеживает реакцию веб-сайта на пользовательский ввод. Основной причиной низкого показателя FID является интенсивная работа JavaScript, которая занимает основной поток браузера, что может задерживать взаимодействие с пользователем. Мы улучшили FID несколькими способами.
Разбивайте длинные задачи JavaScript
Длинные задачи — это задачи, которые длятся 50 миллисекунд или дольше. Длинные задачи занимают основной поток браузера и не дают ему реагировать на пользовательский ввод. Мы разбили длительные задачи на более мелкие, где это было возможно, по запросу пользователя, что помогло сократить раздувание Javascript.
Отложить неиспользуемый JavaScript
Мы отдали приоритет контенту страницы над сторонними скриптами, такими как аналитика, чтобы сделать страницу более отзывчивой. Однако существуют определенные ограничения для некоторых библиотек, поскольку их необходимо загружать в документ <head> , чтобы точно отслеживать путь пользователя.
Уменьшить количество полифиллов
Мы снизили нашу зависимость от определенных полифиллов и библиотек, поскольку браузеры поддерживают современные API, и все меньше пользователей используют устаревшие браузеры, такие как Internet Explorer.
Ленивая загрузка объявлений
Ленивая загрузка объявлений в нижней части страницы помогла сократить время блокировки основного потока и тем самым улучшить FID.
Подведение итогов целей и достижений FID
Благодаря рутинным экспериментам нам удалось сократить время FID с 200 мс до менее 50 мс на сегодняшний день.
Предотвращение регрессий
Economics Times планирует ввести автоматизированные проверки производительности в производстве, чтобы избежать регрессий производительности страниц. Они планируют оценить Lighthouse-CI для автоматизации лабораторных тестов, которые могут предотвратить регрессии в их производственной ветке.