1The Situation — Mobile 38

The site was feature-complete and well-designed. SEO 100, Accessibility 92, Best Practices 100. The only problem was Performance. The diagnostics made the cause clear.

LCP 110 seconds. Not a typo. The Hero image alone was 5.6MB, and there were 6 more images of similar size. 36MB total of images loading on a slow 4G connection — that's how you get 110 seconds.

CLS 0.5 was equally severe. A typewriter animation added characters one by one, pushing content down with each letter. Web fonts loading late caused text size changes on swap.

24-Phase Improvement Overview

Instead of changing everything at once, we fixed one thing at a time and measured after each change. This let us pinpoint exactly how much each optimization contributed.

3Phase 1: Image Compression

Images first, everything else later. The Hero image was 5.6MB, three service section images were 5-7MB each, plus background textures and photos — 6 images totaling 36MB.

Using Node.js sharp library with WebP quality 80, max width 1920px. 36MB total dropped to 0.8MB. This alone brought LCP from 110s to 6.8s.

4Phase 2: CLS Elimination

This phase delivered the biggest score improvement. CLS (Cumulative Layout Shift) measures how much elements shift during page load — and the culprit was unexpected.

The Culprit: Typewriter Animation

The homepage had a typewriter effect where characters appeared one by one. Visually appealing, but each added character changed the text's height and width, pushing content below it down. This component was used across 4 sections and accounted for 60-70% of total CLS.

Fix: Invisible Placeholder Pattern

The core idea is simple: render the full text from the start, but hide the not-yet-typed portion with visibility: hidden.

// Typed portion — visible
<span>{text.slice(0, typedCount)}</span>

// Not yet typed — occupies space but invisible
<span style={{ visibility: "hidden" }}>
  {text.slice(typedCount)}
</span>

This reserves the full text space from the start, locking the layout in place. Users see the same character-by-character reveal, but the browser sees zero layout changes.

Additional Fix: Header Suspense

The Header component was wrapped in Suspense with an 80px-tall empty div as fallback. But since the Header used position: fixed, it doesn't participate in document flow. The fallback's 80px space disappeared when the Header loaded, causing CLS. Fixed by changing the fallback to null.

5Phase 3: Font Optimization

The score change looks small, but this phase brought CLS to a perfect 0. The remaining 0.095 CLS was caused by web font loading that changed text sizes on swap.

Problem: Korean Font @font-face Explosion

Loading a CJK font like Noto Serif KR via next/font/google generates 120+ @font-face rules for Unicode range subsets. This alone adds ~26KB of render-blocking CSS — a scale that's hard to imagine with Latin fonts.

Fix: Custom Subset + Local Font

We extracted only the characters actually used on the site, generated a woff2 file containing just those glyphs via Google Fonts' text API, then loaded it with next/font/local. The @font-face rules dropped to 1, and render-blocking CSS went from 26KB to 3KB.

font-display: optional

font-display: swap shows the fallback font first, then swaps to the web font when loaded. This swap moment causes CLS and re-triggers LCP measurement. Switching to optional keeps the fallback if the font doesn't load within 100ms. On normal connections, the font loads within 100ms anyway, but this prevents font swap and CLS on slow connections.

6Phase 4: LCP Improvement

The final phase was bringing LCP down to 3.4 seconds. This is where we discovered the biggest trap.

The Trap: motion/react's opacity:0

The Hero section had a Framer Motion fade-in animation starting with initial={{ opacity: 0 }} and animating to animate={{ opacity: 1 }}.

The problem: during SSR, this renders as style="opacity:0". The browser excludes opacity:0 elements from LCP candidates. LCP only gets measured after JavaScript executes and sets opacity to 1, making LCP = JavaScript load + execution time. For a detailed analysis of this phenomenon, see our LCP opacity:0 trap analysis.

<motion.div
  initial={{ opacity: 0, scale: 0.95 }}
  animate={{ opacity: 1, scale: 1 }}
>
  <img src="/hero.avif"
       fetchPriority="high" />
</motion.div>

<motion.div
  initial={{ scale: 0.97 }}
  animate={{ scale: 1 }}
>
  <img src="/hero.avif"
       fetchPriority="high" />
</motion.div>

Additional: AVIF Conversion + Preload Cleanup

We converted the Hero image from WebP to AVIF for additional compression. We also found below-the-fold images missing loading="lazy" — Next.js auto-generates preload tags for img elements without lazy. These unnecessary preloads were competing with the Hero image for bandwidth.

7Key Lessons

What Not To Do