NaZapad 13

практическая онлайн конференция

10 часов

полезной информации

img

Оптимизация под PageSpeed/LightHouse как фактор ранжирования или почему проблемы индейцев шерифа не динь – динь

Видео конференции

Demi Murych

PageSpeed (система оценки производительности/чеклист) существовала задолго до появления LightHouse

В 2015-16 появились подозрения, что данные показатели может использовать гугл для ранжирования проектов.

В 2018 PageSpeed кардинально меняют на LightHouse, и его оценки были объективными. В тот момент в блоге Google Webmasters появляется информация, что тест оценки производительности будет одним из факторов ранжирования, то есть результаты 

  • LightHouse – официальный фактор ранжирования.
  • На самом деле этот фактор есть. Но до сих пор не смогли определить, насколько серьезно этот фактор ранжирования влияет, что значительно важнее, ведь оптимизация – это финансово-затратный процесс.
  • Google собирает статистику не с LightHouse, а с пользователей. Сам же LightHouse производит замеры также, как и API Google Chrome.
  • LightHouse не оценивает скорость загрузки сайтов. Он оценивает возможность рендера первой области отображения сайта. Эта характеристика объективная. И все способы оптимизации проектов связаны именно с этим параметром.
  • Time to first bite – время от запроса до получения информации – учитывается Google. Но влияние этого фактора на общие баллы производительности LightHouse ничтожно.

Нынешние видео и туториалы содержат информацию, которая была актуальна для PageSpeed до 2018.

Противоречия в официальных данных

  • В блоге Google Webmasters заявлены баллы, как официальный фактор ранжирования; в консоли есть данные об оценке производительности сайта, но данные не все. И результаты консоли и LightHouse иногда совершенно не совпадают. Причина в том, что консоль учитывает только две временные метки, а LightHouse – 6. И причину этому сложно определить.
  • Мюллер и Мартин в своем видео, где они отвечали на вопросы пользователей, связанные с ранжированием по производительности, сказали, что вебмастера могут заниматься тем, что нужно для их сайта, не обращая внимание на эти показатели. Хотя это противоречит официальному заявлению о том, что производительность по LightHouse  – фактор ранжирования.

Чем же заниматься, решая вопросы производительности?

Производительность – это совокупность факторов, которые предпринимаются для минимизации издержек, связанных с временем отображения и загрузки проекта.

Занимаясь этим фактором ранжирования, мы точно не занимаемся:

  • Временем ответа сервера
  • Оптимизацией протоколов
  • Сжатием
  • Lazyload и т.д.

Самое главное – скорость отображения информации в рамках первого экрана с начала страницы, причем, в случае ее отображения в мобильной версии.

Три важные характеристики:

  1. Характеристика отображения чего-либо – первая временная метка
  2. Отображения того, что можно назвать осмысленным – вторая временная метка
  3. Когда на первом экране достаточно контента, чтобы сделать вывод, что первый экран сформирован (полностью загружен) – третья.

LightHouse считывает эти временные метки из API браузера, которые он выставляет в момент рендера. Задача оптимизации – сделать так, чтобы все эти временные метки были как можно ближе к началу момента рендера.

Влияющие факторы:

  • Нагрузка на центральный процессор, которую создает Javascript

Что делать? Оптимизировать и дифференцировать нагрузку, которую создают скрипты.

У почти всех проектов на сайте присутствует счетчики гугл-метрики или даже Google Tag Manager (их рекомендуют как можно раньше запускать, но они также тормозят ваш сайт больше всего). Чтобы оптимизировать производительность, работу этих скриптов стоит отложить, что может привести к потере точности измерения посещаемости сайта на около 5%.

LazyLoad и отложенность загрузки изображений не добавляют баллы по LightHouse. Баллы повышаются, потому что вы косвенным образом решили какую-то из проблем, связанную с нагрузкой на центральный процессор.

Основные работы по оптимизации связаны с минимизацией нагрузки на ЦП:

  • Исключить скрипты со страницы и написать небольшой скрипт для API браузера Request Idle Callback – благодаря ему скрипт узнает, когда браузер свободен, чтобы что-то делать. В момент рендера скрипты ждут до получения сигнала.
  • В идеале нужно использовать Critical-path CSS (некоторые системы сборки уже имеют плагины для этого). Если ваша страница со всеми стилями весит не более 100 кб, то до этого веса можно на странице включать все, не думая.

Важные тезисы:

  • Практика сбора всех скриптов в единый файл (что было характерно в 2000-х в протоколе http1)

Сейчас таким образом не решается задача. Работая со скриптами, лучше реализовать структуру загрузку части скрипта, потом начинается загрузка части второго, при этом первый скрипт выполняется, и т.д. То есть нагрузка между скриптами и их выполнением распределена.

  • Инструменты: Открыть Developer Tools в Chrome – найти Coverage – позволяет смотреть, какое количество объема CSS и JS кода реально используется и выполняется на каждой странице.
  • Плагины: При использовании системы сборки Grunt, есть плагины, которые можно использовать.
  • Важно написать небольшие кусочки JS кода, чтобы обеспечить интерактивность проекта.
  • Если на сервере используется протокол http2, то о количестве запросов можно вообще не волноваться. Но если ваша аудитория – это пользователи мобильных устройств, то, возможно, от этого протокола придется отказаться.

Итог – факторы, на которые нужно обратить внимание:

  • Нагрузка скриптов на ЦП в момент загрузки первого окна экрана
  • Аналитика создает максимальную нагрузку
  • Рекламу можно вставлять тогда, когда вы хотите, чтобы избежать нагрузки (это не противоречит гайдам от Гугла)