Performance work should follow measurement, not intuition. Start with field data if you have it, and a Lighthouse or WebPageTest run against a production build if you do not. Optimizing a development build tells you almost nothing useful.
Rendering strategy is the highest-leverage decision. Static generation for content that changes rarely, incremental regeneration for content that changes on a schedule, and server rendering only where the response genuinely depends on the request. Marketing pages rendered per-request are a common and expensive mistake.
Images are usually the largest payload on a page. Serve modern formats, size them to their display dimensions, set explicit width and height to prevent layout shift, and lazy-load anything below the fold. A single unoptimized hero image can dominate your Largest Contentful Paint.
JavaScript bundle size drives interactivity delay. Audit what ships to the client: heavy date libraries, chart packages imported for one component, and icon sets pulled in whole are frequent culprits. Dynamic imports for below-the-fold or interaction-triggered components keep the initial bundle lean.
The Server Components boundary is worth being deliberate about. Every 'use client' directive pulls that component and its imports into the client bundle. Push interactivity to leaf components rather than marking a whole page as client-rendered.
Fonts cause avoidable layout shift and render delay. Self-host, preload the primary weight, define a matched fallback stack, and use a display strategy that avoids invisible text during load.
Third-party scripts are frequently the single worst offender and the least examined. Analytics, chat widgets, and tag managers each add blocking work. Load them with a deferred strategy and periodically question whether each one earns its cost.
Finally, set a performance budget and enforce it in CI. Without a gate, bundle size grows monotonically — every feature adds a little, and nobody is responsible for the total.