Let's Connect

MacBook with web performance code on screen

Core Web Vitals are how Google measures real user experience — and they are a ranking signal. When clients come to me with a 'slow site', the work is rarely mysterious: the same handful of issues cause most red scores. Here is my working checklist for each metric.

LCP: get the hero on screen fast

  • Serve images as WebP/AVIF, sized to the actual layout slot, via a CDN
  • Preload the LCP image and the critical font; never lazy-load above-the-fold media
  • Cut server time: cache rendered pages or fragments — TTFB above ~500 ms makes green LCP nearly impossible

CLS: stop the page from jumping

Every image and embed gets explicit width and height (or aspect-ratio) so the browser reserves space. Ads and banners render into fixed-size containers. Fonts load with font-display: swap plus a metric-compatible fallback to avoid layout-shifting swaps. CLS is almost always a 'reserve the space' problem.

INP: do less JavaScript

Interaction to Next Paint punishes heavy main threads. Ship less JS: code-split routes, defer third-party scripts, and move analytics off the critical path. In Next.js, keep components server-side by default and make only truly interactive islands client components — the architecture does the optimization for you.

Measure like Google does

Lab tools (Lighthouse) guide debugging, but ranking uses field data — the CrUX dataset of real Chrome users. Check Search Console's Core Web Vitals report and PageSpeed Insights' field section. Optimize until the field numbers turn green, then add a performance budget to CI so they stay that way.

Performance is a feature you ship once and defend forever.Md Raihan Hasan