Основные веб-жизненные показатели для корпоративного бизнеса: вопросы и ответы с Кэти Браун и Карлом Кляйншмидтом

Основные веб-жизненные показатели для корпоративного бизнеса: вопросы и ответы с нашими Кэти Браун и Карлом Кляйншмидтом

18 февраля мы провели сессию Core Web Vitals для корпоративного бизнеса, посвященную новому обновлению фактора ранжирования Page Experience от Google. Сессия была посвящена тому, что такое Core Web Vitals и почему они важны. Наши эксперты подробно изучили, что означает каждый из новых сигналов ранжирования и как они повлияют на SEO. Несмотря на то, что мы предоставили практические советы и рекомендации, оставалось много вопросов, касающихся FID, LCP, CLS и т. д.

Ниже приведены вопросы, собранные нашей аудиторией, на которые отвечают наши эксперты Кэти и Карл.

В чем разница между полевыми и лабораторными данными?

Кэти : Лабораторные данные — это данные о производительности, которые вы видите в определенной среде. Такие инструменты, как Chrome Dev Tools, а также такие инструменты, как webpagetest.org, предоставляют вам лабораторные данные. Полевые данные — это данные, собранные от многих пользователей, которые используют Chrome для просмотра страниц вашего сайта. Вы можете увидеть данные поля в Google Search Console и часто в Google Page Speed ​​Insights (который будет сообщать как лабораторные, так и полевые данные для страницы). Для нужд автоматизации полевые данные доступны через BigQuery. Помните, что лабораторные данные предназначены для тестирования, а полевые данные — для ранжирования. Основываясь на комментариях Джона Мюллера, мы ожидаем, что первоначально CWV повлияет только на ранжирование мобильных устройств и что вам нужно будет быть «в зеленой зоне», чтобы все три показателя занимали более высокие позиции.

Что вы делаете, когда нет доступных полевых данных?

Кэти : Если данные о полях недоступны, это, вероятно, означает, что страница не получает много трафика. Используйте Google Page Speed ​​Insights, чтобы проверить свои самые популярные страницы и узнать, доступны ли для них данные полей. Затем вы можете экстраполировать результаты для всех ваших страниц, принадлежащих к этому типу страниц. Попробуйте настроить отчет CrUX, чтобы узнать, есть ли он для вашего источника (вашего домена). Вы можете найти готовый шаблон Google Data Studio, и это даст вам данные о производительности вашего сайта в целом.

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

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

Кэти: Значительная часть оценки Core Web Vital будет зависеть от клиента и кода, который он выполняет. Таким образом, плохая оценка CLS не имеет ничего общего с медленным сервером. Однако на LCP может повлиять медленный сервер из-за более медленных подтверждений соединения и времени, необходимого для отправки ресурсов. Один из подходов, который следует рассмотреть, — это сравнение серверов по таким показателям, как TTFB (время до первого байта) для различных страниц, а также сравнение времени доставки каждого 1 КБ данных. Кроме того, если у вас есть операции с базой данных или JS на стороне сервера, также было бы полезно знать разницу между временем выполнения на каждом сервере. Сравните каскадные диаграммы между ними и посмотрите, сколько дополнительного времени ожидания есть в среде разработки. Знание этих различий поможет легче оценить производительность LCP на вашем сервере разработки.

Считаете ли вы, что предварительная загрузка ссылок (для последующих страниц) повлияет на LCP ИЛИ вы думаете, что LCP зависит только от первой страницы, которую загружает пользователь?

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

Может ли CDN с хорошей оптимизацией кеша значительно снизить показатель LCP?

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

Как использовать всплывающие окна, чтобы они не влияли на Core Web Vitals?

Карл: При проблемах с LCP убедитесь, что всплывающие окна не занимают слишком большой процент области просмотра, особенно на мобильных устройствах.

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

Как мы должны думать о CWV в контексте мобильной индексации?

Карл: CWV будет выпущен для мобильных устройств и отложен для настольных компьютеров (мы не знаем, насколько). CWV на самом деле не о том, как Google сканирует ваш сайт, а о том, как посетители взаимодействуют с вашим сайтом, поэтому индексация для мобильных устройств не должна иметь значения.

В чем разница между общим временем блокировки (TBT) и FID?

Карл: Общее время блокировки — это общее количество миллисекунд, в течение которых задачи блокировки основного потока блокируют взаимодействие (100 мс вычитается на задачу). FID — это среднее время, которое требуется вашему веб-сайту, чтобы реагировать на действия посетителей. Таким образом, общее время блокировки — это общее количество миллисекунд при загрузке страницы, когда FID может быть выше 0, в то время как FID фиксирует, как пользователи на самом деле взаимодействуют с вашим сайтом.

Мы видим изменения оценок в Google Search Console без внесения изменений/улучшений с нашей стороны.

Что может быть причиной этих колебаний в поисковой консоли?

Карл: Для Search Console это поле данных, оно зависит от того, как пользователи взаимодействуют с вашим сайтом. Изменения в поведении пользователей могут означать разные оценки CLS, потому что посетители по-разному прокручивают страницу, или разные оценки LCP, потому что более высокий процент посетителей возвращаются к клиентам, поэтому у них кэшируются определенные изображения. Существует множество возможных причин колебаний показателей, и помните, что данные задерживаются примерно на 28 дней, поэтому вы могли что-то выпустить 28 дней назад и теперь видите изменения в данных.

Если кто-то получает разные результаты из Search Console и PageSpeedTest, должны ли мы беспокоиться только о том, что сообщается в Search Console?

Карл: Помимо полевых и лабораторных данных, есть две основные причины различий в данных между консолью поиска и данными о скорости страницы. Если одна из ваших страниц не получила достаточно трафика, Google использует данные о похожих страницах в анализе скорости страницы, а в консоли поиска группирует похожие страницы, для которых может быть достаточно данных. Поэтому также возможно, что на одной из ваших страниц достаточно трафика, но ни на одной из похожих страниц нет достаточного трафика, что также может привести к разнице в оценках. Также было обновление для отчетов в поисковой консоли, которое могло повлиять.

Нужны дополнительные ресурсы?

У нас есть много отличного контента на эту тему. Посетите нашу страницу Core Web Vitals, где мы собрали библиотеку экспертных ресурсов, таких как подкасты, вебинары и блоги. Вы можете найти все необходимое, чтобы подготовиться к обновлению фактора ранжирования Google Page Experience.