How to fix slow page on Next.js (Headless)

Steps for Next.js (Headless)

1. Replace every raw <img> tag with Next.js's built-in <Image> component (next/image). Set explicit width, height, and a descriptive alt prop. Add priority prop to above-the-fold hero images so they are preloaded. This enables automatic WebP/AVIF conversion, lazy-loading, and responsive srcsets out of the box.
2. Eliminate render-blocking scripts by always using next/script with the correct strategy: strategy='lazyOnload' for analytics/chat widgets, strategy='afterInteractive' for tag managers, and strategy='beforeInteractive' ONLY for truly critical polyfills. Never use a plain <script> tag in _app.tsx / layout.tsx.
3. Eliminate render-blocking CSS by importing third-party stylesheets inside the component that needs them (dynamic import) or inlining only the critical CSS. In the App Router, place global styles in app/layout.tsx and use CSS Modules or Tailwind (which purges unused rules at build time) for component styles.
4. Enable HTTP caching and edge delivery by adding Cache-Control headers in next.config.js (headers() API) for static assets, and deploy on a CDN-edge runtime (Vercel Edge, Cloudflare, etc.). For API routes / Route Handlers that feed the page, use Next.js fetch() with { next: { revalidate: N } } to enable ISR and avoid blocking SSR round-trips.
5. Reduce JavaScript bundle size: enable the SWC minifier (default in Next 13+), use dynamic(() => import('./HeavyComponent'), { ssr: false }) for large client-only widgets (carousels, map pickers), and audit your bundle with NEXT_ANALYZE=true next build via @next/bundle-analyzer.
6. Measure before and after: run 'next build && next start' locally, profile with Lighthouse CI or WebPageTest, and verify LCP < 2.5 s, TBT < 200 ms, CLS < 0.1. Commit the next.config.js changes and re-run the audit in CI on every PR.

What is slow page?

Page load time is how long it takes for a visitor's browser to fully display your store page. When a page takes longer than about 3 seconds, visitors tend to leave before they even see your products — a behaviour called "bouncing." Google also directly measures loading speed as part of its Core Web Vitals scoring system, which feeds into how high your pages rank in search results. A load time of nearly 10 seconds (like the example above) is extremely slow and will hurt both rankings and sales.

Google uses Core Web Vitals — which include Largest Contentful Paint (LCP), a direct measure of loading speed — as a confirmed ranking signal. Pages that load slowly rank lower in search results, meaning fewer shoppers find you organically. Research consistently shows that every additional second of load time reduces conversion rates by roughly 4–7 %, so a 10-second page can cost you a significant share of potential sales. Slow pages also create a poor first impression, increase bounce rates, and can disqualify your pages from Google's "Page Experience" enhancements in search results. On mobile — where Google primarily indexes your site — performance issues are amplified further.

See the complete Slow page guide for every platform and the full background.