How to Get Your E-Commerce Store to a Near-Perfect Mobile PageSpeed Score (Without a Redesign)

A heavy site just scored a perfect 100 across the board on Google PageSpeed Insights.

Big Dog Auto is not a lightweight storefront. Deep catalog, thousands of SKUs, fitment data, images, the kind of site that usually drags performance scores into the 40s and 50s on mobile once everything actually loads.

Straight 100s.

And here’s the real story, the “how.” We didn’t redesign anything. Not the layout, not the catalog, not a single template. Every gain came from the delivery layer: how pages are built, cached, and served from the edge. The site your customers see looks exactly the same. It just loads like it’s empty.

This is the whole playbook, written so you can actually run it yourself. Every step names the tool and tells you where the button is, whether you’re on WordPress, Shopify, or BigCommerce. Nothing here requires a redesign or a developer on retainer. Work through it in order.

Why is my e-commerce store slow on mobile?

It’s almost never your design. It’s your delivery layer.

Most online stores, especially ones with deep catalogs and rich product imagery, score in the 30s to 50s on mobile PageSpeed once everything loads. Owners assume the fix is a redesign or a lighter theme. It usually isn’t. The real culprits are mechanical:

• The page is rebuilt on the server for every visitor instead of being served ready-made.
• CSS blocks the browser from painting anything until a stylesheet finishes downloading.
• The biggest image on the page loses a bandwidth race to fonts and scripts.
• A pile of apps and third-party scripts (chat widgets, review apps, popups, tracking pixels) loads on every page.
• Nobody is measuring the slow, cold visits, only the fast ones.

None of those are design problems. They’re delivery problems, and every one of them is fixable without a designer ever opening the file. Here’s how, step by step.

The delivery-layer playbook: 6 steps to a faster store

1. Cache the page and serve it from a CDN

The idea: stop rebuilding the page on the server every time someone visits. Serve a pre-built copy from a server (a CDN edge) physically close to the shopper. A page that re-renders on a cold request is slow at the worst possible moment: the first impression for a new customer.

Do this:

1. Put a CDN in front of your site. Cloudflare’s free plan covers most stores. Create an account, add your domain, and point your domain’s nameservers at Cloudflare. It takes about fifteen minutes and no code.
2. Turn on full-page caching:
   • WordPress / WooCommerce: install a caching plugin. WP Rocket (paid) is the easiest, it turns the big wins on the moment you activate it. LiteSpeed Cache is free if your host supports it. Enable “Page Caching.”
   • Shopify: caching and a global CDN are built in and on by default. You don’t manage this one, so your gains come from steps 2 through 6.
   • BigCommerce: also served through a CDN (Akamai) by default. Same as Shopify, focus your effort downstream.
3. One safety note: page-caching plugins automatically exclude cart, checkout, and account pages so they never serve a stale, logged-in page to the wrong person. Leave those exclusions in place.

Check it worked: load your homepage twice, then look at your caching plugin’s dashboard (or the page response headers) for a “cache HIT.” A hit means the visitor got the pre-built copy, not a fresh rebuild.

2. Eliminate render-blocking CSS

The idea: the browser refuses to paint a single pixel until it has downloaded your stylesheet. Inline the small slice of CSS the first screen actually needs (“critical CSS”) so the page paints instantly, then load the rest afterward.

Do this:

1. WordPress / WooCommerce: in WP Rocket, open the “File Optimization” tab and turn on “Optimize CSS delivery,” then “Remove Unused CSS.” That generates the critical CSS automatically and defers everything else. The free plugins Autoptimize and LiteSpeed Cache both do the same thing under “CSS” settings.
2. Shopify: you can’t easily inline critical CSS on a hosted theme, so the win here is subtraction. Remove apps that inject their own stylesheets (step 5), and start from a lean, modern theme (anything built on Shopify’s Dawn base) rather than a heavy multi-purpose one.

Check it worked: re-run PageSpeed Insights. The “Eliminate render-blocking resources” warning should shrink or disappear, and First Contentful Paint should drop.

3. Win the LCP race (usually your hero image)

The idea: your Largest Contentful Paint is the biggest thing on the first screen, almost always the hero image. The score literally waits on it. Get it to arrive first and small.

Do this:

1. Find it. Run your page in PageSpeed Insights. Under “Largest Contentful Paint element,” it names the exact image that’s holding you back.
2. Shrink it. Drop that image into Squoosh.app or TinyPNG, export it as WebP (or AVIF), and resize it to the size it actually displays at. A 3000px-wide file shown in an 800px slot is wasted bytes. You’ll often cut 70 percent off the file.
3. Stop lazy-loading it. Most themes lazy-load every image by default, which delays the one image you need first. The hero must be set to load immediately (loading="eager"), not lazy.
4. Prioritize it. If you can edit the theme, add fetchpriority="high" to the hero image tag so the browser fetches it before anything else.
5. Don’t let fonts beat it. If you’re preloading web fonts, make sure none of them are set to download ahead of the hero image. They shouldn’t win that race.

Platform notes: on WordPress, the free plugin Perfmatters lets you exclude the hero from lazy-load and control preloading without touching code. On Shopify, most modern themes have a setting like “disable lazy load on first image,” or you edit the image_tag in the theme.

Check it worked: LCP under 2.5 seconds in PageSpeed Insights. That’s the line between “good” and “needs work.”

4. Cut third-party app and script bloat

The idea: this is the most common real cause of a slow store, and the one owners least suspect. It’s rarely the catalog. It’s the stack of apps and scripts loading on every single page: chat widgets, review apps, popups, upsell tools, A/B testers, and three different tracking pixels.

Do this:

1. Find the offenders. In PageSpeed Insights, read “Reduce the impact of third-party code” and “Reduce unused JavaScript.” Both list the culprits by name and domain. WebPageTest.org’s “Domains” breakdown shows the same thing visually.
2. Cull. For each app and pixel, ask one question: is this earning its weight? Uninstall the ones that aren’t. A store carrying fifteen apps can usually get down to six without losing anything customers notice.
3. Delay what stays. Non-critical scripts shouldn’t load until they’re needed. On WordPress, WP Rocket’s “Delay JavaScript Execution” holds chat and marketing scripts until the visitor interacts with the page. For anything you control directly, add defer or async to the script tag.
4. Kill duplicates. It’s extremely common to have the same analytics or ad pixel installed twice, once in the theme and once through an app. Remove the copies.

Check it worked: re-run PageSpeed Insights after each removal and watch Total Blocking Time fall. That’s the metric third-party scripts hurt most.

5. Measure cold, and optimize the floor

The idea: your own browser cache lies to you. By the time you test, your machine has everything saved, so the page feels fast. Real first-time visitors on phones hit cold caches and slower connections. That cold load is the number that matters.

Do this:

1. PageSpeed Insights already simulates a cold, throttled mobile load, so trust its mobile score over how the site feels on your desk.
2. For a truer picture, use WebPageTest.org: set the location to mobile, the connection to “Slow 4G,” and “first view only,” then run the test three times.
3. Quick local version: open your store in a Chrome incognito window (fresh cache), open DevTools, go to the Network tab, set throttling to “Slow 4G,” and reload. Watch how long the hero takes to appear.
4. Take the worst of your three runs, not the best. That floor is what your customers actually experience. Optimize the floor.

6. Re-test after every change, and don’t let it slip back

The idea: speed isn’t a one-time project, it’s something you protect. Stores don’t get slow overnight. They get slow one app, one banner, one “quick” theme tweak at a time.

Do this: make a habit of running PageSpeed Insights right after you install an app, add a feature, or change the theme. If the score drops, you know exactly what did it, and you can roll it back before it costs you customers. Treat a lower score like a bug, not a cost of doing business.

Work those six in order and a heavy catalog store that was stuck in the 40s can reach a genuine 90-plus on mobile, the same way Big Dog did, without touching the design.

How to tell if your store has a delivery-layer problem (30-second check)

1. Open PageSpeed Insights and run your homepage on the Mobile tab.
2. Look at two numbers: the Performance score and Largest Contentful Paint (LCP).
3. If your score is under 70 and LCP is over 2.5 seconds, the problem is almost certainly in your delivery layer, not your design.

If that’s where you are, the good news is that none of the six steps above require a redesign, new photography, or re-platforming your catalog.

Why this matters more in the age of AI shopping agents

For years, speed was about two audiences: people and search engines. A third just arrived. AI agents are starting to browse and buy on shoppers’ behalf, and they don’t experience your beautiful hero. They read the page’s structure, and they wait on the same load times you do. A fast, cleanly built store is no longer only better for humans and Google rankings. It’s the difference between being usable by the next wave of automated shoppers and being invisible to them. The same delivery-layer work that earns a mobile 100 is the work that makes your store legible to machines.

Frequently asked questions

What is a good mobile PageSpeed score for an e-commerce site?

90 or above is excellent, and for a loaded catalog store it’s genuinely rare. Anything under 50 is costing you mobile conversions and search visibility. The goal is a fast experience for real first-time visitors on phones, not one good screenshot.

Does page speed actually affect sales and SEO?

Yes, on both. Google uses Core Web Vitals as a ranking signal, and slower mobile load times correlate strongly with higher bounce rates and lower conversion. A faster store ranks better and converts more of the traffic you already have.

Do I need to redesign my store to make it faster?

Almost never. The majority of mobile speed problems live in the delivery layer, how the page is built, cached, and served, which can be fixed without changing the design, layout, or catalog.

Which of the six steps matters most?

For most stores, cutting third-party app and script bloat (step 4) and fixing the hero image (step 3) deliver the biggest single jumps. Start there if you only have an hour.

How long does it take to improve page speed?

The core fixes are configuration and image work, not a months-long redesign project. Most owners can work through all six steps in an afternoon. The larger payoff comes from re-testing after every change so it stays fast.

Will my page speed degrade again over time?

It will if nothing protects it. That’s why step 6 matters: re-test after every app, feature, or update so a new addition can’t quietly slow you back down.

The takeaway

A pretty store that loads slowly is a show car: gorgeous in the driveway, but it can’t get out of its own way the moment a real customer tries to use it. You don’t need to rebuild it. You need to fix how it’s delivered, and then make sure it stays that way.

See how Web Shop Manager keeps stores fast by default. Get a demo.