Автоматизация сбора данных Core Web Vitals в Google Таблицах на своем сайте и сравнение с конкурентами

Александр Денисов

SEO-аналитик агентства kite.

Хотите себе такой же график по любому из параметров Core Web Vitals (в дальнейшем CWV)? 

Шаблон сводной таблицы 

Чем хорош мой метод: во-первых, анализируется не только продвигаемый сайт, но и сайты конкурентов, а во-вторых – оцениваются не главные страницы (как у большинства сервисов), а продвигаемые листинги (или карточки/статьи/…). 

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

Подготовка страниц для отслеживания 

Первым делом определитесь с конкурентами, которых планируете отслеживать. Для этого нужно взять лидеров по видимости в Google и выбрать из них прямых конкурентов. В дальнейшем мы будем сравнивать, как изменения в метриках CWV отразятся на показателях видимости. 

Как определить равнозначные страницы? Для репрезентативности я беру по 3 страницы различных шаблонов. Например, 3 страницы листингов. При небольшом объеме такие страницы можно найти на сайте вручную или через поисковики по запросу [site:сайт.ру запрос]. 

Если конкурентов больше 5–7 и шаблонов несколько, я автоматизирую это через Google Таблицы (пример шаблона – формулу можно протягивать дальше). Далее получившиеся запросы я отправляю в Key Collector (но можно воспользоваться любым другим съемом выдачи) и собираю там данные по SERP-у по любой ПС. 

Когда данные собрались, скачиваем отчет «Экспортировать данные о поисковой выдаче», фильтруем пустые строки в первом столбце и вуаля: готовый список релевантных страниц! Попутно еще можно проверить, насколько хорошо у вас и конкурентов определяются релевантные страницы. 

Подготовка Screaming Frog SEO Spider 

Для начала необходимо подключить API PageSpeed. Для этого необходимо зайти в Screaming Frog («Лягушка» на простонародном оптимизаторском :)) в Сonfiguration→API Access→PageSpeed Insights. 

Там будет ссылка https://console.developers.google.com/apis/credentials, по которой необходимо перейти для получения ключа. 

Создаем ключ API: 

Включаем доступ к API Google PageSpeed Insights. 

Отлично, теперь у нас есть ключ, который мы вставляем в Screaming Frog и нажимаем Connect. У нас будут собираться данные по PageSpeed, но нужно определить, какие данные мы будем подтягивать: desktop или mobile. 

В этом же окошке есть множество параметров, которые можно собирать. Они разбиты на 5 групп: 

• Overview – общая информация о странице, такая как размер самой страницы, HTML, CSS.  
• CrUX Metrics – усредненные данные от пользователей Chrome за 28 последних дней (Chrome User Experience Report). 
• Lighthouse Metrics – данные из Lighthouse в реальном времени. 
• Opportunities – советы по улучшению показателей PageSpeed на каждой странице.
• Diagnostics –здесь есть такая полезная метрика, как количество элементов в DOM-дереве. 

Для анализа нам пригодятся все, кроме Opportunities (хотя и на основании этих метрик вы можете строить дашборды, но это уже не относится к теме этой статьи). 

Сканирование страниц и анализ результатов 

Тут все просто: полученные URL страниц нашего сайта и сайтов конкурентов мы добавляем в Лягушку в режиме Mode→List. 

Ждем завершения сканирования и скачиваем отчет через кнопку «Export». Далее открываем его через Excel или Google Таблицы, сортируем по имени URL, чтобы сайты шли по порядку, и через условное форматирование закрашиваем интересующие нас столбцы. 

Таким образом мы наглядно определим конкретные параметры скорости загрузки, по которым отстаем от конкурентов, и сможем объяснить клиенту или руководителю, что именно необходимо поправить на сайте. В Cправке Google подробно расписаны основные параметры скорости и за что они отвечают. 

Будьте готовы – для каких-то страниц данных может не быть :( Это связано с тем, что сайты запрещают парсинг своих URL. В таком случае стоит попробовать перебрать различные юзерагенты бота от Лягушки, возможно, поискать бесплатные прокси. И лучше уменьшить скорость обхода сайта: можно поставить скорость обхода одного URL в 1–2 секунды. Если ничего не поможет, эти страницы придется удалить из анализа и дальнейшего сканирования. 

Постановка на регулярное сканирование в Screaming Frog SEO Spider 

Настраивая в первый раз Лягушку на запланированное сканирование, я затупил, так как не знал, что у них есть возможность настроить сканирование через консоль без интерфейса и затем эти команды поставить в планировщик задач. Полез разбираться с этими командами, разобрался. А когда уже приступил к настройке планировщика задач, обнаружил – у Лягушки есть свой планировщик! 

Теперь я хорошо запомнил, что по-английски «планирование» – это не только «planning», но и замысловатое слово «scheduling», которое находится в меню «File»: 

Что нам необходимо сделать в этом меню? На первом этапе («General») нужно назвать проект и настроить периодичность сканирования. Я настроил по понедельникам в ночь, чтобы при еженедельном мониторинге с утра проверять данные и по скорости загрузки. 

В следующем окне («Start Options») нам нужно: 

1. Выбрать вариант сканирования «List» (то есть сканировать по списку URL, а не весь сайт). 
2. Указать путь к перечню URL для сканирования в формате txt. 
3. Указать путь к файлу конфигурации Лягушки (где могут быть настроены юзерагент, скорость сканирования и необходимые пункты проверок PageSpeed).  
4. Выбрать чекбокс в сервисах APIs «PageSpeed Insights». 

В последнем окне, «Export», выбираем: 

• «Headless» (режим без загрузки интерфейса и с возможностью автоматического экспорта). 
• Папку, в которую сохранять файл сканирования. 
• «Create timestamped folder in output» (каждое сканирование сохраняется в отдельном файле, а не перезаписывается).
• Файл сканирования я советую сохранять (чекбокс «Save Crawl»), чтобы потом можно было к нему вернуться.
• В кнопках «Export Tabs», «Bulk Export» и «Reports» содержатся вкладки, которые нужно сохранить (я оставил «Internal:All» и «PageSpeed:All»), и виды отчетов (для данной задачи в этих полях можно ничего не выбирать). 
• Формат необходимо выбрать «gsheet» для онлайн-отображения отчета. 
• Остается указать только доступ от гугл-аккаунта, куда сохранится отчет. 

Для теста запланируйте создание отчета через 5 минут , проверьте его в отчете на Google Диске и насладитесь тем, как вы великолепны! :)

Сведение отчета в одну таблицу с графиками 

Для сводной таблицы создайте два или больше запланированных сканирований (можно с периодичностью в 5 минут создать несколько сканирований). 

Теперь формируем отдельную таблицу: настраиваем перенос необходимых параметров CWV и оформление всех данных в наглядном виде. 

Разберем эти 2 действия подробнее. 

Перенос отслеживаемых параметров в сводную таблицу 

Для этого нам нужно в сводной таблице создать вкладку с данными за определенную дату (вкладку можно назвать в формате дд/мм/гг). Далее я расскажу, как автоматизировал и оптимизировал получение данных, поняв основную механику. Но, возможно, вам будет удобнее сделать по-другому. 

В первую строку первого столбца я вставляю ссылку на таблицу с данными. Для этого в Google Диске открываете папку «Screaming Frog SEO Spider», куда у вас будут сохраняться все сканирования. Далее переходите в папку с именем, которое вы указали при создании планирования, и затем в папку с конкретной датой. Там у вас будет лежать таблица «pagespeed_all», открываете ее и копируете URL из адресной строки. 

Со второй строки уже располагается таблица с URL наших страниц, страниц конкурентов и отслеживаемых параметров. Для анализа я взял данные по Performance Score, CrUX FID, LCP и CLS. 

Как нам автоматизировать заполнение этих данных? Элементарно! Формулой «=IMPORTRANGE». Адресом таблицы-источника данных указываем первую ячейку с адресом таблицы (пример таблицы за дату). Адреса страниц нужно вставлять тоже через эту формулу, но в моем примере я вставил адрес как значение, чтобы переименовать URL из-за NDA. Все остальные параметры из моего примера берутся через формулу. 

Если вы собираете данные в одном аккаунте, а таблица находится в другом, необходимо нажать кнопку «Открыть доступ» к таблице, с которой берутся данные. 

Вывод данных 

Для этого нам нужно будет создать вкладку и в нее агрегировать данные со вкладок по датам.  Я делаю в таком формате: 

Таблица. График делается через формулу «=SPARKLINE». URL-ы расставил по порядку, закрасил по сайтам через условное форматирование, а значения подтянул через «=ВПР», так как при сканировании в Лягушке иногда меняется порядок сканирования адресов страниц. 

Позже я доработал эту статистику и свел данные по страницам (страницы у меня однотипные, только листинги) через формулу «=СРЗНАЧ» к среднему по сайту (вкладка таблицы): 

Создал общий дашборд, объединяющий все графики (изображение в самом начале статьи). Дашборд необходим только для визуального контроля: есть ли сильные падения или рост. По нему непонятны незначительные колебания. Например, когда у страницы в среднем performance score был 25–27, а стал 33, на графике это отразится как значительный рост. А для ранжирования и анализа это небольшие изменения. 

Обновление таблицы 

Для этого нужно: 

1. Сделать копию последней вкладки с датой последнего обхода, переназвать ее по аналогии с соответствующей датой сканирования. 
2. Вставить ссылку на таблицу «pagespeed_all» с соответствующей датой сканирования в ячейку A1, разрешить доступ к данным на этом листе. 
3. Протянуть формулы со значениями в сводной таблице, заменив дату сканирования в «=ВПР» на соответствующую. Если какой-то сайт не удалось просканировать, в значении будет #Н/Д. Это значение удаляем и оставляем ячейку пустой, так как из-за него не получится построить график. В усредненной таблице остается только протянуть данные. Заменять даты не нужно, там значения берутся из предыдущей таблицы. 

Выводы 

Этот дашборд закрыл 2 вопроса: 

1. Есть ли корреляции изменений CWV и ранжирования. На основном дашборде у третьего сайта заметны значительные улучшения показателей, но по видимости в Топвизоре он не вырос в Яндексе и Google ни на следующей неделе после улучшения показателей, ни через 2 месяца. Выходит, что в тематике недвижимости скорость сайта не играет такой важной роли в ранжировании, как предполагалось. 
2. Эта таблица помогла в мониторинге скорости продвигаемого сайта при постоянных внедрениях со стороны разработки. 

Павел Алимов, руководитель отдела интернет-маркетинга «Мир Квартир»

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

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

Из желаемых улучшений : 

1. Выделение и маркировка страниц по типам с последующей возможностью проанализировать средние показатели для страниц каждого типа, сравнить страницы одного типа с сайтами конкурентами. 
2. Сохранение данных всех парсингов в одну таблицу (дата парсинга – просто отдельный столбец). Это позволит подключать таблицу в качестве источника для BI-систем, например, Google Data Studio. 

Дополнительные материалы по теме CWV 

Статьи 

Как сделать дашборд в Data Studio на основании данных по своему сайту (сам дашборд). 

Как отслеживать показатели Core Web Vitals с помощью Google Analytics 4.

Презентация доклада Ильи Горбачева «Идеальная загрузка страниц» со ссылкой на дашборд сравнения показателей CWV по тематикам, видео доклада  

Подробные рекомендации по улучшению каждого из параметров LCP, FID и CLS 

Статья, как в Тинькофф настроили мониторинг производительности 

Инструменты 

• Web Vitals – один из самых первых плагинов для Chrome, который показывает данные LCP, FID, CLS. 

• Core Web Vitals – еще один плагин для Chrome, который выделяет самый большой контент зеленой рамкой, а сдвиг CLS – оранжевой. 

• Core SERP Vitals – показывает LCP, FID, CLS в выдаче Google. 

• https://treo.sh/sitespeed/ – бесплатный инструмент, который показывает хронологию изменения показателей метрик Core Web Vitals. Жалко, что только по главным показывает.
• https://reddico.co.uk/tools/serp-speed/ – инструмент сравнения ТОПа по Core Web Vitals и Mobile Score.