How a Niche E-commerce Site Using 47 GB Monthly Bandwidth Cut Costs, Speeded Up Pages, and Boosted Sales

How a niche retailer with 10,000 visitors a month discovered 47 GB was costing them more than they'd admit
When the owner of a small niche e-commerce store told us they were averaging 47 GB of bandwidth per month, the reaction in our team was immediate: that number could be innocuous or it could hide a mess. This client sold specialty camping gear, averaged about 10,000 sessions per month, and had an average order value of $120. They were on a mid-tier managed VPS and paid for a "managed CDN" add-on that seemed to double as a costly funnel for origin requests.

Two realities became clear on day one. First, site performance was poor - average full page load was 4.2 seconds on mobile, bounce rate hovered near 58%, and conversions were stuck at 1.6%. Second, their 47 GB monthly bandwidth was concentrated in a handful of oversized images, an improperly configured CDN, and a cluster of third-party scripts that made frequent origin calls. The real cost was not just the hosting bill - it was lost conversions and poor user experience.
Client profile and traffic mechanics Monthly sessions: 10,000 Pages per session: 3 Average page size before work: 1.6 MB Monthly bandwidth: ~47 GB Average order value: $120 Conversion rate before: 1.6% (approx. 160 orders) Hosting + CDN stack: Managed VPS with paid CDN add-on and unmanaged S3 buckets for some assets Why 47 GB of bandwidth was strangling performance and profit
47 GB by itself is not a crisis. The problem was where that bandwidth came from and how it was being served. We found four major pain points:
Bulky images and video embeds: Hero images were 2.5-3 MB each, product galleries used full-resolution JPEGs without responsive sources, and some product demo videos were embedded from a raw storage bucket instead of a streaming service. CDN misconfiguration: The CDN was set to pass-through for most requests. Instead of serving cached assets, it forwarded almost every request to the origin. That inflated origin egress and added latency. Excessive third-party scripts: Live chat, multiple analytics instances, A/B testing libraries, and tag managers loaded synchronously. Those scripts blocked the main thread and made pages feel slow despite adequate server CPU. No proper caching headers: Assets lacked long-lived cache headers, so repeat visitors constantly re-requested static files.
When you add those up, you have wasted bandwidth, slow pages, and a host bill that looks modest until you calculate lost revenue from poor conversions. At 1.6% conversion and $120 AOV, the client was doing about $19,200 in monthly revenue. That would change once pages were fixed.
A multi-pronged optimization: move static assets to edge, shrink payloads, and stop asking the origin to work hard
We chose a pragmatic strategy focused on measurable changes that could be rolled out safely. The plan combined best engineering practices with low-cost tools that produce immediate gains. Principal components:
Audit and measurement first - know exactly which files and requests consumed the 47 GB. Push static assets to a properly configured CDN and use origin shielding. Reduce payload by converting images to modern formats, resizing, and lazy loading. Defer and async third-party scripts and remove what was unnecessary. Implement strong caching headers and cache busting where required. Move heavy assets (video, large downloads) to a streaming or dedicated storage solution with cheaper egress. Why we did measurement first
Blind optimizations can break a site. We used server logs, CDN analytics, and tools like WebPageTest and Lighthouse to pinpoint the top 1% of requests that accounted for the majority of bytes. In our case, 12 images and two video files iplocation https://www.iplocation.net/leading-wordpress-hosting-platforms-for-professional-web-designers were responsible for nearly 40% of monthly egress.
Implementing the optimization: a 90-day timeline
The work was split into a 12-week schedule. Each phase had clear deliverables and rollback plans. We kept the client informed with weekly metrics so no change was "mysterious" to the business.
Weeks 1-2 - Audit and quick wins Exported CDN logs and origin access logs to identify top bytes-by-URL. Ran a dependency map of third-party scripts and identified three scripts to remove entirely. Introduced passive monitoring (RUM) to capture real user load times. Weeks 3-5 - Image and media optimization Converted product images to responsive srcset with WebP fallbacks. Average image weight dropped from 900 KB to 160 KB. Replaced in-page video embeds with lazy-loaded poster images linking to hosted streaming files. Video egress moved to a CDN with lower cost and streaming optimizations. Implemented lazy loading on below-the-fold galleries. Weeks 6-7 - CDN and cache rules Changed CDN configuration from pass-through to aggressive caching of static assets with a one-year cache max-age and cache-busting on asset versioning. Enabled origin shielding and tiered caching to reduce origin hits. Set conditional caching for API endpoints and product feeds to avoid stale data. Weeks 8-9 - Script surgery Deferred non-critical JS, inlined critical CSS, and loaded analytics asynchronously. Replaced a heavyweight A/B testing library with a lightweight remote experiment runner for initial rollouts. Weeks 10-12 - Fine tuning and monitoring Stress-tested peak traffic, tuned cache TTLs, and validated no functionality regressions. Set up alerting for egress spikes and a monthly bandwidth report for the client. Rollback plan and safety checks
Every optimization had a canary phase. We released changes to 10% of traffic first, measured performance and conversion, then rolled out to 50% and 100%. If conversion dipped or errors rose, we reversed the last change and investigated.
From 47 GB and 4.2s pages to 18 GB and 1.2s - measurable results in 60 days
Results surfaced fast. Within 60 days the bulk of the work was complete and the numbers told the story.
Metric Before After (60 days) Change Average page weight 1.6 MB 640 KB -60% Monthly bandwidth 47 GB 18 GB -62% Average full load time (mobile) 4.2 s 1.2 s -71% Conversion rate 1.6% 2.4% +50% Monthly hosting + CDN spend $180 $48 -73% Monthly revenue $19,200 $28,800 +$9,600
Lower bandwidth reduced direct costs. The bigger win was faster pages and improved conversion. The client gained roughly $9,600 in monthly revenue from the conversion lift alone. Payback on the team's time and the small tooling fees happened in under one month.
5 critical bandwidth and performance lessons every site owner must learn Measure before changing: Bandwidth is a symptom. Use logs and RUM to find the real causes rather than guesswork. Target the top offenders; in most sites the top 10 files are the problem. Set caching rules deliberately: "Unlimited" hosting is often a trap. Configure long cache TTLs for static files and use cache busting for updates. Modern image formats matter: Converting images to WebP or AVIF and serving responsive sizes cuts bytes dramatically. No one needs a 3 MB hero image on mobile. Third-party scripts are not harmless: Each script can add hundreds of milliseconds and extra bytes. Audit them quarterly and remove deadweight. Roll out changes gradually: Always canary. A small group of users can reveal regressions without affecting the entire business. How your site can replicate this 47 GB breakthrough
Below is a pragmatic checklist and a short self-assessment quiz to help you decide where to start. The steps are ordered for maximum impact with the least risk.
Practical checklist (start here) Export CDN and origin logs for the last 30 days and list the top 25 URLs by bytes transferred. Use Lighthouse, WebPageTest, or SpeedCurve to capture baseline performance and identify render-blocking resources. Create responsive image variants for three breakpoints and convert key asset families to WebP. Replace page hero images first. Enable aggressive CDN caching for static files and configure origin shielding. Set cache-control headers to at least 30 days where appropriate. Defer or async non-critical JS. Inline critical CSS for above-the-fold content. Move large downloads and videos to a dedicated streaming CDN or storage with negotiated egress rates. Measure real user metrics (CLS, FID, LCP) and track conversion rate alongside performance to spot regressions. Quick self-assessment quiz - where are you wasting bandwidth?
Answer yes/no. Give yourself 2 points for each "yes" that indicates a problem.
Do you serve full-size images to mobile devices? (Yes = problem) Do your assets lack cache-control headers? (Yes = problem) Do you load multiple analytics or tracking scripts synchronously? (Yes = problem) Is your CDN configured to forward most requests to origin instead of serving cached files? (Yes = problem) Do you host videos from raw buckets without streaming optimization? (Yes = problem)
Scoring guide:
0 points - Clean. You still should periodically audit. 2-4 points - Medium risk. Prioritize images and CDN settings. 6-10 points - High risk. Follow the checklist and consider a short engagement with an optimization specialist. If you score high - a 30-day sprint you can copy Week 1: Audit logs, identify top 10 byte blobs, enable RUM. Week 2: Replace hero images with responsive WebP and enable lazy load on galleries. Week 3: Reconfigure CDN caching rules and enable origin shielding. Move one heavy video to a streaming CDN. Week 4: Defer third-party scripts, measure impact on conversion, and iterate.
Do not fall for silver-bullet promises from vendors that guarantee "instant speed." Many fixes are simple and incremental. Focus on the largest bytes first, then refine the experience.
Final practical tips from experience Keep a monthly bandwidth dashboard. A small spike can indicate a broken image URL or a bot scan. Automate image generation in your build pipeline so content editors do not upload oversized files. Audit third-party scripts every quarter and require product owners to justify each script's presence with measurable ROI. When negotiating hosting or CDN contracts, ask for realistic egress pricing examples that match your traffic profile, not vendor averages.
Our client went from worrying about 47 GB to treating bandwidth as an instrument of growth rather than a cost center. The combined effect of lower costs, faster pages, and higher conversions turned a monthly expense into a lever for revenue growth. If your site looks like the one in this case study, you have an opportunity to reclaim dollars and seconds - and those translate directly to customers.