Особенности Google PageSpeed: улучшение оценки сайта и его рейтинга в поиске

Original author: Ben Schwarz
  • Translation
Материал, перевод которого мы сегодня публикуем, посвящён рейтингу скорости сайтов, который можно вычислить с помощью Google PageSpeed Insights.

Ни для кого не секрет то, что скорость сайта в наше время стала одной из его важнейших характеристик. Чем быстрее сайт загружается и готовится к работе — тем выше может быть доход, который он приносит своему владельцу. Ускорение сайта означает снижение числа пользователей, которые, едва зайдя на этот сайт, покидают его, устав ждать загрузки его материалов. Особую значимость быстродействию сайта придаёт тот факт, что теперь показатели Google PageSpeed используются как один из факторов ранжирования сайтов в результатах поиска. В результате сегодня многие организации уделяют скорости своих сайтов самое пристальное внимание.



Изменения в алгоритмах ранжирования сайтов


В прошлом году компания Google внесла два серьёзных изменения в алгоритмы поискового индексирования и ранжирования сайтов.

  • В марте индексирование стало основанным на мобильной версии страницы, а не на настольной.
  • В июле алгоритм SEO-ранжирования был обновлён. При его расчёте для мобильных и рекламных страниц начали использовать рейтинг скорости страниц.

Эти факты позволяют нам сделать следующие выводы:

  • Скорость мобильной версии сайта повлияет на его общий SEO-рейтинг.
  • Если страницы сайта загружаются медленно — это снизит оценку качества рекламы (ad quality score) и рекламные объявления будут стоить дороже.

Вот что об этом говорит Google: «Более быстрые сайты не только улучшают ощущения пользователей; последние данные показывают, что повышение скорости работы сайта, кроме того, ведёт к снижению стоимости его поддержки. Мы очень ценим скорость. То же самое можно сказать и о наших пользователях. Именно поэтому мы решили, что при расчёте показателей поискового ранжирования будем учитывать и скорость сайта».

Для того чтобы понять то, как эти изменения воздействуют на наши проекты в плане оптимизации их производительности, нам нужно разобраться с технологиями, лежащими в основе оценки скорости сайтов. PageSpeed 5.0 представляет собой полностью пересмотренную версию этой системы. Теперь в её основе лежат Lighthouse и CrUX (Chrome User Experience Report).

Это обновление, кроме того, принесло и новый алгоритм оценки, который значительно усложняет задачу получения высокого балла в PageSpeed.

Что изменилось в PageSpeed 5.0?


До версии 5.0 инструмент PageSpeed проверял страницу, анализируя её соответствие набору эвристических правил. Если на странице присутствовали большие несжатые изображения — PageSpeed мог посоветовать веб-разработчику сжать эти изображения. Нет заголовков Cache? Система могла посоветовать их добавить.

К этим проверкам страницы были привязаны рекомендации. Следование рекомендациям могло привести к улучшению производительности страницы. Но эвристические правила были довольно-таки поверхностными, они не были нацелены на исследование того, какие впечатления вызовут у реального посетителя сайта загрузка и рендеринг страницы.

В PageSpeed 5.0 страницы загружаются в настоящий браузер Chrome, которым управляет Lighthouse. Lighthouse записывает показатели, полученные из браузера, применяет к ним модель балльных оценок и выводит общую оценку производительности. Рекомендации по улучшению производительности приводятся на основании баллов, набранных исследуемой страницей по отдельным показателям.

В Lighthouse, как и в PageSpeed, есть система оценки производительности сайтов. В PageSpeed 5.0 оценка производительности берётся непосредственно из Lighthouse. Оценка производительности, выводимая PageSpeed, теперь является той же самой оценкой, что выдаёт Lighthouse.


Оценка производительности, выводимая PageSpeed, основана на оценке, формируемой Lighthouse

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

Что такое Google Lighthouse?


Lighthouse — это опенсорсный проект, которым занимается специальная команда, выделенная из числа разработчиков Google Chrome. За последние пару лет Lighthouse стал стандартным бесплатным инструментом для анализа производительности сайтов.

Lighthouse использует средства Chrome по удалённой отладке (Chrome Remote Debugging Protocol) для чтения сведений о сетевых запросах, для измерения производительности JavaScript-кода, для проверки соблюдения стандартов доступности содержимого страницы. Этот инструмент измеряет временные показатели, ориентированные на особенности восприятия страницы пользователями. Среди них, например, First Contentful Paint (Время загрузки первого контента), Time to Interactive (Время загрузки для взаимодействия) и Speed Index (Индекс скорости загрузки).

Если вы интересуетесь Lighthouse — взгляните на этот материал из официального репозитория проекта, посвящённый общему описанию его архитектуры.

Вычисление оценки производительности сайта в Lighthouse


В ходе исследования производительности страницы Lighthouse записывает множество метрик, ориентированных на оценку того, что видит, и что испытывает пользователь, работая со страницей. Вот шесть показателей, используемых для вывода общей оценки производительности:

  • Time to Interactive (TTI, Время загрузки для взаимодействия).
  • Speed Index (Индекс скорости загрузки).
  • First Contentful Paint (FCP, Время загрузки первого контента).
  • First CPU Idle (Время окончания работы ЦП).
  • First Meaningful Paint (FMP, Время загрузки достаточной части контента).
  • Estimated Input Latency (Приблизительное время задержки при вводе).

Каждый из этих показателей оценивается по шкале 0 — 100. Оценка выполняется путём получения 75-го и 95-го перцентилей для мобильных страниц из HTTP Archive и путём применения функции log normal.

Следуя этому алгоритму и рассматривая данные, используемые для вычисления показателя TTI, можно заметить, что если страница смогла стать «интерактивной», пригодной для взаимодействия с пользователем, за 2.1 секунды, то показатель TTI окажется равным 92/100.


TTI

После того, как будет вычислен каждый из показателей, ему назначается определённый вес, который используется как модификатор при расчёте общего показателя. Вот веса, назначаемые различным метрикам.
Метрика
Вес
Time to Interactive (TTI)
5
Speed Index
4
First Contentful Paint
3
First CPU Idle
2
First Meaningful Paint
1
Estimated Input Latency
0

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

В будущем этот набор может быть расширен путём включения в него показателей, взятых из набора данных Chrome User Experience Report, связанных с восприятием сайтов пользователями.

Возможно, вам интересно будет узнать о том, как использование весов влияет на итоговую оценку производительности. Если это так — взгляните на эту таблицу, созданную командой Lighthouse. Проанализировав её, можно лучше понять этот процесс.


Фрагмент таблицы, демонстрирующей расчёт оценки производительности страниц

Если в примере, приведённом выше, изменить показатель interactive (это — то, что мы называем здесь TTI) с 5 секунд до 17 секунд (то есть — до уровня глобального среднего показателя TTI для мобильных страниц), то оценка страницы упадёт до 56% (то есть — она получит 56 баллов из 100 возможных).

Если же установить в значение 17 секунд показатель first-contentful-paint, то оценка упадёт до 62%.

В результате можно сделать вывод о том, что наибольшее влияние на итоговую оценку сайта оказывает метрика TTI. Из этого следует то, что для получения высокой оценки PageSpeed странице необходимо демонстрировать достойный показатель TTI.

Улучшение TTI


Если в общих чертах рассматривать проблему улучшения TTI, то можно сказать, что существуют два фактора, которые чрезвычайно сильно влияют на этот показатель:

  • Объём JavaScript-кода, загружаемый на страницу.
  • Время, которое занимает выполнение различных JavaScript-задач в главном потоке.

Здесь можно найти подробности о TTI, но если вы хотели бы быстро, без необходимости проведения дополнительных исследований, улучшить TTI своего сайта, мы могли бы порекомендовать уменьшить объём JavaScript-кода.

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

Важно помнить о том, что то, что называют «ценой JavaScript», это не только время, необходимое на загрузку кода. Браузеру нужно распаковать, распарсить, скомпилировать и, в итоге, выполнить загруженный JavaScript-код. Выполнение всех этих операций может занять заметное время. Особенно — на мобильных устройствах.

Среди эффективных мер по уменьшению объёма JS-кода, используемого страницами, можно отметить следующие:

  • Анализ используемых полифиллов и отказ от тех из них, которые больше не нужны вашей аудитории.
  • Выяснение «стоимости» каждой из используемых сторонних библиотек. Для того чтобы узнать о размерах библиотек, применяемых в проекте, можно применить такие инструменты, как webpack-bundle-analyser и source-map-explorer.
  • Современные инструменты для работы с JavaScript (вроде webpack) могут разбивать крупные JS-приложения на наборы небольших бандлов, которые автоматически подгружаются по мере того, как в них возникает необходимость. В частности — при переходе пользователя со страницы на страницу сайта. Этот подход к оптимизации производительности сайтов известен как разделение кода (code splitting). Его применение очень хорошо влияет на TTI.
  • Используйте сервис-воркеры, которые кэшируют байт-код, полученный в результате парсинга и компиляции скриптов. Если вы можете включить в свой проект подобные механизмы кэширования, то системные ресурсы посетителей сайта будут тратиться на разбор и компиляцию кода лишь при первом заходе на ресурс. При повторных визитах на сайт необходимые материалы будут браться из кэша.

Мониторинг TTI


Для того чтобы успешно исследовать то, как ваш сайт воспринимают пользователи, просматривающие его, мы рекомендуем использовать системы мониторинга производительности сайтов наподобие Calibre. В частности, речь идёт о том, что сайты испытывают минимум на двух устройствах — на быстром настольном компьютере и на мобильном телефоне, производительность которого находится на уровне медленных устройств среднего класса.

При таком подходе у вас будут данные и для наилучшего варианта работы с вашим сайтом, и для наихудшего. Вам при этом придётся свыкнуться с тем, что посетители вашего сайта не пользуются такими же мощными устройствами, какими пользуется ваша команда.

Тщательное ручное профилирование


Для того чтобы извлечь максимум пользы из профилирования производительности JS-кода тестовые страницы испытывают на специально замедленных мобильных устройствах. Если у вас в ящике стола валяется старый телефон — реализация этой идеи может дать ему замечательную вторую жизнь.

Хорошим заменителем реальных устройств являются возможности инструментов разработчика Chrome. Вот материал, посвящённый профилированию React-приложений с использованием этих инструментов.

Другие метрики


Такие метрики, как Speed Index, First Contentful Paint и First Meaningful Paint, основаны на том, как браузер визуализирует страницу. На них влияют факторы, похожие на те, о которых мы уже говорили. Воздействие на эти факторы часто ведёт к улучшению всех этих показателей.

Объективно говоря, улучшать эти метрики проще, чем TTI. Дело в том, что базой для их вычисления служит скорость рендеринга страниц браузером. Эти метрики можно улучшить, точно следуя рекомендациям, выдаваемым после анализа страниц с помощью Lighthouse.

Если вы ещё не выполняете предварительную загрузку шрифтов или не оптимизируете страницу с учётом особенностей критически важных запросов — то вы вполне можете начать улучшение показателей рендеринга своего сайта именно с этих двух направлений. В этом материале можно найти подробные сведения о том, как браузер загружает и выводит критически важные ресурсы, используемые при формировании веб-страниц.

Итоги: о наблюдении за сайтами и о внесении в их работу ощутимых улучшений


Обновлённая поисковая консоль Google, Lighthouse и PageSpeed Insights — это отличные средства, которые позволяют мгновенно оценить общие показатели производительности сайта. Однако они не очень хорошо подходят для команд, которым необходимо непрерывно отслеживать и улучшать производительность их проектов.

Непрерывный мониторинг производительности — это важнейшая деталь рабочего процесса, нацеленного на постоянное поддержание производительности сайта на высоком уровне. При таком подходе команда разработчиков проекта мгновенно узнаёт о проблемах с производительностью. При ручном тестировании производительности возможен неожиданный разброс результатов. В результате без создания специализированного тестового окружения оказывается почти невозможным проведение испытаний производительности сайта с использованием разных устройств, или с имитацией других изменяющихся параметров систем потенциальных пользователей.

Скорость страниц стала важнейшим фактором в SEO-ранжировании страниц. Особенно сильно это заявление звучит в наши дни, когда почти 50% веб-трафика создают мобильные устройства.

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

Уважаемые читатели! Оптимизируете ли вы свои веб-проекты с учётом улучшения показателей, влияющих на оценки, выставляемые Google PageSpeed?

RUVDS.com
895.22
RUVDS – хостинг VDS/VPS серверов
Share post

Comments 20

    0
    Из моих наблюдений, скорость — далеко не первый параметр.
      0
      Согласен, скорость-не самое важное, но без этого никак.
      есть хорошие статьи на эту тему.
        –3
        page speed, pigdom и.тп — это все маразм, которым постоянно пользуются разного рода «умники» и недалекие люди. Сейчас эти инструменты так крутят гайки, что хоть даже весь сайт будет оптимизирован все равно что-то будет не так, но КЛИЕНТУ это объяснишь т.к для него результат сервиса это истина в последней инстанции. В общем это я в чему, надоело мне этот бред постоянно слушать про скорости и т.п, теперь просто провожу оптимизацию как всегда, НО вывод страниц выгоняю под условие для…
        $_SERVER['HTTP_USER_AGENT']
        или
        navigator.userAgent.indexOf("Speed Insights")
        , для людей показывается сайт, а для инструментов показывается пустая страница — получаю по всем сайтам — 100 и клиенты рады и я нервы берегу.
          +1
          а google console bot вы так же обманываете? а mobile usability?
          Вы так клиента подставляете на самом деле. ботам нужно парсить сайт клиента для SEO. вам про важность SEO кто нибудь рассказывал?
            –2
            Нет, только на время теста и приемок клиента, потом отключаю естественно постепенно на всех страницах.
              +2
              ого, значит вы обманываете только клиентов! вот из за таких как вы, у нас программистов портится репутация.
                –2
                Если бы не было бы терпил и пресмыкающихся особей в среде программистов, которые бы явно ставили заказчиков на место/слали на 3 буквы и указывали на то, что page speed и т.п это «херня с под коня» и достаточно провести базовую оптимизацию БЕЗ фанатизма и маразма, который предлагают выше упомянутые инструменты, то и обманывать не приходилось бы. Все бы заказчики знали, что смысла особого в этих инструментах нет, и ориентироваться на их показатели не стоит.
                  +2
                  Вы прикалываетесь? это всё не херня, а единственный способ конкурировать в поисковых запросах google для новых сайтов. Я занимаюсь оптимизацией сайтов лет 8, и уже года 4 я делаю сайты сразу оптимизированными. Если вы клепаете бложики на вордпрессе используя кучу плагинов с jQuery, то я вас разочарую — вы не программист — вы контент менеджер.
                    –1
                    8 лет, а мозгов ноль, бедные твои клиенты. Если ты считашь себя сеошником (или кто ты там), то поздравляю — ты НУЛЕВОЙ специалист, который даже не знает, кто такие контент менеджеры и программисты. Я в вебе с 2003 года — т.е когда ты еще на горшок ходил, поэтому молчи лучше про опыт. Если КРУПНЫЙ сайт с кучей страниц оптимизирован как надо, гугл speed показывает 80 из-за неадекватно закрученных гаек и БОЛЬШЕ УЖЕ ОПТИМИЗИРОВАТЬ НЕКУДА (только себе во вред), а клиенту подавай — 100. И если клиент не понимает, что есть предел оптимизации, то приходится прибегать к методам выше. Если ты имел дело с одностраничниками и мелкими сайтами, которые можно на раз делать на 100 — поздравляю, ОПЫТА у тебя НОЛЬ, и с проектами серьезными ты никогда не работал т.к ТЫ НОЛЬ во всем. :) Доходчиво вроде объяснил )
                      0
                      Эко вас зацепило, что вы на грубости переходите. Если у вас проект который можно считать легаси, и который не был изначально создан для использования на мобилах, то понятно что оптимизировать его дорого. Но если сайт создаётся с нуля, то по него выбирается архитектура, которая позволяет без особого труда получить 100% по всем пунктам. С другой стороны вы наверно работаете с российскими заказчиками, которые не хотят платить за оптимизацию выбранной ими архитектуры. Все пределы у вас в голове, может быть с 2003 года, и вы слишком суперстар, чтобы понимать что ситуация на рынке изменилась. Или вам не нужен гугль а достаточно яндекса, которому плевать на оптимизации, а главное чтобы вы платили за рекламу бешенные бабки без каких либо гарантий на окупаемость.
                      Я с другой стороны, никогда не работал с российскими клиентами, ввиду того что они мало платят, и зачастую не знают чего хотят.
                      Если бы вы работали на меня, я бы вас уволил или отправил на пенсию, так как вы до сих пор не научились софт скилам и уважительному отношению к оппоненту.
                      Я на хабр не заходил уже несколько лет, и основная причина — такие персонажи как вы. В любом мало мальски уважаемом англоязычном ресурсе на любой вопрос ожидаемо получаешь наиболее четкий ответ по теме и без воды, а на русскоговорящих ресурсах всегда найдётся хоть один чудак который попытается насрать в душу и доказать что он прав. За сим откланиваюсь.

                      PS. в россии роскомнадзор умудрился заблокировать доступ к самому современному и оптимизированному хостингу netlify.com и всем сайтам на нём хостящимся. получается что все пользователи в россии отрезаны от самых качественных ресурсов мира из за бесполезной попытки забанить телеграм. Верной дорогой идём товарищи.
            –1
            Я Вас разочарую.
            Оценка, влияющая на ранжирование, собирается на основании сотен тысяч измерений ваших посетителей.

            Инструменты не крутят гайки, а диктуют стандарты качества, которые объективно влияют на производительность.

            Почти все сайты из красной и желтой зоны, находятся там по причине некомпетентности специалистов их создавших.

            Возврат в зеленую зону почти любого такого проекта — это дело трех дней. Причем не просто в зеленую зону, а 95+ балов. Причем не созданием контрастной заглушки, а честные 95+ балов с сохранением всей JS логики.

            Не верите? Я готов с Вами посоревноваться на любые деньги, что любой из Ваших проектов приведу в зеленую зону за три дня.Не одну страницу, а весь проект.

            Очень жаль что Вы и другие, производят оптимизацию страниц как всегда. Потому что лично я, устал на своем телефоне с 6Гб оперативной памяти и 8 ядерным процессором наблюдать ваши прожорливые тормозящие чудовища.

              0
              Вот по поводу 3х дней вы погорячились) попробуйте оптимизировать какой нибудь вордпресс сайт с кучей плагинов которые используют jQuery. это не реально. Но в целом я вас полностью поддерживаю!
                0
                Я этим деньги зарабатываю.
                Практически любой wordpress opencart bitrix magento за три дня в зеленой зоне. Вне зависимости от количества плагинов.
                Единственное условие: проект должен отдавать первый байт не дольше чем через 2 секунды после запроса. Что в большинстве случаев умеет делать любой самый тормознуть сайт.

                При невыполнении условия, сроки прогнозировать я не могу, потому что в этом случае нужно искать причину такого аномально долгого ответа.
            0
            Это как?
            Если страницы сайта загружаются медленно — это снизит оценку качества рекламы (ad quality score) и рекламные объявления будут стоить дороже.
              0
              А вот так! у гугля в adwords уже несколько лет встроен тест на производительность и оптимизированным сайтам дают хорошие скидки.
              Если ваш сайт грузится без ошибок и быстрее конкурента, и главное — контент релевантный, то в поисковой выдаче он будет выше.
              0
              PageSpeed insight уже древний как мамонт, гугль его уже заменил на Lighthouse, а затем встроил Lighthouse в сам Chrome, в закладке Аудит. гораздо быстрее, надёжнее и полезнее по функционалу
                0
                В общем случае Да. НО к сожалению или к счастью, граничные метрики LightHouse в DevTools и LightHouse в онлайн инструменте — разные.
                  0
                  Всё проще чем кажется — это просто разные версии Lighthouse. В каждой версии хрома версии обновляются. Можете проверить Canary и обычный хром.
                    0
                    Нет. Дело не в версиях. А в целях использования инструмента.
                    В случае PageSpeed его задача получить первый возомжны промежуток времени для интерактивности TTI
                    В случае его же в внутри DevTools его задача показать все что возможно. Собрать всю статистику взаимодействия.

                    Этоже видно по коду на GitHub
                0
                В марте индексирование стало основанным на мобильной версии страницы, а не на настольной.

                То есть, если сайт набирает 100 балов (настольная версия) в Google PageSpeed Insights и 10 баллов в мобильной версии, то по итогу все плохо? Количество баллов набранных в настольная версия для SEO уже не важны?

                Only users with full accounts can post comments. Log in, please.