Частный SEO оптимизатор

Google советует, как улучшить показатель LCP в Core Web Vitals

Барри Поллард из команды Google Chrome представил 5 ключевых рекомендаций по оптимизации Largest Contentful Paint (LCP), одного из основных показателей Core Web Vitals. Эти советы будут полезны каждому SEO-специалисту, стремящемуся улучшить производительность сайта.

Барри Поллард, разработчик и специалист по веб-производительности Google Chrome, объяснил, как найти истинные причины низкого показателя Lowest Contentful Paint и как их исправить.

Largest Contentful Paint (LCP)

LCP — это метрика Core Web Vitals, которая измеряет, сколько времени требуется для отображения самого большого элемента содержимого в области просмотра посетителя сайта (той части, которую пользователь видит в браузере). Элементом содержимого может быть изображение или текст.

Как оптимизировать Largest Contentful Paint (LCP)

Для LCP самыми крупными элементами содержимого являются блочные HTML-элементы, которые занимают наибольшее пространство по горизонтали, например: абзацы <p>, заголовки (H1 – H6) и изображения <img> (по сути, большинство HTML-элементов, которые занимают значительную часть горизонтального пространства).

1. Понимайте, с какими данными вы работаете

Барри Поллард отметил, что одной из распространенных ошибок, которые совершают издатели и SEO-специалисты после того, как PageSpeed Insights (PSI) указывает на низкий показатель LCP, является попытка устранить проблему в инструменте Lighthouse или через Chrome Dev Tools.

Поллард рекомендует оставаться в PSI, так как этот инструмент предоставляет множество подсказок для понимания причин низкой производительности LCP.

Очень важно понять, какие данные предоставляет PSI, особенно данные, полученные из Chrome User Experience Report (CrUX), которые основаны на анонимных показателях посетителей Chrome. Существует два типа данных:

  • Данные на уровне URL
  • Данные на уровне источника (Origin-Level Data)

Данные на уровне URL относятся к конкретной странице, которая анализируется. Данные на уровне источника представляют собой агрегированные показатели всего сайта.

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

Контактная форма

    2. Проверьте показатель TTFB

    Барри Поллард рекомендует обратить внимание на показатель TTFB (Time to First Byte), так как, по его словам, «TTFB — это первое, что происходит с вашей страницей».

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

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

    Барри Поллард пишет:

    «Медленный TTFB, по сути, означает одно из двух:

    1. Слишком много времени уходит на отправку запроса на ваш сервер
    2. Ваш сервер слишком долго отвечает

    Но определить, что именно (и почему!), может быть сложно, так как для каждой из этих категорий существует несколько возможных причин».

    Поллард продолжил обзор отладки LCP, предоставив конкретные тесты, которые описаны далее.

    3. Сравните TTFB с тестом Lighthouse Lab

    Поллард рекомендует проводить тесты с помощью Lighthouse Lab Tests, особенно проверку Initial server response time (время начального ответа сервера). Цель теста — проверить, повторяется ли проблема с TTFB, чтобы исключить возможность того, что значения PSI отображают более быструю скорость, чем та, с которой сталкивается большинство пользователей.

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

    Синтетические тесты полезны, так как они повторяемы и позволяют изолировать конкретную причину проблемы.

    Если тест Lighthouse Lab не воспроизводит проблему, это означает, что он не зафиксировал тех же проблем с TTFB, с которыми сталкиваются реальные пользователи.

    Поллард советует:

    «Ключевой момент здесь — проверить, повторяется ли медленный TTFB. Пролистайте вниз и посмотрите, совпадают ли данные лабораторного теста Lighthouse с медленным TTFB реальных пользователей при тестировании страницы. Обратите внимание на проверку “Initial server response time”.

    4. Совет эксперта: как проверить, не скрывает ли CDN проблему

    Барри поделился отличным советом о проверке Content Delivery Networks (CDNs), таких как Cloudflare. CDN хранит копию веб-страницы в своих дата-центрах, что ускоряет её доставку, но также может скрыть проблемы, связанные с сервером.

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

    Барри предлагает следующие приемы, чтобы обойти кэш CDN:

    • Протестируйте медленную страницу, добавив параметр к URL (например, ?XYZ в конец URL).
    • Протестируйте страницу, которую редко запрашивают.

    Также он рекомендует инструмент для тестирования производительности в разных странах:

    «Вы можете проверить, есть ли проблемы с определёнными странами (особенно если вы не используете CDN) с помощью CrUX и инструмента Treo от @alekseykulikov.bsky.social — это один из лучших инструментов для таких проверок.

    Вы можете запустить бесплатный тест здесь: treo.sh/sitespeed. Пролистайте вниз до карты и переключитесь на метрику TTFB.

    Если в определённых странах TTFB медленный, проверьте, сколько трафика идёт из этих стран. По соображениям конфиденциальности CrUX не показывает объёмы трафика (кроме случаев, когда его достаточно для отображения), поэтому вам придётся использовать аналитику для этой проверки».

    Учитывайте особенности медленных подключений

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

    5. Исправляйте только подтверждённые проблемы

    Барри завершил свою речь советом: проблему можно исправить только после того, как её повторяемость будет подтверждена.

    Он рекомендует:

    «Что касается серверных проблем, то стоит задать себе несколько вопросов:

    • Достаточно ли мощности у сервера?
    • Слишком ли сложен или неэффективен код?
    • Требует ли база данных оптимизации?

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

    Если ничего из этого не выявлено, то проблема может быть вызвана перенаправлениями, особенно от рекламы. Перенаправления могут увеличивать TTFB примерно на 0,5 секунды за каждое перенаправление!

    Как минимизировать перенаправления

    Барри советует:

    • Используйте правильный финальный URL, чтобы избежать перенаправлений на www или https.
    • Избегайте использования нескольких сервисов сокращения ссылок.

    Выводы: как оптимизировать Largest Contentful Paint (LCP)

    Барри Поллард из Google Chrome выделил пять ключевых советов:

    • Данные PageSpeed Insights (PSI)
      PSI предоставляет подсказки для поиска и устранения проблем с LCP, а также содержит нюансы, которые помогают лучше понять данные.
    • Показатель Time to First Byte (TTFB)
      Данные о TTFB в PSI могут указать на причину низких оценок LCP.
    • Тесты Lighthouse
      Лабораторные тесты Lighthouse полезны для диагностики, поскольку их результаты повторяемы. Повторяемые результаты — ключ к точному выявлению источника проблем с LCP и применению правильных решений.
    • CDN может скрывать причины проблем с LCP
      Используйте приёмы, описанные Барри, чтобы обойти кэш CDN и получить корректный результат лабораторных тестов, который будет полезен для устранения проблем.
    • Шесть возможных причин низких оценок LCP:
      • Производительность сервера
      • Перенаправления
      • Код
      • База данных
      • Медленные подключения в определённых географических регионах
      • Медленные подключения из-за специфических причин, например, рекламных кампаний

    Подробнее о LCP: прочитайте пост Барри на Bluesky.

    Мы используем файлы cookie для анализа событий на нашем сайте. Продолжая просмотр сайта, вы принимаете условия использования