The average WooCommerce store scores 38 on Google’s PageSpeed Insights mobile test. The average high-performing WooCommerce store scores 85+. The stores between those numbers 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 25% of your visitors before they see a product.
The Revenue Cost of Slow
Google’s internal research, confirmed by Deloitte in 2019, found that a 0.1-second improvement in site speed increases retail conversions by 8.4%. That’s per 100ms. A 1-second improvement moves checkout conversions by 7%.
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 SiteGround Shared ($5/month) and SiteGround Business ($30/month) 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, Kinsta, and SiteGround Business. Providers that typically don’t: any shared hosting plan, GoDaddy, Bluehost at base tiers.
Carol runs a specialty tea store in Oregon. Her WooCommerce store was on Bluehost Shared at $8/month. Her average TTFB was 1,100ms. She moved to Cloudways on a $22/month DigitalOcean server. TTFB dropped to 190ms. No other changes. PageSpeed score went from 31 to 54 on mobile. Then she removed two poorly coded plugins and compressed her product images — final score: 78. Revenue from organic traffic increased 34% over the following 90 days.
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. An Elementor site loads Elementor’s CSS globally — including all the styles for widgets you haven’t used.
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 average a Lighthouse score of 38 on mobile (our builds across client projects). WooCommerce stores on hand-coded themes average 71–88.
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, because the fundamental problem is that Elementor loads its entire library on every page. You can’t split-load it; that’s how it was architectured.
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 hundreds of kilobytes 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. WooCommerce 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. Check our fixed-price packages if you’re starting from scratch and want performance built in from day one.
Tim owns a sporting goods store doing 400 SKUs on WooCommerce. His site scored 29 on mobile PageSpeed. Investigation: Elementor theme adding 340ms of render-blocking CSS, four plugins loading JavaScript on every page including checkout, product images averaging 1.8MB each, hosting on shared server with 940ms TTFB. After moving to Cloudways, switching to a hand-coded theme, removing redundant plugins, and compressing images to WebP: mobile score 82, desktop score 91. Checkout conversion rate increased from 1.6% to 2.9%.
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.