I recently ran a Lighthouse audit on my portfolio and the results were humbling. Accessibility, Best Practices, SEO, all great. But Performance? **77 out of 100**. The biggest red flag was a Largest Contentful Paint (LCP) of **6.5 seconds**. That's embarrassingly slow for what is essentially a static portfolio site. ![Lighthouse report showing a performance score of 77](/blog-images/lighthouse_77_score.png) So I dug in. What I found wasn't a single catastrophic bug, it was a collection of very common frontend mistakes that compound into a slow experience. After fixing everything, I hit a perfect 100 across the board. Here's exactly what was wrong and how I fixed each issue. No vague tips, just actual code, actual tradeoffs, actual reasoning. ## Understanding What Lighthouse Actually Measures Before jumping into fixes, it's worth understanding what the numbers mean. Lighthouse evaluates your page through **Core Web Vitals**, real metrics that reflect how a user *experiences* your page: - **LCP (Largest Contentful Paint):** When does the biggest visible element finish rendering? Target: under 2.5 seconds. - **FCP (First Contentful Paint):** When does *anything* first appear on screen? Even a single line of text counts. - **TBT (Total Blocking Time):** How long does JavaScript lock up the main thread, making the page feel frozen? - **CLS (Cumulative Layout Shift):** Do things jump around while loading? That jittery experience where a button moves right as you try to click it. - **Speed Index:** How quickly does the viewport visually fill in? My FCP, TBT, CLS, and Speed Index were all green. The sole culprit was LCP at 6.5s, more than double the "poor" threshold. Fixing this one metric was the key to everything. ## Problem 1: State-Gated Rendering Is an LCP Killer This was the single biggest hit to performance, and it's a pattern I see everywhere in React codebases. My hero section had an entrance animation. To make the text fade in after the page loads, I used a common React pattern: ```tsx const [mounted, setMounted] = useState(false) useEffect(() => { setMounted(true) }, []) // In the JSX: I craft interfaces that work. ``` Looks harmless. It's actually catastrophic for LCP, and here's exactly why. ### The Hydration Timeline In a Next.js app, the server renders your component into HTML and sends it to the browser. The browser paints this HTML immediately, and this is what makes SSR fast. But this HTML is *dead*. It has no event listeners, no state, no interactivity. **Hydration** is the process where React runs on the client, walks through the existing DOM, and "wakes it up" by attaching `onClick` handlers, initializing `useState`, and making everything interactive. Here's the critical timing issue: ``` Server sends HTML → Browser paints it (hero text is opacity: 0) → Browser downloads JS bundle → React hydrates the page → useEffect fires → setMounted(true) → React re-renders → opacity becomes 1 → Browser finally paints the LCP element ❌ ``` The browser *sees* the hero text in the DOM from the very first frame. But because it's at `opacity: 0`, it doesn't count as a "contentful paint." The browser waits. React hydrates. `useEffect` fires. State updates. Re-render happens. And only *then* does the text become visible and LCP gets recorded. That entire sequence (download JS, parse, hydrate, effect, re-render) took **980ms** on my page. Almost a full second of delay, just because I wanted a fade-in animation. ### The Fix: CSS Animations Replace JS State The solution is to let CSS handle the entrance animation entirely. No JavaScript involvement during the critical paint path: ```css /* globals.css - extracted at build time, available before JS loads */ @keyframes hero-fade-up { from { opacity: 0; transform: translateY(1rem); } to { opacity: 1; transform: translateY(0); } } .hero-fade-up { animation: hero-fade-up 0.7s ease-out both; } ``` ```tsx // No mounted state, no useEffect I craft interfaces that work. ``` The element is in the HTML from the server. The CSS animation is in the stylesheet, loaded before any JS runs. The browser can paint it immediately, the animation plays from CSS alone, and LCP drops from 6.5s to under 1.2s. The key insight: **`animation-fill-mode: both`** (the `both` keyword in the shorthand) applies the `from` state during the delay period and preserves the `to` state after the animation finishes. So the element starts invisible via CSS, not JavaScript, and stays visible after the animation without needing any state. **Takeaway:** Never gate above-the-fold content behind `useEffect` or `useState`. If you need entrance animations, use CSS `@keyframes` with `animation-delay`. The browser doesn't need React to play an animation. ## Problem 2: Nuking the Image Optimization Pipeline My `next.config.mjs` had this: ```js const nextConfig = { images: { unoptimized: true, }, } ``` One line. It was responsible for **881 KiB** of wasted bandwidth on every page load. ### What This Flag Actually Does Next.js has a built-in image optimization server. When you use the `` component, it doesn't simply render an `` tag pointing to your file. It rewrites the `src` to `/_next/image?url=...&w=640&q=75`, an API route that receives the image request, runs it through the `sharp` library, and serves an optimized version. The pipeline does five things: **1. Re-encodes to modern formats (WebP, AVIF)** JPEG and PNG are legacy formats. WebP delivers 25-35% smaller files with equivalent quality. AVIF pushes that to 50% or more. If you were doing this manually in a vanilla HTML project, you'd use a build script: ```js const sharp = require('sharp') sharp('hero-image.png') .webp({ quality: 80 }) .toFile('hero-image.webp') ``` Next.js negotiates this automatically via the `Accept` header. If the browser supports AVIF, it gets AVIF. If it supports WebP, it gets WebP. Otherwise, the original format. **2. Resizes to the actual display size** My profile avatar was displayed at **56×56 pixels**. The source file, `master-logo.png`, was **640×640 pixels** and weighed **393 KiB**. That's a 56px circle on screen receiving a 640px image. For retina screens, you'd want 2x, so 112×112 pixels. A WebP at that size is about **5 KiB**. That's a 98.7% reduction. **3. Generates a responsive `srcset`** Different devices need different image sizes. A phone with a 375px viewport doesn't need the same 1200px-wide hero image that a desktop monitor does. In plain HTML, you'd write the `srcset` manually: ```html Hero photo

``` The browser reads `sizes` ("this image takes up 100% of the viewport on mobile, 50% on desktop"), looks at the `srcset`, considers the device pixel ratio, and picks the smallest image that will look sharp. Next.js generates the `srcset` for you using the widths in the `images.deviceSizes` and `images.imageSizes` config. But you still need to provide the `sizes` prop because without it, Next.js defaults to assuming the image is 100vw wide. **4. Lazy loading** Images below the fold don't need to load immediately. The native HTML attribute `loading="lazy"` tells the browser to defer fetching the image until it's approximately one viewport away from being visible. Next.js adds this to every `` by default (unless you set `priority`). **5. CLS prevention** When an image loads without known dimensions, the browser doesn't know how tall it will be. The surrounding content shifts down once the image arrives, and this is Cumulative Layout Shift. Next.js prevents this by always rendering the image container with the correct aspect ratio, either through explicit `width`/`height` props or the `fill` prop within a positioned parent. ### So What About `priority` and Prefetch? For above-the-fold images that you *want* to load immediately, Next.js provides the `priority` prop: ```tsx

in the document head /> ``` This tells the browser: "Fetch this image before anything else." It injects a `` tag in the ``, giving the image priority in the network queue. Use it for the LCP image and nothing else, because if you preload everything, you preload nothing. ### The One-Line Fix ```js const nextConfig = { images: { formats: ['image/avif', 'image/webp'], }, } ``` Remove `unoptimized: true`. That's it. The entire optimization pipeline comes alive. I also added `sizes` props to all my `` components so the browser always knows the correct size to request: ```tsx

``` I also had raw `` tags in my articles section for blog thumbnails. Those bypass the entire optimization pipeline. Switching to `` with proper `sizes` gave me automatic format conversion, lazy loading, and CLS prevention for free: ```tsx // Before: raw HTML, no optimization {article.title}

// After: full optimization pipeline {article.title}

``` ## Problem 3: Runtime CSS Injection With ` ``` This looks convenient but it's architecturally flawed. ### How CSS Gets to the Browser: Two Paths **Path 1: Build-time extraction (good)** CSS written in `globals.css`, CSS Modules, or Tailwind utility classes gets processed by the bundler at build time. The output is a static `.css` file that the browser downloads right alongside the HTML. The CSS exists before any JavaScript runs. ``` Browser receives HTML → Sees → Downloads CSS → Builds CSSOM → Paints the page ✅ Keyframes are available from the very first frame ``` **Path 2: Runtime injection (problematic)** CSS-in-JS approaches like `styled-jsx`, `styled-components`, or `Emotion` generate CSS at runtime. The browser does this: ``` Browser receives HTML → Downloads JS → JS executes → styled-jsx injects a

Articles & insights

Article list

How I Took My Portfolio From 77 to 100 on Lighthouse

Unlocking Browser Power: WebContainers & SharedArrayBuffer

Let's build