Core Web Vitals are part of Google’s Web Vital measurements using the Lighthouse tool, and they apply to all pages. The current CWV relevant measurements focus on three aspects of the user experience; loading, interactivity, and visual stability, and they are:
- Largest Contentful Paint (LCP) – this should be under 2.5 seconds
- First Input Delay (FID) – this should be under 100 milliseconds
- Cumulative Layout Shift (CLS) – should be below 0.1
These three metrics should be under recommended values for at least 75% of page loads for mobile and desktop devices.
Table of Contents
Core Web Vitals basics
Largest Contentful Paint (LCP) measures when the largest content element in the viewport becomes visible, meaning what you see on the screen when a web page loads without scrolling. Google considers an LCP under 2.5 seconds to be fast, while an LCP of over 4 seconds is bad.
The most common causes of a poor LCP are:
- Slow server response times
- Render-blocking JavaScript and CSS
- Slow resource load times
- Client-side rendering
First Input Delay (FID) measures the time from when a user first interacts with a page (when they click a link, tap on a button, or use a custom, JavaScript-powered control) to the time when the browser is actually able to begin processing event handlers in response to that interaction. To provide a good user experience, sites should strive to have an FID of less than 100 milliseconds, while an FID of more than 300 milliseconds is considered bad.
The First Input Delay is measured only for ‘field data‘ and is available in Google Search Console. When testing pages with Lighthouse tools, to help predict FID look at Total Blocking Time (TBT), which measures different things, but improvements in TBT usually correspond to improvements in FID. The main cause of a poor FID is heavy JavaScript execution.
Cumulative Layout Shift (CLS) measures the unexpected layout shift that occurs during the page load. A layout shift occurs whenever a visible element changes its position from one rendered frame to the next. Ideally, this should be under 0.1. Scores over 0.25 are considered a poor user experience.
The most common causes of poor CLS are:
- Images without dimensions
- Ads, embeds, and iframes without dimensions
- Dynamically injected content
- Web Fonts causing FOIT/FOUT
- Actions waiting for a network response before updating DOM
Measuring Core Web Vitals
To measure Core Web Vitals, you can use the following online tools that use the Google Lighthouse tool for testing; PageSpeed Insights, WebPageTest.org, GTMetrix, Google Search Console, and web.dev’s measure tool. If you are using Chrome or Edge browsers, you can also install the Web Vitals Chrome extension or use the inbuilt Lighthouse tool within Chrome DevTools for in-browser testing. All these tools, except for the Google Search Console, give you so-called ‘lab data’ while the GSC will give you ‘field data’ scores (actual user experience while loading and interacting with the web pages) relevant to SEO. Please note that Google Search Console ‘field data‘ is available only if you have enough website visitors.
Other Web Vitals
First contentful paint (FCP): measures the time from when the page starts loading to when any part of the page’s content is shown on the screen. Essentially this is when the user perceives the site as starting to load. Ideally, we want this under 1.5 seconds as that is perceived as fast by users.
To improve First Contentful Paint in general:
- Eliminate render-blocking resources
- Minify CSS
- Remove unused CSS
- Preconnect to required origins
- Reduce server response times (TTFB)
- 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 the Webfont load
- Keep request counts low and transfer sizes small.
Time to Interactive (TTI): measures the time from when the page starts loading to when it’s visually rendered, its initial scripts (if any) have loaded, and it’s capable of reliably responding to user input quickly.
To improve Time To Interactive in general:
- Minify JavaScript
- Preconnect to required origins
- Preload key requests
- Reduce the impact of third-party code
- Minimize critical request depth
- Reduce JavaScript execution time
- Minimize main thread work
- Keep request counts low and transfer sizes small.
Total blocking time (TBT): measures the total amount of time between First Contentful Paint (FCP) and Time to Interactive (TTI), essentially the amount of time where the website is not responding to user input or commands. Lower is always better here; ideally, we want this under 300ms when measured on the mobile device.
To improve Total Blocking Time in general:
- Reduce the impact of third-party code
- Reduce JavaScript execution time
- Minimize main thread work
- Keep request counts low, and transfer sizes small
Other metrics when testing the speed of web pages
Time to First Byte (TTFB) is how quickly the web server starts sending data. It should typically be 0.1-0.2 in the country the site is hosted in and 0.2-0.5 internationally. Higher than this is likely a problem. FAST is consistently 0.1 or below.
Fully Loaded Time is when the Document Complete or Window Loaded event has been reached, AND the site has had no network activity for 2+ seconds. This metric can be misleading as even small amounts of marketing code can make this really high. The difference between this timing and Document Complete Time is usually how long it takes for your third-party code like Analytics, Affiliate Code & Ads, and Facebook Pixels to load.
