Mobile PageSpeed: Why Your eCommerce Store Is Slow and How to Fix It

Run your store through Google PageSpeed Insights right now. If your mobile score is above 70, you're doing better than most eCommerce sites we audit. If it's below 50, you're in the majority—and it's costing you conversions.

The reason most stores score poorly isn't because the tool is unfair. It's because PageSpeed Insights simulates a mid-range phone on a 3G connection with CPU throttling. That's not a worst-case scenario—it's how a significant portion of your customers actually experience your site.

What PageSpeed Insights Actually Tests

The Lighthouse engine behind PageSpeed doesn't just measure how fast your server responds. It simulates a Moto G Power on a slow 4G / fast 3G connection (roughly 1.6 Mbps throughput with 150ms RTT) and throttles the CPU to 4x slowdown. Then it measures how the page loads under those conditions.

This means your desktop development machine with its fast CPU and gigabit connection gives you a completely misleading picture of real-world performance. What loads in 1 second on your laptop might take 8 seconds on your customer's phone.

Core Web Vitals Explained

Google uses these metrics to measure user experience, and they directly affect your search rankings:

The Biggest Mobile Performance Killers

1. Render-Blocking CSS and JavaScript

When the browser encounters a CSS file or synchronous script in the head of your document, it stops rendering until that resource is downloaded and processed. If you have three large CSS files and four JavaScript files loading synchronously, the browser is doing nothing visible for seconds while it processes them.

Fix: Inline critical CSS (the styles needed for above-the-fold content), defer non-critical CSS, and add async or defer to scripts. Remove any CSS or JS that isn't needed on the current page.

2. Unoptimised Images

This is the single biggest offender on most eCommerce sites. We regularly see product images served as 3000x3000 PNGs when the display size is 400x400. That's 10x more data than necessary.

Fix: Serve images in WebP (or AVIF where supported) at the correct display size. Use responsive images with srcset so mobile devices get smaller files. Lazy load images below the fold. For the hero/LCP image, preload it with a link rel="preload" tag.

3. Third-Party Scripts

Analytics, chat widgets, tracking pixels, A/B testing tools, heatmaps, social proof popups—each one adds JavaScript that the browser must download, parse, and execute. We've seen stores with 30+ third-party scripts loading on every page. Each one competes for the main thread and delays interactivity.

Fix: Audit every third-party script. Remove anything you're not actively using. For essential scripts (analytics, chat), load them after the page is interactive using requestIdleCallback or a delayed load strategy. Consider server-side analytics where possible.

4. Icon Font Libraries

Loading all of Font Awesome (300KB+) or Material Icons (400KB+) for 10 icons is wasteful. These fonts block rendering while they download, and the browser has to parse thousands of glyphs you'll never use.

Fix: Switch to inline SVGs for the icons you actually use. If you must use an icon font, subset it to include only the glyphs you need. Or use a tree-shakeable icon library that only bundles the icons you import.

5. Excessive JavaScript (React Hydration Cost)

Modern JavaScript frameworks like React ship a runtime that must download, parse, and execute before the page becomes interactive. On a throttled mobile CPU, hydrating a complex React component tree can take several seconds—even if the HTML was server-rendered and looks ready.

Fix: Use server components where possible (React Server Components, Next.js App Router). Implement code splitting so only the JavaScript needed for the current page is loaded. Consider partial hydration or islands architecture for content-heavy pages.

Self-Hosting Fonts vs CDN

The conventional wisdom was to use Google Fonts CDN because the fonts might be cached from another site. That's no longer true. Modern browsers partition their cache by domain, so a Google Font loaded on site A won't be cached for site B. Self-hosting is now almost always faster because it eliminates the extra DNS lookup and connection to fonts.googleapis.com.

Self-host your fonts, preload the critical ones with link rel="preload", use font-display: swap to prevent invisible text while fonts load, and subset your font files to include only the character sets you need (Latin, for example, instead of the full Unicode range).

Code Splitting and Lazy Loading

A typical eCommerce store loads all of its JavaScript upfront—the homepage hero, the product quick-view, the cart drawer, the search overlay, the newsletter popup, and the footer accordion. Most of that JavaScript isn't needed until the user interacts with those features.

Code splitting breaks your JavaScript into smaller chunks that load on demand. The homepage only loads homepage code. The product page only loads product page code. Components like modals and drawers load when the user triggers them, not on initial page load.

With frameworks like Next.js, route-based code splitting happens automatically. Component-level splitting requires dynamic() imports or React.lazy() for interactive components that aren't needed at page load.

How Next.js / SSG Improves Mobile Performance

Static Site Generation (SSG) pre-renders pages at build time, so the server sends fully-formed HTML that the browser can display immediately without waiting for JavaScript to render the page. Combined with Next.js features like automatic code splitting, image optimisation via next/image, and edge caching, SSG can dramatically improve mobile performance.

For eCommerce, this works exceptionally well for product listing pages, category pages, and content pages. Product detail pages can use Incremental Static Regeneration (ISR) to serve static pages while keeping pricing and inventory fresh.

Realistic Expectations

A score of 100 on mobile PageSpeed is nearly impossible for any site with rich content, analytics, and interactive features. The tool's throttling is aggressive, and even Google's own properties don't score perfectly.

Aim for 90+ on mobile for content pages and 75+ for interactive pages with necessary third-party scripts. The real goal isn't a perfect score—it's ensuring your Core Web Vitals pass the "good" thresholds so your search rankings aren't penalised and your customers don't bounce from slow load times.

Focus on real user metrics (check your CrUX data in Search Console) rather than obsessing over lab scores. A site that scores 85 in PageSpeed but delivers great real-world performance is better than one that games a 98 in the lab but falls apart under real traffic.