Performance

The cheapest client JavaScript is the JavaScript you never send

Server Components give you a structural way to keep non-interactive code out of the browser bundle. That is often more valuable than shaving a few bytes from code that never needed to be client-side in the first place.

Audit large 'use client' boundaries before reaching for micro-optimisations.

Large client boundary
        ↓
More modules enter client graph
        ↓
More JS downloaded and parsed
        ↓
More code to execute and hydrate
        ↓
Potentially slower interaction

Know what the Core Web Vitals are telling you

• LCP is about how quickly the main visible content appears.
• INP reflects responsiveness to user interaction.
• CLS measures unexpected visual movement.
• Use field data when available. A perfect local run is not the same as real users on real devices.

Network shape often matters more than raw query speed

A 100 ms request followed by another 100 ms request is slower than starting both together when they are independent. Look for waterfalls in server work, browser requests, fonts, images, and third-party scripts.

Streaming can improve perceived speed when some work cannot be made faster or parallel.

Prefetch with intent

Next.js navigation can prefetch route data to make transitions feel immediate. That is useful, but prefetching still consumes network and server resources.

For unusually large or expensive destinations, test the trade-off instead of assuming more prefetching is always better.

Optimise from evidence

Use production traces, Web Vitals, bundle information, database timings, and request waterfalls to find the real bottleneck. Performance work based only on intuition tends to optimise whatever is easiest to see.

The fastest component is irrelevant if the route is waiting on a serial database waterfall.