Барри Поллард, защитник веб-производительности Google Chrome, объяснил, как найти реальные причины плохой оценки Contentful Paint и как их исправить. Самая большая содержательная краска (LCP) LCP — это основной показатель веб-жизненной активности, который измеряет, сколько времени требуется для отображения самого большого элемента контента в области просмотра посетителей сайта (той части, которую пользователь видит в браузере).
Элементом контента может быть изображение или текст. Для LCP самыми большими элементами контента являются HTML-элементы блочного уровня, которые занимают наибольшее пространство по горизонтали, например абзац, заголовки (H1–H6) и изображения (в основном большинство HTML-элементов, занимающих большой объем). горизонтального пространства).
1. Знайте, какие данные вы просматриваете
Барри Поллард написал, что распространенная ошибка, которую допускают издатели и оптимизаторы, увидев, что PageSpeed Insights (PSI) помечает страницу с плохой оценкой LCP, заключается в отладке проблемы с помощью инструмента Lighthouse или инструментов разработчика Chrome.
Поллард рекомендует придерживаться PSI, поскольку он предлагает множество подсказок для понимания проблем, вызывающих плохую производительность LCP. Важно понимать, какие данные предоставляет вам PSI, особенно данные, полученные из отчета об опыте пользователей Chrome (CrUX), который основан на анонимных оценках посетителей Chrome. Есть два вида:
- Данные уровня URL-адреса
- Данные исходного уровня
Оценки на уровне URL-адреса относятся к конкретной странице, которая отлаживается. Данные уровня происхождения — это совокупные оценки со всего веб-сайта. PSI покажет данные на уровне URL-адреса, если на URL-адрес было получено достаточно трафика. В противном случае будут показаны данные уровня источника (агрегированная оценка по всему сайту).
2. Просмотрите оценку TTFB
Барри рекомендует обратить внимание на показатель TTFB (время до первого байта), потому что, по его словам, «TTFB — это первое, что происходит с вашей страницей». Байт — это наименьшая единица цифровых данных для представления текста, чисел или мультимедиа. TTFB сообщает вам, сколько времени потребовалось серверу, чтобы ответить первым байтом, и показывает, является ли время ответа сервера причиной плохой производительности LCP.
Он говорит, что сосредоточение усилий на оптимизации веб-страницы никогда не решит проблему, коренящуюся в плохом TTFB. Барри Поллард пишет: «Медленный TTFB по сути означает одну из двух вещей:
1) Отправка запроса на ваш сервер занимает слишком много времени.
2) Ваш сервер слишком долго отвечает.
Но что это такое (и почему!) бывает сложно понять, и для каждой из этих категорий есть несколько возможных причин». Барри продолжил свой обзор отладки LCP конкретными тестами, которые описаны ниже.
3. Сравните TTFB с лабораторным тестом Lighthouse
Поллард рекомендует проводить тестирование с помощью лабораторных тестов Lighthouse, в частности, аудита «Первоначальное время ответа сервера». Цель состоит в том, чтобы проверить, повторяется ли проблема с TTFB, чтобы исключить вероятность того, что значения PSI являются случайностью.
Результаты лабораторных исследований являются синтетическими и не основаны на реальных посещениях пользователей. Синтетический означает, что они моделируются с помощью алгоритма, основанного на посещении, инициированном тестом Lighthouse. Синтетические тесты полезны, поскольку они повторяемы и позволяют пользователю изолировать конкретную причину проблемы.
Если лабораторный тест Lighthouse не воспроизводит проблему, это означает, что проблема не в сервере. Он посоветовал: «Ключевым моментом здесь является проверка повторяемости медленного TTFB. Итак, прокрутите вниз и посмотрите, соответствует ли лабораторный тест Lighthouse этому медленному TTFB реального пользователя при тестировании страницы. Найдите аудит «Начальное время ответа сервера». В данном случае это произошло гораздо быстрее – это интересно!»
4. Совет эксперта: как проверить, не скрывает ли CDN проблему
Барри дал отличный совет о сетях доставки контента (CDN), таких как Cloudflare. CDN будет хранить копию веб-страницы в центрах обработки данных, что ускорит доставку веб-страниц, но также замаскирует любые основные проблемы на уровне сервера. CDN не хранит копии в каждом центре обработки данных по всему миру. Когда пользователь запрашивает веб-страницу, CDN получит эту веб-страницу с сервера, а затем сделает ее копию на том сервере, который ближе к этим пользователям.
Таким образом, первая выборка всегда медленнее, но если сервер изначально работает медленно, то первая выборка будет даже медленнее, чем доставка веб-страницы прямо с сервера. Барри предлагает следующие способы обхода кеша CDN: Проверьте медленную страницу, добавив параметр URL-адреса (например, добавив «?XYZ» в конец URL-адреса). Протестируйте страницу, которая обычно не запрашивается.
Он также предлагает инструмент, который можно использовать для тестирования конкретных стран: «Вы также можете проверить, есть ли медленные страны, особенно если вы не используете CDN, с помощью CrUX, а Treo @alekseykulikov.bsky.social — один из лучших инструментов для этого. Вы можете запустить бесплатный тест здесь: treo.sh/sitespeed, прокрутить вниз до карты и переключиться на TTFB. Если в определенных странах медленные TTFB, проверьте, какой объем трафика поступает из этих стран. По соображениям конфиденциальности CrUX не показывает вам объемы трафика (за исключением случаев, когда у него достаточно трафика для отображения), поэтому для этого вам нужно будет просмотреть свою аналитику».
Что касается медленных соединений из определенных географических регионов, полезно понимать, что низкая производительность в некоторых развивающихся странах может быть связана с популярностью недорогих мобильных устройств. И стоит повторить, что CruX не раскрывает, из каких стран поступают плохие оценки, а это означает использование аналитики, чтобы помочь идентифицировать страны с медленным трафиком.
5. Исправьте то, что можно повторить
Барри завершил свое обсуждение, сообщив, что проблему можно исправить только после того, как будет проверено, что она повторяется. Он посоветовал: «Что касается проблем с сервером, недостаточно ли у него мощности? Или код слишком сложен/неэффективен? Или база данных требует настройки? Нужен ли CDN для медленных соединений из некоторых мест?
Или разобраться, почему оттуда столько трафика (рекламной кампании?) Если ничего из этого не выделяется, возможно, это связано с перенаправлениями, особенно с рекламы. Они могут добавлять ~0,5 секунды к TTFB – за перенаправление! Постарайтесь максимально сократить количество перенаправлений: – Используйте правильный конечный URL-адрес, чтобы избежать необходимости перенаправления на www или https. – Избегайте использования нескольких сервисов сокращения URL-адресов».
Выводы: как оптимизировать рисование с наибольшим содержанием
Барри Поллард из Google Chrome предложил пять важных советов.
1. Данные PageSpeed Insights (PSI) могут помочь в устранении проблем LCP, а также других нюансов, обсуждаемых в этой статье, которые помогают разобраться в данных.
2. Данные PSI TTFB (время до первого байта) могут указывать на то, почему страница имеет низкие оценки LCP.
3. Лабораторные тесты Lighthouse полезны для отладки, поскольку результаты повторяемы. Воспроизводимые результаты являются ключом к точному выявлению источника проблем LCP, что позволяет затем применить правильные решения.
4. CDN могут маскировать истинную причину проблем LCP. Используйте описанный выше трюк Барри, чтобы обойти CDN и получить истинную лабораторную оценку, которая может быть полезна для отладки.
5. Барри перечислил шесть потенциальных причин плохих показателей LCP: Производительность сервера перенаправляет код база данных Медленные соединения из-за географического положения. Медленные соединения из определенных областей, вызванные определенными причинами, такими как рекламные кампании.