Frontend Performance Playbook: How I Get Core Web Vitals to 100/100

Clients frequently come to me after an expensive website redesign has quietly wrecked their Google PageSpeed scores - a visually stunning interface that scores 38 or 42 on mobile PageSpeed Insights and is visibly bleeding organic search rankings and conversion rates as a result.

As a Frontend Developer with over 12 years of experience, I've found that getting a site to a clean 100/100 is rarely about complex wizardry. It comes down to executing unglamorous, consistent engineering fundamentals.

1. Fix Images First: The Fastest Path to Low LCP

Oversized, non-optimized raster images remain the single biggest culprit behind poor Largest Contentful Paint (LCP) scores. I routinely see 4MB PNG hero graphics served to mobile devices with 375px screens.

The fix follows a disciplined three-point pipeline:

• Next-Gen Formats: Convert all images to WebP or AVIF, which yields 60–85% file size reductions over standard JPEG and PNG formats with zero perceptible visual degradation.
• Explicit Responsive Sizes: Use the HTML5 <picture> element or srcset attributes so mobile devices download 400px assets while 4K displays receive high-res variants.
• Preload Above-the-Fold Media: Use <link rel="preload" as="image"> on the hero element, and strictly set loading="lazy" on every image below the fold.

2. JavaScript Weight and Interaction to Next Paint (INP)

Every JavaScript package you install is a tax on your user's CPU and battery life. Bloated client bundles block the main thread, resulting in high Interaction to Next Paint (INP) scores where buttons take 300ms to register taps.

My default rule before installing any npm library is simple: can this be built with 25 lines of vanilla JavaScript instead of a 50KB bundle?

In React and Next.js applications specifically:

• Code-Split by Route: Ensure users only download the JavaScript required for the current view.
• Defer Non-Critical Third Parties: Analytics tags, feedback widgets, and social embeds should be deferred until after the first paint (or loaded only upon user interaction).
• Move to Server Components: As detailed in my guide on React.js to Next.js, server-rendered components send pure HTML to the client rather than shipping heavy JavaScript execution trees.

3. Layout Shifts (CLS) Are Sizing Problems

Cumulative Layout Shift (CLS) measures how much page content jumps around while loading. It is almost always caused by elements loading without reserved physical dimensions:

• Images and videos missing explicit width, height, or aspect-ratio CSS rules.
• Web fonts swapping in with mismatched fallback metrics (FOUT). Use font-display: swap paired with size-adjusted system fallback fonts.
• Dynamic marketing banners or cookie bars injected asynchronously above the main header.

/* Reserve aspect ratio space before image loads to eliminate layout shift */
.media-container {
  width: 100%;
  aspect-ratio: 16 / 9;
  background-color: var(--bg-surface-alt);
  overflow: hidden;
  border-radius: var(--radius-sm);
}

.media-container img {
  width: 100%;
  height: 100%;
  object-fit: cover;
  display: block;
}

4. The Mobile-First Reality: India and Emerging Markets

Optimizing for Core Web Vitals is not about chasing an arbitrary Lighthouse badge; it is about building for real people on the other end of the network.

In mobile-first markets like India, a significant portion of traffic comes from mid-range smartphones running on fluctuating 4G or congested public networks. When building platforms like Photocopywala.in (which serves 7,000+ daily users across India), keeping client bundles under 50KB is what makes the product feel instantaneous.

Read my case study on Building Photocopywala.in: A Speed and Scale Case Study for practical examples of client-side performance engineering.