Five Reasons to Use Catchpoint for Measuring Core Web Vitals

We are in this together. As part of our continuous efforts to meet customer expectations, we have recently added Core Web Vitals to our performance measurement programs. We are happy to share that these metrics are now a native part of the Catchpoint Platform. DevOps’ SREs, Platform Operations Engineers, and business and monitoring strategists alike will realize a series of key benefits from this addition.

By combining Core Web Vital Metrics with the world’s largest Digital Experience monitoring platform and our performance analysis capabilities, Catchpoint users will be able to:

1. Move from drawing loose correlations to making confident causality statements (between IT and the business).
2. Better match performance perception thresholds by customer segment or user journey.
3. Leverage the power of our intelligence platform to realize the value of real-world customer-centric outcomes.

What Are Core Web Vitals?

The Chrome team at Google announced Core Web Vitals last year “to help site owners measure user experience on the web”. They represent a subset of metrics related to speed, responsiveness, and visual stability – and include these metrics:

1. Cumulative Layout Shift (CLS)
2. Largest Contentful Paint (LCP)
3. First Input Delay (FID)

Cumulative Layout Shift (Visual Stability)

CLS measures the visual instability of a page, as actually seen by the customer. Instability, in this context, refers to “moving targets” i.e., when a customer goes to click on something and that something has suddenly moved to a completely different location in the viewport. It could mean the difference between clicking on the desired search result versus clicking on an ad that will place 5,000 cookies on your local device!

The video below has some useful visual examples:

Largest Contentful Paint (Loading)

LCP measures when page navigation appears complete to the customer. For context, “complete” is usually the meaningful, contextual reason for the customer being on a page in the first place. Unlike First Contentful Paint, which can be something like “a splash screen” or “your page is loading” icon, Largest Contentful Paint measures how quickly the main, relevant content of a web page loads and is visible to users.

First Input Delay (Interactivity)

First Input Delay (FID), meanwhile, measures the responsiveness of interactive experiences on a web page. It is the difference between “adding one item to your cart” versus “adding multiple items to your cart” because the add to cart button felt unresponsive causing a customer to click it again, leading to a disrupted journey. Specifically, FID measures the time from when a user first interacts with a page to “the time when the browser is actually able to begin processing event handlers in response to that interaction” (source: web.dev/fid/).

Moving Up the Hierarchical Chain of Digital Monitoring Needs

Perhaps the best way to summarize the value of these new core web vital metrics is they will move Catchpoint users higher up the hierarchical chain of digital monitoring needs. There is an ocean of monitorable IT indicator metrics for uptime, response time, and latency. And the idea of experience-based metrics, like page load time or document complete, has also been around for quite some time. What is different about the Core Web Vital metrics is they take the idea of customer experience-based metrics to a new level – a level of capability based on what the customer actually sees and experiences with their own eyes as they are trying to complete their respective journeys.

Why Use Catchpoint to Measure Core Web Vitals?

Google already offers customers plenty of ways to measure Core Web Vital metrics. So why should Catchpoint users care that these metrics are now available on our platform?

Ignore for a moment that most of the offered dev tools from Google are Chrome only (which for some will be a disqualifier out of the gate) or that some of its data sources are updated only once a month. More importantly, these tools have a hard-coded, aggregate 75th percentile as the “good” versus “poor” threshold. This one-size-fits-all view is too constricted and could lead to incorrect actions and/or a waste of precious optimization resources. After all, your customers are anything but one-size-fits-all. Put another way, customer performance profiles vary by ISP, device, browser type, user journey, personal goal, and many other variables. So, the optimal use and measurement of these Core Web Vital metrics likewise need to match and account for these varied user combinations.

Further, if you think about Google’s other provided tools, whether DevTools or PageSpeed Insights, which measure locally or close to the source, you’ll soon realize that you need more reach and reproducibility than using Google alone can give you. Think Developer A sharing their DevTools results with Developer B, and seeing completely different results based on where they are located.

In short, our users will benefit from using Catchpoint to measure Core Web Vitals for five key reasons:

1. Actionability: More signals with less noise to focus precious optimization resources.
2. Granularity: Match perception thresholds by customer segment, geography, or another dimension (run WebPageTest on an M1 anyone?).
3. Reach: Combine these new metrics with the world’s largest digital monitoring telemetry footprint.
4. Trustworthiness: Single source of truth for normalized measurements and reproducibility.
5. Cohesiveness: Both lab and field measurements in a single, unified platform.

Want to learn more about how you can use Catchpoint’s WebPageTest to support Google’s Core Web Vitals? Read the press release today.