Performance Optimisation and Core Web Vitals

Performance is not a single number but a user's lived experience of how fast a page becomes visible, how soon it becomes usable, and how stable it is as it loads — and Google's Core Web Vitals are the standardized metrics that capture exactly these felt qualities. There are three: Largest Contentful Paint measures how quickly the main content appears, Interaction to Next Paint measures how responsively the page reacts when the user interacts with it, and Cumulative Layout Shift measures how much the page jumps around as it loads. These metrics matter doubly, because they govern both real user satisfaction — people abandon slow, janky pages — and search ranking, since Google incorporates them into how it ranks sites. The App Router gives you strong defaults and specific tools for each, and performance optimization is largely the discipline of understanding what drives each metric and using the right tool to improve it.

This topic deserves systematic treatment rather than a grab-bag of tips because performance problems are usually specific and diagnosable, mapping onto particular metrics with particular causes and particular fixes, and the App Router's architecture has already addressed many of them by default in ways worth understanding. Server Components ship less JavaScript, which directly helps responsiveness; static and ISR rendering produce fast first paints; next/image and next/font prevent layout shift and oversized downloads; streaming with Suspense improves perceived speed. But defaults are not automatic perfection — a page can still ship too much client JavaScript, block on a slow data fetch, load oversized assets, or shift its layout — and the skill is diagnosing which metric is suffering and why, then applying the targeted remedy. Rather than optimizing blindly, you measure, identify the bottleneck, and fix the specific cause. This lesson covers the three Core Web Vitals and what drives them, the App Router features that address each, and the disciplined measure-diagnose-fix approach that turns performance from guesswork into engineering.

Analogy🏏Cricket

🏏 Think of it like cricket: Picture a Test match where, before the openers walk out, the curator has already prepared the pitch, the umpires are positioned, and the scoreboard is live — the players just play. Plain React is like arriving at an empty ground and being told to roll the pitch, set the field, and wire up the scoreboard yourself before a single ball is bowled. Just as the prepared ground lets the batsmen focus on batting rather than groundskeeping, Next.js prepares routing, rendering, and bundling so you focus on features rather than plumbing. Just as the live scoreboard shows runs the instant a shot is played, server rendering hands the browser finished HTML the instant the page loads. And just as every Test follows the same agreed laws so any team can play anywhere, the App Router's file conventions mean any developer can read the folder structure and instantly know the routes. This reveals why Next.js wins on large teams: shared conventions remove the guesswork that custom setups create.