Лучшие инструменты для тестирования скорости сайта (плюс как ускорить ваш сайт)

Посмотрите на загрузку вашего сайта глазами посетителя

Получите хорошее представление о том, что ваши посетители на самом деле испытывают, когда они посещают ваш сайт.

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

Снимок экрана, показывающий результат веб-теста производительности DebugBear, октябрь 2022 г.

Диафильм временной шкалы показывает ход рендеринга веб-сайта с течением времени.

Например, эта страница начинает отображаться через 0,7 секунды, а основное изображение — через 1,3 секунды.

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

Снимок экрана DebugBear, показывающий ход рендеринга веб-сайта с течением времени, октябрь 2022 г.

В инструменте вы также можете посмотреть видеозапись процесса рендеринга.

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

Снимок экрана с видеозаписью частично отрендеренного веб-сайта в DebugBear, октябрь 2022 г.

Проверьте изменения скорости сайта, увидев истинную статистику загрузки

Допустим, вы оптимизировали свой веб-сайт и хотите понять, повлияют ли эти изменения.

Этот инструмент выполняет «лабораторный тест» в оптимальной среде, чтобы определить, правильно ли вы оптимизируете свой сайт.

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

1. Первая содержательная краска (10% от общей оценки).
2. Индекс скорости (10%).
3. Самая большая содержательная краска (25%).
4. Время до интерактивности (10%).
5. Общее время блокировки (30%).
6. Совокупный сдвиг макета (15%).

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

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

Как оптимизировать скорость сайта

Запуск теста скорости — это первая часть пути оптимизации вашего сайта.

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

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

• Первая содержательная отрисовка : это можно ускорить, восстановив скорость связи с сервером.
• Самая большая содержательная отрисовка : ее можно ускорить за счет оптимизации мультимедиа и ресурсов.

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

Как ускорить первую содержательную отрисовку (FCP)

Давайте начнем с того, что ваш веб-сайт появится раньше для ваших посетителей; сначала мы займемся First Contentful Paint.

Что такое первая содержательная краска?

First Contentful Paint измеряет, как скоро содержимое страницы начинает отображаться после того, как посетитель переходит на эту страницу.

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

Но как узнать, что именно вызывает медленную загрузку вашего сайта?

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

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

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

Звучит много, но есть простой способ увидеть, что именно замедляет работу FCP, — водопад запросов.

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

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

Снимок экрана, показывающий данные отладки для метрики First Contentful Paint в DebugBear, октябрь 2022 г.

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

Понимание того, что происходит перед первой содержательной отрисовкой

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

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

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

Загрузка страницы, часть 1: браузер создает соединение с сервером

Перед первым запросом веб-сайта с сервера браузер вашего посетителя должен установить сетевое соединение с этим сервером.

Обычно это занимает три шага:

1. Проверка записей DNS для поиска IP-адреса сервера на основе доменного имени.
2. Установление надежного соединения с сервером (известного как TCP-соединение).
3. Установка защищенного соединения с сервером (известного как соединение SSL).

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

В этом случае для установления соединения с сервером требуется около 251 миллисекунды.

Снимок экрана DebugBear, показывающий круговые поездки по сети, используемые для установления соединения с сервером, октябрь 2022 г.

Загрузка страницы, часть 2: браузер запрашивает HTML-документ (здесь отображается время до первого байта)

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

В этом случае HTTP-запрос занимает 102 миллисекунды. Эта продолжительность включает в себя как время, затраченное на передачу данных по сети, так и время, затраченное на ожидание ответа сервера.

Через 251 миллисекунду на создание соединения и 102 миллисекунды на выполнение HTTP-запроса браузер вашего посетителя, наконец, может начать загрузку HTML-ответа.

Эта веха называется временем до первого байта (TTFB). В данном случае это происходит через 353 миллисекунды.

После того, как ответ сервера готов, браузер вашего посетителя тратит дополнительное время на загрузку HTML-кода. В этом случае ответ довольно мал, а загрузка занимает всего 10 дополнительных миллисекунд.

Снимок экрана DebugBear, показывающий различные компоненты HTTP-запроса, октябрь 2022 г.

Загрузка страницы, часть 3: ваш сайт загружает дополнительные ресурсы, блокирующие рендеринг

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

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

Загрузка двух дополнительных таблиц стилей в этом примере теста скорости веб-сайта занимает 137 миллисекунд.

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

Снимок экрана DebugBear, на котором показаны дополнительные ресурсы, блокирующие рендеринг, загружаемые после HTML-документа, октябрь 2022 г.

Загрузка страницы, часть 4: браузер отображает страницу

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

Снимок экрана DebugBear, показывающий шаги, ведущие от загрузки HTML-документа к рендерингу веб-страницы, октябрь 2022 г.

Теперь мы понимаем, почему FCP происходит через 632 миллисекунды:

• 364 миллисекунды для запроса документа HTML.
• 137 миллисекунд для загрузки таблиц стилей.
• 66 миллисекунд для рендеринга страницы.
• 65 миллисекунд для другой обработки.

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

Как оптимизировать первую содержательную отрисовку (FCP)

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

• Может ли сервер быстрее ответить на HTML-запрос?
• Можно ли загружать ресурсы по тому же соединению вместо создания нового?
• Есть ли запросы, которые можно удалить или изменить, чтобы они больше не блокировали рендеринг?

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

Как ускорить отрисовку с наибольшим содержанием (LCP) с помощью рекомендаций DebugBear

Есть много способов ускорить LCP.

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

Давайте рассмотрим несколько примеров рекомендаций и узнаем, как ускорить LCP этого веб-сайта.

Рекомендация 1. Инициировать запросы изображений LCP из HTML-документа

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

Однако эта передовая практика используется не всегда, и иногда браузеру требуется много времени, прежде чем он обнаружит, что ему необходимо загрузить основное изображение.

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

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

Как исправить: в зависимости от веб-сайта есть два возможных решения.

Решение 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 г.