Содержание
- 0.1 Посмотрите на загрузку вашего сайта глазами посетителя
- 0.2 Проверьте изменения скорости сайта, увидев истинную статистику загрузки
- 1 Как оптимизировать скорость сайта
- 2 Как ускорить первую содержательную отрисовку (FCP)
- 3 Как ускорить отрисовку с наибольшим содержанием (LCP) с помощью рекомендаций DebugBear
- 4 Следите за скоростью вашего сайта с помощью DebugBear
Посмотрите на загрузку вашего сайта глазами посетителя
Получите хорошее представление о том, что ваши посетители на самом деле испытывают, когда они посещают ваш сайт.
Заметили, что что-то загружается медленно или не на своем месте? Это может помочь вам определить важные задержки и проблемы с конверсией, с которыми сталкиваются ваши посетители.
Диафильм временной шкалы показывает ход рендеринга веб-сайта с течением времени.
Например, эта страница начинает отображаться через 0,7 секунды, а основное изображение — через 1,3 секунды.
Веб-сайт полностью визуализируется, также известный как визуально завершенный, когда виджет чата отображается через 3,7 секунды.
В инструменте вы также можете посмотреть видеозапись процесса рендеринга.
Это отличный способ продемонстрировать влияние проблем с производительностью на клиентов или других членов вашей команды.
Screenshot showing a video recording of a partially rendered website in DebugBear, October 2022Проверьте изменения скорости сайта, увидев истинную статистику загрузки
Допустим, вы оптимизировали свой веб-сайт и хотите понять, повлияют ли эти изменения.
Этот инструмент выполняет «лабораторный тест» в оптимальной среде, чтобы определить, правильно ли вы оптимизируете свой сайт.
Когда вы протестируете свой сайт, вы получите официальную «оценку лаборатории», которая представляет собой сводку шести показателей производительности, полученных из оценки производительности с помощью инструмента Google Lighthouse:
- Первая содержательная краска (10% от общей оценки).
- Индекс скорости (10%).
- Самая большая содержательная краска (25%).
- Время до интерактивности (10%).
- Общее время блокировки (30%).
- Совокупный сдвиг макета (15%).
Используя эти данные, вы узнаете, насколько полезным был ваш последний раунд оптимизации и что вам, возможно, потребуется изменить.
К настоящему времени вы, вероятно, задаетесь вопросом, что вам нужно изменить. Давайте узнаем, как оптимизировать ваш сайт с помощью каждой ключевой метрики в обзоре метрик.
Как оптимизировать скорость сайта
Запуск теста скорости — это первая часть пути оптимизации вашего сайта.
Когда у вас есть показатели, вам нужно знать, как их интерпретировать и что делать, чтобы их исправить.
В области «Обзор показателей» отчета о скорости вашего веб-сайта вы увидите ключевые показатели, на которые мы сосредоточимся, чтобы ускорить работу вашего сайта:
- Первая содержательная отрисовка : это можно ускорить, восстановив скорость связи с сервером.
- Самая большая содержательная отрисовка : ее можно ускорить за счет оптимизации мультимедиа и ресурсов.
Кроме того, вы можете использовать водопад запросов, чтобы увидеть, сколько времени занимают запросы и как это влияет на эти показатели.
Как ускорить первую содержательную отрисовку (FCP)
Давайте начнем с того, что ваш веб-сайт появится раньше для ваших посетителей; сначала мы займемся First Contentful Paint.
Что такое первая содержательная краска?
First Contentful Paint измеряет, как скоро содержимое страницы начинает отображаться после того, как посетитель переходит на эту страницу.
Важно, чтобы ваш ключевой контент появлялся быстро, чтобы посетитель не покинул ваш сайт. Чем быстрее пользователь покидает ваш сайт, тем быстрее Google узнает, что страница может быть плохой.
Но как узнать, что именно вызывает медленную загрузку вашего сайта?
Как узнать, какие проблемы с сервером замедляют работу вашего сайта? Давай выясним.
Почему моя первая содержательная раскраска занимает так много времени?
На ваш FCP могут влиять скорость соединения с сервером, запросы к серверу, ресурсы, блокирующие рендеринг, и многое другое.
Звучит много, но есть простой способ узнать, что именно замедляет работу FCP, — водопад запросов .
Этот полезный инструмент показывает, какие запросы делает ваш веб-сайт и когда каждый запрос начинается и заканчивается.
Например, на этом снимке экрана мы сначала видим запрос HTML-документа, а затем два запроса на загрузку таблиц стилей, на которые есть ссылки в документе.
Почему первая содержательная отрисовка происходит через 0,6 секунды? Мы можем разобрать, что происходит на странице, чтобы понять это. Понимание того, что происходит перед первой содержательной отрисовкой
Прежде чем первые фрагменты контента смогут загрузиться на вашу веб-страницу, браузер вашего пользователя должен сначала подключиться к вашему серверу и получить контент.
Если этот процесс занимает много времени, то вашему пользователю потребуется много времени, чтобы увидеть ваш сайт.
Ваша цель — узнать, что происходит, до того, как ваш веб-сайт начнет загружаться, чтобы вы могли точно определить проблемы и ускорить работу.
Загрузка страницы, часть 1: браузер создает соединение с сервером
Перед первым запросом веб-сайта с сервера браузер вашего посетителя должен установить сетевое соединение с этим сервером.
Обычно это занимает три шага:
- Проверка записей DNS для поиска IP-адреса сервера на основе доменного имени.
- Установление надежного соединения с сервером (известного как TCP-соединение).
- Установка защищенного соединения с сервером (известного как соединение SSL).
Эти три шага выполняются браузером один за другим. Каждый шаг требует кругового пути от браузера вашего посетителя до сервера вашего веб-сайта.
В этом случае для установления соединения с сервером требуется около 251 миллисекунды.
Загрузка страницы, часть 2: браузер запрашивает HTML-документ (здесь отображается время до первого байта)
Как только соединение с сервером установлено, браузер вашего посетителя может запросить HTML-код, содержащий содержимое вашего веб-сайта. Это называется HTTP-запросом.
В этом случае HTTP-запрос занимает 102 миллисекунды. Эта продолжительность включает в себя как время, затраченное на передачу данных по сети, так и время, затраченное на ожидание ответа сервера.
Через 251 миллисекунду на создание соединения и 102 миллисекунды на выполнение HTTP-запроса браузер вашего посетителя, наконец, может начать загрузку HTML-ответа.
Эта веха называется временем до первого байта (TTFB). В данном случае это происходит через 353 миллисекунды.
После того, как ответ сервера готов, браузер вашего посетителя тратит дополнительное время на загрузку HTML-кода. В этом случае ответ довольно мал, а загрузка занимает всего 10 дополнительных миллисекунд.
Загрузка страницы, часть 3: ваш сайт загружает дополнительные ресурсы, блокирующие рендеринг
Браузеры не отображают и не отображают страницы сразу после загрузки документа. Вместо этого обычно есть дополнительные ресурсы, блокирующие рендеринг .
Большинство страниц выглядели бы плохо без каких-либо визуальных стилей, поэтому таблицы стилей CSS загружаются до начала рендеринга страницы.
Загрузка двух дополнительных таблиц стилей в этом примере теста скорости веб-сайта занимает 137 миллисекунд.
Обратите внимание, что эти запросы не требуют нового подключения к серверу. Файлы CSS загружаются из того же домена, что и раньше, и могут повторно использовать существующее соединение.
Загрузка страницы, часть 4: браузер отображает страницу
Наконец, как только все необходимые ресурсы будут загружены, браузер вашего посетителя может начать рендеринг страницы. Однако выполнение этой работы также требует некоторого времени обработки — в данном случае 66 миллисекунд. На это указывает оранжевый маркер задачи ЦП в каскадном представлении.
Теперь мы понимаем, почему FCP происходит через 632 миллисекунды:
- 364 миллисекунды для запроса документа HTML.
- 137 миллисекунд для загрузки таблиц стилей.
- 66 миллисекунд для рендеринга страницы.
- 65 миллисекунд для другой обработки.
Другая работа по обработке включает в себя небольшие задания, такие как запуск встроенных скриптов или анализ кода HTML и CSS после его загрузки. Вы можете увидеть это действие в виде маленьких серых линий прямо под диафильмом рендеринга.
Как оптимизировать первую содержательную отрисовку (FCP)
Теперь, когда вы понимаете, что приводит к отображению вашего веб-сайта, вы можете подумать о том, как его оптимизировать.
- Может ли сервер быстрее ответить на HTML-запрос?
- Можно ли загружать ресурсы по тому же соединению вместо создания нового?
- Есть ли запросы, которые можно удалить или изменить, чтобы они больше не блокировали рендеринг?
Теперь, когда начальные части вашего веб-сайта загружаются быстрее, пришло время сосредоточиться на том, чтобы ускорить загрузку всего сайта.
Как ускорить отрисовку с наибольшим содержанием (LCP) с помощью рекомендаций DebugBear
Есть много способов ускорить ваш LCP.
Чтобы упростить задачу, DebugBear дает нам отличные дальнейшие шаги в разделе рекомендаций.
Давайте рассмотрим несколько примеров рекомендаций и узнаем, как ускорить LCP этого веб-сайта.
Рекомендация 1. Инициировать запросы изображений LCP из HTML-документа
Если самым большим элементом контента на вашей странице является изображение, лучше всего убедиться, что URL-адрес непосредственно содержится в исходном HTML-документе. Это поможет начать загрузку как можно скорее.
Однако эта передовая практика используется не всегда, и иногда браузеру требуется много времени, прежде чем он обнаружит, что ему необходимо загрузить основное изображение.
В приведенном ниже примере самое большое содержимое, представляющее собой изображение, добавляется на страницу с помощью JavaScript. В результате браузер должен загрузить и запустить 200-килобайтный скрипт, прежде чем он обнаружит изображение и начнет его скачивать.
Как исправить: в зависимости от веб-сайта есть два возможных решения.
Решение 1. Если вы используете JavaScript для отложенной загрузки большого изображения, оптимизируйте размер изображения и удалите скрипт отложенной загрузки или замените его современным атрибутом loading=”lazy” , который не требует JavaScript.
Решение 2. В других случаях рендеринг на стороне сервера предотвратит загрузку приложения JavaScript перед рендерингом страницы. Однако иногда это может быть сложно реализовать.
Рекомендация 2. Убедитесь, что изображения LCP загружаются с высоким приоритетом
После загрузки HTML-кода страницы браузеры ваших посетителей могут обнаружить, что в дополнение к вашему основному изображению может потребоваться загрузка большого количества дополнительных ресурсов, таких как таблицы стилей.
Цель здесь состоит в том, чтобы убедиться, что ваша большая основная картинка загружается, чтобы выполнить требование Google о самой большой содержательной рисовании.
Другие ресурсы, такие как сторонние скрипты аналитики, не так важны, как ваше основное изображение.
Кроме того, большинство изображений, на которые есть ссылки в HTML-коде вашего сайта, после отображения страницы будут находиться в нижней части страницы. Некоторые могут быть полностью скрыты во вложенной навигации заголовка.
Из-за этого браузеры изначально устанавливают низкий приоритет для всех запросов изображений. После отображения страницы браузер определяет, какие изображения важны, и меняет приоритет. Вы можете увидеть пример этого на снимке экрана ниже, на что указывает звездочка в столбце приоритета.
Снимок экрана DebugBear, показывающий, как образ LCP загружается с низким начальным приоритетом, октябрь 2022 г.Водопад показывает, что, хотя браузер знал об изображении на ранней стадии, он не начал его загрузку, на что указывает серая полоса.
Как исправить: Чтобы решить эту проблему, вы можете использовать новую функцию браузера, называемую подсказками приоритета. Если вы добавите атрибут fetchpriority=»high» к элементу img, браузер начнет загружать изображение с самого начала.
Рекомендация 3: не скрывайте содержимое страницы с помощью CSS
Иногда вы можете посмотреть на водопад запросов, и все ресурсы, блокирующие рендеринг, загружены, но содержимое страницы все равно не отображается. В чем дело?
Инструменты A/B-тестирования часто скрывают содержимое страницы до тех пор, пока к элементам содержимого на странице не будут применены тестовые варианты. В этих случаях браузер отобразил страницу, но весь контент прозрачен.
Что делать, если вы не можете удалить инструмент A/B-тестирования?
Как исправить: проверьте, можете ли вы настроить инструмент так, чтобы скрывать только тот контент, на который повлияли A/B-тесты. В качестве альтернативы вы можете проверить, есть ли способ ускорить загрузку инструмента A/B-тестирования.
Снимок экрана DebugBear, показывающий диафильм рендеринга, где содержимое скрыто инструментом A/B-тестирования, октябрь 2022 г.Следите за скоростью вашего сайта с помощью DebugBear
Хотите постоянно тестировать свой сайт? Попробуйте наш платный инструмент мониторинга с бесплатной 14-дневной пробной версией .
Таким образом, вы можете проверить, работают ли ваши оптимизации производительности, и получать уведомления о любых регрессах производительности на вашем сайте.
Снимок экрана, показывающий тенденции скорости сайта в DebugBear, октябрь 2022 г.
