How to analyze Core Web Vitals in Grafana Cloud Frontend Observability

• 2025-07-14 • 6 min

One of the biggest challenges in frontend development is understanding how users actually experience your application. Slow load times, layout shifts, and a slow response to user interactions can quietly degrade the user experience if they go unnoticed.

This is where Grafana Cloud Frontend Observability comes in.

Frontend Observability is a hosted service for real user monitoring (RUM) that provides immediate, clear, and actionable insights into the end user experience of web applications. Grafana Cloud Frontend Observability and the Grafana Faro Web SDK help you collect and visualize real user monitoring (RUM) data like performance metrics, logs, exceptions, events, and traces.

With minimal setup, developers gain immediate insight into real-world frontend performance, including page load behavior, Core Web Vitals, logs, session data, and error tracking. In this blog post, we’ll focus on one of the most critical areas of these dashboards to assess the user experience of a web app: the Core Web Vitals section.

Understanding Core Web Vitals metrics can help you identify bottlenecks and make targeted improvements to deliver a faster, more stable, and more responsive user experience.

Core Web Vitals: an overview and how to analyze them

Core Web Vitals were created by Google to measure the real-world user experience for loading performance, interactivity, and visual stability of web pages. These metrics provide standarized guidance for quality signals that are essential to delivering a great user experience on the web.

Core Web Vitals are among the first metrics available in the Grafana Cloud Frontend Observability dashboard. These help you measure how fast your site loads, how stable it remains during that process, and how responsive it is to user interactions.

A screenshot of Core Web Vitals metrics in Frontend Observability

Grafana Faro collects these metrics using Google’s web-vitals JavaScript library. The metrics are automatically visualized in the out-of-the-box Frontend Observability dashboard via queries from Grafana Loki.

To make interpretation easier, the dashboard uses clear color coding, where green indicates good performance, yellow indicates a need for improvement, and red indicates poor performance. It also provides markers and a bar to visually indicate thresholds and where the current value is placed on the scale.

A screenshot of the color coding for Core Web Vitals

Now, let’s break down what each Core Web Vital measures and how to interpret and optimize them.

Time to First Byte (TTFB)

The first Core Web Vital metric we see is TTFB, or Time to First Byte. It measures the time between when a request is made and when the first byte of the response is received. This metric reflects how quickly the server starts responding. According to Google, TTFB is impacted by the following phases: redirect time, service worker startup time (if applicable), DNS lookup, connection and TLS negotiation, and, finally, the request phase up until the point at which the first byte of the response has arrived.

A screenshot of the TTFB metric in Frontend Observability

A high TTFB often indicates backend delays, network latency, or inefficient server configurations. To ensure good performance, you should aim to keep TTFB under 800 milliseconds. You can reduce TTFB by optimizing backend processing, implementing effective caching strategies, and using a content delivery network (CDN). Additionally, reducing latency in connection setup time and on the backend can lower your TTFB.

First Contentful Paint (FCP)

First Contentful Paint, or FCP, measures how long it takes the browser to render any piece of content from the Document Object Model (DOM), such as text, images, or SVG elements. It provides insight into how quickly users see something appear on the screen after navigating to a page.

A screenshot of the FCP metric in Frontend Observability

A fast FCP can make the site feel quicker and more responsive, especially on slower networks or devices. To ensure a strong user experience, FCP should be under 1.8 seconds. To improve FCP, minimize render-blocking resources, prioritize the loading of visible content, and remove unused CSS and Javascript.

Largest Contentful Paint (LCP)

Largest Contentful Paint, or LCP, measures the time it takes for the largest visible element in the viewport, like an image or headline, to fully render. It’s one of the clearest indicators of when page content becomes useful to the user.

A screenshot of the LCP metric in Frontend Observability

For an optimal experience, LCP should occur within 2.5 seconds of when the page starts loading. Performance can be improved by compressing large assets like images, reducing server response times, and eliminating render-blocking JavaScript or CSS.

Cumulative Layout Shift (CLS)

Cumulative Layout Shift, or CLS, measures the amount of unexpected movement of content on a page during its lifecycle. These layout shifts can be frustrating for users, especially when they try to interact with content that suddenly moves.

A screenshot of the CLS metric in Frontend Observability

CLS scores under 0.1 are considered good. To minimize layout shifts, you should define dimensions for images and videos, preload fonts to avoid late-loading changes, and avoid injecting content above existing elements without reserving space. Another effective technique for keeping CLS scores low is to ensure your web pages are eligible for the back/forward cache (bfcache).

Interaction to Next Paint (INP)

Interaction to Next Paint, or INP, measures the time between a user’s interaction and when the next visual update is painted on screen. INP captures all interactions throughout the session and reflects the slowest one (excluding outliers), making it a holistic measure of responsiveness.

A screenshot of the INP metric in Frontend Observability

A good INP is below 200 milliseconds. You can improve INP by eliminating long JavaScript tasks, deferring non-critical work, and optimizing how and when updates are rendered.

Note: Frontend Observability users may have noticed another Core Web Vital included in their dashboards: First Input Delay, or FID, which captures the time between a user’s first interaction with a page and the moment the browser responds. Google has officially replaced FID with INP, which is a better way to measure interaction responsiveness. Consequently, we will be removing FID support from the Frontend Observability dashboard in the near future.

Integrate Core Web Vitals into a DevOps practice

Google encourages treating Core Web Vitals as part of a continuous performance improvement cycle. This process includes evaluating website health, optimizing key problem areas, and continuously monitoring for regressions.

Grafana Cloud Frontend Observability supports each of these phases:

Evaluation is done by collecting performance data with Grafana Faro
Debugging is done by investigating issues using Frontend Observability dashboards, logs, errors, and traces.
Continuous monitoring is done by setting up automated checks and integrating Grafana Faro with CI/CD pipelines.

Wrapping Up

Frontend Observability allows developers to glean real-time insight into how users experience their applications. Teams can continuously measure key metrics like Core Web Vitals, track performance trends, and investigate issues as they arise through session-level logs and error data.

Whether you’re debugging layout shifts, improving interactivity, or validating improvements across releases, Grafana Cloud provides the tools to help you close the loop.

To learn more about Grafana Cloud Frontend Observability and Grafana Faro, please check out our documentation.

Grafana Cloud is the easiest way to get started with metrics, logs, traces, dashboards, and more. We have a generous forever-free tier and plans for every use case. Sign up for free now!