Mastering Core Web Vitals: The Complete Guide to TTFB, FCP, LCP, INP, CLS & More

Murali SinghMurali Singh
6 min read

In today's performance-first web, speed isn’t just a nice-to-have, it's a ranking factor and a core part of user experience. Google’s Core Web Vitals provide a set of standardized metrics to evaluate how fast, responsive, and stable your site feels to real users.

This blog breaks down TTFB, FCP, LCP, INP, and CLS the essential metrics every developer and SEO should understand along with important Lighthouse metrics like TBT and Speed Index. We keep it precise, actionable, and up to date.

First Contentful Paint (FCP)

FCP measures the time from when the browser starts loading the page to when any content is first rendered on the screen.

For this metric, content refers to text, images (including background images), <svg> elements, or non-white <canvas> elements.

To provide a good user experience, sites should strive to have FCP of 1.8 seconds or less.

Good FCP values are 1.8 seconds or less, poor values are greater than 3.0 seconds, and anything in between needs improvement

How to Improve FCP ?

1. Use preload for Critical Resources

  • Preload key assets like fonts, hero images, or important CSS/JS files.

  • This tells the browser to fetch these resources early, speeding up rendering.

  • Example:

      <link rel="preload" href="/fonts/myfont.woff2" as="font" type="font/woff2" crossorigin="anonymous" />
    

2. Use preconnect to Speed Up External Requests

  • Establish early connections (DNS lookup, TCP handshake, TLS negotiation) to important third-party domains.

  • Helps reduce the time waiting for resources like fonts, analytics, or APIs.

  • Example:

      <link rel="preconnect" href="https://fonts.googleapis.com" crossorigin />
    

3. Minify CSS and JavaScript

  • Remove unnecessary whitespace, comments, and reduce file size by minifying CSS and JS.

  • Smaller files download and parse faster, improving FCP.

4. Reduce Unnecessary CSS and JavaScript Load

  • Only load critical CSS needed for above-the-fold content initially.

  • Defer or asynchronously load non-critical JS and CSS (e.g., below-the-fold or interactive features).

  • Techniques:

    • Inline critical CSS in <head>.

    • Use media="print" or media="(max-width: 600px)" for non-critical CSS.

    • Use async or defer attributes on script tags.

5. Eliminate Render-Blocking Resources

  • CSS and JS files that block the browser from painting delay FCP.

  • Optimize by splitting and loading only essential styles/scripts first.

Bonus Tips:

  • Optimize images (compress, use modern formats like WebP).

  • Use a fast CDN and server.

  • Avoid slow fonts by using font-display: swap.

For more details refer :
https://web.dev/articles/fcp


Largest Contentful Paint (LCP)

It reports the render time of the largest visible content element.

To provide a good user experience, sites should strive to have LCP of 2.5 seconds or less.

Good LCP values are 2.5 seconds or less, poor values are greater than 4.0 seconds, and anything in between needs improvement

What Elements are consider for measurement of LCP?

As specified in the Largest Contentful Paint API, the types of elements considered are:

  • <img> elements

  • <image> inside <svg>

  • <video> poster image

  • Block-level elements with text nodes (e.g., <h1>, <p>)

  • Elements with background images (only if using CSS background-image)

For more details refer :
https://web.dev/articles/lcp
https://web.dev/articles/optimize-lcp


INP (Interaction to Next Paint)

  • Measures the time from user interaction (click, tap, key press) to the next visual update.

  • Considers all interactions on the page, not just the first.

  • Reports the longest reasonable interaction latency, excluding outliers.

  • Replaced FID (First Input Delay) as a Core Web Vital in 2024.

  • FID only measured the first interaction delay.

  • INP is more comprehensive and reliable than FID.

  • Below 200ms → Good

  • 200–500ms → Needs improvement

  • Above 500ms → Poor

  • Poor responsiveness leads to user frustration and lower engagement.

Good INP values are 200 milliseconds or less, poor values are greater than 500 milliseconds, and anything in between needs improvement.

For more details refer :
https://web.dev/articles/inp
https://web.dev/articles/optimize-inp


Cumulative Layout Shift (CLS)

CLS (Cumulative Layout Shift) measures how visually stable a webpage is during its load and use.
It tracks unexpected shifts of elements on the page like text or buttons moving after you have started reading or interacting. It tells you if elements jump around on the screen, which can cause poor user experience.

Before 2021

  • Measured across entire page lifecycle (from load to unload).

  • All layout shifts counted, regardless of user interaction or time.

  • No session window concept.

  • Penalized long sessions and infinite scrolling pages unfairly.

  • Layout Shifts triggered from user input were still included.

  • CLS could increase endlessly with time.

After 2021 (June update)

  • Introduced layout shift session windows:

    • Max 5 seconds long.

    • Ends if no layout shift for 1 second.

  • Only the highest-impact session window is used for the final CLS score.

  • Layout Shifts triggered by user input are excluded.

  • Infinite scrolling no longer causes cumulative penalties.

  • Fairer for long-lived or interactive pages.

  • Good threshold below 0.1

Good CLS values are 0.1 or less, poor values are greater than 0.25, and anything in between needs improvement

The Layout Shift Score is calculated as:

Layout Shift Score = Impact Fraction × Distance Fraction

  • Impact Fraction: It’s basically a calculation of how much an element occupies in the viewport before and after the shifting.

  • Distance Fraction: It is the greatest horizontal or vertical distance any unstable element has moved in the frame divided by the viewport's largest dimension (width or height, whichever is greater).

Example:
If 50% of the viewport shifts and the elements move 25% of the viewport height, the layout shift score is: 0.5 × 0.25= 0.125

Please refer the articles link there you will get exposure to more examples.

For more details refer :
https://web.dev/articles/cls
https://web.dev/articles/optimize-cls


Time to First Byte (TTFB)

TTFB is a metric that measures the time between the request for a resource and when the first byte of a response begins to arrive.

What’s Included in TTFB ?

  1. DNS Lookup Time

  2. TCP Connection Time

  3. TLS Handshake (if HTTPS)

  4. Server Processing Time

Good TTFB values are 0.8 seconds or less, poor values are greater than 1.8 seconds, and anything in between needs improvement

Why High TTFB is a Problem

  • Delays the start of all rendering

  • Pushes back FCP, LCP, and overall page load time

  • Hurts both SEO and user perception of speed

To provide a good user experience, sites should strive to have TTFB of less than 0.8 seconds (800ms).

For more details refer : https://web.dev/articles/ttfb


Total Blocking Time (TBT)

  • It is a metric which calculates the total time between FCP and Time to Interactive(TTI) during which the main thread is blocked.

  • Indicates how long the browser was too busy to respond to user input.

  • Strongly correlated with INP (which is a Core Web Vital).

  • High TBT suggests poor interactivity because JavaScript is doing too much.

  • Heavily weighted when calculating the Performance score of page (30%).

  • To provide a good user experience, sites should strive to have a Total Blocking Time of less than 200ms when tested on average mobile hardware.

For more details refer : https://web.dev/articles/tbt


Speed Index (SI)

  • It is a metric which measures how quickly content is visually displayed during page load.

  • Helps identify how smoothly content appears.

  • Can show issues not caught by FCP/LCP if content paints unevenly.

For more details refer : https://developer.chrome.com/docs/lighthouse/performance/speed-index


Understanding and optimizing Core Web Vitals is no longer optional it's essential for ranking well and delivering a great experience. With TTFB, FCP, LCP, INP, and CLS now tightly integrated into Google’s real-world performance scoring, each millisecond matters.

By combining field-focused metrics with lab tools like Lighthouse (and watching TBT and Speed Index), you’ll have a full picture of your performance story and the tools to fix it.

Start with what matters, measure continuously, and optimize smart.

1
Subscribe to my newsletter

Read articles from Murali Singh directly inside your inbox. Subscribe to the newsletter, and don't miss out.

Written by

Murali Singh
Murali Singh

Remote SWE | JavaScript | OpenSource Engineer | Loves to build scalable systems |