Быстрая загрузка веб-сайта обеспечивает удобство использования и помогает повысить коэффициент конверсии. Google также недавно обновил свою документацию, чтобы подтвердить, что Core Web Vitals используются ее системами ранжирования.

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

1. Проанализируйте водопад сетевых запросов для вашего сайта

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

Какие ресурсы скачиваются?

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

Как это соотносится с тем, что видят посетители во время загрузки сайта?

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

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

Чтобы интерпретировать водопад, обратите внимание на три ключевых этапа в процессе загрузки веб-сайта:

Время до первого байта (TTFB): сколько времени требуется серверу веб-сайта, чтобы вернуть HTML-документ?

Первая отрисовка контента (FCP). Когда содержимое первой страницы становится видимым?

Самая большая отрисовка контента (LCP): когда становится видимым самый большой элемент контента?

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

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

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

Чтобы оптимизировать FCP, вы можете:

Полностью удалите ресурсы, блокирующие рендеринг.

Уменьшите размер загружаемых файлов CSS.

Загружайте сценарии блокировки рендеринга асинхронно.

Ускорьте сами запросы ресурсов.

Например, в приведенном выше примере мы видим, что размер файла app.css превышает 100 килобайт. Загрузка может занять некоторое время, особенно при медленном мобильном соединении.

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

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

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

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

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

2. Сначала загружайте самый важный контент

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

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

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

Чтобы обеспечить приоритетность образа LCP, вы можете:

Убедитесь, что он не загружается отложенно.

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

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

3. Уменьшите размер загрузки ключевых ранних запросов

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

Например, на этом снимке экрана показан большой файл CSS:

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

Чтобы уменьшить размер файла, вы можете:

Используйте современные форматы изображений, такие как WebP и Avif.

Используйте сжатие Brotli для текстового контента (например, HTML, CSS и JavaScript).

Проанализируйте свой код HTML или CSS, чтобы идентифицировать встроенные изображения, шрифты и данные.

4. Сравните реальные пользовательские данные с лабораторными данными

Google предоставляет реальные данные пользователей для большинства веб-сайтов в рамках своего инструмента PageSpeed ​​Insights. Сравнение этих данных с результатами лабораторного теста Lighthouse может помочь вам лучше понять, что происходит на вашем веб-сайте.

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

Две распространенные причины, по которым результаты лабораторных испытаний опережают реальные пользовательские данные:

Тест PageSpeed ​​Insights выдает недостоверные данные.

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

5. Посмотрите, как эффективность вашего сайта изменилась с течением времени

Набор реальных пользовательских данных, который Google предоставляет на основе отчета об опыте пользователей Chrome (CrUX), также включает исторические данные, хотя они не отображаются в PageSpeed ​​Insights. Наблюдение за тем, как производительность вашего веб-сайта менялась с течением времени, позволяет увидеть, когда возникла проблема, и определить ее основную причину.

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

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

6. Настройте постоянный мониторинг скорости сайта

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

DebugBear – это служба мониторинга, которая обеспечивает два типа мониторинга:

Лабораторное тестирование. Тестирование скорости страницы можно проводить по расписанию в контролируемой лабораторной среде.

Мониторинг реальных пользователей. Узнайте, как посетители воспринимают ваш сайт.

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

7. Посмотрите на показатели помимо времени загрузки

Производительность веб-сайта – это не только начальная скорость загрузки, измеряемая показателем LCP. Google также учитывает, насколько быстро веб-сайт реагирует на взаимодействие с пользователем, что измеряется показателем «Взаимодействие с следующей отрисовкой» (INP), который 12 марта стал основным веб-важным показателем.

Хотя LCP в основном зависит от того, что загружается по сети, INP учитывает обработку ЦП и то, сколько времени требуется, прежде чем страница сможет обработать взаимодействие и обновить пользовательский интерфейс, чтобы быть готовым к следующему взаимодействию.

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

Чтобы улучшить взаимодействие с Next Paint, вам нужны реальные данные мониторинга пользователей (RUM). Эти данные могут рассказать вам:

На каких страницах INP медленный?

С какими элементами взаимодействуют пользователи?

Какие сценарии способствуют задержкам?

Заключение

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

Инструмент мониторинга веб-сайта помогает вам отслеживать основные веб-показатели с течением времени и получать уведомления о регрессах. Вы можете начать бесплатную 14-дневную пробную версию DebugBear здесь.

Анонсы наших новых статей в Телеграме

Read More