Performance & UX
·8 min read

[Guide] Core Web Vitals: What They Are and How to Improve Them

If you’ve started to dig into the technical side of SEO, inevitably the term Core Web Vitals will have come across your path. In this post, we’ll explore not only what Core Web Vitals are, but also how you can take steps to improve them on your website.

What are Core Web Vitals?

Before learning about Core Web Vitals, we must first define the broader term, Web Vitals, and explain the motivation behind their creation. Web Vitals is a project spearheaded by Google to give web developers consistent recommendations for performance measurements. The design of each metric ensures that they assess signals that predict superior user experiences on the web.

Core Web Vitals are a curated subset of metrics selected from the full list of Web Vitals. Google recommends anyone with a website check their Core Web Vitals to evaluate the user experience (UX) of their site.

They display the results of Web Vital diagnostic tests throughout many of their developer tools, like Page Speed Insights and Lighthouse. Each vital is selected because they believe it’s one of the most relevant vitals for improving UX. Each of these vitals captures a unique aspect of the UX that aims to reflect the real-world experiences of users on the web.

How does Core Web Vitals impact SEO?

Google’s secrecy when it comes to disclosing what variables factor into SEO ranking is infamous. The specific extent to which bad performance harms SEO ranking is unknown, but Google and their developer advocates have made numerous public statements confirming that sites with poor Lighthouse scores will be ranked lower than sites with good Lighthouse scores. Which brings us to Lighthouse and our next important question.

How do you measure and evaluate core web vitals?

Lighthouse collects "Lab data" (also known as synthetic data) from a controlled environment to measure different web vitals. It is important to note that this data is not derived from actual users since it's going to run scripts with synthetic data.

This puts them in sharp contrast with real user metrics (RUM) since the data can be collected during the development process and incorporated into CI processes. Another example of a tool that collects synthetic data is WebPageTest.

On the other hand, Google’s Page Speed Insights provides results that are based on a mixture of real-world data and lab data, which can provide another perspective of a site’s performance.

What are the Primary Vitals and what do they measure?

There are many web vitals you can track, but there are specifically three that are referred to as Core Web Vitals. These metrics are:

  • Largest Contentful Paint: when the largest element on the page becomes visible, which helps Google understand how users will perceive page load speed.
  • First Input Delay: how long it takes before the user can interact with the content they see on the page, telling Google how quickly the page becomes “usable” from the user perspective.
  • Cumulative Layout Shift: how much the elements on the page move around while the page is loading, which helps Google evaluate how stable the user’s experience on the page will be.

Let’s take a closer look at each of these metrics and how you can improve them.

Get a free starter kit to help find your first client!

Check out our starter kit Notion template to help you kick off your web development freelance journey successfully!

Largest Contentful Paint (LCP) and how to improve it

What is Largest Contentful Paint?

Largest Contentful Paint (LCP) observes the time needed for the largest element to load and appear on the user’s screen. This is important because users want to be immediately served viewable content when they open the page instead of having to wait and stare at a blank screen. According to Google, the following elements are considered for Largest Contentful Paint:

  • <img> tags
  • <image> tags within an <svg> tag
  • <video> tags
  • Tags loading a background image with the url() function
  • Block-level tags containing nodes or inline-level text elements.

The element size that is reported will usually be determined by the size that is visible to users within the viewport. Elements that extend outside the viewport do not count toward the final size. Google's guidelines advise aiming for less than 2.5 seconds across 75% or more of page visits.

To achieve this, Google recommends eliminating resource load delay and element render delay along with reducing resource load time and time to first byte (to understand these terms better, you can find them here, in Google’s documentation).

How can I reduce my LCP?

To reduce your LCP scores, consider the following strategies:

  • Load CSS stylesheets and JavaScript files asynchronously to eliminate render-blocking resources. Alternatively, the resources can be inlined directly inside the HTML.
  • Use DNS-prefetch or preconnect resource hints to initiate an early connection to any required third-party origins.
  • Defer unused or unnecessary JavaScript that delays rendering the page.
  • Compress and resize images to ensure as few bytes as possible are sent over the network.

You can observe granular timing information in JavaScript by utilizing performance APIs such as the Largest Contentful Paint API, the Navigation Timing API, and the Resource Timing API.

First Input Delay (FID) and how to improve it

What is First Input Delay?

First Input Delay (FID) detects the length of time from a user interacting with a page for the first time to the browser being able to process a response to that interaction.

For example, it would detect the length of time between when a user clicks a link on the page and when the browser responds to their click by processing event handlers. FID is calculated even if an event listener hasn’t been registered.

HTML elements like <input>, <textarea>, <select>, and <a> must wait for the browser’s main thread to complete any tasks that are in progress before they can respond to user interactions.

Google's guidelines advise aiming for 100 milliseconds or less for FID across at least 75% of page loads.

How can I reduce my site’s FID?

To achieve the ideal FID, Google recommends breaking up long tasks, optimizing the page for interaction readiness by minimizing the data needed for post-processing on the client, and freeing up more capacity on the main thread.

To reduce your FID scores, consider the following strategies:

  • Offload computation to a web worker so the main thread is not blocked. Partytown is a library built specifically for this task and can be integrated with many popular JavaScript frameworks.
  • Minimize work on the main thread since the less work the main thread has to do, the more responsive it will be to input events. To minimize this work, use efficient algorithms and data structures. For example, don’t sort an array of 10 items when only the first five items are needed. Break up work into smaller chunks such as parsing a large JSON file in pieces instead of all at once.
  • Use requestIdleCallback() API to allow developers to schedule work to be done when the main thread is idle. Low-priority work can be performed in the background without disturbing any latency-sensitive events. It’s similar to setTimeout(), but instead of scheduling work to be done as soon as possible, requestIdleCallback() schedules work to be done when the main thread is idle. If there’s no idle time before the scheduled time, work will happen immediately.

Not signed up for The Optimized Dev?

Staying on the leading edge of web development just got easier. Explore new tech with a fun, scaffolded coding challenge that lands in your inbox once a month.

Cumulative Layout Shift (CLS) and how to improve it

What is Cumulative Layout Shift?

Cumulative Layout Shift (CLS) measures how much elements on the page move from their initial position as the page loads.

Google guidelines advise having a CLS score of 0.1 or less for 75% of pages or more. They recommend including image dimensions such as width and height size attributes, anticipating and alleviating layout shifts from advertisements, avoiding dynamically inserting new content on top of existing content, and using transform animations.

How can I reduce my Cumulative Layout Shift?

To reduce your Cumulative Layout Shift, consider the following strategies:

  • Lazy-load offscreen images and videos rather than loading all images and videos when the page first loads. Only loading those that are visible in the viewport reduces the amount of layout shifts that can occur as new content is loaded.
  • Minimize third-party scripts by reducing or eliminating scripts that aren’t needed for your page to function. These can cause unexpected layout shifts when they load.
  • Under the "Core Web Vitals" section of Google Search Console you can find a report on your site's CLS score. This report can help you identify specific URLs that are affecting your score.

How Web Vitals patterns can further improve performance

The Web Vitals patterns are a curated selection of patterns designed to attain high scores on Core Web Vitals. They target common UI components that are frequently difficult to optimize. provides a list of these patterns and recommendations for how to avoid common problems:

  • Carousel - A component that displays content like a slideshow with each image cycled through, one by one. A page’s LCP element can be contained within large carousels above the fold and impact LCP scores. CSS scroll snaps can be used to create transitions free of layout shifts.
  • Fonts - Browsers typically delay rendering any text that uses a web font that hasn't been loaded yet. FCP and LCP can be delayed due to fonts loading too late and layouts can shift when the text finally renders the correct font. This can be avoided by using inline font declarations, the WOFF2 font format, or preconnect resource hints. See's Best practices for fonts for more details on those techniques.
  • Images - Layout shift can be caused by images if they load after the rest of the page has already been rendered. This happens more often with slow-loading images due to weak internet connections or images with large file sizes. This can be avoided by specifying the width and height of the image or by using density descriptors.
  • Infinite Scroll - A continuous stream of content is loaded and appended to the page as the user continues to scroll past the end of the currently available content. This technique may lead to layout shifts with some implementations. See’s infinite scroll implementation for an example of how to use JavaScript when creating an infinite scroll to avoid causing any layout shifts.
  • Banners and Notices - Banners and notices commonly cause layout shifts because lower page elements are pushed further down the page when a banner is inserted into the DOM after the rest of the page has already been rendered. Adding a banner that slides in from the bottom can avoid layout shift. Modals can also be used as alternatives to banner notices.
  • Placeholders - One solution to layout shifts that occur from injected page content is reserving space for anticipated content with a placeholder. They can also be used along with lazy-loading to visually indicate to the user that fresh content is loading.
  • Video - Video can cause layout shifts and can also delay LCP by monopolizing network resources. This delays the loading of other page resources. The <video> tag can be used to display a poster image which doesn't cause layout shift.

Final thoughts

Core Web Vitals are a collection of metrics designed to capture important aspects of the user experience. They can be a complex and bewildering array of metrics. Thankfully, the creators behind these metrics have gone to great lengths to explain the purpose of each metric and how to address them. Google provides tools to help developers measure their Core Web Vitals scores and offers recommendations on how to improve them.

Some common techniques for improving Core Web Vitals scores include optimizing images, fonts, and videos; reserving space for content with placeholders; and using alternatives to banner ads and modals. By taking the time to improve their site's performance on these metrics, developers can make a real difference in the user experience of their visitors all over the world. And furthermore, they can impact the business outcomes that their websites are designed to support.

Article written by

Anthony Campolo

Anthony Campolo is a Developer Advocate at QuickNode, a member of the RedwoodJS core team, and co-host of the FSJam Podcast. He contributes articles, podcasts, and presentations about various open-source tools and frameworks.

More posts
A portrait of Anthony Campolo in a blue shirt, smiling.

Join the discussion

Hit your website goals

Websites success stories from the Prismic Community

How Arcadia is Telling a Consistent Brand Story

Read Case Study

How Evri Cut their Time to Ship

Read Case Study

How Pallyy Grew Daily Visitors from 500 to 10,000

Read Case Study