Core Web Vitals in Data Studio Using the CrUX Dashboard

If you’ve been paying attention at all lately. You’d know that starting in May 2021, Core Web Vitals will become a ranking factor in Google search. What better way to track your SEO progress than to build a dashboard!

Fortunately for you (and me). Our friends over at have already built a Google Data Studio connector to their API and built a dashboard to go along with it.

To get you started.

  1. You’re going to click here to open the template in a new tab.
  2. Once the report is open in Data Studio, copy the report by clicking on the two sheets of paper in the top right corner.
  3. A light-box should appear and allow you to select a new data source. Click “New Data Source” and at the bottom, “Create New Data Source”.
  4. Type “Chrome UX Report” in the search box.
  5. Click the Chrome UX Report connector and enter any URL that you’d like to track.
  6. Click “OK’ in the top right then “Add To Report” in the top right on the next screen.
  7. Finally, click “Copy Report” on the last screen.

A new tab should appear with your brand new report! Now, a big caveat before we dive into the report. This report, like Google Search Console Web Vitals, will be missing data if your website doesn’t have an abundance of traffic. The Chrome UX Report is a public data set of real user experience data.

Why The Chrome User Experience Report is Important

The Chrome User Experience report is important for a few reasons. First as any SEO will tell you. Web Vitals is about to become a ranking factor.

If that isn’t enough. Your website’s user experience is much more important to your business’s bottom line than you probably think. Let’s go over a few examples.

Study after study after study after study show site speed matters in bounce rate, conversion rate, and time on page.

Let’s assume your website takes longer than 3 seconds to load. The probability of users bouncing increases from 32% to 90%. That translates into less people in your sales funnel and less dollars in your pocket.

It’s not just bounce rate. People that do stay on your site are less likely to purchase and more likely to exit from your site once they’re in your funnel. If you’re losing more people at every step in your funnel, the final impact on conversion rate can be drastic.

Just a 0.1 second decrease in your site speed can increase your conversion rate by 8%. That’s 8% more dollars in your pocket for a little bit of work. That’s not even considering the Life Time Value of the customer that you may have just lost with having a slow site.

If you hate money, then please, by all means, hit that back button and ignore this advice.

Core Web Vitals

The first page is the Core Web Vitals overview for the previous month. Google views these as the most important UX metrics. Largest Contentful Paint (LCP), First Input Delay (FID), and Cumulative Layout Shift (CLS) will be broken out by month and explained in more detail in the following 3 pages.

Core Web Vitals Main Dashboard

This is arguably the most important page of the dashboard.

Largest Contentful Paint (LCP)

Think of LCP as what you see on the screen on the device you’re on. Once the initial load of the largest hero image or text block is shown, the calculation of LCP is over.

The dashboard shows you the last 12 months so that you can see how you’re trending with large call outs for the most recent month compared to the previous month.

Largest Contentful Paint (LCP) Page

Google recommends an LCP of less than 2.5s and deems your site poor if it takes longer than 4s.

The elements that you’re going to want to focus on to improve LCP are:

  • Minimize the amount of JS & CS on your site
    • Audit website code for JS & CS that is no longer used
    • Audit website code for JS & CS that is used but could be removed
  • Server response time
    • Optimize your server
    • Use a CDN
    • Cache assets
    • Serve HTML pages cache-first
    • Establish third-party connections early by using the rel=”preconnect”
  • Render-blocking JS and CS
    • Minify and compress JS and CSS
    • Defer non-critical JS and CSS
    • Incline critical CSS
  • Resource load time
    • Optimize and compress images
    • Utilize an image CDN
    • Preload important resources
    • Compress text files
    • Cache assets

See Google’s full documentation on how to improve LCP.

First Input Delay (FID)

Think of first input delay as when a user interacts with your website and your website responds. If the browser is too busy parsing your website’s JavaScript, it won’t have the resources to respond to a link click or scroll.

The dashboard page shows you the last 12 months so that you can see how you’re trending with large call outs for the most recent month compared to the previous month.

First Input Delay (FID) Dashboard

Google thinks 0.1s or 100ms is a good threshold due to research suggesting that the brain’s perception of input causing a reaction is 0.1s. Anything above 200ms and humans don’t perceive a causal relationship between input and reaction.

The main cause of slow FID is heavy JavaScript execution.

The elements that you’re going to want to focus on to improve LCP are:

  • Reduce the amount of JavaScript that loads on a page
  • Long JavaScript tasks caused by chunking
    • Break Java Script into shorter tasks
  • Defer unused JavaScript

See Google’s full documentation on how to improve FID.

Cumulative Layout Shift (CLS)

Cumulative Layout Shift is the measure of the sum of all individual layout shifts that occur during the life of the page. You ever read an article and suddenly an ad changes or loads and you lose your place?

Worse yet. Have you ever accidentally clicked on an ad or “confirmed” something on a page like a purchase because of this? This is what Google is trying to stop when making it a ranking factor.

Websites with a large CLS are annoying at best and harmful in some scenarios. How it’s measured is a little convoluted, above my head, and above the scope of this article. What you need to know is your target is 0.1 and definitely not greater than 0.25.

Cumulative Layout Shift (CLS) Dashboard

The elements that you’re going to want to focus on to improve LCP are:

  • Images without dimensions
    • Add “width” and “height” attributes to your image tags
  • Ads, embeds, and iframes without dimensions
    • Statically reserve space for the ad slot
    • Avoid collapsing the reserved space if no ad is returned
    • Reserve the largest possible size for the ad slot
  • Dynamically injected content
    • For all of our sake. Just don’t do this
  • Web Fonts causing FOIT/FOUT

See Google’s full documentation on how to improve CLS.

First Contentful Paint (FCP)

This is the start of Google’s “Other Web Vitals”. Still important, but not “Core”. Think of these as metrics that role up to the Core Vitals.

First Contentful Paint is when the browser renders or shows the first bit of content from the DOM. When the user knows that the page is actually loading.

First Contentful Paint (FCP) Dashboard

Google’s Data Studio dashboard considers anything less than 1.5s to be good and anything greater than 2.5s to be poor.

The largest offender of a long FCP is render blocking resources. The other elements that you’re going to want to focus on to improve LCP are:

  • Eliminate render-blocking resources
  • Minify CSS
  • Remove unused CSS
  • Preconnect to required origins
  • Reduce server response times (TTFB) covered below
  • Avoid multiple page redirects
  • Preload key requests
  • Avoid enormous network payloads
  • Serve static assets with an efficient cache policy
  • Avoid an excessive DOM size
  • Minimize critical request depth
  • Ensure text remains visible during webfont load
  • Decrease the amount of requests your page makes
  • Decrease code base size

See Google’s full documentation on how to improve FCP.

Time to First Byte (TTFB)

Time to first byte is your server response time. When a user requests to view your website, how long does your server take to respond?

Time to First Byte (TTFB) Dashboard

A simple way to fix this for a lot of websites is to get off of shared hosting and get a dedicated server. If that’s not possible or you’re already on your own server, try the following.

  • Upgrade your server to have more memory or CPU
  • Optimize the server’s logic to prepare pages faster
  • Optimize your databases or migrate to a faster database system

First Paint (FP)

First paint is when the browser shows the first pixel from the DOM. As opposed to First Contentful Paint showing the first bit of content from the DOM. As you improve FCP, FP will improve in parallel.

To be more specific.

“First Paint reports the time when the browser first rendered after navigation. This excludes the default background paint, but includes non-default background paint. This is the first key moment developers care about in page load – when the browser has started to render the page.”

First Paint (FP) Dashboard

Google’s Data Studio dashboard considers anything less than 1s to be good and anything greater than 3s to be poor.

DOM Content Loaded (DCL)

The DOM Content Loaded is when the initial HTML document has been completely loaded and parsed. Not including stylesheets, images, and subframes.

Google seems to not have much documentation on this metric in relation to web vitals which tells me that it won’t play a very large part into their Web Vitals signals.

DOM Content Loaded (CDL) Dashboard

Like FP above, if you focus on the core web vitals (LCP, FID, CLS) and FCP/TTFB, your DCL will also improve.

Onload (OL)

Like DCL, Onload is an older metric that has been replaced by the Core Web Vitals. I advise deleting this page and the DCL page as they don’t become a distraction away from what your core optimization metrics are.

If you’re curious though.

“The load event is fired when the page and its dependent resources have finished loading.” – MDN.

Onload (OL) Dashboard

Device Distribution

Since this page in the Google Data Studio report serves no real purpose related to Web Vitals, I’d advise just deleting it.

The majority of the web is mobile and everyone (should) know that by now. I think Google just included this page as a reminder. There are rare exceptions where the majority of a website’s visitors are utilizing a desktop though. This website being one of them.

Device Distribution Dashboard

Connection Distribution

This page shows what type of network your website’s visitors are on. If you’re in the US, >95% of your users are on 4G. Just delete this page.

If you’re not in the US, this page may be insightful of your user base. You should be testing your site on a network compatible with your user base.

Connection Distribution Dashboard

When you finally decide to get smarter about all things digital and get your first second income stream built to make that WiFi Money. You need to sign up for my Substack below. Start with the article on Your Path to WiFi Money.

If you're looking at how to start your own website, I've created an easy guide for that too.