Пример изменений, которые GoDaddy внедрила для повышения производительности миллионов сайтов и помогла им достичь хороших показателей PageSpeed Insights и Core Web Vitals.
GoDaddy — крупнейшая в мире платформа услуг для предпринимателей по всему миру. Наша миссия — расширить возможности нашего мирового сообщества, насчитывающего более 20 миллионов клиентов (и предпринимателей во всем мире), предоставляя им всю помощь и инструменты, необходимые для роста в Интернете.
В 2019 году компания GoDaddy запустила веб-сайты + маркетинг с целью предоставить инструменты и услуги, которые просты в использовании и помогут владельцам бизнеса достичь своих целей. Веб-сайты + маркетинг объединяет создание веб-сайтов с инструментами маркетинга и электронной коммерции и сочетает их с лучшими в своем классе рекомендациями, чтобы помочь клиентам добиться успеха в своих новых предприятиях.
С момента запуска «Веб-сайты + маркетинг» производительность стала важной частью продукта, над которой активно отслеживали и работали. В этой статье мы рассмотрим путь GoDaddy от лабораторного тестирования производительности до использования реальных данных с помощью Core Web Vitals, а также ряд улучшений, внесенных в продукт, чтобы обеспечить очень высокий процент проходимости сайтов наших клиентов.
Отслеживание эффективности с помощью Lighthouse
Для отслеживания производительности мы использовали данные Lighthouse. Каждый раз, когда веб-сайт публикуется на платформе, мы измеряем его производительность с помощью нашего внутреннего инструмента Lighthouse4u, который предоставляет Google Lighthouse в качестве услуги https://github.com/godaddy/lighthouse4u . Это дало нам хорошее представление о том, как сайты в целом работали в лабораторных условиях .
Поскольку миллионы сайтов, которые мы размещаем на нашей платформе, имеют широкий спектр функций и контента, было важно объединить данные о производительности с метаданными о каждом тестируемом сайте (например, используемый шаблон, тип отображаемых виджетов и т. д.). Это позволило нам сделать выводы о том, какие функции веб-сайта имели более низкую производительность, а также дало представление о том, где искать улучшения.
Например, это помогло нам определить, что «всплывающее окно» оказывает негативное влияние на скорость страницы; сайты с этой функцией оказались на 12 пунктов ниже, чем без нее. После внесения обновлений в код, позволяющих отложить загрузку JavaScript, мы улучшили оценку Lighthouse на 2 балла. Мы смогли применить эти знания к другим функциям, таким как «баннер cookie», который отображается вскоре после загрузки страницы.
Наряду с изучением проблемных сайтов на основе функций мы провели анализ нашего пакета JavaScript и увидели, что большая часть его размера обусловлена внешними зависимостями (immutable.js и Draft.js). Мы уменьшили размер пакета, перестроив потребителей на ленивую загрузку зависимостей по требованию. Это привело к снижению общего размера пакета JavaScript более чем на 50%: с более чем 200 КБ до примерно 90 КБ (минимизированный). Меньший размер пакета позволил браузеру загружать внешние ресурсы и выполнять важные сценарии на более раннем этапе первоначального жизненного цикла загрузки сайта, что привело к увеличению показателей наибольшей отрисовки контента (LCP) и задержки первого ввода (FID) .
Благодаря нашим постоянным усилиям средний балл Lighthouse на клиентском сайте увеличился с примерно 40 баллов в ноябре 2020 года до более 70 баллов в мае 2021 года. Однако не все наши попытки сработали, и мы иногда удивлялись, когда результаты не всегда согласовывались с тем, что было протестировано в местных тестовых средах и результаты, которые мы получили в полевых условиях. Результаты лабораторных исследований оказались очень полезными, но пришло время сосредоточиться на реальном опыте пользователей, наблюдаемом в полевых условиях.
Отслеживание реальных пользовательских данных с помощью Core Web Vitals
После добавления библиотеки web-vitals на сайты наших клиентов мы смогли измерить данные о реальных устройствах реальных посетителей, где оборудование, скорость сети, взаимодействие с пользователем (например, прокрутка или нажатие) не находятся на постоянном базовом уровне, как в лаборатории. настройка с помощью Lighthouse. Это был большой шаг в правильном направлении, поскольку теперь у нас были данные, отражающие то, что испытывали посетители нашего сайта.
Сосредоточимся на нашем самом слабом звене: совокупном сдвиге макета (CLS).
Анализ новых данных дал нам новый взгляд на то, что нужно сделать, чтобы улучшить скорость сайта. Благодаря работе по улучшению оценки Lighthouse наш 75-й процентиль LCP составил 860 мс, а FID при том же пороге был ниже 10 мс, поэтому мы добились высокого процента прохождения этих показателей на сайтах наших клиентов: 78% и 98%. соответственно. Однако цифры совокупного смещения макета (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 для использования преимуществ производительности рендеринга на стороне сервера. Это трудные области для улучшения изменений макета, потому что контент (и, следовательно, высота) будет различаться. В таких случаях мы помещали компонент в контейнер с применением min-height , заранее определенной на основе наблюдения средней высоты для каждого из конкретных компонентов. min-height удаляется после завершения рендеринга внутреннего динамического компонента. Хотя это решение и не было идеальным, оно позволило нам значительно сократить сдвиг макета.
Сосредоточившись на улучшениях CLS, мы продолжили работу над LCP. На многих веб-сайтах изображения являются основным источником LCP, и для нас это была очевидная область для улучшения. Мы внесли улучшения в отложенную загрузку изображений с помощью IntersectionObserver , но поняли, что размеры изображений не установлены наиболее оптимальным образом для каждой точки останова (мобильный телефон, планшет, настольный компьютер, большой настольный компьютер), поэтому мы обновили наш код генерации изображений, чтобы фиксировать и масштабировать изображения для каждой точки останова. точку останова, а затем снова масштабируйте разрешение в зависимости от плотности пикселей. Например, это уменьшило размер конкретного большого изображения со 192 КБ до 102 КБ.
Чтобы быстро отображать веб-сайты на устройствах с плохим сетевым подключением, мы добавили код для динамического снижения качества изображения в зависимости от скорости соединения. Это можно сделать с помощью свойства downlink , возвращаемого navigator.connection . Мы применяем параметры запроса на основе URL-адреса, чтобы снизить качество изображения через наш API активов в зависимости от условий сети.
Ряд разделов сайтов наших клиентов загружаются динамически. Поскольку мы знаем, какие разделы будут отображаться на данном сайте при его публикации, мы использовали подсказку ресурса rel=preconnect для предварительной инициализации соединения и необходимых рукопожатий. Мы также используем подсказки ресурсов для быстрой загрузки шрифтов и других важных ресурсов.
При создании своих сайтов клиенты добавляют различные разделы, которые могут содержать встроенные скрипты, обеспечивающие различные функции. Наличие этих сценариев внутри HTML-страницы не всегда оптимально с точки зрения производительности. Мы решили экспортировать эти сценарии, чтобы позволить браузеру асинхронно загружать и анализировать содержимое сценариев. Новые внешние сценарии также можно было бы использовать на разных страницах. Это позволило получить дополнительный прирост производительности за счет кэширования браузера и CDN. Мы сохранили важные сценарии в режиме реального времени, чтобы браузер мог быстрее анализировать и выполнять их.
Полученные результаты
Сосредоточение наших усилий на CLS принесло свои плоды: показатель успешности прохождения Core Web Vitals увеличился с примерно 40 % до почти 70 %: улучшение на 75 %!
Когда пользователи возвращаются на нашу платформу, чтобы обновлять и повторно публиковать свои сайты, они получают последние улучшения производительности, и в результате количество сайтов, «проходящих основные веб-показатели», неуклонно растет, как показано на диаграмме ниже:
Выводы
Поиск областей для улучшения производительности и успешное отслеживание прогресса во многом зависят от того, какие инструменты используются для измерения. Хотя Lighthouse был полезен для измерения максимальной производительности в «лабораторных условиях», он не точно фиксировал проблемы с производительностью, возникающие только в результате взаимодействия с пользователем (например, при прокрутке страницы).
Отслеживание реальных основных веб-показателей с помощью метаданных позволило нам визуализировать, нацелить и измерить влияние наших улучшений. Попытка улучшить показатели Core Web Vitals позволила команде выявить и заменить неэффективные шаблоны, обнаруженные в нашей кодовой базе. Иногда многообещающие изменения не оказывали даже близкого эффекта, которого мы ожидали, а иногда происходило наоборот. Это не первозданный мир, поэтому вам придется продолжать попытки.