WordPress Site Speed Audit: The 8MB That Most Tools Missed
TL;DR
A specialty e-commerce brand’s mobile homepage looked fine on paper. GTmetrix and Lighthouse both scored the media payload at around 5.5MB. The real number, measured byte for byte off the wire, was over 13MB. A full WordPress site speed audit traced 8.2MB of that gap to a CDN that never reports its own transfers to any standard testing tool, meaning every byte it delivered was invisible to the software both we and the client had been trusting. After converting oversized product demo GIFs to video, fixing a WebP setting that had silently been off since January, and clearing out code no shopper ever needed, total mobile media dropped 91 percent: from 8.2MB down to 0.7MB.
In This Case Study
Your website is running right now, on its own, with no one watching. Real visitors are loading it on real phones, on real cell connections, this minute. Most site owners trust their speed test score to tell them how that experience actually feels. This case study is about what happens when that score is wrong, and nobody notices for months because every tool available says everything is fine.
What Happens When Every Speed Tool Agrees, and They Are All Wrong?
The client is a specialty e-commerce brand running WooCommerce on Cloudways, with a dual CDN setup (Cloudflare plus a second provider) handling image delivery. Their homepage was scoring poorly on mobile speed tests, but the reports did not add up. The testing tools said the page was about 5.5MB. Our own instruments initially agreed. Everything we optimized helped, a little. Something kept eating the improvements before they showed up in the real experience.
That is the moment most performance work stalls out. The dashboard says you fixed it. The score barely moves. Either the fix did not work, or the dashboard is not measuring the right thing. In this case, it was the second one.
How Does a Real WordPress Site Speed Audit Catch What Other Tools Miss?
The answer was hiding behind the store’s own CDN. The content delivery network serving the site’s images does not emit the timing headers that speed tools rely on to measure a transfer, so every byte it delivered was invisible to standard performance audits. GTmetrix could not see it. Browser timing APIs could not see it. Both simply reported those transfers as zero.
So we stopped trusting the dashboards and measured the actual bytes crossing the wire instead. The real number: the homepage delivered more than 13MB to a mobile phone, and 8.3MB of that was three animated GIFs sitting in a “How to Use” section. Product demo clips, set to autoplay on loop, each roughly the size of an entire website, downloading in full for every single visitor. The heaviest one alone was 3.5MB, for a five second demo clip.
Every one of these tools was working exactly as designed. None of them could see the 8MB the CDN never reported. The audit only found it because we measured the wire, not the report.
What Was Actually Slowing the Store Down?
Animated GIF is a decades-old format doing a job that video now does far better. We converted all three demo clips to modern video, keeping the same autoplay, the same loop, the same silent playback, and the same rounded corners so the visitor experience did not change at all, only the weight behind it.
93%
Smaller product demos (8,258KB to 588KB, GIF to video)
76%
Smaller hero image (845KB PNG to 201KB WebP)
91%
Total mobile media reduction (8.2MB to 0.7MB)
Once the demos were fixed, we kept pulling on the thread and found three more problems hiding in plain sight:
The image optimizer had been generating WebP versions of every image since January, and serving none of them. A single delivery setting was switched off. So what does that mean for a shopper? Every product photo on the site had a lighter, faster version sitting ready and unused for months. One toggle turned the 845KB hero image into 201KB.
The theme was shipping WordPress’s own admin media library code to every visitor. Roughly 150KB of upload dialog JavaScript that no shopper could ever use or trigger, left over from a development build. So what does that mean for a shopper? They were downloading part of the store’s back office before they ever saw a product.
The brand font was declared six separate times across the theme’s stylesheets, and every one of them pointed to the older, heavier format. Modern browsers dutifully downloaded the bigger, slower file each time. So what does that mean for a shopper? Text on the page was rendering in a fallback font for longer than it should have, because the correct font was arriving late. We fixed all six declarations; the font now loads before first paint.
The Layout Shift Bug Three Tools Missed
One stubborn metric refused to explain itself: a layout shift score that showed up in lab tests but nowhere on screen. We frame by frame reviewed the testing service’s own screen recording, and the page looked rock stable the whole time. The testing service strips out the diagnostic detail that would explain a score like that, so it stayed unauditable until we ran a local, fully instrumented performance engine with full diagnostics intact.
That run named the culprit: a single image with no declared dimensions. The site’s caching plugin lazy loads it, collapsing the space to zero height until the image arrives, then expanding it, a shift too fast for a human eye to register but slow enough for a lab test to score every time. Two attributes, width and height, fixed it for good. The bug had been sitting in the page for years, invisible to the naked eye and measurable only by the right tool pointed the right way.
What This Means for Your Site
Every one of these problems passed every standard check before we got involved. The image optimizer was installed and technically “working.” The theme was professionally built. The speed reports were generating on schedule, right on time, every week. None of that caught the 8MB the homework never mentioned.
Your website is your storefront and your best salesperson. You want it open, fast, and ready the moment a real customer walks in, not quietly serving them 8MB of media your own tools swear does not exist. If your speed score has been stubbornly stuck for months despite real optimization work, this is exactly the kind of blind spot worth ruling out before you spend another dollar on a fix that cannot move the number that is actually broken.
This is the kind of digging that happens as standard practice under a Titanium Care Plan: not just running the same tools everyone else runs, but measuring what those tools cannot see. If you want a second set of eyes on your own site’s real numbers, you can also schedule a free assessment and we will walk through what your site is actually sending, not just what the dashboard says it is sending.
Want to Know What Your Site Actually Sends to a Phone?
That is the first thing we check, before we touch a single plugin.
Frequently Asked Questions
Why didn’t GTmetrix or PageSpeed catch this 8MB problem?
Both tools rely on timing headers that a transfer has to report about itself. The CDN handling this store’s images does not emit those headers, so the tools recorded those transfers as zero bytes. The tools were not broken, they were simply blind to a specific type of connection. Finding it required measuring the actual bytes on the wire instead of trusting the report.
Can I check my own site’s real transfer size myself?
You can get a good first read with your browser’s own network panel, watching total transferred bytes on a mobile emulation profile rather than the “size” column speed tools report. It will not catch every blind spot the way a full audit does, but it is a fast way to sanity check whether your speed score and your real payload agree.
Is this the kind of problem a caching or speed plugin can fix on its own?
No. Caching and image plugins are useful, but they optimize what they can see and measure. A CDN that hides its own transfers, a WebP setting quietly switched off, or admin code left in a theme by accident will not show up in a plugin dashboard. Those need a human looking at the actual wire traffic, not another automated report.
How often should a WooCommerce store get a full speed audit?
Once a year at minimum, and sooner after any theme update, plugin change, or CDN migration. Most of the issues in this case study, the dormant WebP setting, the leftover admin code, the duplicated font declarations, were introduced quietly over time rather than all at once. Regular checks catch them before they compound.
What is included in Your WP Guy’s Titanium Care Plan?
Titanium is our proactive performance engineering tier: full-site monitoring, hands-on optimization work like the fixes in this case study, and direct access to a real person when something needs attention. You can see current plan details on our care plans page.
