Many WooCommerce stores score poorly on Google’s PageSpeed Insights mobile test, while high-performing ones score far higher. The stores at either end aren’t running different products or different themes. They made different decisions about code, plugins, and hosting.
Why WooCommerce Stores Slow Down
WooCommerce itself is not slow. A WooCommerce install with no theme, no plugins, and minimal products loads fast. What makes WooCommerce stores slow is everything added on top: theme frameworks that load 400KB of CSS, plugins that enqueue JavaScript on every page, cheap hosting that can’t serve requests quickly, and images that haven’t been compressed.
The performance problems are layered and compounding. A page builder theme might add 300ms of render-blocking CSS. Three plugins adding unoptimized JavaScript add 200ms more. Shared hosting with high TTFB adds another 600ms. Individually, each problem seems manageable. Together, they explain a 4-second load time that drops a large share of your visitors before they see a product.
The Revenue Cost of Slow
Deloitte’s Milliseconds Make Millions study (2020, commissioned by Google) found that a 0.1-second improvement in mobile site speed increased retail conversions by 8.4%. That’s per 100ms.
For a store doing $1,000/day in revenue, improving load time from 4 seconds to 1.5 seconds is worth — conservatively — $200–$400/day in additional completed orders from the same traffic.
Hosting: The Foundation That Determines the Ceiling
No optimization done at the application layer can fully compensate for bad hosting. If your server takes 800ms to respond to a request before a single byte of content is delivered, that 800ms is your performance floor.
TTFB (Time to First Byte) targets:
- Under 200ms: good
- 200–500ms: acceptable
- Above 500ms: the hosting is the problem
WooCommerce requires managed WordPress hosting, not shared hosting. The performance difference between a base-tier shared plan and a properly provisioned managed or cloud plan on a real store is measured in hundreds of milliseconds of TTFB. That’s not marketing copy. That’s server architecture.
Providers that consistently deliver TTFB under 200ms for WooCommerce: Cloudways (DigitalOcean stack), WP Engine, and Kinsta. Providers that typically don’t: any shared hosting plan, GoDaddy, Bluehost at base tiers.
Say a specialty tea store runs WooCommerce on a base-tier shared hosting plan with a slow TTFB. Moving to a properly provisioned server fixes the response time first; removing poorly coded plugins and compressing product images then takes care of most of what is left on the page.
Page Builder Themes and Render-Blocking CSS
Elementor, Divi, and WPBakery build pages using CSS and JavaScript that load on every page of your site, regardless of whether that page uses any of the builder’s components.
Elementor’s core CSS file is approximately 100KB unminified. Divi’s frontend JS bundle runs around 200KB. These files block rendering: the browser can’t display any content until they’re parsed. On a 3G connection, that delay runs 800ms–2 seconds.
WooCommerce stores on page builder themes typically score far lower on mobile Lighthouse than stores on hand-coded themes.
The fix is to stop using page builders. There is no “optimize Elementor” that gets you to the same performance as a custom-coded theme: even with its conditional asset loading, a page builder still carries more overhead than a hand-coded theme.
All custom WooCommerce stores we build use hand-coded themes — no Elementor, Divi, or equivalent. The performance floor is 90+ on PageSpeed Insights, and we don’t ship below it.
Plugin Audit: How to Find the Performance Killers
Most WooCommerce stores accumulate plugins over time — a marketing plugin here, a popup tool there, three different SEO-adjacent tools that all do overlapping things. Every active plugin has the potential to add HTTP requests, JavaScript, CSS, and database queries to your pages.
The process for auditing your plugin stack:
-
Install Query Monitor (free plugin) and load your homepage, a product page, and your checkout page. Look at the “Scripts” and “Styles” tabs. Note every asset loading on each page and which plugin is responsible.
-
Identify assets that don’t belong on specific pages. A slider plugin loading its JavaScript on your checkout page is a problem. A gallery plugin loading 150KB of CSS on a text-heavy post is a problem.
-
Use Asset CleanUp or Perfmatters to conditionally load plugin assets only on pages where they’re needed. A plugin that only runs on the shop page should only load its scripts on the shop page.
-
Deactivate plugins you haven’t used in 90 days. If deactivating a plugin improves your PageSpeed score, don’t reactivate it unless you have a specific, current need.
For stores where performance is seriously degraded, run a before/after PageSpeed test after deactivating each plugin. You’ll identify the exact culprits within a few hours.
Image Optimization — The Highest-Impact Quick Fix
Product images are the largest assets on most WooCommerce pages. Unoptimized images from a camera or a supplier’s product sheet are typically 2–8MB each. Those files served as-is contribute megabytes of unnecessary data per page load.
The optimization stack for WooCommerce images:
Format: Convert to WebP. WebP images are 25–35% smaller than equivalent JPEG files with no visible quality loss. WordPress supports WebP natively since version 5.8. The Imagify or ShortPixel plugins automate conversion of your existing library.
Dimensions: Use srcset attributes to serve appropriately sized images for each device. A 2000px wide product image served to a mobile screen at 375px width sends 5x more data than needed.
Lazy loading: Images below the fold should load only when scrolled into view. WordPress 5.5+ adds loading="lazy" to images by default, but verify this is working on your product pages using Chrome DevTools’ Network tab.
Compression: Aim for JPEG quality 75–80% on product images. Most shoppers cannot perceive the difference between 80% and 100% quality, but the file size difference is 40–60%.
If you want a store audit before committing to a rebuild, Honest gives you a blunt read on what’s actually slowing your store down.
Caching: What to Cache and What Not to
Caching stores rendered HTML so subsequent visitors get a pre-built page instead of triggering a full PHP execution cycle. On a WooCommerce store, proper caching can reduce server response time by 80–95% for cacheable pages.
Pages that should be cached:
- Homepage
- Category pages
- Static product pages (price and availability don’t change frequently)
- Blog posts
Pages that must not be fully cached:
- Cart
- Checkout
- My Account
- Any page with dynamic pricing or user-specific content
WP Rocket and LiteSpeed Cache are the two best-performing caching plugins for WooCommerce. Both handle WooCommerce exclusions properly out of the box. W3 Total Cache and WP Super Cache require more manual configuration to avoid caching cart content for the wrong user.
Database Optimization — The Problem That Appears at Scale
WooCommerce writes aggressively to the database. Order records, session data, product meta, stock updates, and transient options accumulate over time. A store that’s been running two years with no database maintenance can have a wp_options table exceeding 500MB, slowing every page load that queries it.
Database maintenance tasks:
- Delete expired transients (automatically done by WP-Cron, but verify it’s running)
- Limit post revisions (add
define('WP_POST_REVISIONS', 5);towp-config.php) - Clear orphaned order data and draft products
- Optimize tables using WP-CLI:
wp db optimize
WP-Optimize or Advanced Database Cleaner handle most of this automatically. Run them quarterly. On a large store, expect to recover 200–800MB of unnecessary database weight.
Our WooCommerce development builds include performance optimization built into the architecture — not a plugin you install after the fact. Talk to us if you’re starting from scratch and want performance built in from day one.
Say a sporting goods store with 400 SKUs on WooCommerce scores poorly on mobile PageSpeed. A typical investigation finds an Elementor theme adding render-blocking CSS, plugins loading JavaScript on every page including checkout, oversized product images, and shared hosting with a slow TTFB. Moving to better hosting, switching to a hand-coded theme, removing redundant plugins, and compressing images to WebP addresses each of those in turn.
FAQ
What is a good PageSpeed score for WooCommerce? For mobile: 70+ is good, 85+ is strong. For desktop: 80+ is good, 90+ is strong. Most ecommerce sites perform worse on mobile due to slower connections and heavier resource loading. If your mobile score is below 50, there’s a specific, addressable problem.
Will caching plugins fix a slow WooCommerce store? Partially. Caching fixes server response time for cacheable pages and can improve PageSpeed significantly. It won’t fix render-blocking CSS from a page builder, unoptimized images, or poor database architecture. Caching is one layer of a complete performance solution, not the whole answer.
Do I need to switch themes to improve performance? If you’re running a page builder theme (Elementor, Divi, OceanWP with page builders, etc.), yes — changing themes will have the largest single impact on your performance. The performance penalty from page builder CSS and JavaScript cannot be fully eliminated by any optimization plugin.
How often should I optimize my WooCommerce database? Quarterly for most stores. Monthly if you’re running a high-volume store with 1,000+ orders per month. Use WP-Optimize or Advanced Database Cleaner and set it on a schedule.
Is WooCommerce inherently slower than Shopify? No. A well-built WooCommerce store on quality hosting outperforms an average Shopify store. The difference is that Shopify handles hosting and infrastructure, which removes the floor risk (you can’t accidentally run WooCommerce on terrible hosting if Shopify is managing it). But Shopify’s infrastructure isn’t custom-tuned for your store, and their theme ecosystem introduces the same JavaScript bloat problems as WordPress page builders.