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


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.
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"
ormedia="(max-width: 600px)"
for non-critical CSS.Use
async
ordefer
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.
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 imageBlock-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.
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
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 ?
DNS Lookup Time
TCP Connection Time
TLS Handshake (if HTTPS)
Server Processing Time
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.
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 |