How We Achieved PageSpeed 100/100 on a Next.js Ecommerce Website
A technical walkthrough of how we optimized a Next.js ecommerce site to score 100/100 on Google PageSpeed Insights on both mobile and desktop.
PageSpeed matters more than most businesses realize. Google uses page speed as a ranking factor. Slow sites lose visitors — research shows that a one-second delay in page load time can reduce conversions by 7 percent. For ecommerce sites, where every fraction of a second affects whether someone completes a purchase, speed is not optional.
We recently completed a Next.js ecommerce project where we achieved a perfect 100/100 on Google PageSpeed Insights for desktop and 96 on mobile. Here is exactly what we did, step by step, and the mistakes we avoided.
Why We Chose Next.js
Before diving into optimization, the framework choice matters. We chose Next.js 14 with the App Router for several reasons. Server-side rendering and static generation mean pages are pre-built and served instantly instead of being constructed in the browser. The built-in Image component handles responsive images, lazy loading, and format conversion automatically. Code splitting is automatic — each page only loads the JavaScript it needs. Font optimization with next/font eliminates layout shift caused by web fonts loading.
WordPress with WooCommerce is the default choice for most Indian ecommerce sites, but it comes with significant performance baggage. Plugin bloat, render-blocking scripts, unoptimized images, and server-side PHP processing typically result in PageSpeed scores between 30 and 60 on mobile. We have seen WordPress ecommerce sites scoring as low as 15 on mobile PageSpeed.
Step 1 — Image Optimization
Images are the single biggest performance bottleneck on ecommerce sites. Product photos, banner images, category thumbnails — they add up fast.
We used the Next.js Image component for every single image on the site. This component automatically serves images in WebP format when the browser supports it, generates multiple sizes for different screen widths, lazy loads images below the fold, and adds proper width and height attributes to prevent layout shift.
For product images, we defined specific sizes: 400px for thumbnails, 800px for product cards, and 1200px for product detail pages. This prevents the common mistake of loading a 3000px image for a 400px thumbnail.
We also set priority loading on above-the-fold images (the hero banner and first row of products) so they load immediately while everything else lazy loads.
Step 2 — Font Optimization
Web fonts are a silent performance killer. The typical approach of linking to Google Fonts in your HTML head creates a render-blocking request that delays your entire page.
Next.js provides next/font which downloads fonts at build time and self-hosts them. No external requests, no layout shift, no flash of unstyled text. We used Space Grotesk for headings and Inter for body text, both loaded through next/font with display swap and specific weight subsets.
The key detail: we only loaded the weights we actually used. Loading all weights of a font family when you only use Regular and Bold is wasted bandwidth.
Step 3 — Code Splitting and Bundle Size
Next.js handles code splitting automatically at the page level, but there are additional optimizations we implemented.
Dynamic imports for heavy components: the product filter sidebar, image zoom modal, and review section were all loaded dynamically using next/dynamic with ssr false where appropriate. This means these components only load when the user actually needs them.
We audited every npm package. Date formatting libraries, animation libraries, icon libraries — each one adds to your bundle size. We replaced moment.js with native Intl.DateTimeFormat. We imported individual icons from lucide-react instead of the entire icon set. We removed unused dependencies.
The result: our initial JavaScript bundle was under 90KB gzipped.
Step 4 — Eliminating Render-Blocking Resources
This is where most sites lose points. Third-party scripts, analytics tags, chat widgets, and social media embeds all compete for browser resources during page load.
We implemented a strict loading strategy. Critical CSS is inlined by Next.js automatically. Google Analytics loads asynchronously after the page is interactive. The WhatsApp chat widget loads on user scroll, not on page load. Social media embeds use facade patterns — a static preview image that loads the actual embed only when clicked.
Step 5 — Server Configuration
Even with perfect frontend optimization, slow server response times will tank your PageSpeed score. Time to First Byte (TTFB) needs to be under 200ms.
We deployed on Vercel, which serves pages from edge locations globally. For Indian users, this means content is served from Mumbai or Singapore edge nodes rather than crossing the ocean to a US server. Static pages are cached at the edge and served in under 50ms.
We also configured proper cache headers: static assets get one-year cache with immutable flag, HTML pages get stale-while-revalidate for instant loads with background updates.
Step 6 — Core Web Vitals
Google PageSpeed is built on Core Web Vitals, so optimizing for these metrics directly improves your score.
Largest Contentful Paint (LCP) — we ensured the largest visible element (usually the hero image) loads within 1.2 seconds by using priority loading and properly sized images.
Cumulative Layout Shift (CLS) — we eliminated layout shift by setting explicit dimensions on all images, reserving space for dynamic content, and using font display swap.
Interaction to Next Paint (INP) — we kept JavaScript execution lightweight and avoided long tasks that block the main thread.
Common Mistakes to Avoid
Do not load all product images on the category page. Use pagination or infinite scroll with lazy loading. Do not use unoptimized PNG images for product photos — WebP at 80 percent quality is visually identical and 40 to 60 percent smaller. Do not load Google Fonts from a CDN link tag — use next/font instead. Do not install npm packages for simple functionality you can write in 10 lines of code. Do not skip the lighthouse audit during development — run it on every page before deployment.
The Results
Desktop PageSpeed: 100/100. Mobile PageSpeed: 96/100. Largest Contentful Paint: 0.8 seconds. Cumulative Layout Shift: 0. Total page weight: under 500KB on initial load.
These scores are not theoretical maximums achieved in a lab environment. They are production scores on a live ecommerce site with real product data, images, and user-facing functionality.
PageSpeed 100 is achievable for any website if you make deliberate technical choices from the start. The framework matters, the hosting matters, and the discipline to avoid bloat matters most of all.