Shipping SSR on Next.js: how I cut page loads by 35%
A pragmatic walk-through of the rendering, caching and image strategies behind a real CMS revamp — including the trade-offs nobody talks about.
When I joined Atrina to lead the CMS revamp, the legacy stack was a tangle of client-side rendering, oversized hero images and a CDN that was barely doing its job. The brief was simple: make it fast, make it Google-friendly, ship in a quarter.
1. Pick the rendering strategy per route
Next.js gives you SSR, SSG, ISR and client-only — and the temptation is to default to one. Don't. Marketing pages are SSG with ISR, dashboards stay client-side, the blog is ISR with on-demand revalidation. Treat it as a per-route decision.
export const revalidate = 60; // ISR — refresh in the background2. Image pipeline is 60% of the win
Most performance regressions I've seen on Next sites come from images. AVIF + responsive sizes + a good CDN beats almost any JS optimization you'll do.
3. Measure, don't vibe
Lighthouse is a starting point. Real user monitoring with Web Vitals beats it every time — 35% in the lab is meaningless if p75 LCP doesn't move in the field.
Tagged
Keep reading
All posts →Docker + Azure DevOps: a CI/CD recipe that halves release time
The exact pipeline structure, caching tricks and image layering rules that took our deploys from 18 minutes to under 9.
Design systems with Tailwind: lessons from real-world products
Tokens, primitives, and the discipline it takes to keep a Tailwind codebase from devolving into utility-class soup.
Build log: shipping a real-time video app with WebRTC & Socket.io
What I learned wiring up signaling, ICE servers and connection recovery for MeetSpace — the unsexy parts of real-time.