A Common Misconception: Stop Chasing a PageSpeed Score of 100
PageSpeed Insights scores are a reference point, not a goal. A site scoring 93 with genuinely fast real-world load times is far better than one scoring 100 whose aggressive compression has broken its layout. The numbers that actually matter are the Core Web Vitals:
| Metric | What It Measures | Google's Target |
|---|---|---|
| LCP (Largest Contentful Paint) | Time for the main content to finish loading | โค 2.5 seconds |
| INP (Interaction to Next Paint) | Page response time after user interaction | โค 200ms |
| CLS (Cumulative Layout Shift) | Amount of unexpected element movement during load | โค 0.1 |
Add TTFB (Time to First Byte, target under 800ms) and Fully Loaded Time (target under 3 seconds), and these five numbers are what speed optimization should actually be measured against. The Core Web Vitals data in Google Search Console's "Experience" section reflects real user conditions โ that's more meaningful than a single PageSpeed Insights test.
Layer One: The Server Is Everything's Foundation
Plugins and configuration can only do so much. If the server itself is under-resourced, no amount of caching helps. WooCommerce stores generate substantially more database queries than a typical blog โ server selection should reflect the actual store size, not a "start cheap and figure it out later" mentality.
The impact of different hosting types on performance: shared hosting divides resources among multiple users, and high-traffic periods can severely spike TTFB. VPS and cloud servers give you dedicated resources and more stable performance. Managed platforms like Cloudways sit on top of VPS infrastructure with the server environment pre-configured โ Nginx plus Redis is the default performance stack โ which suits operators who don't want to manage servers themselves. The detailed hosting comparison is in the Cloudways WooCommerce guide.
Layer Two: Caching Configuration
Caching produces the largest single-change speed improvement available.
Page caching pre-renders PHP-generated pages into static HTML so subsequent visits read the static file directly, bypassing PHP execution and database queries entirely. TTFB can drop from several seconds to tens of milliseconds.
Which caching plugin to use depends on the server environment โ LiteSpeed Cache delivers its full potential on LiteSpeed servers. Cloudways' DigitalOcean and Vultr plans default to Nginx, which makes LiteSpeed Cache largely pointless there; use WP Rocket or W3 Total Cache instead. This was covered in the plugin guide โ same conclusion applies. Install one caching plugin, not two simultaneously.
WooCommerce requires specific attention here: cart pages, checkout pages, and account pages must not be cached, because they contain user-specific dynamic content. Major caching plugins exclude these by default, but if you've customized your checkout flow, manually confirm those URLs are excluded from caching.
Object caching (Redis or Memcached) targets database queries specifically. WooCommerce stores make frequent queries for product data, inventory, and user sessions. Object caching stores those query results in memory so repeated requests read from memory rather than hitting the database again. On Cloudways, enabling Redis is a one-click operation under Server โ Manage Services โ Redis.
Layer Three: Image Optimization
Images typically account for 40โ60% of page weight โ the single resource type with the highest optimization return.
Format: WebP runs roughly 25โ35% smaller than JPEG with broad modern browser support โ use it by default. AVIF is even smaller but lacks support in some older browsers, so it requires a fallback strategy. ShortPixel, Imagify, or EWWW Image Optimizer can batch-convert existing uploaded images and automatically compress new uploads.
Upload at the actual display size: if an image displays at 400ร300px on the page, uploading a 2000ร1500px original means the browser downloads the full-size file and scales it down locally โ wasted bandwidth on every load.
Lazy loading: images below the fold load only when the user scrolls to them, significantly reducing the initial page payload. WordPress has natively supported lazy loading since version 5.5 โ in most cases, no additional plugin is needed.
Layer Four: CDN
A CDN caches static resources โ images, CSS, JavaScript, fonts โ at edge nodes globally, serving users from the nearest node rather than pulling from your origin server every time. For cross-border stores, this optimization is particularly impactful. The latency difference between a server in China serving resources to European or North American users versus a nearby CDN edge node can be several times over.
Cloudflare's free tier covers most cross-border stores adequately: global CDN, basic DDoS protection, Brotli compression, and Auto Minify (CSS/JS/HTML). Configuration priorities: enable Brotli and Auto Minify under Speed settings, set reasonable browser cache times under Cache settings, and exclude cart and checkout pages from caching. For higher traffic volumes or more granular performance control, Bunny CDN offers competitive pricing and solid performance as an upgrade option.
Layer Five: CSS, JavaScript, and Third-Party Scripts
CSS and JS optimization: removing unused CSS and deferring JavaScript not needed for the initial render can significantly reduce first-paint blocking time. Major caching plugins (WP Rocket, FlyingPress) include these functions built-in โ enable them in the plugin settings. Important caveat: these optimizations sometimes break theme or plugin styling. Test across multiple devices after each change to confirm nothing has broken visually.
Third-party scripts are the most commonly overlooked performance drain. Google Analytics, Meta Pixel, TikTok Pixel, live chat plugins, heatmap tools โ each initiates requests to external servers, and combined they can weigh more heavily on load time than your theme or images. Audit every installed third-party script, remove anything no longer in use, and route the remainder through Google Tag Manager with non-critical scripts set to load on delay. This is the most effective single intervention in this layer.
Layer Six: Fonts, Database, and PHP
Fonts: Google Fonts can load slowly in certain regions, and loading multiple font weights across several typefaces compounds the problem. Minimize the number of font families and weights in use โ load only what's actually rendering on the page. Where licensing permits, self-hosting font files on your own server removes the external dependency entirely.
Database cleanup: long-running sites accumulate post revisions, auto-drafts, spam comments, and WooCommerce session data. This accumulation slows database queries over time. WP-Optimize or Advanced Database Cleaner can handle periodic cleanup โ always back up the database before running a cleanup operation.
PHP version: running PHP 8.3 or the current latest supported version delivers meaningfully faster performance than older versions, along with improved security. Confirm theme and plugin compatibility in a staging environment before upgrading production. Most actively maintained plugins have had solid PHP 8.x support for some time now.
WooCommerce-Specific Optimizations
WooCommerce draws on database resources more heavily than a standard WordPress blog. A few additional optimizations specific to stores:
Convert all product images to WebP and serve them through CDN โ stores with many SKUs have large image libraries, and the gains here are proportionally significant. Search functionality slows noticeably in stores with thousands of products; ElasticPress or similar plugins offload search queries to Elasticsearch rather than MySQL's default full-text search. At checkout, limit the number of marketing plugins (upsells, popups) โ each one loads additional scripts on the page where conversion matters most, directly hurting the load time that influences purchase completion.
Speed Optimization Checklist
- [ ] Server is appropriately resourced โ not an underpowered shared host
- [ ] Page caching plugin installed and correctly configured (one plugin only)
- [ ] Cart, checkout, and account pages excluded from caching
- [ ] Redis object caching enabled (strongly recommended for WooCommerce)
- [ ] All images uploaded as WebP and compressed
- [ ] Image lazy loading enabled
- [ ] Cloudflare CDN connected with Brotli and Auto Minify active
- [ ] Unused third-party scripts removed
- [ ] CSS and JS minified and deferred (tested for visual issues)
- [ ] Font families and weights reduced to what's actually in use
- [ ] Database cleaned periodically (revisions, drafts, sessions)
- [ ] Running PHP 8.3 or latest supported version
- [ ] PageSpeed Insights and GTmetrix tests confirm key metrics are in range
- [ ] Core Web Vitals status confirmed in Google Search Console
Speed optimization isn't a one-time project โ it's an ongoing monitoring and adjustment practice. As content grows, plugins update, and traffic scales, performance characteristics shift. Checking Google Search Console and GTmetrix every few months, catching issues early, and adjusting accordingly is far less effort than diagnosing a problem after it's already affecting conversion.