Guide to fast websites with Next.js: Tips for maximizing server speeds and minimizing client burden

Measuring site speed the right way

Tinloof, a web agency focused on high-performance builds, measures speed across three stages of the user journey before optimizing anything: server response time (first feedback after landing), page render time (when a page is fully visible and interactive), and user interaction time (actions like navigating or adding to cart).

For the agency's work — such as taking jewelry brand Jennifer Fisher from Shopify to Next.js and cutting JavaScript by 80% — data is the starting point. Google PageSpeed Insights and Vercel Speed Insights provide objective, reproducible metrics for diagnosing issues related to loading, interactivity, and visual stability. Tinloof pairs those tools with manual testing of the user journey under varied network conditions, giving a fuller picture than either approach alone.

Cutting server response time: Next.js rendering strategies

Once metrics expose a slow server, the fix often lies in choosing the right rendering mode. Next.js offers a progression of options, from fully static to fully dynamic.

Pre-render the whole page when possible

The fastest server response comes from pages built at compile time and served from a CDN rather than your origin server. Next.js does this automatically when a route avoids the edge runtime and doesn't depend on cookies, headers, or search parameters. In that case, the page is static by default.

Partial Prerendering as a middle ground

Many pages can't be fully static. Partial Prerendering (PPR), currently an experimental Next.js feature, lets you pre-render a static shell of the route — served from the CDN — while dynamic sections stream in separately. The advantage is isolating only the truly dynamic parts of a page instead of treating the whole route as request-time work.

Loading shells for dynamic routes

When a page must be rendered at request time, users should see something immediately rather than a dead end. A loading UI that closely matches the final layout prevents layout shift and feels responsive. In Next.js's App Router, you can define this UI in a loading.tsx file within the route folder, upstream of where dynamic rendering happens.