Web Hosting Bandwidth Explained: Metered, Unmetered & Unlimited — What They Really Mean

What Counts as Bandwidth (And What Does Not)

Most site owners assume bandwidth is just "how much traffic their site gets." That is close but not precise enough to make good decisions. Bandwidth is data transfer: the total bytes your server sends to visitors across all HTTP and HTTPS responses in a given month. Some of those bytes you control. Some you do not. And a meaningful chunk can be shifted off your hosting account entirely.

What Uses Your Hosting Bandwidth

• HTML pages: Every page load transfers the rendered HTML document. A typical WordPress page is 30 to 80 KB of HTML. This is the smallest component of total transfer on most sites.
• Images: The dominant consumer. Unoptimized product images, hero photos, and inline graphics routinely make up 60 to 80 percent of a page's total weight. An unoptimized 1,200 x 800 JPEG uploaded directly from a camera is 3 to 8 MB. Multiply by every image on every page and you understand where most bandwidth goes.
• CSS and JavaScript: Combined, typically 200 KB to 1.5 MB per page on a site with a modern theme and several plugins. Compressible (see the Brotli section below), but not eliminable.
• Web fonts: WOFF2 format fonts are 20 to 100 KB each. A site loading three custom fonts from your own server adds 60 to 300 KB per visit.
• Video and audio files served from your host: The fastest way to exhaust any bandwidth allocation. A 200 MB video file viewed by 500 visitors generates 100 GB of transfer from that one asset. Never serve video directly from shared hosting.
• File downloads: PDFs, ZIP archives, software packages served from your hosting account count as direct transfer against your allocation.
• Bot and crawler traffic: Googlebot, Bingbot, and other legitimate crawlers generate traffic. Vulnerability scanners, scrapers, and spam harvesters generate more. I have seen sites where bad bot traffic consumed 35 percent of total monthly bandwidth without contributing a single real visitor.
• API requests: REST API responses from WordPress, JSON feeds, and XML sitemaps all count.

What Does Not Use Your Hosting Bandwidth

This is the useful part. These categories can offload a large share of your total transfer away from your hosting account:

• Files served from a CDN: When Cloudflare or BunnyCDN serves an asset from its edge cache, that traffic hits the CDN network, not your origin server. Your host never sees the request. This is why CDN offload is the highest-impact bandwidth reduction available.
• YouTube and Vimeo embeds: A video embedded from YouTube plays from YouTube's servers. The video data transfers from Google's infrastructure to your visitor. Your hosting bandwidth is not involved at all beyond the HTML that references the embed.
• Third-party hosted fonts: Fonts loaded from Google Fonts, Adobe Fonts, or a font CDN serve from those external networks. If you load fonts from your own server, they count. Externally hosted fonts do not.
• Email: On most hosts, email bandwidth is measured separately from web hosting bandwidth, or not measured at all. Check your specific host's documentation if email volume is high.

The pattern here is clear: anything you can move to a CDN or third-party service stops consuming your hosting allocation. The entire optimization strategy in the sections below follows from this principle.

The Unlimited Bandwidth Myth and the Fair Use Reality

Every shared hosting plan advertised as "unlimited bandwidth" has a fair use clause buried in the terms of service. That clause is not a technicality. It is the actual policy. Understanding what it says in practice is more useful than trusting the headline.

The term "unlimited" in hosting means the provider has chosen not to publish a specific gigabyte cap. It does not mean you can transfer any volume of data for any purpose without consequence. The fair use policy defines what "standard web hosting" means to that provider. Almost universally, it prohibits:

• Using the account primarily as a file distribution server
• Streaming video to users from the hosting account
• Operating a service whose primary purpose is large-scale data transfer (torrent proxies, software distribution, large media libraries)
• Generating sustained data transfer that measurably degrades server performance for neighboring accounts

What "unlimited" does permit: a standard WordPress site that gets a large traffic spike, publishes frequently, or has a viral post. The policy protects the shared hosting infrastructure from being used as a data center. It does not restrict normal, growing web traffic.

How Different Hosts Handle This in Practice

The two most honest bandwidth policies in managed WordPress hosting belong to Kinsta and Cloudways. Kinsta publishes actual bandwidth numbers per plan (not "unlimited") and separates CDN bandwidth from origin bandwidth so you can see exactly what you are getting. Cloudways measures actual monthly transfer with a published overage rate, which means you can project costs. A $0.02 per GB overage on 50 unexpected GB costs one dollar. That transparency is more useful than an unlimited claim with an enforcement policy you discover only after the account is suspended.

How to Calculate Your Real Bandwidth Needs

Most hosting guides tell you what plans include. None tell you how to work out whether those plans cover your site before you commit to one. Here is the formula and how to get the inputs right.

Step 1: Find Your Actual Page Size

Average page size is the most important input and the one most often guessed wrong. Three ways to measure it accurately:

• Chrome DevTools: Open DevTools (F12), go to the Network tab, check "Disable cache," and reload the page. The total transferred size appears at the bottom of the Network panel. Do this for your five most-visited page types and average the results.
• GTmetrix: Run a free test at gtmetrix.com. The summary shows "Page Size" in the first row of the performance metrics. Also shows the breakdown by file type, which tells you where to cut.
• WebPageTest.org: The waterfall view shows every request with its file size, giving you the full breakdown including third-party requests.

Most site owners are surprised by their measured page size. A site that "feels fast" because of caching might be transferring 3 to 5 MB per uncached load. That number feeds directly into the bandwidth calculation.

Bandwidth by Site Type: 1,000 Daily Visitors

Worked Example

The CDN offload number is what your hosting plan needs to cover. The pre-CDN number is what you use to evaluate whether a CDN would solve a current overage problem. If you are on a 50 GB plan and using 45 GB per month, adding Cloudflare free tier will almost certainly drop you to 5 to 8 GB per month and give you runway to grow significantly before bandwidth becomes a constraint again.

Reduce Bandwidth Step 1: Serve Assets via CDN (The 60 to 90 Percent Fix)

Every other bandwidth optimization in this guide is secondary to this one. A CDN does not compress files more efficiently or block more bots. It removes the transfer from your hosting account entirely by serving cached copies of your assets from a separate network. You cannot compress your way to a 90 percent bandwidth reduction. You can CDN your way there.

The mechanism: Cloudflare, when configured as your DNS proxy, sits between your visitors and your origin server. Requests for images, CSS, JavaScript, and fonts go to the nearest Cloudflare edge node. If Cloudflare has a cached copy, it serves it and your origin server is never contacted. Your hosting bandwidth allocation is not touched. Only requests for dynamic content (fresh PHP-generated pages) pass through to your origin.

For a typical WordPress site where images alone are 65 percent of page weight, offloading images to Cloudflare edge cache cuts origin bandwidth by at least 50 percent before touching anything else. Add CSS and JavaScript (another 20 percent of page weight) and the effective origin bandwidth drops to the fraction required for HTML responses only.

Cloudflare Free Setup: 5 Steps

Alternative CDN Options

Cloudflare free is the right starting point for most sites. Two alternatives worth knowing:

• BunnyCDN: Charges at $0.005 to $0.01 per GB of CDN traffic. No free tier, but the lowest per-GB rate available for pure asset delivery. The right choice for high-volume sites where you want CDN bandwidth to be metered and predictable rather than included in a flat plan.
• KeyCDN: Pay-as-you-go at $0.04 per GB. 48 edge locations. No monthly minimum. Works as a pull zone with URL rewriting through WP Rocket or LiteSpeed Cache.

The full mechanics of how a CDN caches, when it bypasses cache, and how cache hit ratios affect your bandwidth reduction are covered in detail in the CDN explainer. Understanding cache hit ratios is particularly relevant for WooCommerce sites, where logged-in users and cart sessions prevent many pages from being cached at all.

Reduce Bandwidth Step 2: Optimize Images Before They Hit the Server

A CDN delivers your images faster and offloads the transfer from your hosting account. It does not reduce the size of the images being delivered. An unoptimized 4 MB JPEG served from Cloudflare edge still transfers 4 MB. The optimization and the CDN work independently: cutting image sizes reduces total transfer volume, CDN offload moves that transfer off your hosting plan. Both matter.

After working with image libraries on dozens of WordPress sites, the most common failure I encounter is a media library full of images uploaded straight from cameras or stock photo downloads with no resizing or format conversion. A single image at 4,000 x 3,000 pixels displayed in a 800 x 600 container transfers six times the pixels that will actually be rendered. The browser downloads all of them.

Target Sizes That Actually Matter

• Hero images: Target under 200 KB. Maximum display width on most sites is 1,440 px. An 1,440 x 600 px WebP image at 75 percent quality should be 80 to 150 KB.
• Content images: Target under 100 KB. Blog post images displayed at 800 px wide should be 40 to 80 KB in WebP format.
• Thumbnails and grid images: Target under 30 KB. These are loaded in bulk on archive pages. A category page showing 12 products should not load 1.2 MB of thumbnail images.

Format: WebP and AVIF

WebP saves 25 to 35 percent over JPEG at equivalent visual quality. AVIF saves 40 to 55 percent. Both are lossless compression options with better algorithms than JPEG. Current browser support: WebP works in every browser in active use. AVIF is supported in Chrome, Firefox, Safari 16+, and Edge.

You do not need to convert manually. Three approaches by workflow:

• Before upload (best): Squoosh.app converts individual images to WebP or AVIF in the browser, for free. Drag in a JPEG, select WebP or AVIF, set quality to 75 to 85 percent, and download. The file size feedback is immediate.
• WordPress plugin (easiest for bulk conversion): ShortPixel or Imagify convert existing media library images automatically and serve WebP to supported browsers with JPEG fallback. Both have free tiers covering a few hundred images per month.
• CDN-level conversion: Cloudflare Pro includes Polish and Mirage, which convert and resize images at the edge on delivery. The original files on your server stay as JPEG; Cloudflare serves WebP automatically to browsers that support it.

Lazy Loading

Lazy loading tells the browser to defer loading images until they are about to scroll into view. On a long blog post with 10 images, a visitor who reads only the first three paragraphs downloads only the first two or three images rather than all ten. This reduces per-visit bandwidth for visitors who do not read to the bottom. The implementation is one HTML attribute: loading="lazy" on image tags. WordPress adds this to images automatically since version 5.5. Verify it is working by checking your page source for the attribute on below-fold images.

Reduce Bandwidth Step 3: Compression, Bot Blocking, and Video Decisions

After CDN offload and image optimization, three more bandwidth levers remain: text file compression, bad bot removal, and video hosting decisions. Each addresses a different part of the transfer picture.

Enable Brotli Compression on Text Assets

Text files (HTML, CSS, JavaScript) compress dramatically. GZIP reduces text assets by 60 to 75 percent. Brotli reduces them by 70 to 85 percent. A 400 KB JavaScript bundle that your browser receives as Brotli-compressed data is under 80 KB of actual network transfer. These savings compound: every visit to every page transfers less CSS and JS.

How to verify compression is active:

curl -sI -H "Accept-Encoding: br" https://yourdomain.com | grep content-encoding
# If Brotli is active: content-encoding: br
# If GZIP only: content-encoding: gzip
# If neither: no content-encoding header (bad)

Enabling compression: if you are on Cloudflare, enable Brotli under Speed > Optimization (it is a single toggle). If you are on cPanel hosting, your host likely has Brotli or GZIP enabled at the server level already. If not, LiteSpeed Cache or W3 Total Cache can enable GZIP through their settings. If you have VPS access, add brotli on; to your Nginx config inside the http block.

Block Bad Bots

Bad bots are the bandwidth expense that most site owners do not notice until they look at the server logs. Vulnerability scanners, spam harvesters, AI training crawlers, and scraping operations hit pages continuously. They do not buy products. They do not read content. They generate HTTP responses that count against your allocation.

Two effective approaches:

• Cloudflare Bot Fight Mode: Available on the free tier under Security > Bots. Detects and challenges known bot fingerprints before they reach your origin. I have seen this reduce origin requests by 15 to 30 percent on sites that have been indexed for a few years and accumulated scraper attention.
• Wordfence Bot Blocking: If Cloudflare is not an option, Wordfence's free tier blocks requests matching known malicious user agents at the WordPress application layer. It does not prevent the HTTP request from reaching the server, but it does prevent WordPress from generating a full response, reducing the data transferred per bot request.

Video: Never Self-Host on Shared Hosting

A 150 MB video file viewed by 1,000 visitors consumes 150 GB of bandwidth from that one asset. On most shared hosting plans, that is the entire month's allocation from a single piece of content. Self-hosting video on shared hosting is the single fastest path to an unexpected suspension.

The correct architecture depends on your control requirements:

• YouTube or Vimeo embeds: Public video that you do not mind living on their platforms. Their bandwidth, not yours. Zero setup. The video data never touches your hosting account.
• Cloudflare R2: For video you need to control. Free egress (you pay $0.015 per GB of storage, nothing for delivery). Create a bucket, upload the video, use the public URL in a <video> tag or a player like Plyr.js. No CDN fee for delivery. The free egress policy makes this the lowest-cost self-controlled video hosting available.
• Backblaze B2: Similar to R2. Storage at $0.006 per GB per month. Egress is free when paired with Cloudflare, which is the standard configuration for B2. Slightly cheaper storage than R2 for large libraries.

Reduce Bandwidth Step 4: Page Caching Reduces How Much Your Server Transfers

Page caching reduces bandwidth in a way most explanations miss. The connection is not obvious: a cached page is not just faster to serve, it is smaller. An uncached WordPress page includes all the dynamically generated overhead from PHP and database queries. A cached static HTML file has the same content but without the extra headers, debugging output, and WordPress-specific metadata that some poorly configured setups add. More practically: a cached HTML page served from your origin is the only part of a page load that your CDN cannot fully cache on the first visit. Getting that HTML response small and fast reduces the one part of origin bandwidth that is unavoidable.

The bigger bandwidth benefit from page caching comes from reducing the number of requests that reach your PHP application at all. An uncached WordPress page triggers PHP execution plus multiple database queries. If your host measures "bandwidth" as including all server-side processing overhead (some do), cached pages cost less bandwidth per request.

For CDN-cached full pages (Cloudflare APO or a page cache with CDN integration), the bandwidth win is complete: the HTML is served from the CDN edge and the origin never transfers it at all. That is the configuration to aim for on any high-traffic content site.

Cache plugin recommendations by setup:

• LiteSpeed Cache: Free. Works best on LiteSpeed web servers, which are common on cPanel hosts. Handles page cache, object cache, CDN integration, and image optimization from one plugin. Check your server type first: curl -sI yourdomain.com | grep -i server.
• WP Rocket: Paid ($59 per year per site). Works on Apache and Nginx hosts. The cleanest setup with the fewest configuration mistakes. Integrates with Cloudflare for automatic CDN cache purge on publish.
• W3 Total Cache: Free. Maximum flexibility with maximum complexity. The correct choice if you need granular control or are running a non-standard WordPress setup.

The full cache layer picture, including object cache, PHP OPcache, Redis setup, and WooCommerce cache exclusions, is covered in the WordPress cache guide. Bandwidth reduction is one benefit of caching. Performance and server load reduction are the bigger motivations, and they are interconnected.

Bandwidth vs Speed: Why More Transfer Headroom Does Not Mean Faster Pages

Upgrading to a hosting plan with more bandwidth does not make your site load faster. This is the most common bandwidth-related misconception I encounter, and it comes from conflating two metrics that measure entirely different things.

Bandwidth is capacity: the total volume of data your server can send per month. Speed is latency and processing time: how quickly your server generates and delivers each individual response. A server can have a 10 TB monthly allocation and still take 2.5 seconds to respond to each request. The bandwidth headroom is irrelevant to that 2.5 second wait.

The right fix for a speed problem is not more bandwidth. It is faster PHP (better hosting tier, OPcache configuration, fewer plugins), faster database (object cache with Redis, query optimization), or better caching (page cache that eliminates PHP execution for public pages). These are the constraints that affect time to first byte and Core Web Vitals scores.

A CDN improves both bandwidth and speed simultaneously, but for different reasons. It reduces bandwidth because CDN-cached assets do not transfer from your origin. It improves speed because static assets are delivered from an edge node physically close to your visitor instead of from a distant origin server. These are two separate mechanisms happening in the same product.

What to Do If You Are Already Hitting Bandwidth Limits

If your host has already warned you about bandwidth usage, or you are watching the counter approach your monthly cap, here is the sequence that resolves most situations without upgrading your hosting plan.

Option A: Optimize First (Always Start Here)

Before paying for more bandwidth, measure where it is going. Open your CDN analytics (Cloudflare shows origin vs cached traffic). Check your server logs for bot patterns. Run GTmetrix on your highest-traffic pages. In most cases, the bandwidth consumption is concentrated in two or three sources: unoptimized images, video files served from the origin, or a sudden increase in bot scanning activity. Fixing those specific causes is faster and cheaper than upgrading hosting.

Option B: Add Cloudflare (Even If You Already Have Another CDN)

If you are hitting limits without a CDN, adding Cloudflare free tier is the single step that resolves most overage situations immediately. From the calculation in the earlier section: a site using 80 GB per month typically drops to 8 to 16 GB after Cloudflare is configured. If you already have Cloudflare but are still hitting limits, check your cache hit ratio in the Cloudflare dashboard under Analytics > Cache. A hit ratio below 60 percent means most requests are still going to origin. The issue is usually uncacheable cookies, missing cache rules for image types, or a cache bypass from a security plugin setting a Cookie header on all responses.

Option C: Move Video to Cloudflare R2

If video is causing the overage, this is a same-day fix:

1. Sign into Cloudflare and go to R2 Object Storage. Create a bucket.
2. Upload your video file to the bucket.
3. Enable Public Access on the bucket to get a public URL.
4. Replace the <video src="..."> tag in your content with the R2 public URL.
5. The video now serves from Cloudflare's network with free egress. Your hosting server is not involved.

Cloudflare R2's free egress policy means the video data transfer does not cost anything beyond storage. You pay $0.015 per GB per month for the stored file, nothing for delivery. A 500 MB video file costs $0.0075 per month to store and delivers to unlimited visitors at no additional cost.

Option D: Upgrade the Hosting Plan

Upgrade last, after optimization. If optimization and CDN offload still leave you consistently over quota, the right upgrade path is: shared hosting with higher quota or unmetered plan, then cloud hosting with measured overage billing, then managed VPS with dedicated port speed. Each step gives more transfer headroom but also requires more configuration and cost. Most sites that appear to need a hosting upgrade actually need CDN setup and image optimization.

Bandwidth Policies Across Hosting Types

Bandwidth policy differs more between hosting types than almost any other spec. Understanding the enforcement model helps you choose the right environment for your site's traffic pattern.

For the detailed comparison of what ScalaHosting and Cloudways include in their plans and how their bandwidth policies work in practice alongside their other hosting features, the best web hosting comparison covers both in detail.

Where to Go Next

Bandwidth is one component of your hosting infrastructure's performance picture, but it rarely works in isolation. The CDN guide covers the full CDN request flow, cache hit ratios, Cloudflare's APO for full-page WordPress caching, and exactly how CDN offload interacts with WooCommerce session cookies that prevent many pages from being cached at all. If you followed the CDN setup steps here and want to understand why some pages are still hitting origin, that guide explains the bypass mechanics in detail.

If page load speed is the problem alongside or instead of bandwidth, the TTFB guide breaks down the server response time components that a CDN cannot fix for dynamic pages. Slow PHP execution and database queries produce slow TTFB regardless of how much bandwidth the plan includes. The WordPress cache guide covers the full six-layer cache stack and which plugins configure each layer correctly. Getting object cache (Redis), page cache, and CDN cache all working together is the baseline for a genuinely fast WordPress site. For sites that have grown beyond what shared hosting handles well on CPU and memory rather than bandwidth, the managed VPS guide explains when the move to a dedicated environment makes sense and what to look for when evaluating providers.