The Architecture Decision That Cut Our Site's Heavy Background Payload by ~180 KB

We cut our site's background payload by approximately 180 KB by replacing eager loading of a Three.js particle scene with a Next.js dynamic import set to ssr: false. This kept the animation for desktop users while preventing it from blocking the initial page render and hurting Core Web Vitals.

The Problem: A Visually Rich Hero with a Heavy Tax

Modern marketing sites compete on first impression. A dark mode, particle-filled hero looks premium. But that premium feel often comes with a JavaScript tax. In our case, the Three.js scene was ~180 KB of compressed JavaScript — a meaningful chunk for a page whose first job is to explain what we do in under 3 seconds.

Why 180 KB Matters for First Paint

On a 3G connection or a budget Android phone, 180 KB of JavaScript is not instant. It has to be downloaded, parsed, and executed before the browser can finish rendering. If that code is in the critical path, it delays LCP. If it runs on the server during SSR, it can also slow time-to-first-byte.

The Fix: Dynamic Import with SSR Disabled

We used Next.js dynamic imports so the background is not included in the server-rendered HTML, loads on the client only after the critical content is visible, and the main bundle stays lighter, protecting LCP and INP.

The Numbers We Targeted

We aligned the change with explicit Core Web Vitals targets: LCP under 2.5 seconds, CLS under 0.1, and INP under 200 milliseconds. Lazy-loading the background was one of several moves. Others included preconnecting to Google Fonts, lazy-loading below-fold sections, and structuring FAQ content with schema markup.

Lessons for Founders Building Visually Ambitious Sites

Visual polish and performance are not mutually exclusive. The trick is separating critical content from decorative enhancements and loading each on the right schedule. If an asset does not need to be there on first paint, do not put it there.