Learn
>
Sygnal-U
>
Webflow Bandwidth
>
Webflow's Bandwidth Reports

Webflow Bandwidth

Webflow's Bandwidth Reports

Overview
Introduction & Overview
What You Need to Know About Bandwidth
001
Diagnosing Bandwidth Problems
002
Webflow's Bandwidth Reports
003
Optimizing Images
Why Optimize?
301
Webflow's Image Optimization Tools
10:37
301
Advanced Image Optimization
302
Using XnConvert to Optimize Images
305
AVIF Format
305
Best Practices for Image Optimization
306
Optimizing Videos
Optimizing Videos
401
Re-Hosting Videos & Large Assets
402
More
Optimizing Fonts
500
Removing Google Fonts
501
No items found.
Published
September 14, 2025
in lightbox

If you find Webflow's bandwidth utilization reports confusing, you're not alone.

Here are a few reasons why;

  • It shows total bandwidth utilization, but does not subdivide it by usage types- assets, HTML, JS, fonts, and so on.
  • The downloadable CSV only shows assets, not HTML.
  • It has no indication of the usage source- website users, search engine bots, AI bots, RSS feeds, and so on.
  • It does not show a projection of anticipated bandwidth, assuming consistent usage.

On top of the problem of understanding the data is the problem of how to use it effectively. Unfortunately there is no way to go from the report's listed asset to a report indicating where it is on the site- assets, CMS, which pages, which records & fields, and so on.

Let's start by understanding how traffic calculated.

Webflow's Bandwidth Calculations

Here's what I've found in my research.

Webflow measures bandwidth as all data transferred from your site's servers to visitors' browsers.

This includes every byte of page content and assets that Webflow delivers when someone (or something, like a bot) accesses your site ##. In practical terms, whenever a page is loaded, Webflow sends the HTML for that page plus all of its associated assets (images, CSS, JavaScript, etc.) to the requester. The more (and larger) files your site serves and the more frequently they're requested, the higher the bandwidth usage will be ## ##.

Importantly, Webflow's tracking counts all traffic, regardless of the visitor or request type. This means every request from any user agent (human users or bots) and every HTTP request outcome (successful page loads, as well as 404 errors or redirects) is included in the bandwidth total ## ##. In summary, Webflow's reported bandwidth is a comprehensive total of all data Webflow hosted content served out, not just a sum of your media files.

Total Bandwidth vs. Top 1000 Assets Discrepancy

It's common to notice that the total bandwidth number in Webflow's Site Usage dashboard is much larger than the sum of the "Top 1000 Assets" listed. This discrepancy is expected because the total includes several categories of data transfer that are not fully captured in the asset-by-asset breakdown. According to Webflow's own explanation, the total bandwidth encompasses more than just the largest files on your site ##:

  • HTML pages and core site files – The page HTML, CSS, and JavaScript (including files like webflow.js and webflow.css) for your site contribute to "hosting bandwidth" and are counted in the total ##. These may not appear in the Top 1000 Assets list (which typically highlights large media files), yet frequent page loads can accumulate significant bandwidth. For example, if a page's HTML is, say, 100 KB, a high volume of page requests (even without large images) will add up in the total bandwidth count. In one forum case, an unintended automated script was hitting the homepage every few seconds, driving up bandwidth via repeated HTML page deliveries ## ##. The asset report in that case showed only a few GB of image/asset usage, while the total bandwidth was hundreds of GB – the difference was almost entirely the page HTML being requested constantly by a bot.
  • High volume of small or uncatalogued assets – The "Top 1000 Assets" list is not a 100% accounting of all files, but rather the largest or most-used 1000 items. If your site has more than 1000 assets being accessed (including many small images, PDFs, etc.), the long tail beyond those top 1000 isn't shown individually. Any bandwidth from assets beyond the top-1000 cutoff still counts toward the total, even though summing the listed assets won't reflect it. In other words, the reported top assets are a subset of total usage, not an exhaustive list. (Webflow allows exporting a CSV of "all assets," but the in-app view is limited – users have noted it "just repeats what's in the ... 'top 1,000 assets' spreadsheet," indicating it may be capped ## ##.) Thus, the sum of the top 1000 assets is inherently only a portion of the total if additional assets (or HTML/CSS files as mentioned above) contributed bandwidth outside that top list.
  • Bot traffic and repeated requests – The total bandwidth includes all user agents, so crawlers or bots hitting your site can inflate usage without corresponding human pageviews ## ##. Bots might request pages or assets repeatedly. Some bots (or monitoring services) even ignore caching and download files repeatedly, or scrape your site's content in bulk. These requests might not all show up as distinct large assets, but they massively increase the total transfer. For example, Webflow Support identified one site's spike coming mostly from a "DatadogSynthetics" monitoring bot repeatedly loading pages/assets ## ##. Another example: an AI crawler or SEO tool might systematically download every image and page on the site, ballooning bandwidth ##. In such scenarios, the asset list may show certain files requested tens or hundreds of thousands of times, but even more of the bandwidth might come from the base page or other files being fetched repeatedly. The asset breakdown might not obviously reveal this if, for instance, the HTML page itself isn't listed as an "asset." This is why users have observed cases where adding up the top assets barely reached a few GB while total bandwidth was hundreds of GB ## ## – the "missing" bandwidth was coming from sheer volume of requests (often by bots) for pages or other resources not itemized in the top assets list.
  • HTTP errors and redirects – Every request counts toward bandwidth, even if it's not a normal page view. If a bot or user requests a non-existent URL, the 404 error page that Webflow serves (including any default text or custom 404 page content) consumes some bandwidth. Similarly, if there are redirects (301/302) configured, the redirect response has a small size that counts as well ##. These are typically small per request, but a flood of such requests can add up. The asset report usually won't itemize 404 or redirect responses as "assets," but the total will still include them. This is another way the total can exceed the visible asset sums.

In short, the total bandwidth number is comprehensive, covering page HTML, core scripts/styles, and every single request from anyone or anything, whereas the Top 1000 Assets report is a limited drill-down focusing on the largest files. Webflow explicitly confirms that the difference between the sum of assets and the total is due to those extra factors – "hosting bandwidth (HTML, CSS, JS files) and all user-agent traffic and status codes" are all included in total bandwidth ##. Therefore, the top-assets list does not represent 100% of your usage; it often accounts for the majority of large file transfers, but the remainder (sometimes a significant portion) comes from page content and other requests not individually listed.

What Counts Toward Bandwidth (and What Doesn't)

Understanding exactly what is counted vs. not counted in Webflow's bandwidth can clarify the reporting:

  • Included in Bandwidth Calculations: Essentially, anything served by Webflow's hosting counts. This includes:
    • HTML pages – The content of each page delivered (the raw HTML).
    • CSS and JS files – Your site's stylesheet and script files (including Webflow's autogenerated webflow.js and webflow.css, as well as any custom JS/CSS files hosted on Webflow) ##.
    • Images, videos, and other media – All images (JPEG, PNG, WebP, etc.), background images, videos, PDFs or file attachments, font files, and any other asset files uploaded to your Webflow site's hosting. These often consume the most bandwidth per request due to their size ##. (If an image or video is hosted in Webflow's CMS or asset library, every time a visitor views it, the file's bytes are transferred and counted.)
    • CMS-driven content and API data – If your site uses Webflow's CMS and, for example, has interactions that load additional content via the CMS (e.g. an infinite scroll or filtering that fetches more items, or a search that hits Webflow's API), those data transfers are counted. Webflow notes that interactions triggering server requests (like loading data from the CMS/API) will contribute to bandwidth usage ##. Essentially, any data your site pulls from Webflow's servers during use counts just like a page load.
    • All visitor types – Both real users and bots/crawlers. There is no distinction made in bandwidth accounting between a human visitor loading 5 MB of images or a bot doing the same – both count toward your total ##. This means bot traffic, scrapers, or even uptime monitors can rack up bandwidth usage even if your human traffic is low.
    • All request outcomes (status codes): Even when a page isn't found (404) or is redirected, the server still sends a response. Webflow counts those bytes too ##. For example, if an outdated URL on your site triggers a redirect, the HTTP 301/302 response has a small size; if a missing page triggers your custom 404 page, the HTML (and any assets like images on your 404 page) counts as well. High volumes of errors or redirects (often caused by bots guessing URLs or old links) can contribute to bandwidth usage.
  • Excluded from Bandwidth Calculations: Any resource that is not served by Webflow's servers will not count toward your bandwidth. Key exclusions are:
    • Third-party embedded content and external links – If you embed videos from YouTube/Vimeo, add an external image via a URL, or use third-party widgets/analytics that load resources from other domains, those files are served by the third-party, not by Webflow. External images or scripts do not consume your Webflow bandwidth. ## (They may impact your page load speed, but they aren't counted against your hosting plan's data transfer.) Similarly, if you have custom code that calls an external API or loads an external resource, that traffic goes directly to the third-party and does not pass through Webflow's servers.
    • Visitor's own resource usage – Any processing or caching on the client side doesn't count. For example, if a visitor revisits a page and their browser caches some Webflow-hosted files, the cached content isn't downloaded again from Webflow, so it doesn't add new bandwidth. (Bandwidth is only counted when data actually transfers from Webflow's server. That said, many bots or certain browsers might bypass caching, so this benefit applies mostly to human visitors.)
    • Webflow Editor/Designer activity – Edits made in the Webflow Designer or Editor interfaces do not count toward the published site's bandwidth. Bandwidth usage is tied to the published site content being viewed. (However, if you have something like an RSS feed or an automated service pulling your site's content, that would count as it's essentially an external request to published pages.)

In summary, Webflow's bandwidth usage report counts everything it delivers (pages and assets) to any requester, but it does not include content served from outside sources. For instance, if you host large files or images elsewhere and embed them, those won't appear in the bandwidth report at all ##. On the flip side, even things that might be invisible to you – like a rogue bot hitting your site's pages, or an RSS feed reader downloading images in their original size – will count and can inflate usage ##.

Do the "Top 1000 Assets" Cover 100% of Bandwidth?

No – the Top 1000 Assets list is only a subset of your total bandwidth usage, focusing on the most bandwidth-heavy individual files. Webflow's usage dashboard is designed to help identify the biggest culprits (large images, media, etc.), but it is not a complete ledger of every byte. There are two reasons the top-1000 assets don't sum to total:

  1. Omission of Non-Asset Data: As explained above, the total includes things like page HTML and small requests (e.g., 404 pages or tiny files) that aren't considered "assets" in the report. The Top Assets table mostly lists static files like images, videos, PDFs, scripts, etc. – it does not list each page's HTML document as a row. So, all the bandwidth from serving pages and miscellaneous requests is in the total but has no line item in the asset breakdown ##. This alone can account for a big gap, especially if your site's HTML or base files were requested extremely often (e.g. due to bots or a high number of page views).
  2. Limit to 1000 Items: Even for actual asset files, the report intentionally shows only the top 1000 items. If your site has more than 1000 assets that were accessed in the time period, anything ranked 1001 and beyond is not shown individually. Those lower-ranked assets might each consume tiny amounts of bandwidth, but in aggregate they could add up to something non-trivial – yet they won't be captured in the "top 1000" sum. In one case, a user exported the asset list and summed it, getting ~80 GB, while the dashboard showed over 800 GB used ##. The remaining hundreds of GB were from other requests not listed in those top lines. Webflow's support has acknowledged this by clarifying that the total bandwidth includes categories beyond the listed assets, such as HTML/CSS/JS and all traffic types ##. In practice, the top-assets list often accounts for the majority of heavy files, but it rarely ever equals 100% of the total – there is always some overhead and "the rest" accounted for in the total.

For a fully comprehensive view, Webflow allows downloading a CSV of "all pages or assets consuming bandwidth" ##. Using the "Show all" option in the Site Usage dashboard should reveal more than just the initial preview of top assets. However, even with all asset entries, remember that page HTML and other non-asset bytes won't appear as an asset entry. Those portions can only be inferred by the difference between the total and the sum of all listed assets. Essentially, the Top 1000 (or even an "all assets" CSV) covers asset bandwidth usage, while total bandwidth = asset bandwidth + hosting (HTML/JS/CSS) bandwidth + misc. request overhead ##.

Official Word from Webflow

Webflow's own documentation and staff have addressed this discrepancy directly. The Help Center confirms that "Bandwidth includes both asset bandwidth (e.g., images, videos, files, etc.) and hosting bandwidth (e.g., HTML, CSS, and JS files, etc.). Webflow counts traffic from any type of user agent (bot or non-bot) and traffic with any status code (e.g., 200, 404s, redirects, etc.)" ##.

In a forum discussion, a Webflow representative similarly explained that the total bandwidth figure accounts for HTML pages, CSS/JS, bot traffic, and even error/redirect requests, which is why it can exceed the sum of the top asset usage. ##

In short, the Top 1000 Assets report is not a full accounting of bandwidth because it omits those categories and is limited in scope, whereas the total is truly all-encompassing.

If you're seeing a large gap between total bandwidth and your asset breakdown, the likely causes are the above factors (e.g. heavy page traffic or bots, not necessarily a hidden giant file). Webflow support often advises checking for unwelcome bot activity or overly frequent hits (and using tools like robots.txt to mitigate them) when bandwidth usage seems inexplicably high. ##

They also encourage optimizing assets (compressing images, using Webflow's responsive image features, etc.) to reduce the asset portion of bandwidth ##. ## ##

But fundamentally, understanding that the total bandwidth includes much more than just your top assets should demystify why "adding up the top 1000 assets barely hit X GB, but the dashboard shows Y GB" – the rest is coming from the non-asset and uncatalogued usage that Webflow tracks behind the scenes.

Sources

Citations

‍

‍

Table of Contents
Comments
Need help with your project?
Talk to us
Want to show your appreciation?
Buy us a beer
Did we just make your life better?
Passion drives our long hours and late nights supporting the Webflow community. Click the button to show your love.
Buy us a beer