Pagespeed insights оптимизация: Как оптимизировать скорость сайта с помощью Google PageSpeed / Хабр

Содержание

Как оптимизировать скорость сайта с помощью Google PageSpeed / Хабр

Привет читателям Хабра!

Меня зовут Сергей Кузнецов, я руковожу отделом frontend-разработки в компании AGIMA. Сегодня мне бы хотелось поговорить про оптимизацию сайта в разрезе показателей Google PageSpeed.

Статей разной свежести и полезности много, но обычно в них даются наиболее простые и распространенные рекомендации, которые известны любому, кто хоть немного дружит с вебом. Что-то вроде: «Выносите скрипты вниз страницы» или «Минифицируйте файлы». Но что делать, когда базовые рекомендации были учтены еще на этапе разработки, а показатели все еще далеки от идеальных?

Давайте попробуем разобраться с этой проблемой. Поговорим о тех пунктах, которые описаны в рекомендациях PageSpeed Insights довольно обобщенно, например: «Минимизируйте работу в основном потоке» или «Сократите время выполнения кода». Отличные рекомендации, но только что конкретно требуется?

Ниже примеры вопросов, которые могут поставить в тупик недостаточно погруженных в тему оптимизации разработчиков.

Что делать с аналитикой или сторонними виджетами?
Что работает быстрее: секвенция или видео?
Имеет ли смысл настраивать CDN?
Нормально ли, что показатели периодически скачут, хотя вы ничего не делали?

И другие подобные моменты из практики. Конечно, мы не сможем охватить в одной статье все подобные моменты, но постараемся коснуться наиболее распространенных проблем, чуть более сложных, чем: «На страницу загрузили не сжатую картинку на 20 мегабайт» или «Забыли на сервере включить GZIP».

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

Изменения в Google PageSpeed

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

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

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

Вот как написано на официальном сайте:

«На результат измерения скорости загрузки в разной степени влияет множество факторов. Основные из них — это доступность локальной сети, доступность аппаратных средств клиента и наличие конфликтов при доступе к ресурсам клиента.»

На самом деле, повлиять может все что угодно, поэтому для более релевантной оценки, рекомендуется сделать не 1 замер, а 3-5 в течение дня в разное время суток.

В 2020-ом произошло обновление движка Lighthouse 6, на базе которого работает PageSpeed Insights. В Lighthouse 6 разработчиками было добавлено несколько значительных изменений. Появились новые метрики, которые ощутимо влияют на общую оценку быстродействия страницы. Обновились аудиты для «доступности» и Javascript.

Ключевые метрики:

Largest ContentFul Paint (LCP) — отрисовка крупного контента. Время, за которое большая часть контента отрисовывается на экране. Желательное время до 2,5 секунд, приемлемое — до 4 секунд.
First Input Delay (FID) — задержка между первым действием пользователя и реакцией браузера. Желательное время до 100 мс, приемлемое — до 300 мс.
Cumulative Layout Shift (CLS) — совокупный сдвиг макета. Показывает оценку визуальной стабильности страницы. Нацелено на борьбу с всплывающей рекламой и блоками, которые появляются и пропадают без действий со стороны пользователя. Если изображение «скачет», то показатели падают. Нормальное значение до 0,1, допустимое — до 0,25.

И вот эти показатели из отчета входят в Core Web Vitals. А значит, метрики будут существенно влиять на ранжирование поисковой выдачи. Важное условие — как минимум 75% страниц сайта должны соответствовать нижним границам этих трёх показателей. Иначе сайт будет признан Google плохо оптимизированным. Но при этом сами показатели имеют разные веса в учете суммарной оценки, например, LCP или FID влияют на итоговую сильнее, чем CLS.

В ноябре 2020 года Google подтвердил, что Core Web Vitals станет фактором ранжирования с мая 2021 года. Рекомендации как и раньше есть, но теперь они напрямую не связаны с баллами. Совершенно не факт, что следование рекомендациям улучшит ситуацию, так как выполнение некоторых из них может ухудшить ситуацию или быть неприемлемым с точки зрения поддержки различными браузерами. Ранее частенько встречалась ситуация, когда очевидно тормозящие сайты выдавали отличные оценки, а быстрые сайты оценивались плохо. Теперь с изменением алгоритмов становятся важными именно скорость и восприятие пользователем. Все маркетинговые погремушки, которые так любят запихнуть на первый экран, теперь неизбежно будут ухудшать оценку, как ты их не отлаживай. Поэтому рекомендация на будущее: на странице, особенно на первом экране, должен быть только максимально необходимый контент, желательно с минимумом анимаций и сторонних включений.

Как улучшить производительность?

Итак, что мы можем сделать для улучшения общей картины производительности?

Широко рекомендуется использовать асинхронную загрузку. При этом следует помнить, что асинхронный и «не влияющий на скорость загрузки» — разные вещи. Да, он позволяет загружать ресурсы параллельно, не блокируя какой-то из них, но общее время все равно увеличивается. Далее, если код вы уже вынесли вниз страницы, то добавление асинхронности ничего в плане блокирования загрузки контента не изменит. Так что асинхронность не панацея, а лишь способ частично улучшить ситуацию. Намного эффективнее — это использовать как можно меньше кода в целом, например, загружать не всю библиотеку, а только те компоненты, которые вам необходимы конкретно на этой странице.

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

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

Можно настроить кэширование на своем сервере и обновлять по крону, но помимо банального неудобства такого решения оно может ничего и не улучшить. А вот настройка самого контейнера на загрузку сценариев по событию способно поправить ситуацию. Нас интересует, естественно, отложенная загрузка по событию. В идеале подгрузку таких вещей стоило бы отложить до полной загрузки страницы, но аналитики скорее всего будут против, так как, например, если пользователь уйдет с сайта до момента полной загрузки, они не получат вообще никакой информации. Но, как минимум, стоит ориентироваться на событие DOM Ready только для сбора наиболее критичных метрик.
Можно использовать service worker, он будет кешировать часть или всё содержимое HTML-страницы. Сервис обновляет кеш только при каких-либо изменениях на странице.
Указывайте размеры изображений и видео в тэгах, это опять полезно. Если изображения адаптивные, указывайте хотя бы пропорции (например, 16:9).

Хочется обратить внимание, что рекомендация: сводить все изображения в спрайт, сейчас скорее вредит, чем помогает. Гораздо больше пользы принесет отложенная или «ленивая загрузка» не попадающих в текущую область видимости. Помните, что «ленивую загрузку» можно применять и для видео. Недавно я подробнее рассказывал об анимации. Во-первых, для видео, которое не нужно автоматически прокручивать, используйте атрибут preload=»none». Для видео, которое используется в качестве анимаций, указывайте атрибут poster=»» и используйте код JavaScript, аналогичный примерам отложенной загрузки изображений на основе Intersection Observer.

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

Можно применить web-workers — специальное API-решение, позволяющее загружать JavaScript, который не связан с пользовательским интерфейсом в фоновом режиме. Можно отказаться от отрисовки тяжелого содержимого в браузере в пользу серверного рендеринга. Так вы сократите время ответа сервера. Держите проект на быстром хостинге или VPS/VDS, мониторьте потребление ресурсов, оптимизируйте базу данных, настройте кеширование. Перейдите на новую версию PHP. Версия 7.3 работает в 3-4 раза быстрее старых редакций.

Используйте протокол http/2, он позволяет быстрее и эффективнее передавать данные между браузером и сервером. В отличие от http/1 он не создает отдельные соединение для загрузки каждого файла, а загружает их параллельно. Таким образом, http/2 уменьшает нагрузку на сервер и экономит его ресурсы.

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

Что касается предпочтительности той или иной анимации, то все упирается в качество изображения и продолжительность. В силу наиболее продвинутых алгоритмов сжатия, видео предпочтительнее использования секвенции. Кроме того, в самом видео предпочтительно использовать новый формат WebM, поскольку он специально разработан для потоковой передачи через интернет. WebM намного меньше по сравнению с MP4. А такие решения как гиф-анимация вообще вызывают предупреждение PageSpeed с просьбой использовать более современные форматы. Выбор же между WebGL или видео для анимаций уже сильно неоднозначен, предсказать результат заранее не получится. В целом следует исходить из соотношения веса решений к их продолжительности.

Также иногда возникает вопрос: на некоторых сайтах сперва изображения не очень четкие, а потом они прогружаются, это же ускорение работы сайта? Визуально — да, но по факту — нет. Для подобной технологии мы сперва вынуждены грузить маленькие по весу изображения, а потом асинхронно подтягивать качественные. Это не частичная загрузка большого файла «побыстрей», а дополнительная предзагрузка маленького. Для пользователя это неплохо, а вот метрики таким не улучшить.

Не забываем про шрифты, помимо использования подходящих форматов, рекомендуется использовать rel=»preload» как и для скриптов.

Также в стилях стоит указать font-display:swap; — это даст возможность использовать встроенные шрифты в ожидании загрузки основного.

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

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

Улучшаем скорость сайта с помощью Google PageSpeed Insights

Ускорение вашего сайта — непростая задача. Бывает трудно определить, что заставляет ваш сайт работать медленнее.

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

Интерфейс Google PageSpeed Insights

Чтобы начать работу, откройте инструмент PageSpeed Insights и введите URL вашего сайта в соответствующее поле, затем нажмите «Анализировать»:

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

Вот как выглядит мой отчет:

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

Low (красный) — свидетельствует о медленной загрузке страницы.
Medium (оранжевый) — страница испытывает некоторые проблемы с быстрой загрузкой, но не критические.
High (зеленый) — страница загружается быстро.

Скорость загрузки страницы замеряется по Cобытию первой отрисовки контента (FCP) и DOM Content Loaded (DCL):

Отчет состоит из 3 разделов:

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

Давайте пройдемся по всем рекомендациям Google PageSpeed, чтобы понять как их использовать.

Читайте также: Оптимизация под голосовой поиск

Рекомендации Google PageSpeed Insights

1. Сократите время ответа сервера

Нормальным показателем будет 200-500 мс (0,2-0,5 с). Все что выше — Google уже отмечает.

Многое зависит от хостинга, а именно конфигурации и настроек сервера. Если он недостаточно мощный — могут возникать задержки в ответе сервера.

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

Как дополнительный вариант, можно отключить все ненужные службы, работающие на сервере, чтобы увеличить скорость.
Но самая большая разница, которую я заметил, чтобы уменьшить время отклика сервера, достаточно перейти на новую версию PHP, например PHP 7. Разные отчеты в интернете показывают увеличение скорости на 20-50% с переходом на PHP 7.

Читайте также: Как улучшить позиции сайта в мобильной выдаче

Итак, подытожим, что можно сделать для увеличения время ответа сервера:

перейти на более современный и быстрый хостинг с поддержкой PHP 7
изменить или обновить версию CMS сайта
отключить или удалить все ненужные, устаревшие и “тяжелые” плагины на сайте, уменьшив таким образом количество обращений к базе данных и снизив нагрузку на CPU сервера
очистить базу данных сайта от лишних записей, что также уменьшит использование CPU

Больше рекомендаций по оптимизации сервера в документации Google:
https://developers.google.com/speed/docs/insights/Server

2. Оптимизируйте изображения

Основная причина медленной загрузки страниц и низких баллов в PageSpeed Insights — большие изображения.

К примеру, для ПС Google все, что превышает 100 Кб считается большим.

Как только я сжал все свои изображения на сайте — получил огромное прибавление в скорости.

Если вы используете WordPress, один из лучших способов сжать изображения, не потратив много времени, использовать плагин. Мой любимый плагин для использования — WP Smush Image Compression and Optimization:

Если ваш сайт страдает из-за большого количества больших изображений, то их просто нужно сжать. Например, при сохранении в Photoshop качество сжатия jpeg-файла должно быть не выше 85%. В большинстве случаев нет никакой потребности указывать столь высокое значение. Некоторые веб-дизайнеры часто упоминают магическое число «51» для сжатия jpeg, но вы можете сами оценить, насколько можете уменьшить качество.

Бесплатные сервисы для сжатия изображений:

TinyPNG
Compressor.io
Optimizilla

Более детально об оптимизации изображений:
https://developers.google.com/speed/docs/insights/OptimizeImages

3. Удалите код JavaScript и CSS, блокирующий отображение верхней части страницы

Некоторые скрипты и стили, расположенные в самом верху страницы в header, блокируют отображение страницы.

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

Детальнее о блокирующих элементах кода в документации Google:
https://developers.google.com/speed/docs/insights/BlockingJS#InlineJS

4. Используйте кеш браузера

Кэширование браузера или Leverage browser caching — еще один инструмент, который может оказать большое влияние на скорость страницы. Получение ресурсов для загрузки вашего сайта требует больших усилий. Он требует загрузки каждого элемента изображения и страницы, а затем имеет дело с тяжелым HTML и кодированием. Каждый раз, когда кто-то загружает ваш сайт, этот процесс должен происходить снова и снова. Ваш сайт будет слишком долго загружаться. И именно здесь может помочь кэширование.

Кэширование позволяет вашему браузеру «помнить» определенные элементы, которые были недавно загружены — заголовок, навигация, логотип и т. д. Чем больше элементов браузер может кэшировать, тем меньше элементов он должен загружать, когда пользователь делает запрос и, в конечном счете, быстрее загрузится страница. Google рекомендует минимальную политику кэширования в течение одной недели, а для элементов, которые в основном остаются неизменными, предпочтительнее один год.

Он работает путем «запоминания» ранее загруженных ресурсов, поэтому ему не нужно перезагружать их при каждом посещении. Когда посетитель веб-сайта перемещается на новую страницу вашего сайта, все ваши данные, например, логотипы и нижние колонтитулы, больше не нужно загружать. Это приведет к значительному увеличению скорости!

Читайте также: Как использовать og image

5. Сократите JavaScript и CSS

Сведение к минимуму пространства, которое занимает ваше кодирование в формате Java Script, является еще одним важным фактором получения идеального результата от Google. Минимизация — это процесс удаления или исправления ненужных или дублированных данных, не влияя на то, как браузер будет обрабатывать HTML. Он включает в себя исправление кода, форматирование, удаление неиспользуемого кода и сокращение кода, когда это возможно. И еще раз, благодаря потрясающим плагинам WordPress, вам не нужно быть гением программирования, чтобы исправить это.

Желательно начать с валидации всего HTML-кода сайта: https://validator.w3.org

Список сервисов для оптимизации JavaScript:

JavaScript Minifier
JsCompress
Minify JavaScript

Список сервисов для оптимизации CSS:

СSS Compressor
CSS Minifier
Minify CSS

Детальнее об оптимизации JavaScript и CSS файлов в документации Google:
https://developers.google.com/speed/docs/insights/MinifyResources

6. Включите сжатие

Существует большой объем данных, которые необходимо передавать между серверами и пользователями при доступе к сайту. К счастью, есть способ сжатия передаваемой информации. Он называется — gzip (от GNU Zip).

Пользователи WordPress могут включить gzip сжатие, установив плагин GZip Ninja Speed Compression.Читайте также: Советы для SEO по WordPress.

На многих хостингах gzip-сжаите уже включено по умолчанию, но вы можете проверить включено оно или нет на вашем сайте с помощью сервиса: https://checkgzipcompression.com/

Детальнее о сжатии в документации Google:
https://developers.google.com/speed/docs/insights/EnableCompression#-

7. Мобильная версия

Все рекомендации выше касались десктопной версии сайта. Для мобильной они мало чем отличаются, но связаны с работой сайта под смартфоны и планшеты. Думаю, не стоит рассказывать вам, насколько важны обе, особенно с введением Mobile first Index в Google. Большую роль тут играет адаптивность и наличие AMP-страниц (Accelerated Mobile Pages). Что выбрать — мобильную версию или качественную адаптивную верстку — читайте в статье: Мобильный поиск в современном SEO

О PageSpeed Insights | Разработчики Google

PageSpeed Insights (PSI) сообщает о взаимодействии пользователей со страницей как на мобильных устройствах, так и на настольных компьютерах. устройств, а также дает предложения по улучшению этой страницы.

PSI предоставляет как лабораторные, так и полевые данные о странице. Лабораторные данные полезны для отладки вопросы, так как он собирается в контролируемой среде. Однако может и не захватывать узкие места в реальном мире. Полевые данные полезны для захвата истинного, реального пользователя опыт, но имеет более ограниченный набор метрик. Посмотрите, как думать О Speed Tools для получения дополнительной информации о двух типах данных.

Данные реального взаимодействия с пользователем

Данные реального взаимодействия с пользователем в PSI основаны на пользовательском интерфейсе Chrome. Отчет (CrUX) набор данных. PSI сообщает о реальных пользователях First Contentful Paint (FCP), первая задержка ввода (FID), Самая большая содержательная отрисовка (LCP) и совокупный макет Shift (CLS) за предыдущий 28-дневный период сбора.

PSI также сообщает опыт для экспериментальных метрик Interaction to Next Paint (INP) и время до первого байта (TTFB).

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

Оценка качества опыта

PSI классифицирует качество пользовательского опыта по трем категориям: хорошее, нуждается в улучшении, или Бедный. PSI устанавливает следующие пороговые значения в соответствии с Инициатива Web Vitals:

	Хорошо	Требуется улучшение	Бедный
ФКП	[0, 1800 мс]	(1800 мс, 3000 мс]	более 3000 мс
ПИД	[0, 100 мс]	(100 мс, 300 мс]	более 300 мс
ЛКП	[0, 2500 мс]	(2500 мс, 4000 мс]	более 4000 мс
CLS	[0, 0,1]	(0,1, 0,25]	свыше 0,25
ИЯФ (экспериментальный)	[0, 200 мс]	(200 мс, 500 мс]	более 500 мс
ТТФБ (экспериментальный)	[0, 800 мс]	(800 мс, 1800 мс]	более 1800 мс

Распределение и выбранные значения показателей

PSI представляет распределение этих показателей, чтобы разработчики могли понять диапазон опыт для этой страницы или источника. Это распределение разделено на три категории: «Хорошо», «Требуется улучшение» и «Плохо», которые представлены зелеными, желтыми и красными полосами. Например, 11 % в пределах желтой полосы LCP означает, что 11 % всех наблюдаемых значений LCP падают между 2500 мс и 4000 мс.

Над полосами распределения PSI сообщает 75-й процентиль для всех показателей. 75-й процентиль выбран так, чтобы разработчики могли понять наиболее разочарование пользователей на их сайте. Эти значения метрик поля классифицируются как хорошо/нуждается в улучшении/плохо, применяя те же пороговые значения, что и выше.

Основные веб-показатели

В противном случае агрегат не проходит оценку. Если агрегации недостаточно данных для FID, то она пройдет оценку, если и 75-й процентили LCP и CLS являются хорошими. Если в LCP или CLS недостаточно данных, страница или агрегирование на уровне источника не может быть оценено.

Различия между полевыми данными в PSI и CrUX

Разница между полевыми данными в PSI и Набор данных CrUX в BigQuery заключается в том, что данные PSI обновляются ежедневно, в то время как набор данных BigQuery обновляется ежемесячно и ограничивается данными на уровне источника. Оба источника данных представляют конечные 28-дневные периоды.

Лабораторная диагностика

PSI использует Lighthouse для анализа заданного URL-адреса в смоделированном среду для категорий «Производительность», «Доступность», «Оптимальные методы» и «SEO».

Оценка

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

Метрики

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

Каждая метрика оценивается и помечается значком:

Хорошее обозначено зеленым кружком

Требует улучшения обозначен желтым информационным квадратом
Неудовлетворительное состояние обозначается красным предупреждающим треугольником

Аудиты

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

Часто задаваемые вопросы (FAQ)

Какие устройства и сетевые условия использует Lighthouse для имитации загрузки страницы?

В настоящее время Lighthouse имитирует условия загрузки страницы устройства среднего уровня (Moto G4). в мобильной сети для мобильных устройств и emulated-desktop с проводным подключением для рабочего стола. PageSpeed также работает в Google центр обработки данных, который может варьироваться в зависимости от условий сети, вы можете проверить местоположение, в котором было просмотром блока окружающей среды Lighthouse Report:

Примечание. PageSpeed сообщит о работе в одной из следующих стран: Северная Америка, Европа или Азия.

Почему полевые и лабораторные данные иногда противоречат друг другу?

Лабораторные данные основаны на смоделированной загрузке страницы на одном устройстве и фиксированных набор сетевых условий. В результате значения могут отличаться. См. Почему лабораторные и полевые данные могут отличаться (и что с этим делать) для получения дополнительной информации.

Почему для всех показателей выбран 75-й процентиль?

Наша цель — убедиться, что страницы хорошо работают для большинства пользователей. Ориентируясь на 75-й значения процентиля для наших показателей, это гарантирует, что страницы обеспечивают хорошее взаимодействие с пользователем в самых сложных условиях устройства и сети. См. Определение пороговых значений показателей Core Web Vitals. для получения дополнительной информации.

Что такое хорошая оценка лабораторных данных?

Любая зеленая оценка (90+) считается хорошим, но учтите, что хорошие лабораторные данные не обязательно означает, что реальный пользовательский опыт также будет хорошим.

Почему показатель производительности меняется от запуска к запуску? Я ничего не менял на своей странице!

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

Почему данные CrUX реального пользователя недоступны для URL-адреса или источника?

В отчете об опыте использования Chrome собраны реальные данные о скорости из подписавшиеся пользователи и требует, чтобы URL-адрес был общедоступным (сканируемый и индексируемый) и иметь достаточное количество отдельных образцов, которые обеспечивают репрезентативное анонимное представление производительности URL или источника.

Есть вопросы?

Если у вас есть конкретный вопрос об использовании PageSpeed Insights, на который можно ответить, задайте свой вопрос на английском языке в Stack Overflow.

Если у вас есть общие отзывы или вопросы о PageSpeed Insights, или вы хотите начать общее обсуждение, начните тему в списке рассылки.

Если у вас есть общие вопросы о показателях Web Vitals, начните обсуждение в группе обсуждения web-vitals-feedback.

Обратная связь

Была ли эта страница полезной?

Большой! Спасибо за ваш отзыв! Если у вас есть конкретный вопрос об использовании PageSpeed Insights, на который можно ответить, задать вопрос на английском в стеке Переполнение. Для общих вопросов, отзывов и обсуждений создайте тему в список рассылки. Жаль это слышать. Если у вас есть конкретный вопрос об использовании PageSpeed Insights, на который можно ответить, задать вопрос на английском в стеке Переполнение.

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

О PageSpeed Insights | Разработчики Google