How to Reduce Webflow Bandwidth Before It Quietly Raises Your Bill.

What counts as bandwidth on Webflow?

Bandwidth is the total amount of data Webflow sends from its servers to your visitors' browsers each month. Every byte counts: images, fonts, JavaScript, CSS, video, PDFs, and every repeat visit that is not served from cache.

A useful way to think about it: bandwidth is not a Webflow tax. It is a measurement of how heavy your site is and how often people load it. A 5 MB homepage viewed 10,000 times a month burns 50 GB on its own. The same page trimmed to 1.2 MB burns 12 GB for the identical traffic. Bandwidth is downstream of page weight, and page weight is something you control.

That reframe matters because the work you do to lower your bill is the same work that improves Largest Contentful Paint, reduces load time on mobile, and gives AI crawlers lighter pages to fetch. You are not just saving money. You are shipping a faster, more citable site.

What are Webflow's bandwidth limits in 2026?

On May 13, 2026, Webflow simplified its Site plans and merged the old CMS and Business plans into a single Premium plan. This changed the numbers most people had memorized.

The line to notice: Premium starts at 50 GB, while the old Business plan included 100 GB. If you were on Business and your site was comfortably using 70 or 80 GB, you did not have a problem before. Under Premium, you now do.

Ecommerce Site plans were not part of this update and keep their own structure.

How does Webflow actually charge for going over?

This is the part most guides get wrong, so it is worth being precise.

Webflow does not charge a per-gigabyte overage fee. There is no meter that adds a dollar every time you cross a line. The mechanic is different, and slower, and easier to miss:

1. The first month you exceed your limit, Webflow applies a grace period, often called surge protection. Nothing changes on your bill yet.
2. If you exceed the limit again the following month, Webflow treats it as a pattern. It automatically adds a bandwidth add-on to your Site plan to cover the usage.
3. That add-on is recurring. It stays on your plan and raises your monthly cost until you reduce usage back under the threshold or manage it deliberately.

Bandwidth add-ons scale from an extra 50 GB up to a 2.5 TB total. The entry tiers are inexpensive, in the low tens of dollars per month, but the higher tiers climb fast. Because Webflow does not publish every add-on price cleanly across every plan and the tiers have shifted with the May 2026 change, treat any specific dollar figure you read elsewhere with caution and confirm the current numbers on Webflow's own pricing page before you budget.

The practical takeaway: bandwidth costs do not spike overnight. They creep. You get one month of warning, then a recurring charge that many site owners do not connect back to a heavy hero video they added six weeks earlier. Catching it early is the entire game.

How do you find what is eating your bandwidth?

Do not optimize blindly. In almost every site, a small number of assets account for the majority of transfer. Find them before you touch anything.

Three ways to audit, from fastest to most thorough:

• Browser DevTools, Network tab. Open your page, disable cache, reload, and sort requests by size. The heaviest three or four items are usually your whole problem. This takes two minutes and tells you more than any dashboard.
• PageSpeed Insights or WebPageTest. Both report total page weight and flag oversized images, render-blocking resources, and unused code. WebPageTest also shows you the waterfall so you can see what loads on every visit.
• Webflow's asset panel and CMS. Scan for large uploaded images and any video files hosted directly in Webflow. Background videos and full-resolution CMS images are the two most common silent offenders.

The pattern you will almost always find: one hero video, a set of uncompressed CMS images, and a full-weight font family are doing most of the damage.

The fixes, from quick wins to infrastructure

Work top to bottom. The first three cover most of the savings for most sites.

1. Fix your images first

Images are the single largest lever on nearly every marketing site.

• Serve modern formats. WebP and AVIF are dramatically smaller than PNG or JPEG at the same visual quality. Webflow converts many uploaded images to WebP automatically, but background images and some CMS uses can slip through. Verify in the Network tab what format is actually being served.
• Ship the right dimensions. A 4000-pixel-wide image dropped into a 600-pixel slot wastes most of its bytes. Resize before upload. Webflow generates responsive variants for image elements, but not for background images, so those need to be sized correctly by hand.
• Lazy-load below the fold. Anything not visible on first paint should load only when the visitor scrolls to it. Webflow's image element supports this; set it and confirm it.

Here is the underlying HTML pattern if you are placing an image through a custom embed rather than the Designer:

<img
  src="/images/dashboard-800.webp"
  srcset="/images/dashboard-400.webp 400w,
          /images/dashboard-800.webp 800w,
          /images/dashboard-1600.webp 1600w"
  sizes="(max-width: 768px) 100vw, 800px"
  loading="lazy"
  width="800"
  height="500"
  alt="Product dashboard showing pipeline metrics">

The browser downloads only the size it needs for the visitor's screen, and only when the image is about to enter view.

2. Get video off Webflow

Self-hosted video is the fastest way to blow through a bandwidth limit. A single autoplaying background video can transfer more data in a week than the rest of your site does in a month.

• Move hero and background video to YouTube or Vimeo and embed it, or stream it from a dedicated video host.
• Replace autoplay with a poster image plus click-to-play. Most visitors never press play, so you avoid shipping the video bytes to everyone.

A lightweight click-to-load pattern you can paste into a Webflow embed:

<div class="video-facade" style="cursor:pointer;position:relative">
  <img src="/images/video-poster.webp" alt="Watch the product demo" width="1280" height="720">
  <button aria-label="Play video" class="play-btn"></button>
</div>

<script>
  document.querySelector('.video-facade').addEventListener('click', function () {
    this.innerHTML =
      '<iframe width="1280" height="720" ' +
      'src="https://www.youtube.com/embed/VIDEO_ID?autoplay=1" ' +
      'frameborder="0" allow="autoplay; encrypted-media" allowfullscreen></iframe>';
  });
</script>

The page loads a single poster image. The video only downloads if someone actually wants to watch it.

3. Subset and trim your fonts

Full font families are heavier than they look, especially if you load weights you never use.

• Use woff2, the most compressed web font format.
• Load only the weights and styles that appear on the page. Four weights of a family you use twice is waste.
• Subset the character set if you only serve one language.

4. Offload downloadable files

If your site is a lead-magnet machine (whitepapers, PDFs, ebooks, downloadable assets), those downloads count against your Webflow bandwidth every single time someone grabs one. A popular gated PDF can quietly consume tens of gigabytes a month.

Move those files to object storage such as Cloudflare R2 or Amazon S3 and link to them there. The download traffic then hits that storage bill, which is far cheaper per gigabyte than a Webflow bandwidth add-on, and it never touches your Webflow limit.

5. Trim code and third-party scripts

• Webflow minifies CSS and JavaScript on publish, so the built-in code is already handled.
• The weight usually comes from third-party embeds: chat widgets, analytics stacked on analytics, marketing pixels, heavy animation libraries. Audit what actually earns its place, and defer or async-load what stays.

6. Put a caching proxy in front (advanced)

This is the infrastructure lever, and it ties directly into how we think about Webflow hosting at the architecture level.

Webflow measures bandwidth as data served from Webflow's servers. If you route your domain through Cloudflare and configure cache rules so that static assets are cached at Cloudflare's edge, repeat requests for those assets are served from Cloudflare, not from Webflow. Those cached hits never reach Webflow's origin, so they do not count against your Webflow bandwidth.

The caveats are real and worth stating plainly:

• Only cacheable static assets benefit. HTML that changes and any dynamic behavior still hits the origin.
• SSL mode and cache configuration have to be correct, or you will either break the site or cache nothing.
• Webflow already runs its own CDN, so you are layering a second edge in front of it. This works, but it is a deliberate setup, not a toggle.

This is the same reverse-proxy thinking behind running Cloudflare Workers in front of Webflow for server-side rendering. If you want the full walkthrough of that setup, see our guide on Webflow with Cloudflare Workers.

What eats bandwidth, and what to do about each

When should you stop optimizing and reconsider the platform?

Here is the honest version, from an agency that builds on Webflow every week and runs its own site on Astro.

For the large majority of B2B marketing sites, the answer is: stay on Webflow and optimize. The fixes above will pull most sites well under the Premium limit, and Webflow's speed of iteration is worth far more than the bandwidth you are trying to save. Optimizing images and offloading video is a couple of hours of work that pays for itself and improves your Core Web Vitals as a bonus.

There is a narrower case where bandwidth is a symptom of a deeper mismatch. If you run a high-traffic content operation, a media-heavy site, or a product where large assets are the point, and you find yourself perpetually fighting the cap and stacking add-ons, the economics of a visual hosting plan may simply not fit your use case. A static or edge-rendered stack, for example Astro deployed to Cloudflare Pages or Vercel, removes metered bandwidth as a line item at the traffic levels most marketing sites operate at.

We took that route for our own site, deliberately, because we manage it solo and wanted full development control. That is a specific decision for a specific situation, not a blanket recommendation. If you are a marketing team that values editing in a visual canvas, migrating away to dodge a bandwidth bill you could have solved with image compression would be the wrong trade. If you want a straight read on whether your site is bandwidth-bound or just under-optimized, our Webflow to Astro migration guide lays out where the line actually is.

Key takeaways

• Webflow bandwidth overages are not a per-gigabyte meter. They are a recurring add-on applied automatically after two billing months over the cap, which is why they are easy to miss and worth catching early.
• After May 2026, Premium includes 50 GB of base bandwidth. Former Business-plan sites lost half their included allowance and are the group most likely to feel this.
• A few heavy assets cause most of the problem. Audit first, then fix images, video, and downloadable files in that order.
• The same optimizations that lower your bill also improve Core Web Vitals and make your pages lighter for AI crawlers to fetch and cite.
• Only reconsider the platform if you are truly bandwidth-bound. For most marketing sites, optimizing beats migrating.