---

Data Studio is a fantastic tool not only for interactive reporting but also for process automation. Or, at least, if not fully automating certain processes, it can certainly facilitate a quicker, more robust reach of a process’ goal. 

As SEOs, and frankly even some web developers, too, we are being tasked with performing a page experience audit of a site more and more frequently, considering the page experience ranking factor update that just finished updating at the beginning of September. 

The goal of the auditing process is arguably not the audit itself, but the recommendations we, auditors, can provide, the solutions to the problems we can generate by looking at the data. 

So, to cut a long story short, in case you are wondering what the aim of the dashboard I will be presenting and discussing today is, it is just that – to cut the time spent auditing, quickly visualize the patterns of the problems observed, and provide the ability to move towards brainstorming solutions to the problems observed. 

A little while ago, I first wrote about the Core Web Vitals – a set of metrics, introduced by Google as part of their ranking algorithm in 2021. Today, the discussion continues, delving a bit deeper into the topic of making core web vitals reporting interactive, quicker, and integrated, using Screaming Frog, Google Sheets, and Data Studio. 

Here is what I will cover in this article:

• A bit of context regarding the Core Web Vitals – a refresher and recap of the methods, tools, and data that can be used
• An overview regarding the different pain points in the Core Web Vitals auditing process
• How to Set-up and Troubleshoot the V2.0 Core Web Vitals Auditor Data Studio Dashboard, using the free template 
• Different use cases for  site-, section-, and page-level reporting at a glance.

• Different ways to supercharge Core Web Vitals reporting in Data Studio.
• How to track progress and semi-automate the process, using Screaming Frog and Google Sheets

Prefer video? Check out my talk on this topic on YouTube:

Let’s dive in.

Page Experience as a Ranking Factor: What You Need to Know

So, Page Experience is a ranking factor. 

Have you noticed any changes?

John Mueller and the rest of the team at Google have been continuously and consistently telling us a few things, which I feel the need to emphasize

The Page Experience ranking factor only applies to mobile. 

As we all know, Google moved to mobile-first indexing at the beginning of 2021. Responsive pages have also been a thing for quite some time now. Something Google heavily encourages, instead of maintaining two static versions of a site (mobile and desktop). 

This is just another signal that Google has moved towards a mobile-first assessment of pages and sites. And so should you.

Core web vitals is only a part of the Page Experience Update, not all of it. 

While the other elements are not commonly discussed when talking about the update, that does not mean that they are less important. At present we don’t have any information about the distribution of importance between all the factors (or otherwise – different web vitals) that are a part of the Page Experience ranking update. 

As part of the page experience update, Google will not only look at your Core Web vitals scores but other metrics, too. So, paying attention to all factors is necessary.

 Speed, crawling, and rendering are also quite important

In case you needed any reminders for this – speed, crawling, and rendering of sites are also quite important. Even though they are not labeled as Core Web Vitals. 

Aim for 100%, but be happy with a pass. 

As with any other test in mind, expect that getting a perfect score is not going to be a straightforward, or easy task. Aim for a perfect score, but rest assured Google is not expecting that to rank your site. Of course, there would be other factors involved in the assessment, too. 

So, needless to say (but I will say it once again for the people at the back): getting a score of 100 does not mean that your website will shoot up to position one, just because of your Page Experience score alone. Content, EAT, backlinks, search intent, and the overall technical health of your site still determine the majority of your rankings score. 

Audit and start making improvements to your site early, as some fixes might not be as straightforwards as others

John has been on and on about the benefits of being prepared for the ranking algorithm update. Specifically,  getting an early start for making improvements, as some of them might take longer than expected… when done right, of course.

While there are a number of quick-fix solutions you can implement to ‘save’ your score if failing, implementing quick-fix solutions in the long term is problematic for a number of reasons. For instance, reliance on plug-ins can hinder your site’s security, as well as disrupt the current design principles you have implemented. 

But is anyone paying attention to these updates? 

Perhaps not as much as needed be.

Current Core Web vitals Performance of 20,000 URLs

According to a Screaming Frog study with a sample of over 20,000 URLs, only 12% of mobile pages pass the Core Web Vitals assessment. 

In the eCommerce space, 87% of Websites Fail Google’s Core Web Vitals test. 

So, apparently, we need to step it up. 

Web Vitals Metrics Recap

Let’s recap each of the three metrics: 

• Largest Contentful Paint (LCP) measures loading performance
  • Should occur within 2.5 seconds of when the page first starts loading

• First Input Delay (FID) measures interactivity
  • should be less than 100 milliseconds

• Cumulative Layout Shift (CLS) measures visual stability
  • should be less than 0.1

Other web vitals include measures of

• Mobile friendliness
• Security – Safe Browsing, HTTPS
• Intrusivity

From the additional web vitals, one not commonly discussed, but in my opinion very important is the Time To First Byte.

• Time To First Byte (TTFB) measures response speed
• Should be around 200-500ms

There are two types of data that Google collects and analyze:

• Field data – i.e. Real user monitoring (RUM)
• Lab data – i.e. Emulated data

There are also a wide array of tools that can be used, each with their own unique set of benefits, limitations, and use-cases, which you can examine, using this handy infographic. 

• PageSpeed Insights, which reports on URL-level user experience metrics
  • Very good for testing of fixes and performance measurement on individual pages.
  • Lab + Field data
• Chrome UX Report, which reports on aggregated performance, accross all elligible pages on the site 
  • Field data, i.e. RUM.
• Search Console’s Page Experience report provides groupings of pages, based on similar issues
  • Hindered by sampling as it only shows up to 15 pages with similar issues, not all pages
• Chrome DevTools and Lighthouse provide detailed measurement and guidance on fixing CWV issues.
  • Suitable for detailed analyses
• WebVitals Extension gives a real-time view of metrics’ performance.

Challenges in the Core Web Vitals Auditing Process

You might be wondering: ‘With so many tools at our fingertips, what can really be the challenge?’

Well, let me tell you. 

Most tools available are not user-friendly for site-wide auditing.

While advised, integrating all tools for a site-wide assessment of medium and large sites is near impossible. 

Page-level performance data can differ greatly across different site sections. This can be a result of the use of different templates across the website, the ‘heaviness’ of images and other media on particular pages, or even different pages or sections having different integrations (e.g. GTM, Google Ads, Hubspot, or other third-party scripts),  which can weigh down the site. 

Getting a complete picture for patterns can be difficult.

Snapshot instruments, such as the ChromeUX report don’t enable section- or page-level drill down. On the other hand, the Page Experience report in the Google Search Console obstructs site-wide reporting as it samples the data. To elaborate, it only shows 15 pages with a similar issue, instead of giving a full list of the affected URLs.

This results in a number of different challenges from an SEO and technical auditing standpoint, all of which stall the potential improvements that can be done on a site. 

Let’s discuss some of them.

Inability to communicate and prioritize clearly

If you can’t identify all pages for an observed issue, prioritization will be a struggle. 

Failing to communicate urgency to the developers that will be implementing the recommendations you provide, will result in delays. Because, as we all know – tasks perceived as non-urgent typically get put straight in the backlog. 

And once a task is there, it is probably staying there forever until urgency is established, which often happens externally. 

Inability to spot the root cause of the issue

Often, a certain template or widget might be causing the issues that you are observing. Knowing where the issue is contained is the first step in its resolution. 

Is the problem page-, section-, or site-wide?

Finding all instances as an auditor using the conventional tools is near impossible unless you are intricately familiar with the site’s characteristics from a web development standpoint. 

Inability to delegate appropriately

Medium and large sites often have organizational silos, which manage different parts of the website. 

Allow me to explain what I mean via an example. 

Imagine a website that has its <investor> subdomain, managed by an external party, which typically handles <legal>, too. 

The same site will have a <PR> subdomain or section, managed by a different external agency.

Content pages such as the <blog> and <resource> pages will likely be managed and owned by content marketers internally. The same goes for <product> and <solution> pages, however, these will typically be managed by an internal product marketing team.

External web agencies might also have contracted developers for the sections they manage, but in all cases, there will be internal developers, who will likely be implementing your proposed fixes. 

An organization, such as the one in this example, will typically also have a demand-gen or head of growth marketer, whom you will need to convince of the importance of fixing page experience issues site-wide. 

Good luck with delegating tasks, if you can’t filter your recommendations by section. 

Slow auditing process

All the aforementioned challenges will likely result in a very painfully slow auditing process.

Even though web.dev advises to use all tools, implementing this in practice site-wide is near impossible.

Inability to export & easily create actionable sheets for devs

The current processes subject you to providing non-actionable recommendations, they set you up to fail. 

Unless you’ve implemented all tools on a page-by-page level, you will need a few sweeps of auditing, getting back to developers, implementing recommendations, and testing before you get things right site-wide. 

The lack of interactivity in many of the tools means exporting dev sheets with a full list of the URLs, where a particular issue is contained can be a pain. 

Progress and impact tracking of fixes is ad-hoc

Site-wide auditing and audit comparison are unavailable for most tools. Testing is ad-hoc. 

Most tracking is done either holistically, by looking at site-level metrics, or page-by-page.

How to Set-Up and Troubleshoot Your Core Web Vitals Data Studio Dashboard in Google Data Studio

Just plug-and-play in three simple steps:

• Bulk-audit Core Web Vitals with Screaming Frog 
• Copy the Data Studio Dashboard
• Connect your data 

Okay, maybe not so easy. Might take a little bit longer than just three steps, but bear with me

1. Filter Pagespeed Insights API traffic in GA

2. Audit Core Web Vitals with Screaming Frog and export the audit data to a Drive spreadsheet.

To audit the Page Experience, using the Pagespeed Insights API via Screaming Frog, you must first connect the API. 

To do this, go to API access and enter your API key in the PageSpeed Insights > Account Information tab, shown on the left on the image below. Then, ensure to select all metric groups for auditing. 

Export your crawl via connecting your Google Drive with Screaming Frog, as this will directly export it in the necessary format for Data Studio. 

3. Copy the Data Studio dashboard template and connect your data.

Here, you will have two data sources to connect – the first one is the Screaming Frog crawl that you just exported. To do this, you must select from the connector list the native Google Sheets connector, locate your crawl spreadsheet, and connect it. 

In the second field is the ChromeUX report connector, which reports on RUM data only. To locate this report, search ‘Chrome UX’ in the connector search tab, select the connector, and enter your site’s URL. 

? If you are having errors connecting the ChromeUX report, try disabling the option for being able to change the URL in the report – I’ve noticed this can sometimes obstruct the connection process. 

Some additional tips before connecting (or added steps, which will make your life easier later, I promise): 

• Get a feel for the site’s categories before you start the audit

Find out about different themes on the site. Best to talk to developers if there are different templates used across the site’s main sections. 

• Check the CMS

While not directly tied to the analysis, this will come very handy in researching the issues you are noticing and suggesting recommendations. 

• Get access to Google Analytics 

While optional this can really help you supercharge the report and prioritize the implementation of recommendations. 

A quick note here – you can also connect Google Analytics in Screaming Frog, using the same API menu you used for connecting the PageSpeed Insights API. 

In my opinion, though, connecting Google Analytics via the native Data Studio Connector via adding it as an additional data source of this report is the better approach. 

? A quick word of caution here: The dashboard’s scorecards are filtered. This can cause errors in the connection. Rest assured, I will walk you through how these errors can be resolved. 

If you see any fields that are not populated due to a data studio error, click on them. On the right-hand side, you might see a filter-related error, such as this one, in the image below. 

Screaming Frog might sometimes change the names of the fields, which could break the filters of the scorecards. This can be easily fixed in Data Studio. 

Simply click on the scorecard, then select the filter, and provide the relevant field for the exclusion. 

But now that the setup is out of the way – Voila! We have a fully functioning dashboard.

Use Cases of the Core Web Vitals Dashboard

Get an overview of the site’s performance using two types of data.

With this dashboard, you can quickly get an overview of site performance, using two data sources and two types of data. 

LCP, FID, CLS side by side performance for the entire site in the performance overview section. 

Differences in the data can be caused by the difference in lab versus reported page experience. The CrUX API only reports field user experience data, unlike the existing PageSpeed Insights API, which also reports lab data from the Lighthouse performance audits. 

They can also be attributed to null values. Null values are excluded from the PSI API data in the dashboard, yet you can amend this in the filter settings if you wish. 

? Don’t be scared of seeing null values in the Chrome UX report

If upon connecting your property with the Chrome UX report, there is no associated data, you can still view any opportunities identified via PSI API and work on implementing changes, based on the savings opportunities data. 

This only means that there isn’t enough data collected for your site yet, or that it is new in the search console. You can still implement improvements and be ready for when your site reaches Google’s visitor threshold and enough user data is collected for an accurate assessment to be made.

View savings opportunities at a glance

The dashboard shows you all savings opportunities at a glance. Here, you can view the impact of different issues, which can be the first step in the prioritization. 

The opportunities are grouped per category: 

• Image optimisation 
• Resource optimisation
• Server optimisation
• Render optimisation

Each opportunity also visualizes a clickable element to a web.dev resource, where best practices in resolving the issue observed are highlighted.

Filter pages by metric performance category

In the Page Level Drill-down section, you can see all pages that pass, fail or need improvement in any of the three metrics. 

The first table enables you to view the category assessment for each of the three metrics on a page-by-page level, whereas the second table shows you the individual values (in Bytes) for the savings that can be achieved for each of the identified opportunities. 

You can sort and filter pages by saving opportunities and values

See all opportunities on an individual page level. Sort and Filter per metric value. 

Filter pages based on keywords in the URL

Perhaps one of the most useful things is the ability to filter based on values in the URL. 

Enter a keyword contained in the URL address, select the type of filter (e.g. contains, regex, equals, etc), and press enter. This will filter the savings opportunities widgets, as well as the two tables.

You can export a dev sheet easily from the tables, by clicking the top right-hand corner and selecting export.

How to Supercharge Core Web Vitals reporting in Data Studio

Merge with Google Analytics or Google Search Console data for prioritisation, based on KPIs

By merging the data sources of Google Analytics data with the crawl data, using the address/URL dimension, you can add a layer of prioritization for the needed improvements, based on the page visits, new users, or conversion metrics (such as goal completions). 

You can also do the same with Google Search Console’s URL data source, which can help you prioritize improvements, based on clicks, impressions, and CTR. 

Create groups of pages, based on website section templates

Do this by creating a custom field with a regex filter. On the bottom right-hand side of the screen, click on ‘Create Field’.

You can create a filter for pages in different languages: 

Or different page sections

Read a full guide on how to use regex filters.

Incorporate ChromeUX data for competitors and monitor how they are evolving over time

Rachel Anderson wrote an amazing guide on the idea of Core Web Vitals competitor analysis, which includes a step-by-step tutorial on blending data for your selected competitors, as well as a full process on how to get a report page that looks like this.

Add a new page to the dashboard and follow along with her amazing tutorial to visualize where you are against competitors.

? Be wary of Google Data Studio’s limitations.

While you may want to view 10 competitors (or even all of your competitors in a single graph), if you need to blend data sources (as in Rachel’s tutorial), you are limited to up to five. 

In addition, if you need to visualize many charts on a single page, there are limitations to the number of elements that you can use on a single page, too. 

Overall, there are still sadly far too many instances where Data Studio could (temporarily) fail you. Be aware of Google Data Studio’s limitations, as well as the limitations of your data sources, and prepare accordingly. 

My best advice here is to use version control to avoid being stuck with a broken version of the dashboard right before a client meeting. 

How to track progress and semi-automate the process, using Screaming Frog and Google Sheets

Incorporate a performance-tracking sheet for changes and map out the impact of changes

Give your developers a list of recommendations based on the Page Experience issues you are observing. 

To make life a bit easier for you, I’ve created a Core Web Vitals Recommendations template. It includes:

• The area and metric of impact of the recommendation 
• The recommendation name and description 
• An Impact-Confidence-Ease (ICE) prioritisation framework assessment
• Rationale for implementing the recommendation
• Guidance / How-to
• Recommendation Implemented (yes/no) checkbox
• Implementation Date
• Implementation Notes

While difficult, get your devs to include a date for the implementations in the progress tracking sheet. Notes will be great, too, but are totally optional.

That way you can proactively monitor via blending your progress tracking sheet with Chrome UX field data, whether your changes have made an observable impact on the site’s reported page experience. 

This sheet is currently embedded as a second page of the dashboard for easy access. Feel free to copy it and fill it with the details of your site’s audit. 

Once completed, connect it as an additional data source to your copy of the template, and use the date dimension to blend the progress-tracking sheet with the Chrome UX report to map out the change of implementations.

Set your crawl to re-occur bi-weekly or monthly

By doing this you will have more data to work with and visualize, especially if there are many developments being worked on. 

If implementations have been made, this will also allow you to showcase the different results to your stakeholders in the same dashboard, as well as the percentage change from the previous crawl.

Send out bi-weekly or monthly snapshots of the report via email

Data Studio enables your report to be sent out automatically. Utilize this option to send out bi-weekly or monthly reports about Core Web Vitals, depending on how fast your developers are progressing.

In the future, we might even be able to fully automate the process via Zapier’s Data Studio Connection (currently in development), but for now we would have to settle for this semi-automated approach.

Final Thoughts

An interactive progress-tracking approach can definitely benefit your stakeholder relations greatly, so don’t underestimate it. 

Peak client and developer interest in the topic of Page Experience, as it is a shared cause. And it really should be considered one!

Get their hands dirty and start improving your site’s page experience health sooner, rather than at the next update. A shared interest and engagement in this area, as well as some communicated urgency, can sometimes be the only way to get your recommendations actually implemented.

Looking to find out what else you can report on with Screaming Frog crawls in Data Studio? Check out my URL Inspection API Google Data Studio Dashboard template that I released in February.

---

In case you are interested in checking out my slides for MeasureFest, here they are. 🙂