Key takeaways
- Google grades three field metrics from real Chrome users: LCP ≤ 2.5 s, INP ≤ 200 ms, CLS ≤ 0.1 (at the 75th percentile). INP replaced FID in March 2024 and is where most WordPress sites now fail.
- Indian mobile reality: median 4G throughput is modest and devices are mid-range, so image weight and JavaScript hurt more here than in the US benchmarks most guides assume.
- Fix order that works: TTFB (server/cache) → hero image → render-blocking CSS/JS → third-party scripts → layout shifts. Doing them in another order wastes a weekend.
- Lighthouse (lab) and CrUX (field) disagree constantly. Field data decides ranking; lab data tells you what to change. Use both — our speed & SEO check shows both side by side.
1. The three metrics
LCP — Largest Contentful Paint. Time until the biggest element above the fold (usually the hero image or heading) is visible. Bad LCP = slow server, heavy hero image, blocking CSS/fonts.
INP — Interaction to Next Paint. The slowest interaction (tap, click, key) on the page, from input to the next frame. Bad INP = heavy JavaScript on the main thread: page builders, sliders, chat widgets, tag managers firing 15 scripts.
CLS — Cumulative Layout Shift. How much the page jumps while loading. Bad CLS = images without dimensions, late-loading fonts, ads/banners injected above content, cookie bars pushing content.
2. Why Indian sites fail on mobile
- TTFB over 800 ms — shared hosting without page cache, WordPress with 40 plugins, no CDN. Nothing downstream can fix a slow first byte.
- Hero images of 1–3 MB — exported straight from a phone or Canva, no WebP/AVIF, no
srcset. - Page builders (Elementor/Divi/WPBakery) shipping 500 KB–1.5 MB of JS/CSS per page.
- Third-party scripts — Meta pixel, GA, Hotjar, chat widgets, WhatsApp buttons, each loading synchronously.
- Web fonts — four families, eight weights, no
font-display: swap.
3. The fix list, in order
Step 1 — Server & cache (fixes TTFB, helps LCP)
- Full-page cache (LiteSpeed Cache on Hostinger/LiteSpeed hosts; WP Rocket or FlyingPress elsewhere; NGINX FastCGI cache for custom stacks).
- A CDN in front (Hostinger CDN, Cloudflare). Target TTFB < 400 ms from Mumbai and Delhi.
- PHP 8.3, OPcache on, object cache (Redis) if the site is dynamic.
Step 2 — Hero image (fixes LCP)
- Resize to the displayed size (1600 px wide is enough for most heroes), convert to WebP/AVIF, ≤ 150 KB.
<link rel="preload" as="image">the LCP image; do not lazy-load it. Lazy-load everything below the fold.- Explicit
width/heighton every image (fixes CLS too).
Step 3 — CSS/JS (fixes LCP and INP)
- Inline critical CSS; load the rest async. Remove unused CSS (page builders are the usual culprit).
- Defer all non-critical JS. Delay third-party scripts until first interaction (most cache plugins can do this).
- Replace sliders with a static hero; replace heavy icon fonts with inline SVG.
Step 4 — Third parties (fixes INP)
- One tag manager, loaded after interaction; audit every tag quarterly; remove the ones nobody reads.
- Self-host fonts, 2 families × 2 weights max,
font-display: swap, preload the primary one.
Step 5 — Layout (fixes CLS)
- Reserve space for ads, embeds and cookie bars. Never inject content above existing content after load.
- Use
aspect-ratioCSS for video/iframe containers.
4. Numbers you can expect
A typical Indian WordPress business site goes from mobile 35–55 → 80–92 with Steps 1–3 alone, in one working day, without changing the design. Custom static sites (like this one) should sit at 90+; if they do not, it is almost always the hero media or an unoptimised script.
5. Measuring properly
- Field: Search Console → Core Web Vitals report (needs traffic); PageSpeed Insights "Discover what your real users are experiencing".
- Lab: Lighthouse mobile (throttled) for before/after on each fix.
- Re-test after caching has warmed; the first run after a change is always slow.
We do performance tuning as a fixed-scope engagement — before/after report included. Or run the free check and do Steps 1–3 yourself this weekend.