Shipping fast websites with Next.js

When a founder asks us for a "launch-ready website in a week," they usually mean two things at once: the site should look done, and it should feel done. Looking done is design work. Feeling done is performance. This is how we get there.

Pick the right rendering mode

Next.js gives you four ways to render a page: static, ISR, server, and client. Most marketing sites should live in the first two.

• Static (SSG) — the default. Page is HTML at build time. Fastest possible serve.
• ISR — like static, but revalidated on a schedule. Great for blog indexes.
• Server (SSR) — re-rendered on every request. Use sparingly.
• Client (CSR) — "use client". Use for actual interactivity, nothing else.

If you can't articulate why a route needs SSR, it doesn't need SSR.

Three habits that buy back milliseconds

1. Ship a single font and use next/font so it's self-hosted with font-display: swap baked in.
2. Always reach for next/image, even on icons — the AVIF/WebP pipeline is free and the layout-shift protection alone is worth it.
3. Defer client components. If a feature doesn't need to react to user input on first paint, it doesn't belong in the initial bundle.

A worked example

Say you have a hero with a CTA button. The button is interactive, so it lives in a client component. But the surrounding copy — the headline, subheading, badge — is just text. Don't wrap the whole hero in "use client". Split it:

// hero.tsx — Server Component, ships zero JS
import { HeroCTA } from "./hero-cta";

export function Hero() {
  return (
    <section>
      <h1>Launch-ready websites</h1>
      <p>We design, build, and host so you don't have to.</p>
      <HeroCTA />
    </section>
  );
}

// hero-cta.tsx — Client Component, ships a few KB
"use client";

import { useState } from "react";

export function HeroCTA() {
  const [hovered, setHovered] = useState(false);
  return (
    <button
      onMouseEnter={() => setHovered(true)}
      onMouseLeave={() => setHovered(false)}
      className={hovered ? "scale-105" : ""}
    >
      Book a call
    </button>
  );
}

The page now ships ~95% server-rendered HTML and only hydrates the button. That's how you get a 100/100 Lighthouse score on a real-world hero.

Measure, don't guess

The shape of "fast" you care about isn't bundle size — it's Core Web Vitals. Wire them up to your analytics on day one. Without numbers, every optimisation argument is a vibe.

In summary

• Default to static rendering
• Treat "use client" as a budget, not a default
• Keep the critical render path lean: one font, optimised images, no surprise scripts
• Watch Web Vitals from launch day

That's most of the playbook. The rest is taste — which is what we get paid for.