The 5 metrics, with fixes
1. Largest Contentful Paint (LCP)
LCP measures how long the main content — usually the hero image or H1 — takes to appear. Good is 2.5 seconds or less at the 75th percentile of real mobile visits.
Slow LCP usually comes from a slow server, render-blocking CSS and JavaScript, web fonts or a large hero image. Never lazy-load the LCP element and never animate it in from zero opacity.
Checklist
- Find the LCP element in PageSpeed Insights.
- Inline critical CSS and defer non-critical scripts.
- Serve the hero image in WebP or AVIF at the right size with fetchpriority=“high”.
- Use system fonts or preload a single font file.
- Do not lazy-load or fade in the LCP element.
Measure it with: LCP ≤ 2.5 s (Techtency™ target: under 1.8 s)
2. Interaction to Next Paint (INP)
INP measures how quickly a page responds to taps, clicks and typing. Good is 200 milliseconds or less. It replaced First Input Delay as a Core Web Vital in March 2024.
Poor INP comes from heavy JavaScript: large frameworks, chat widgets, tag managers and third-party scripts. Pages that feel fine on a laptop can respond slowly on mid-range Android phones.
Checklist
- Check INP in PageSpeed Insights field data.
- Remove or delay non-essential third-party scripts.
- Break up long JavaScript tasks.
- Load chat, maps and video only on click.
- Test on a mid-range Android phone.
Measure it with: INP ≤ 200 ms
3. Cumulative Layout Shift (CLS)
CLS measures how much a page jumps while loading. Good is 0.1 or less. Shifts frustrate users and cause mis-taps.
The usual causes are images without dimensions, embeds or banners without reserved space, late-loading fonts and content injected above existing content.
Checklist
- Add width and height to every image and video.
- Reserve space for embeds, ads and cookie banners.
- Never insert content above what is already shown.
- Use system fonts or sensible font-display settings.
- Re-check CLS after every design change.
Measure it with: CLS ≤ 0.1 (Techtency™ target: 0)
4. Time to First Byte (TTFB)
TTFB measures how long the server takes to start sending the page. About 0.8 seconds or less is a common good target; a slow TTFB delays everything else.
Slow TTFB usually comes from cheap shared hosting, no page caching, slow database queries or servers far from visitors. A CDN and server-level caching fix most cases.
Checklist
- Measure TTFB from India in PageSpeed Insights or WebPageTest.
- Enable full-page caching at the server or CDN.
- Use hosting with servers in or near India.
- Fix slow queries and plugins.
- Purge and re-warm the cache after deployments.
Measure it with: TTFB ≤ 0.8 s
5. Crawlable HTML
Search engines can render JavaScript, but rendering can be delayed, and many AI crawlers fetch raw HTML and may not run scripts. If prices, answers or product details appear only after JavaScript runs, some crawlers may never see them.
Server-render or pre-render key content, keep page weight reasonable and do not block verified bots at the firewall. This is not a Core Web Vital, but it decides whether search and AI tools can read and cite a page at all.
Checklist
- Use View Source to confirm key text is in the HTML.
- Server-render or pre-render JavaScript-framework pages.
- Keep FAQs and answers visible, not loaded on click.
- Allow verified search and AI crawlers in robots.txt and your firewall.
- Watch crawl stats in Search Console and Bing Webmaster Tools.
Measure it with: Key content present in the initial HTML
Prefer to hand this to a team that already works this way? Get a written scope for your site.
