От автора: в этой статье мы расскажем, как Google PageSpeed вычисляет критическую оценку скорости. Ни для кого не секрет, что скорость стала решающим фактором в увеличении доходов и снижении числа отказов. Теперь, когда Google использует скорость страницы как фактор ранжирования, многие организации стали ориентироваться на производительность.
В прошлом году Google внес два существенных изменения в свои алгоритмы поисковой индексации и ранжирования:
В марте индексация стала основываться на мобильной версии страницы, а не на настольной.
В июле алгоритм SEO ранжирования был обновлен, чтобы включить скорость страниц в качестве фактора ранжирования как для мобильных страниц, так и для рекламы.
Исходя из этого, мы можем сформулировать два утверждения:
Скорость сайта на мобильном телефоне повлияет на ваш общий SEO рейтинг.
Если ваши страницы загружаются медленно, это снизит показатель качества вашей рекламы, и объявления будут стоить дороже.
В Google заявляют: Более быстрые сайты не просто улучшают пользовательский опыт; последние данные показывают, что повышение скорости сайта также снижает операционные расходы. Как и мы, наши пользователи придают большое значение скорости — именно поэтому мы решили учитывать скорость сайта в наших поисковых рейтингах.
Чтобы понять, как эти изменения влияют на нас с точки зрения производительности, нам нужно понять основную технологию. PageSpeed 5.0 — это полный пересмотр предыдущих версий. Теперь он работает на Lighthouse и CrUX (Chrome User Experience Report).
Это обновление также содержит новый алгоритм оценки, который значительно усложняет получение высокой оценки PageSpeed.
Что изменилось в PageSpeed 5.0?
До версии 5.0 PageSpeed запускал серию эвристик для данной страницы. Если на странице были большие несжатые изображения, PageSpeed предлагал сжатие изображений. Отсутствуют заголовки кэша? Добавьте их.
Эта эвристика сочеталась с набором рекомендаций, которые, скорее всего, могли бы привести к повышению производительности, но были просто поверхностными и фактически не анализировали нагрузку и опыт, с которым сталкиваются реальные посетители.
В PageSpeed 5.0 страницы загружаются в настоящий браузер Chrome, которым управляет Lighthouse. Lighthouse записывает метрики из браузера, применяет к ним модель оценки и представляет общую оценку производительности. Рекомендации по улучшению предлагаются в зависимости от оценки конкретного показателя.
Как и PageSpeed, у Lighthouse также есть оценка производительности. В PageSpeed 5.0 оценка производительности берется непосредственно из Lighthouse. Показатель скорости PageSpeed теперь совпадает с показателем производительности Lighthouse.
Теперь, когда мы знаем, откуда берется оценка PageSpeed, давайте рассмотрим то, как она рассчитывается и как мы можем внести существенные улучшения.
Что такое Google Lighthouse?
Lighthouse — это проект с открытым исходным кодом, управляемый специальной командой Google Chrome. За последние несколько лет, он стал популярным инструментом анализа.
Lighthouse использует протокол удаленной отладки Chrome для чтения информации о сетевых запросах, измерения производительности JavaScript, соблюдения стандартов доступности и измерений ориентированных на пользователя метрик времени, таких как Время до первого отображения, Время до первого взаимодействия или Speed Index.
Как Lighthouse рассчитывает оценку производительности
Во время тестов производительности Lighthouse записывает множество показателей, ориентированных на то, что видит пользователь. Для создания общей оценки производительности используются 6 показателей. А именно:
Время до первого взаимодействия (TTI)
Speed Index
Время до отображения контента (FCP)
Время окончания работы ЦП
Время до первого значимого отображения (FMP)
Задержка на ввод пользователя
Lighthouse применит модель оценки 0 — 100 к каждой из этих метрик. Для этого получаются мобильные 75-ый и 95-ый процентили из HTTP-архива с последующим применением функции log normal.
Следуя алгоритму и справочным данным, используемым для расчета времени до взаимодействия, мы можем видеть, что если бы странице удалось стать «интерактивной» за 2,1 секунды, показатель метрики Времени до первого взаимодействия составил бы 92/100.
После оценки каждой метрики ей присваивается вес, который используется в качестве модификатора при расчете общей оценки производительности. Весовые коэффициенты следующие:
Эти весовые коэффициенты относятся к влиянию каждой метрики на мобильных пользователей. В будущем это также может быть улучшено за счет включения данных наблюдения пользователей из набора данных Chrome User Experience Report.
Вам может быть интересно, как вес каждой метрики влияет на общую оценку производительности. Команда Lighthouse создала полезный калькулятор в электронных таблицах Google, объясняющий этот процесс:
Используя приведенный выше пример, если мы изменим (время до) первого взаимодействия с 5 секунд на 17 секунд (средний глобальный показатель TTI для мобильных устройств), наш показатель упадет до 56% (или 56 из 100).
Принимая во внимание, что если мы изменим Время до первого отображения контента на 17 секунд, мы наберем 62%. Время до первого взаимодействия (TTI) — наиболее значимый показатель для оценки производительности. Поэтому, чтобы получить высокий балл PageSpeed, вам потребуется быстрое TTI.
Смещение акцента на TTI
В целом, есть два значительных фактора, которые сильно влияют на TTI:
Количество JavaScript доставляемого на странице
Время выполнения задач JavaScript в основном потоке
В нашем руководстве Time to Interactive подробно объясняется, как работает TTI, но если вы хотите достичь быстрых, не требующих исследований результатов, мы бы предложили:
Уменьшение количества JavaScript
Там, где это возможно, удалите неиспользуемый код JavaScript или сосредоточьтесь только на доставке скрипта, который будет запускаться текущей страницей. Это может означать удаление старых полифилов или замену сторонних библиотек более мелкими, более современными альтернативами.
Важно помнить, что время, затрачиваемое на JavaScript — это не только время, необходимое для его загрузки. Браузер должен распаковывать, проанализировать, скомпилировать и в конечном итоге выполнять его, что особенно существенно на мобильных устройствах.
Эффективные меры по уменьшению количества скриптов на страницах:
Просмотрите и удалите полифилы, которые больше не требуются для вашей аудитории.
Определите влияние каждой сторонней библиотеки JavaScript. Используйте webpack-bundle-analyzer или source-map-explorer для визуализации размера каждой библиотеки.
Современные инструменты JavaScript (такие как Webpack) могут разбивать большие приложения JavaScript на серию небольших пакетов, которые автоматически загружаются при навигации пользователя. Этот подход известен как разделение кода и чрезвычайно эффективен для улучшения TTI.
Service Worker кэшируют байт-код результат анализа + компиляции скрипта. Если вы сможете использовать это, время на анализ и компиляцию будет затрачиваться один раз, после чего эти затраты будут уменьшены за счет кэша.
Мониторинг времени до первого взаимодействия
Чтобы успешно выявить существенные различия в пользовательском опыте, мы предлагаем использовать систему мониторинга производительности (например, Caliber!), которая позволяет тестировать минимум два устройства; быстрый настольный компьютер и слабый-средний смартфон.
Таким образом, вы получите данные как для лучшего, так и для худшего случая опыта ваших клиентов. Стоит принять тот факт, что ваши клиенты не используют такое же мощное оборудование, как вы.
Углубленное ручное профилирование
Чтобы получить наилучшие результаты в профилировании производительности JavaScript, тестируйте страницы с помощью намеренно медленных мобильных устройств. Если у вас в ящике стола завалялся старый телефон, это прекрасная возможность снова использовать его.
Отличной заменой для использования реального устройства является режим аппаратной эмуляции Chrome DevTools. Мы написали обширное руководство по профилированию производительности, которое поможет вам начать.
А как насчет других показателей?
Speed Index, Время до первого отображения контента, Время до первого значимого отображения — это все метрики, зависящие от браузера. Они подвержены влиянию сходных факторов и часто могут быть улучшены одновременно.
Объективно легче улучшить эти показатели, так как они рассчитываются по тому, как быстро отображается страница. Тщательное следование рекомендациям аудита Lighthouse Performance приведет к улучшению этих показателей.
Если вы еще не загружаете шрифты или не оптимизируете их для критически важных запросов, это подходящая точка для начала процесса повышения производительности.
Отслеживание прогресса и внесение значительных улучшений
Недавно обновленная поисковая консоль Google, Lighthouse и PageSpeed Insights — это отличный способ получить начальное представление о производительности ваших страниц, но это не подходит для команд, которым необходимо постоянно отслеживать и улучшать производительность страниц.
Непрерывный мониторинг производительности важен для обеспечения повышения скорости в течение всего периода, и получения командами мгновенных уведомлений о регрессах. Ручное тестирование вносит неожиданные изменения в результаты и делает тестирование в разных регионах, а также на разных устройствах практически невозможным без специальной лабораторной среды.
Скорость стала решающим фактором для SEO ранжирования, особенно сейчас, когда почти 50% веб-трафика поступает с мобильных устройств.
Чтобы не потерять свои позиции, убедитесь, что вы используете современный набор для мониторинга производительности ключевых страниц. (Мы создали Caliber, чтобы он стал вашим помощником в оптимизации производительности. Он имеет встроенный Lighthouse. Сотни команд со всего мира используют его каждый день).
Автор: Ben Schwarz
Источник: https://calibreapp.com
Редакция: Команда webformyself.
