{"id":19,"date":"2026-06-06T21:48:40","date_gmt":"2026-06-06T21:48:40","guid":{"rendered":"https:\/\/softwareproduction.eu\/wordpress\/?p=19"},"modified":"2026-06-07T01:22:02","modified_gmt":"2026-06-07T01:22:02","slug":"ultimate-performance-optimization-chasing-that-100-lighthouse-score","status":"publish","type":"post","link":"https:\/\/softwareproduction.eu\/?p=19","title":{"rendered":"Ultimate Performance Optimization \u2014 Chasing That 100% Lighthouse Score"},"content":{"rendered":"\n

Masterclass in building a modern Nuxt 4 stack that hits Lighthouse 97\u2013100 on mobile without going \u201czero\u2011JS\u201d.<\/em><\/p>\n\n\n\n

\n\n\n\n

Performance Is an Architecture Decision<\/h2>\n\n\n\n

In large enterprise applications, performance rot rarely starts with \u201cslow code.\u201d It starts when the architecture cannot absorb new features without stacking more JavaScript, more requests, and more complexity on the critical path.<\/p>\n\n\n\n

Most teams:<\/p>\n\n\n\n

    \n
  1. Build features fast.<\/li>\n
  2. Ship.<\/li>\n
  3. Only care about performance when Lighthouse scores become embarrassing.<\/li>\n<\/ol>\n\n\n\n

    By that point, slow patterns are baked into the system. The only options left are tactical band-aids.<\/p>\n\n\n\n

    The mindset here is inverted: define performance targets first, then design the architecture so those targets are the default outcome.<\/strong> Optimization becomes a design constraint, not a cleanup phase.<\/p>\n\n\n\n

    \n\n\n\n

    Understanding the Metrics That Actually Matter<\/h2>\n\n\n\n

    Lighthouse simulates a real user on a mid-range phone over throttled 4G. It measures:<\/p>\n\n\n\n

      \n
    • How quickly something meaningful paints.<\/li>\n
    • How soon the page feels interactive.<\/li>\n
    • Whether the layout jumps around while loading.<\/li>\n<\/ul>\n\n\n\n

      The Performance<\/em> score (0\u2013100) is just a weighted composite of LCP<\/strong>, TBT<\/strong>, CLS<\/strong>, FCP<\/strong>, and Speed Index<\/strong>. The score is a proxy; the real goal is to keep each metric in the \u201cgood\u201d range where user-perceived performance and bounce rates are measurably better.<\/p>\n\n\n\n

      The targets:<\/p>\n\n\n\n

      Metric<\/th>Target<\/th>Why<\/th><\/tr><\/thead>
      LCP<\/strong> (Largest Contentful Paint)<\/td>< 2.5 s<\/td>Core Web Vitals \u201cgood\u201d threshold<\/td><\/tr>
      CLS<\/strong> (Cumulative Layout Shift)<\/td>< 0.1<\/td>Prevents content jumps<\/td><\/tr>
      TBT<\/strong> (Total Blocking Time)<\/td>< 200 ms<\/td>Page feels interactive quickly<\/td><\/tr>
      Lighthouse Performance<\/strong><\/td>\u2265 95 (mobile)<\/td>Competitive benchmark<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n

      Everything that follows exists to hit these numbers by design.<\/p>\n\n\n\n

      \n\n\n\n

      Layer 1: SSR as the Performance Foundation<\/h2>\n\n\n\n

      Server-Side Rendering is the foundational<\/strong> decision. With SSR, the server returns fully-rendered HTML for the initial request, so the browser can paint meaningful content before any JavaScript executes.<\/p>\n\n\n\n

      sequenceDiagram\n    participant U as User\n    participant B as Browser\n    participant S as Server\n    participant J as JS Runtime\n\n    U->>B: Request page\n    B->>S: HTTP request\n    S-->>S: Render complete HTML (SSR)\n    S-->>B: Return HTML\n    B-->>U: Paint content (FCP, meaningful content)\n    Note over B,U: Page visible, usable without JS\n\n    B-->>J: Load JS in background\n    J-->>B: Hydrate page\n    Note over B,U: Page becomes fully interactive<\/pre>\n\n\n\n
      In a client-rendered SPA, the browser first downloads a JS bundle, parses it, executes it, and then finally renders content. SSR shortcuts straight to \u201ccontent on screen,\u201d giving you an LCP advantage that no client-rendered approach can match.<\/p>\n\n\n\n
      This is what makes the later layers\u2014deferred hydration, same-origin images, lazy third-party scripts\u2014safe: the user always has real content immediately.<\/p>\n\n\n\n
      \n\n\n\n
      Layer 2: Multi-Tier Caching \u2014 Eliminate Redundant Work<\/h2>\n\n\n\n
      Rendering a page from CMS or backend data on every request is wasteful. The content often barely changes; the work repeats constantly.<\/p>\n\n\n\n
      A multi-tier cache<\/strong> strips out redundant work at every layer:<\/p>\n\n\n\n
      flowchart TD\n    R[Request \/products\/premium] --> T1[\"Tier 1: Page Data Cache<br\/>(Redis + in-memory LRU)<br\/>Key: page-data:\/products\/premium\"]\n    T1 -- Hit --> P1[Return cached payload]\n    T1 -- Miss --> T2[\"Tier 2: Apollo Server Cache<br\/>(per GraphQL operation, LRU)\"]\n    T2 -- Hit --> P2[Return cached response]\n    T2 -- Miss --> T3[\"Tier 3: Apollo Client Cache<br\/>(InMemoryCache, per session)\"]\n    T3 -- Hit --> P3[Return from memory]\n    T3 -- Miss --> T4[\"Tier 4: Nuxt useState<br\/>(SSR payload hydration)\"]\n    T4 --> H[\"Data serialized into HTML<br\/>Client hydrates without fetch\"]<\/pre>\n\n\n\n
      Tier 1: Page Data Cache<\/strong> is the heavy hitter. Each page is composed from many CMS entries via GraphQL\u2014the \u201cstub-and-load\u201d pattern. Instead of re-running all those queries, the cache stores the fully assembled payload for a URL path.<\/p>\n\n\n\n
      On a cache hit:<\/p>\n\n\n\n
        \n
      • No CMS calls.<\/li>\n
      • No GraphQL roundtrips.<\/li>\n
      • Just a sub-millisecond payload lookup and SSR render.<\/li>\n<\/ul>\n\n\n\n
        Invalidation is webhook-driven: content change \u2192 webhook \u2192 Redis Pub\/Sub \u2192 replicas clear affected keys. You get the dynamic behavior of a headless CMS with the speed profile of a static site.<\/p>\n\n\n\n
        \n\n\n\n
        Layer 3: Deferred Hydration \u2014 Interactivity on Demand<\/h2>\n\n\n\n
        SSR gives you a fast first paint. But if the browser immediately downloads and executes a multi-megabyte JS bundle for hydration, the main thread stalls, TBT explodes, and the page feels<\/em> sluggish despite looking ready.<\/p>\n\n\n\n
        The strategy:<\/p>\n\n\n\n
        > Defer hydration until the user interacts.<\/strong><\/p>\n\n\n\n
        A Nitro render:html<\/code> plugin rewrites the HTML in three steps:<\/p>\n\n\n\n
          \n
        1. Collect & strip <\/code><\/strong>  <\/li>\n<\/ol>\n\n\n\n
             Nuxt emits dozens of preload hints, causing eager download\/parse of ~90 JS chunks. The plugin:<\/p>\n\n\n\n
            \n
          • Captures these URLs into a JS array.<\/li>\n
          • Removes the tags from the HTML, preventing early work.<\/li>\n<\/ul>\n\n\n\n
              \n
            1. Replace the entry