Пошаговый процесс выявления проблем и определения приоритетов исправлений перед обновлением интерфейса страницы. Еще в мае 2020 года Google объявила, что основные веб-Виталы станут частью алгоритмов Google в 2021году , но сказала владельцам сайтов, что “нет никакой непосредственной необходимости принимать меры.” К ноябрю 2020 года Google сообщила, что это обновление вступит в силу в мае 2021 года, поэтому для владельцев сайтов и СЕО по всему миру настало время принять меры по метко названному обновлению Page Experience.
Основные веб-показатели-это набор показателей, используемых для измерения загрузки веб-сайта, интерактивности и визуальной стабильности. Все три так или иначе связаны со скоростью сайта, что, как мы знаем, было важно как для поисковых систем, так и для пользователей в течение очень долгого времени.
Что действительно интересно в Core Web Vitals, и обновление опыта страницы в частности, заключается в том, что Google не часто очень откровенен со спецификой своих обновлений алгоритмов. Но в этом случае нам были даны точные показатели, которые нам нужно измерить и улучшить, и дата, когда это обновление вступит в силу. Это указывает на то, что опыт работы с страницами, безусловно, будет важным обновлением, но также и тем, к которому мы действительно можем подготовиться, если процесс аудита детализирован и точен.
LCP- измеряет производительность загрузки (т. е. сколько времени требуется для загрузки самого большого элемента в окне просмотра). Чтобы обеспечить хороший пользовательский опыт, LCP должен происходить в течение 2,5 секунд с момента первой загрузки страницы или максимум 4 секунд, чтобы избежать “плохого” результата (хотя между 2,5 и 4 секундами все еще “нуждается в улучшении”).
FID- измеряет интерактивность (то есть, сколько времени требуется веб-сайту, чтобы ответить, когда пользователь нажимает на что-то). Чтобы обеспечить хороший пользовательский опыт, страницы должны иметь FID менее 100 миллисекунд или максимум 300 миллисекунд, чтобы избежать “плохого” результата (хотя между 100 и 300 миллисекундами все еще “нуждается в улучшении”).
В процессе аудита, подробно описанном в этой статье, используется аналогичная метрика “Общее время блокировки (ТБТ)”, поскольку для первой задержки ввода требуются полевые данные, но в этом аудите используются лабораторные данные, поскольку полевые данные не всегда могут быть доступны для проверяемого веб-сайта.
CLS- измеряет визуальную стабильность (т. е. независимо от того, прыгает ли страница по мере прокрутки содержимого пользователем). Чтобы обеспечить хороший пользовательский опыт, страницы должны поддерживать CLS менее 0,1 или минимум 0,25, чтобы избежать “плохого” балла (хотя между 0,1 и 0,25 все еще “нуждается в улучшении”).
Этот аудит фокусируется на показателях с “плохим” баллом, поскольку они будут основными приоритетными областями, но вы можете настроить его так, чтобы он также включал “потребности в улучшении”. Итак, теперь мы знаем, что мы проводим аудит, давайте перейдем к самому процессу аудита.
Знать, что такое основные веб-показатели, - это одно, но найти способ аудита и доведения основных веб-показателей до сведения клиентов полезным и действенным способом-это задача, с которой сталкиваются оптимизаторы по всему миру. Процесс аудита, который Мы собрали, предназначен для предоставления реальных деталей, примеров и данных для работы при решении основных проблем веб-Виталий.
Чтобы начать аудит, вам понадобятся три вещи:
Во-первых, вам нужно будет подключить свой API-ключ PageSpeed Insights к Screaming Frog. Это позволит вам получать доступ к данным PageSpeed Insights и рекомендациям постранично. Вы получите только ограниченное количество запросов PageSpeed Insights (около 25 000 в день), которых должно быть достаточно для небольших сайтов, но для больших сайтов вы сможете применить знания со страниц, на которые вы получаете запросы, к остальной части сайта.
После подключения нажмите на кнопку " метрики.” Здесь вы определите метрики, которые будут отображаться в вашем обходе контента. Для целей этого аудита выбираем “все метрические группы”, но вы можете выбрать только те, по которым вы хотите отчитаться, и нажать “OK.”
Доступны следующие группы метрик:
Затем вам нужно будет начать свой обход. Скопируйте домен веб-сайта, который вы просматриваете, и вставьте его в поле в верхней части сканера с надписью “введите URL-адрес для spider.” По мере обхода сайта вы заметите, что в правом верхнем углу есть индикатор выполнения “обхода” и “API”. Вам нужно будет подождать, пока оба эти показателя достигнут 100%, прежде чем вы начнете анализировать свои данные.
Прежде чем вы перейдете к конкретике того, что нужно исправить, первым шагом будет сообщить о масштабах проблемы. Чтобы сделать это, вам нужно посмотреть, какой процент страниц терпит неудачу в каждом ядре веб-виталов минимальных пороговых значений. В верхней панели навигации выберите “PageSpeed”, а затем “Export.”
Просматривая экспортированные данные, найдите следующие столбцы и отфильтруйте их соответствующим образом:
Добавьте эти данные в отдельную таблицу данных, чтобы вы или ваш клиент могли легко просматривать страницы, которые выходят из строя в каждом основном веб-Витале. Затем вы можете сообщить о проценте страниц на сайте, которые не соответствуют минимальному порогу каждого основного веб-критерия.
Это та часть аудита, где мы превращаем проблемы в решения. Мы знаем, что X количество страниц не соответствует минимальным пороговым значениям основных веб-виталов, но что мы/клиент можем с этим поделать? Именно здесь API PageSpeed Insights действительно творит свою магию. С правой стороны, на вкладке “Обзор”, прокрутите вниз до “PageSpeed.” Здесь вы найдете список вопросов/рекомендаций, касающихся скорости страницы и, по большей части, основных веб-показателей.
Здесь сообщается о большом разнообразии различных вопросов. Если есть что-то, с чем вы не знакомы, поищите его на сайте web.dev, чтобы получить более подробную информацию. Хотя данные, доступные в Screaming Frog и PageSpeed Insights, возможно, не дают полностью исчерпывающего списка всех проблем, которые могут повлиять на основные жизненные показатели веб-сайта, они, безусловно, помогают при анализе вашего сайта/сайта вашего клиента в целом.
Нажмите на проблему, чтобы увидеть затронутые страницы, и экспортируйте их, чтобы сохранить в своей таблице данных. Теперь вы сообщаете о том, на сколько страниц влияет конкретная проблема, а также об URL - адресах затронутых страниц. Для каждой из рекомендаций, которые вы делаете, вы также сможете увидеть “экономию”, которая может быть сделана путем исправления этой конкретной проблемы, либо в байтах, либо в миллисекундах.
Используя экспортированные данные для каждой проблемы, теперь вы можете сложить потенциальную экономию для каждой проблемы и среднюю экономию, которую можно было бы получить на странице при решении этой проблемы, чтобы дать рекомендации по решению проблем в первую очередь на основе суммы потенциальной экономии нагрузки, которая может быть достигнута.
Сообщая о примерах проблем, характерных для каждой страницы, мы предоставляем более детализированный набор данных, который позволяет клиенту/разработчикам быстро понять, в чем заключается проблема и может ли она быть решена или нет.
Следуя примеру с ресурсами, блокирующими рендеринг, теперь вам нужно выбрать один из URL-адресов, затронутых этой проблемой, и выбрать вкладку " Сведения о скорости страницы” в нижней панели навигации. На нижней левой панели теперь будет отображаться информация о скорости страницы, относящаяся к выбранной странице. Перейдите в раздел возможности > устранить блокировку рендеринга ресурсов.
Теперь на правой нижней панели вы увидите URL-адреса ресурсов, блокирующих рендеринг на этой странице, их размер (в байтах) и потенциальную экономию загрузки страницы, которая может быть достигнута (в миллисекундах), если эти ресурсы, блокирующие рендеринг, будут устранены.
К сожалению, вы не можете экспортировать эти конкретные проблемы оптом , но вы можете скопировать и вставить несколько примеров в свою таблицу данных и снова искать любые шаблоны. Часто одни и те же ресурсы появляются на нескольких страницах/каждой странице сайта, поэтому обучение может быть применено по всему сайту.
После того как вы собрали эти данные для каждой проблемы на сайте, вы можете предоставить письменный отчет с рекомендациями по каждой проблеме в порядке приоритета и обратиться к данным в вашей таблице данных.
Чем скорее вы завершите этот аудит, тем лучше, так как для решения некоторых проблем потребуется время. Как только проблемы будут решены, вы можете вернуться к первому шагу и заново просмотреть сайт, чтобы увидеть, как все изменилось.
Именно здесь вам пригодится процент страниц, не соответствующих минимальным пороговым значениям основных веб-показателей, поскольку он показывает быстрый и простой способ понять, оказали ли ваши изменения желаемое воздействие или нет. Несмотря на то, что это явно важное обновление, Мы не предполагаем, что сайты, которые не достигли минимальных пороговых значений, увидят огромное падение рейтинга.
Скорее всего, это будет тот случай, когда сайты с отличным контентом, способным соответствовать или превышать минимальные пороговые значения основных веб-показателей, увидят небольшое улучшение рейтинга, что, конечно же, будет означать небольшое падение рейтинга для конкурентов, которых они обогнали. Это мнение подтверждается собственными руководящими принципами Google по этому вопросу:
“Хотя все компоненты page experience важны, мы будем отдавать приоритет страницам с наилучшей информацией в целом, даже если некоторые аспекты page experience некачественны. Хороший опыт страницы не переопределяет наличие большого, релевантного контента. Однако в тех случаях, когда имеется несколько страниц с одинаковым содержимым, взаимодействие с ними становится гораздо более важным для обеспечения видимости в поиске.”
Владельцы сайтов, которые могут соответствовать минимальным пороговым значениям, получают явное преимущество с точки зрения видимости поиска, и хотя мы не можем точно предсказать, что произойдет в тот день, когда обновление страницы будет запущено, этот процесс аудита поможет вам хорошо подготовиться.
"Вся Информация Размещенная В Блоге "Septem Plus" Несет Ознакомительно-Информационный Характер И Не Принуждает К Каким Либо Действиям Пользователей Блога. Блог "Septem Plus" Не Несет Ответственности За Действия Пользователей После Посещения Блога "Septem Plus"."
Так же прочитайте наши другие статьи: Для Чего Google Переходит На Новое Отслеживание?!, а так же Что Нового В Поисковой Рекламе Google Ads?! и Что Выбрать Ключевое Слово или Ключевую Фразу?!
Связь с Блогом: [email protected]