Overview
Web Vitals are webpage performance metrics developed by Google to understand and improve user experience. Web Vitals are numbers that tell you how your users experience a web page and have become widely accepted as industry standard for website performance.
Below you find a detailed guide on Web Vitals that will help interpret the results of ObservePoint scans and take appropriate action.
Why Web Vitals Matter
If your pages have great web vitals, you will get:
Happier users đ
Better placement in Google search results
Better ad prices for pages that are the target of ads
Better ad placement over your competitors (especially if your competitors have bad web vitals)
Types of Web Vitals
The first 3 web vitals reported by ObservePoint are measured in seconds, in sequential order from the moment ObservePoint begins to visit your page. This simulates a user clicking a link or pasting a URL to your website in the browser address bar.
Time to First Byte (TTFB): This number measures the time (in seconds) it takes for your web server to respond to the user's browser with any data. The clock starts when the user navigates to a page. The clock stops when the server sends the first byte of data to the user's browser. More technical details from Google.
First Contentful Paint (FCP): This number measures the time (in seconds) it takes for the first visual content to appear on the page. The clock starts when the user navigates to the page. The clock stops as soon as anything visible appears (not counting non-content like background color). More technical details.
Largest Contentful Paint (LCP): Many website owners consider this the most important web vital. This number measures the time (in seconds) it takes for the largest visual change to happen on the page. The clock starts when the user navigates to the page. Every time visible content changes (text, images, anything visible), the browser measures the size of the change in visible pixels. If the size is bigger than the previously recorded visual change, the browser records the time as LCP. In other words, LCP increases as you wait for more content to change. Remember, LCP only counts visible content. More technical details.
There is a fourth Web Vital ObservePoint report which is different from the ones mentioned above because it measures movement:
Cumulative Layout Shift (CLS): This number measures how âjumpyâ your page content is. Sometimes pages move content out from under your mouse or finger while they are loading, and CLS measures the amount of that movement. If you have a CLS score of 0, it means the page content did not move after it appeared (even if it appears in chunks). CLS is tricky, because even a good score of 0.1 can be very bad for your users if the wrong element moves (e.g., the login button moves right when users try to click on it). More technical details.
These metrics are available either at a URL level or an Audit-wide level, both found in the Pages Report.
Web Vitals at URL Level
Web Vitals at Audit Level
Lab Data & Field Data
Web vitals can be collected in two ways that we will refer to in this guide as "Lab Data" (synthetic monitoring) and "Field Data" (real user monitoring).
Lab Data
Lab Data represents a way of measuring the effect of a change without exposing the change to users and, at the same time, provides more detailed information about your pages. However, it might not reflect real user experience because the CPU and internet connection of these devices may not exactly match your users. Lab Data is gathered by automated tools through vendors such as ObservePoint or Google Lighthouse.
Field Data
Field Data measures real user experience, and it gives you accurate information coming from a user environment, but the volume of data can be large and may lead to slowing down users' experience. Tools used to measure Field Data are Google Analytics, Google Tag Manager or CrUX (Chrome User Experience Report).
Note: Web vitals numbers can vary between runs of ObservePoint due to numerous factors, even in controlled settings. It's best to analyze these numbers across multiple pages or runs to get reliable results. Avoid drawing conclusions from a small sample size; consider gathering numerous samples and discarding outliers. It's typical for LCP to fluctuate by 20% - 80% even when accessing the same page repeatedly with the same device and internet connection.
Understanding Web Vitals Data
It is crucial to know when a web vital is bad or good and what it needs to be done in order to improve it. The information below represents an interpretation of high (bad) and low (good) numbers for each vital and what actions they might require.
Note: The tables assume you are considering a web vital on a single page at a time. While itâs useful to view web vitals in aggregate across many pages or many views, you must typically focus on a single page at a time (or single class of pages, like a template).
Web Vital: Time to First Byte (TTFB)
What it means if itâs high (bad): | What it means if itâs low (good): | What causes it to be high (bad): |
A high TTFB means your server is slow or the userâs internet connection is slow. In the case of ObservePointâs reported web vitals, the internet connection is usually not at fault, since ObservePointâs scanners have gigabit internet connections. Generally, from the TTFB number alone, you canât tell whether itâs the server or the userâs internet connection. To differentiate, you can view metrics provided by your server(s) to see how long each request is taking. Most frontline services like Akamai and Cloudflare provide metrics to tell you how long they take to provide browsers with content.
If your TTFB is high, youâll need to improve it before the other web vitals, because FCP and LCP cannot be smaller than TTFB. In other words, itâs the first web vital that must be fixed | Most practitioners agree that a good TTFB is under 0.8 seconds, but ObservePoint suggests 0.2 seconds, since TTFB gates all the other web vitals. Most popular websites have a TTFB under 0.1 seconds.
A low TTFB means your server is responding fast, and your user has a fast internet connection. This does not guarantee that the page appears fast for the user, but itâs the first required step. In other words, a low TTFB is necessary, but not sufficient, for a good user experience. |
|
Note: Remember that TTFB only counts the time it takes for the first byte of your pageâs main HTML document. It has nothing to do with CSS, images, or JavaScript. This means that, by definition, tags cannot affect TTFB (in other words, Adobe Analytics never affects TTFB).
Web Vital: First Contentful Paint (FCP)
What it means if itâs high (bad) | What it means if itâs low (good): | What causes it to be high (bad): |
A high FCP means your user is waiting for any meaningful visual content to appear on the screen.
A high FCP might be caused by a high TTFB. See the rows above. If your TTFB is low, but your FCP is high, the most common cause is big, slow JavaScript and CSS files at the top of your HTML, which block page content from appearing until they are downloaded. The 3 most common solutions are: | Practitioners generally aim for an FCP under 1.8 seconds, but consider your users' tolerance for wait times. A poor FCP may give the impression of a frozen website. Understand how caching affects your FCP score; browsers store certain files for faster subsequent visits. FCP scores can increase significantly in a cold state (no cache) compared to a warm state (cached), especially for sites with frequent repeat visitors. |
|
Web Vital: Largest Contentful Paint (LCP)
What it means if itâs high (bad): | What it means if itâs low (good): | What causes it to be high (bad): |
LCP, arguably the most crucial web vital, measures how long users wait for a web page to become usable after navigation. If your LCP is high, you should first address FCP improvement. A significant time gap between FCP and LCP indicates delayed loading of essential content after the initial page load, leading to reflows that can worsen LCP. Some prefer batching visual changes to prevent incremental rendering, thus improving CLS. Another approach is to display minimal content or placeholders, reducing reflows. Ultimately, to enhance LCP, minimize the time it takes to display all critical content visible in the viewport. | Similar to FCP, this means that your web pageâs visual content appears on the screen quickly for your users. | Same reasons as FCP, plus:
Dynamic content that appears above the fold after the FCP |
Web Vital: Cumulative Layout Shift (CLS)
What it means if itâs high (bad): | What it means if itâs low (good): | What causes it to be high (bad): |
High CLS indicates content that shifts during page loading, often observed as content appearing in one position then moving elsewhere. Typically, developers need to address this issue. Analytics tags seldom affect CLS as they lack visual elements. To resolve, identify dynamically appearing content causing shifts. Solutions include pre-allocating space for dynamic content or deferring content display until all is ready. Spinners typically don't impact CLS as they don't change position. | A low CLS is unrelated to TTFB, FCP, or LCP. Excellent CLS doesn't guarantee good overall performance if other web vitals are poor. Similarly, good TTFB, FCP, and LCP numbers don't guarantee a good CLS score because CLS measures a distinct aspect of user experience. Users might tolerate a poor CLS if layout shifts occur rapidly before they interact with page content, minimizing disruption to their workflow.
| Lots of dynamic content that appears after FCP and causes already-visible content to move. The bigger the content that moves, the bigger the CLS. |
Conclusion
Web Vitals can be found in the Page Details Report within the Audits you run. You can see these metrics at an Audit-wide level or an URL level by clicking on any URL in the Pages Report. You will see the performance metrics that can help you analyze and understand how your users perceive your website. A proper interpretation of the results using this guide will empower your team take the right actions.