Пример изменений, которые компания GoDaddy внедрила для повышения производительности миллионов сайтов, помогая им достичь высоких показателей PageSpeed Insights и Core Web Vitals.
GoDaddy — крупнейшая платформа хостинговых услуг для всего мира. Они стремятся расширить возможности их сообщества, насчитывающего более 20 миллионов клиентов и предпринимателей во всем мире, предоставляя им всю помощь и инструменты, необходимые для роста в Интернете.
В 2019 году GoDaddy запустила программу «Веб-сайты + маркетинг», стремясь предоставлять инструменты и услуги, которые просты в использовании и помогают владельцам бизнеса достигать своих целей. Программа "Веб-сайты + маркетинг" объединяет создание сайтов с инструментами маркетинга и электронной коммерции и сочетает их с лучшими в своем классе рекомендациями, чтобы помочь клиентам добиться успеха в своих новых кампаниях.
С момента запуска программы «Веб-сайты + маркетинг» производительность стала важной частью продукта, за которой активно наблюдают и активно работают. В этой статье мы рассмотрим путь GoDaddy от лабораторного тестирования производительности к использованию реальных данных с помощью Core Web Vitals, а также серию улучшений, внесенных в продукт, чтобы получить очень высокий процент проходных баллов для сайтов их клиентов.
Вот, что пишет GoDaddy про отслеживание эффективности с помощью Lighthouse
Мы полагались на данные Lighthouse для отслеживания производительности. Каждый раз, когда веб-сайт публиковался на хостинге - мы измеряем его производительность с помощью нашего внутреннего инструмента Lighthouse4u, который предоставляет Google Lighthouse как услугу. Это дало нам хорошее представление о том, как сайты в целом работают в лабораторных условиях.
Поскольку миллионы сайтов, которые мы размещаем на нашей платформе, имеют широкий спектр функций и контента, было важно объединить данные о производительности с метаданными о каждом тестируемом сайте (например, используемый шаблон, тип отображаемых виджетов и т. д.). Это позволило нам сделать выводы о том, какие функции веб-сайта имеют более низкую производительность, а также дали представление о том, где искать улучшения.
Например, это помогло нам определить, что «всплывающее модальное окно» оказывает негативное влияние на скорость страницы; сайты с этой функцией показали результаты на 12 баллов ниже, чем без нее. После внесения изменений в код для отложенной загрузки JavaScript мы улучшили оценку Lighthouse на 2 балла. Мы смогли применить эти знания к другим функциям, таким как «баннер с файлами cookie», который отображается вскоре после загрузки страницы.
Диаграмма, показывающая оценку производительности для сайтов с всплывающим модальным окном и без него (синяя и зеленая линии соответственно) до и после улучшения производительности.
Наряду с поиском проблемных сайтов на основе функций, мы провели анализ нашего пакета JavaScript и увидели, что большая часть его размера приходится на внешние зависимости (immutable.js и draft.js). Мы уменьшили размер пакета, реструктурировав потребителей так, чтобы они лениво загружали зависимости по требованию. Это привело к снижению общего размера пакета JavaScript более чем на 50%, который увеличился с более чем 200 КБ до примерно 90 КБ (уменьшенный). Меньший размер пакета позволил браузеру загружать внешние ресурсы и выполнять критические сценарии на более ранних этапах начального жизненного цикла загрузки сайта, что привело к выигрышу в скорости загрузки основного контента (LCP) и временем ожидания до первого взаимодействия с контентом (FID).
Average Lighthouse score for newly published sites over time. Major optimizations are overlaid on the graph to show impact.
Благодаря нашим постоянным усилиям средний балл Lighthouse для клиентских сайтов вырос примерно с 40 баллов в ноябре 2020 года до более 70 баллов в мае 2021 года. Однако не все наши попытки сработали, и мы иногда удивлялись, когда результаты не всегда соответствовали тому, что были протестированы в местных условиях с результатами, которые мы получили в полевых условиях. Лабораторные результаты оказались действительно полезными, но пришло время сосредоточиться на реальном опыте пользователей, наблюдаемом в полевых условиях.
Отслеживание реальных пользовательских данных с помощью Core Web Vitals
После добавления библиотеки web-vitals на сайты наших клиентов мы смогли измерить данные о реальных устройствах от реальных посетителей, где оборудование, скорость сети, взаимодействие с пользователем (например, прокрутка или нажатие) не соответствуют базовым показателям, как в лабораторных опытах с настройками Lighthouse. Это был большой шаг в правильном направлении, так как теперь у нас были данные, отражающие то, что испытывают посетители нашего веб-сайта.
Сосредоточение внимания на нашем самом слабом звене: совокупном смещении макета (CLS)
Анализ новых данных позволил нам по-новому взглянуть на то, что нужно сделать, чтобы повысить скорость работы сайта. Благодаря работе, проделанной для улучшения оценки Lighthouse, наша LCP составила 860 мс, а FID при том же пороге был ниже 10 мс, поэтому мы получили высокий процент прохождения этих показателей на сайтах наших клиентов: 78% и 98%, соответственно. Однако цифры Cumulative Layout Shift (CLS) сильно отличаются от того, к чему мы привыкли в Lighthouse. Наш CLS на 75-м проценте был 0,17 — выше порога 0,1 для «сдачи» — и, таким образом, наш коэффициент сдачи составил всего 47% по всем нашим сайтам.
Этот показатель снизил наш общий показатель успешности до 40%, поэтому мы решили поставить перед собой амбициозную цель - поднять это число выше 60% к концу августа 2021 года. Для этого нам нужно было бы сосредоточиться на CLS.
В реальной жизни пользователи взаимодействуют со страницей и прокручивают контент «вверху», что Core Web Vitals улавливает лучше. Из-за различий в том, как пользователи взаимодействуют с сайтом во время его первоначальной загрузки, CLS отличался от лабораторных и полевых данных.
Путь к прохождению всех Core Web Vitals
Повышение производительности требует проб и ошибок, и каждая попытка не всегда работает так, как ожидалось. Тем не менее, вот несколько улучшений, которые помогли нам достичь наших целей.
Резервирование места для загрузки изображений значительно улучшило нашу оценку CLS, поскольку оно предотвращает смещение содержимого под изображениями. Мы использовали свойство CSS aspect-ratio, чтобы решить эту проблему в браузерах, которые его поддерживают. Для тех, кто этого не делает, мы загрузили прозрачное изображение-заполнитель, которое было кэшировано и имело размер всего несколько байтов, таким образом загружаясь почти мгновенно.
Это общее поведение изображения позволило нам предварительно рассчитать окончательную высоту изображения во время рендеринга на стороне сервера на основе ширины области просмотра и соотношения сторон изображения. Это привело к разметке HTML с вертикальным пространством, соответствующим образом зарезервированным для конечного изображения. Улучшение было особенно заметно на мобильных устройствах, так как изображения рендерятся на весь диапазон мобильных окон просмотра.
Некоторые компоненты на сайтах наших клиентов имеют динамический контент (например, список отзывов внешних клиентов) и не могут быть преобразованы в чистый CSS, чтобы использовать преимущества производительности рендеринга на стороне сервера. Это сложные области для улучшения смещения макета, потому что содержимое (а значит, и высота) будет меняться. В этих случаях мы заворачивали компонент в контейнер с применением минимальной высоты, заранее определенной на основе наблюдения за средней высотой для каждого из конкретных компонентов. Минимальная высота удаляется после завершения рендеринга внутреннего динамического компонента. Хотя это и не идеальное решение, оно позволило нам значительно уменьшить сдвиг макета.
Сосредоточив внимание на улучшениях CLS, мы продолжили работу над LCP. На многих веб-сайтах изображения являются самым большим виновником LCP, и для нас это было очевидной областью улучшения. Мы внесли улучшения в ленивую загрузку изображений с помощью IntersectionObserver, но поняли, что размеры изображений не были установлены оптимальным образом для каждой контрольной точки (мобильное устройство, планшет, настольный компьютер, большой рабочий стол), поэтому мы обновили наш код генерации изображений, чтобы зафиксировать и масштабировать изображения по точку останова, а затем снова масштабируйте разрешение в зависимости от плотности пикселей. Например, это уменьшило размер определенного большого изображения со 192 КБ до 102 КБ.
Чтобы быстро отображать веб-сайты на устройствах с плохим сетевым подключением, мы добавили код для динамического снижения качества изображения в зависимости от скорости подключения. Это можно сделать с помощью свойства нисходящей линии связи, возвращаемого navigator.connection. Мы применяем параметры запроса на основе URL-адреса для снижения качества изображения с помощью нашего API активов в зависимости от этих сетевых условий.
Ряд разделов сайтов наших клиентов загружаются динамически. Поскольку мы знаем, какие разделы будут отображаться на данном сайте после его публикации, мы использовали подсказку ресурса rel=preconnect, чтобы заранее инициализировать соединение.
При создании своих сайтов клиенты добавляют различные разделы, которые могут иметь встроенные сценарии для обеспечения различных функций. Встраивание этих скриптов в HTML-страницу не всегда оптимально для производительности. Мы решили внедрить эти скрипты, чтобы позволить браузеру асинхронно загружать и анализировать содержимое скриптов. Новые внешние сценарии также можно было использовать на разных страницах. Это позволило получить дополнительный прирост производительности за счет кэширования браузера и CDN. Мы сохранили важные скрипты в очереди, чтобы браузер мог быстрее анализировать и выполнять их.
Результаты
Сосредоточение наших усилий на CLS окупилось, наш показатель прохождения Core Web Vitals вырос с 40% до почти 70%: улучшение на 75%!
Процент действующих веб-сайтов + маркетинговые веб-сайты с «прохождением Core Web Vitals» с течением времени (общий и субпоказатель).
По мере того, как пользователи возвращаются на нашу платформу, чтобы обновить и повторно опубликовать свои сайты, они получают последние улучшения производительности, и в результате количество сайтов с «прохождением Core Web Vitals» неуклонно растет, как показано на диаграмме ниже:
Диаграмма, представляющая сайты GoDaddy Website Builder с «хорошими показателями основных веб-показателей».
Заключение
Поиск областей для улучшения производительности и успешное отслеживание прогресса во многом зависят от того, какие инструменты используются для измерения. Хотя Lighthouse был полезен для измерения производительности в верхней части страницы в «лабораторных условиях», он не точно отражал проблемы с производительностью, возникающие только при взаимодействии с пользователем (например, при прокрутке страницы).
Отслеживание Core Web Vitals в реальном мире с помощью метаданных позволило нам визуализировать, нацелить и измерить влияние наших улучшений. Путь к улучшению показателей Core Web Vitals позволил команде выявить и заменить неэффективные шаблоны, обнаруженные в нашей кодовой базе. Иногда многообещающие изменения не оказывали ожидаемого влияния, в других случаях происходило обратное.