Pagespeed insights оптимизация: Как Pagespeed Insights от Google помогает улучшить скорость загрузки сайта

Содержание

Как Pagespeed Insights от Google помогает улучшить скорость загрузки сайта

Вы можете использовать PageSpeed Insights бесплатно со страницы project или следуйте инструкции по установке расширения Google PageSpeed Insights Plesk в вашей панели Plesk

1. Избегайте переадресаций целевой страницы

Переадресации могут вызвать ощутимые задержки, если запрос переадресуется несколько раз на конечный адрес откуда в итоге отсылаются данные клиенту. Каждая переадресация инициирует свою процедуру HTTP запроса-ответа (с возможным поиском DNS и ТСP согласованием), которая может значительно снизить производительность сайта, особенно для мобильных устройств со слабым интернет соединением.

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

Также убедитесь, что настроен правильный редирект в один шаг с http://example. com на https://www.example.com. Люди привыкли набирать короткий адрес вашего домена в адресной строке браузера. Но ваш сайт должен работать только на https (для большей защиты и лучшего рейтинга) и возможно использовать www как субдомен.

Заметки SEO: 301 редирект с HTTP на HTTPS

HTTPS становится важным фактором в ранжировании Google. Поисковый движок отдает предпочтение сайтам, которые используют HTTPS протокол для обеспечения безопасных подключений между двумя конечными объектами — клиентом и сервером. Проверьте возможность активации 301 редиректа на ваших доменах как только вы установили SSL-сертификаты.

Пользователям Plesk поможет расширение Security Advisor для активации бесплатных SSL-сертификатов. И вы можете активировать 301 редирект через опцию «Настройки хостинга» в панели управления.

Говоря о редиректах, Plesk поддерживает из своей коробочной версии 301 редиректы, дружественные к SEO. Т.е. если вы устанавливаете бесплатный SSL сертификат Lets’Encrypt (о том, как его установить из панели Plesk, читайте в этой статье (прим. редакции Русоникс)), то Плеск поможет вам переключиться на безопасный протокол без потери в поисковом рейтинге.

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

Всегда отсылайте пользователям контент сжатым с помощью GZIP или Deflate. Эти способы сжатия проверяют может ли быть сжат запрошенный ресурс такой как HTML картинки или JS/CSS файлы. Сжатие уменьшает количество байтов, передаваемых через сеть, до 90%. Это сокращает общее время загрузки всех ресурсов, что приводит к ускорению времени загрузки и лучшему юзабилити. Для сжатия важным является то, что обе стороны (и клиент и сервер) понимают примененный алгоритм сжатия. В так называемых полях HTTP заголовков происходит обмен поддерживаемыми алгоритмами.

Большинство современных браузеров уже поддерживают сжатие по умолчанию. На серверной стороне вы можете использовать специальные модули такие как mod_deflate (в Apache) или ngx_http_gzip_module (в Nginx)

Plesk поддерживает сжатие из коробочной версии

Не переживайте, сервер Plesk уже имеет предустановленные необходимые модули сжатия. Вам лишь необходимо активировать эту опцию вручную для всех доменов где нужно использовать сжатие. Вы можете добавить необходимый код в .htaccess (apache) или web.config (nginx) в корневой директории вашего сайта или прямо в панели Plesk, что ещё проще.

Перейдите в закладку «Сайты и домены» и выберите «Настройки apache и nginx». Если вы используете веб-сервер apache, то вам нужно добавить следующий код в текстовом поле под опцией «Дополнительные директивы apache».

Выберите текстовое поле следующей опции «Дополнительные директивы для HTTPS» если вы используете HTTPS.

Для APACHE:

AddOutputFilterByType DEFLATE text/plain text/html text/xml;
AddOutputFilterByType DEFLATE text/css text/javascript;
AddOutputFilterByType DEFLATE application/xml application/xhtml+xml;
AddOutputFilterByType DEFLATE application/rss+xml;
AddOutputFilterByType DEFLATE application/javascript application/x-javascript

Если вы используете nginx, добавьте следующий код в текстовом поле «Дополнительные директивы nginx»

Для NGINX

gzip on; gzip_vary on;
gzip_proxied any;
gzip_comp_level 6;
gzip_disable «msie6»;
gzip_types text/plain text/css text/javascript text/xml application/json application/javascript application/x-javascript application/xml application/xml+rss;

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

3. Настройте кеширование браузером

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

Вы можете использовать два поля в заголовке ответа: cache-control и ETag. С помощью Cache-Control вы можете определить как долго браузер может кешировать индивидуальные ответы. ETag создаёт ревалидацию токенов с помощью которых браузер может легко определять изменения файлов.

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

4. Уменьшите время ответа сервера.

PageSpeed Insights выводит это сообщение, когда сервер не отвечает через определённое время (>200ms) . Время ответа обозначает время, которое нужно браузеру для загрузки HTML кода для вывода. На этот параметр может влиять множество причин.

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

Вопрос в том как найти эти «узкие места»? Вы можете использовать расширение New Relic для решения или с помощью тестирования ресурсом Webpagetest где можно увидеть как браузеры отображают страницы и какие файлы замедляют ваш сайт.

5.Уменьшите HTML, CSS&JS

Сервер может уменьшить объём таких ресурсов, как HTML код или JS и CCS файлы, перед отправкой их в браузер. Это сохранит много байтов данных, что увеличивает скорость загрузки ресурсов. Уменьшение объёма — это процесс оптимизации кода без потери нужной информации, чтобы сайт для посетителя отображался корректно.

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

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

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

Это правило действует, когда PageSpeed Insights выявляет, что HTML код ссылается на блокирующий внешний файл JavaScript в верхней части страницы. PageSpeed Insights запускает это правило, если браузер загружает JS и CSS файлы для верхней части страницы, даже если данное содержимое не нуждается в коде для создания правильного вывода. Это значит, что брауезр не может отобразить HTML вывод так как внешние ресурсы доступны частично.

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

Также есть смысл объединять все файлы в один файл (1 файл для CSS и JS) для уменьшения количества HTTP запросов. В общем, опредённо следует активировать HTTP/2 на вашем сервере. Новая версия протокола имеет очень положительное влияние на производительность сайта.

7.

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

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

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

Content-Delivery-Networks (CDN) такие как CloudFlare, могут оптимизировать картинки для вас автоматически.

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

8.Оптимизация видимого контента

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

Также важно структурировать HTML код, который загружает «тяжёлый» контент первым. Например если рядом с вашей статьей есть боковая панель, то разместите ее после статьи в HTML коде так, чтобы браузер отображал статью перед боковой панелью.

В статье уже упоминалось про асинхронную передачу JS и это также возможно для улучшения настройки доставки CSS. Необходимые инструкции CSS в видимой части контента могут быть встроены напрямую в HTML код а остальное выделить в один файл после процесса отображения.

Google PageSpeed Insights расширение в Плеск

Если вы ещё не делали этого установите расширение в Плеск «Google PageSpeed Insights Plesk » сегодня и улучшите производительность веб-сайта и позиции в поисковой выдаче.

Перевод: Сергей Гордеев (Русоникс)
Оригинал

Как оптимизировать скорость сайта с помощью 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.

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

О PageSpeed Insights | Google для разработчиков

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

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

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

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

Отчет (CrUX) набор данных. PSI сообщает о реальных пользователях First Contentful Paint (FCP), первая задержка ввода (FID), Самая большая содержательная краска (LCP), кумулятивный макет Shift (CLS) и Interaction to Next Paint (INP) предыдущий 28-дневный период сбора. PSI также сообщает об опыте экспериментального метрика Время до первого байта (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-й процентиль выбран так, чтобы разработчики могли понять наиболее разочарование пользователей на их сайте. Эти значения метрик поля классифицируются как хорошо/нуждается в улучшении/плохо, применяя те же пороговые значения, что и выше.

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

Core Web Vitals — это общий набор сигналов производительности, критически важных для весь веб-опыт. Метрики Core Web Vitals — это FID, LCP и CLS, и они могут собраны либо на уровне страницы, либо на уровне источника. Для агрегатов с достаточным количеством данных во всех три метрики, агрегация проходит оценку Core Web Vitals, если 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 сообщит о работе в одной из следующих стран: Северная Америка, Европа или Азия.

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

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

Почему для всех показателей выбран 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, на который можно ответить, задать вопрос на английском в стеке Переполнение.

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

Как улучшить оценку Google PageSpeed Insights Score

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

Медленное время загрузки страницы отрицательно сказывается на общем взаимодействии с пользователем и конверсии вашей целевой страницы. И дело не только в пользователе — Google также штрафует за медленную загрузку страниц.

Итак, как обеспечить быструю загрузку страницы? Здесь на помощь приходит Google PageSpeed Insights.

Что такое Google PageSpeed Insights?

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

Оценка PageSpeed Insights варьируется от 0 до 100 баллов. Чем выше оценка, тем лучше, а оценка 85 или выше указывает на то, что страница работает хорошо.

Если ввести URL-адрес и нажать «Анализ», вы быстро получите подробный отчет о причинах замедления этой веб-страницы на основе двух параметров с рекомендациями по устранению этой проблемы.

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

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

Достижение высокого балла Google PageSpeed Insights

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

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

1. Избегайте перенаправлений на целевые страницы

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

На сайте example.com используется адаптивный веб-дизайн, перенаправления не требуются — быстро и оптимально
example.com → m.example.com/home – штраф за многократную передачу туда и обратно для мобильных пользователей
example.com → www.example.com → m.example.com – очень медленно работает на мобильных устройствах

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

(Все макеты Instapage являются адаптивными, поэтому вашему пользователю никогда не придется щипать для увеличения.)

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

Современные браузеры способны предоставлять пользователям Интернета уменьшенную альтернативную версию страницы. С включенным компрессором gzip эти страницы могут уменьшиться в размере на 90%.

Вот как gzip оптимизирует процесс HTTP-запросов и ответов:

Однако при включенном сжатии процесс выглядит примерно так:

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

3. Минимизация CSS, HTML, JavaScript

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

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

Минимизатор HTML для минимизации HTML
CSSNano и csso для минимизации CSS
UglifyJS2 и компилятор Closure для минимизации JavaScript

Другой вариант — это, конечно же, воспользоваться преимуществами Google AMP и AMP для рекламных фреймворков. Обе программы позволяют разработчикам создавать страницы с урезанной версией HTML, CSS и JavaScript. В результате страницы и реклама загружаются за доли секунды.

4. Отдайте предпочтение содержанию верхней части страницы

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

Воспринимаемая производительность может быть описана просто как «насколько быстро загружается ваш веб-сайт?» Это может немного отличаться от скорости загрузки вашего сайта. Воспринимаемая производительность определяется с точки зрения пользователя, а не с точки зрения инструмента тестирования скорости веб-сайта.

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

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

5. Ускорьте время отклика сервера

Время отклика сервера — время, которое требуется вашему серверу, чтобы начать загрузку содержимого страницы для пользователя — оно может замедлиться по ряду факторов согласно Google:

Запросы к базе данных
Медленная маршрутизация
Каркасы
Библиотеки
Ресурс Нехватка ЦП
Нехватка памяти

6. Устранение блокировки рендеринга JavaScript

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

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

Скрипты, которые не имеют решающего значения для процесса загрузки, должны быть намеренно задержаны — выбраны и выполнены после того, как страница будет полностью отрисована.
Сценарии, которые загружаются асинхронно, должны использоваться поверх тех, которые загружаются синхронно. Синхронные скрипты приостанавливают процесс рендеринга страницы, а асинхронные позволяют браузеру одновременно загружать другие элементы.
Рассмотрите возможность встраивания скрипта — вставки небольших внешних ресурсов JavaScript непосредственно в ваш HTML-документ — чтобы уменьшить количество запросов, которые должен делать ваш браузер.

7. Использование кэширования браузера

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

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

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

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

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

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

К счастью, оптимизировать изображения несложно. Замена PNG файлом изображения JPEG может легко сэкономить размер страницы и время загрузки. То же самое можно сказать и о компрессорах изображений, таких как Guetzli и Zopfli от Google.

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

Узнайте, где вы находитесь, с помощью Google PageSpeed Insights

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

Нужна помощь в создании быстрых целевых страниц? Вам нужен Инстапейдж.

Платформа целевой страницы ускоряет скорость вашей страницы с помощью AMP и Thor Render Engine®. Узнайте, как эти решения работают для вас, создав целевые страницы с высокой конверсией уже сегодня. Подпишитесь на 14-дневную пробную версию.