Барри Поллард из Google Chrome объяснил 5 советов по оптимизации для Largest Contentful Paint. Каждый SEO должен прочитать это.
Барри Поллард, защитник Google Chrome Web Performance Developer Advocate, объяснил, как найти истинные причины плохого результата Lowest Contentful Paint и как их исправить.
Рисирование наибольшего содержимого (LCP)
LCP – это основной показатель веб-показателей, который измеряет, сколько времени требуется, чтобы наибольший элемент содержимого отобразился в окне просмотра посетителей сайта (часть, которую пользователь видит в браузере). Элемент содержимого может быть изображением или текстом.
Для LCP наибольшими элементами содержимого являются элементы HTML на уровне блоков, занимающих наибольшее пространство по горизонтали, как абзац Барри Поллард писал, что распространенной ошибкой издателей и поисковиков после того, как увидят, что PageSpeed Insights (PSI) обозначает страницу как низкую оценку LCP, является устранение проблемы в инструменте Lighthouse или с помощью Chrome Dev Tools . Поллард рекомендует придерживаться PSI, поскольку он предлагает многочисленные подсказки для понимания проблем, вызывающих низкую производительность LCP. Важно понимать, какие данные предоставляет вам PSI, в частности данные, полученные из отчета о взаимодействии с пользователем Chrome (CrUX), полученные по анонимным оценкам посетителей Chrome. Есть два вида: <ол> Оценки на уровне URL-адреса – это показатели для настраиваемой конкретной страницы. Данные уровня происхождения – это совокупные баллы со всего сайта. PSI будет отображать данные на уровне URL, если до URL-адреса было достаточно измеренного трафика. В противном случае он будет отображать данные уровня происхождения (совокупный балл для всего сайта). Барри рекомендует взглянуть на показатель TTFB (время до первого байта), поскольку, по его словам, “TTFB — это первая вещь, которая происходит с вашей страницей.”< /p> Байт — это наименьшая единица цифровых данных для представления текста, чисел или мультимедиа. TTFB сообщает вам, сколько времени понадобилось серверу для ответа первого байта, показывая, является ли время ответа сервера причиной низкой производительности LCP. Он говорит, что сосредоточение усилий на оптимизации веб-страницы никогда не решит проблему, корнями которой является плохой TTFB. Барри Поллард пишет: “Медленный TTFB в основном означает 1 из 2 вещей: 1) Задолго посылается запрос на ваш сервер Но что это такое (и почему!) может быть трудно выяснить, и для каждой из этих категорий есть несколько возможных причин.~~~~~~~~~~~~ blockquote> Барри продолжил свой обзор отладки LCP с помощью конкретных тестов, которые описаны ниже. Поллард рекомендует тестировать с помощью лабораторных тестов Lighthouse, в частности “Начального времени ответа сервера” аудит. Цель состоит в том, чтобы проверить, повторяется ли проблема TTFB, чтобы устранить возможность того, что значение PSI является случайностью. Результаты лаборатории являются синтетическими, не основываются на фактических посещениях пользователей. Синтетический означает, что они имитируются алгоритмом на основе посещения, инициированного тестом Lighthouse. Синтетические тесты полезны, поскольку они повторяются и позволяют пользователю выделить конкретную причину проблемы. Если тест Lighthouse Lab’ проблему, это означает, что проблема не в сервере. Он посоветовал: “Ключевой вещью здесь является проверка повторяемости медленного TTFB. Прокрутите вниз и посмотрите, совпал ли лабораторный тест Lighthouse с этим медленным TTFB реального пользователя во время проверки страницы. Найдите “Начальное время ответа сервера” аудит. В этом случае это было гораздо быстрее – это’интересно!” Барри дал замечательный совет относительно сетей доставки содержимого (CDN), таких как Cloudflare. CDN сохраняет копию веб-страницы в центрах обработки данных, что ускорит доставку веб-страниц, но также маскирует любые основные проблемы на уровне сервера. CDN’не сохраняет копию в каждом центре обработки данных во всем мире. Когда пользователь запрашивает веб-страницу, CDN получит эту веб-страницу с сервера, а затем сделает ее копию на сервере, который ближе к этим пользователям. Таким образом, первая выборка всегда медленнее, но если сервер работает медленно, то первая выборка будет даже медленнее, чем доставка веб-страницы непосредственно с сервера. Барри предлагает следующие приемы, чтобы обойти кэш CDN : Он также предлагает инструмент, который можно использовать для тестирования отдельных стран: “Также можно проверить, являются ли именно страны медленными в частности, если вы’не используете CDN— с CrUX и @alekseykulikov.bsky.social ‘s Treo является одним из лучших инструментов для этого с. Вы можете запустить бесплатный тест здесь: treo.sh/sitespeed, прокрутите вниз к карте и перейдите на TTFB. Если некоторые страны имеют медленные TTFB, проверьте, сколько трафика поступает из этих стран. Из соображений конфиденциальности CrUX не показывает объемы трафика (кроме случаев, когда он имеет достаточный трафик для отображения), поэтому для этого вам нужно будет просмотреть свою аналитику. ~ Что касается медленного соединения с определенными географическими регионами, Полезно понимать, что низкая производительность в некоторых развивающихся странах может быть вызвана популярностью недорогих мобильных устройств. Следует повторить, что CrUX не раскрывает, из каких стран исходят плохие оценки, а это означает привлечение Analytics, чтобы помочь определить страны с медленным трафиком. Барри завершил свою дискуссию, посоветовав, что проблему можно решить только после проверки ее повторяемости. Он посоветовал: “Что касается проблем с сервером, или недостаточная мощность сервера? Или код слишком сложный/неэффективный? Или база данных требует настройки? Для медленного подключения с некоторых мест вам нужен CDN? Или исследовайте, почему так много трафика оттуда (рекламная кампания?) Если ни один из них не выделяется, это может быть из-за перенаправления, в частности из рекламы. Они могут добавить ~0,5 с к TTFB – за перенаправление! Попробуйте уменьшить перенаправление как можно больше: Барри Поллард из Google Chrome&rsquo дал пять важных советов. 1. Данные PageSpeed Insights (PSI) могут предоставить подсказки для устранения проблем с LCP, а также другие нюансы, рассмотренные в этой статье, которые помогают понять данные. 2. Данные PSI TTFB (время до первого байта) могут указывать на то, почему страница имеет низкие показатели LCP. 3. Лабораторные тесты Lighthouse полезны для отладки, поскольку результаты повторяются. Повторяющиеся результаты являются ключевыми для точного определения источника проблем LCP, что затем позволяет применять правильные решения. 4. CDN могут маскировать истинную причину проблем с LCP. Используйте трюк Барри, описанный выше, чтобы обойти CDN и получить настоящие лабораторные результаты, которые могут быть полезны для отладки. 5. Барри перечислил шесть потенциальных причин плохих результатов LCP:1. Знайте, какие данные вы ищете
2. Просмотрите оценку TTFB
2) Ваш сервер слишком долго соответствует3. Сравните TTFB с лабораторным тестом Lighthouse
4. Совет эксперта: как проверить, скрывает ли CDN проблему
5. Исправить то, что можно повторить
– Используйте правильный конечный URL, чтобы избежать необходимости перенаправлять на www или https.
– Избегайте нескольких служб сокращения URL-адресов.&aa;60~/p>Выводы: как оптимизировать для рисования наибольшего содержимого