My website’s bandwidth usage has skyrocketed recently, which caused our plan to be automatically upgraded, including add-ons. However, I’ve seen many people here reporting the same issue, and in my case, everything seems also very strange.
In the most recent billing cycle, for example — from March 11 until today — the site has used 843.3 GB of bandwidth, averaging 32 GB per day. Over time, usage jumped from 5.3 GB in November 2023, to 290.7 GB in December 2023, and then to 877.3 GB in January 2024 — and it never went back down. All this without any plausible explanation.
In the same period of this last cycle, according to GA, the entire site had only 3,717 pageviews and 2,639 sessions. Meanwhile, Webflow shows that a single PNG used 114 GB of bandwidth during that time — it’s a 711.65 KB image that was somehow accessed 160,487 times. We just can’t make sense of this. Below is a screenshot showing the top-loaded assets.
We’ve already used Webflow’s image optimization tool and currently have no PNGs left in our asset library. Yet, the assets consuming the most bandwidth are still PNGs.
When exporting the CSV of assets and summing the total bandwidth usage, it adds up to 79.6 GB — far from the 800+ GB shown.
We use Weglot for translations and, per Webflow Support’s guidance, we completely disabled it for a period. Bandwidth usage did not decrease.
One strange thing in Weglot’s pageview dashboard (see screenshot) is the huge number of hits in English compared to Spanish and Portuguese (the site’s native language). The difference is massive.
As suggested by Webflow Support, we switched Weglot’s proxy back to Webflow so they could analyze the traffic. According to them, the main source of the bandwidth traffic seems to be “DatadogSynthetics.” They recommended blocking this user agent by adding the following to our robots.txt:
User-agent: DatadogSynthetics
Disallow: /
This was already done in February, but it had no effect.
I’ve been trying to get to the bottom of this issue since January, exchanging messages with both Webflow and Weglot support, and we’re still without a solution.
Since I’ve noticed this problem seems very similar to what others here are experiencing, I thought maybe someone could help.
The lack of visibility into what’s happening at the firewall is a real issue, but a few things I’ve seen cause problems.
If you’re lucky, you might be able to determine the source of the traffic by running through my checklist.
First remember Webflow does not track HTML bandwidth, it tracks asset bandwidth, so it’s your assets that matter the most. That makes e.g. GA4 reports of limited value. These are the things I’ve seen hit assets hard;
RSS. If you’re using RSS, some readers will hit your RSS feed hard and frequently, and RSS feeds download uncompressed assets even if you’ve optimized them, for compatibility with older readers I’m assuming that might not support AVIF.
SEO tools that scan your site for audits can also do recurring full downloads.
SEO tools that are designed for editing, like Graphite, can keep re-downloading certain assets while the editor is open.
AI bots like Claude, will hit juicier sites, ignore the robots.txt and scrape everything including assets
Monitoring tools ( data dog is a monitoring tool, and probably used as a platform for other monitoring solutions if you’re using one )
Third party monitoring tools, e.g. “watch competitor site for price changes”.
Any scripts which cause assets to unload and reload. That can include certain interactions, looped background videos, etc. You can use Chrome’s Network tab to learn a lot there, however different browsers can behave differently as well in terms of how they handle and cache assets.
Hi there! Sorry to hear about the overage charges - those can be frustrating and costly.
There are simple things you can do to reduce bandwidth waste that could dramatically lower those charges.
I took a quick look at your home page and found an immediate opportunity: the background image at https://cdn.prod.website-files.com/64a2d32d985e1e3d89959e6a/64efe8e1f79656d1bd40a04e_img-home-porquesofist02.webp is 548kb.
This is problematic for two reasons:
Background images don’t benefit from Webflow’s responsive image generator
Every device loads the full-size image regardless of screen size
I ran this single image through my optimization process and reduced it to just 76kb with no visual quality loss. That’s an 86% reduction on just one asset!
Other common bandwidth issues I typically find include uncompressed videos, oversized fonts, and redundant JavaScript libraries.
Having optimized 50+ Webflow sites with similar issues, I offer comprehensive performance services that typically reduce bandwidth by 40-70%. Feel free to DM me if you’d like a quick assessment of your specific situation.
Thanks for the help, @webdev
However, I have a question that might help clarify things: is it reasonable for a single PNG to be loaded more than 160,000 times in a month, when the entire site had only 3,700 pageviews during the same period? How can that be explained?
It makes me think that, even if we optimize the heaviest images, the huge number of loads (which, at first glance, doesn’t make sense) will continue to negatively impact bandwidth usage.
Personally I would run another analytics tool for a while to gain more insight into actual traffic and to spot any aberrations. You could also load a remote resource that you can track. I am not personally confident in Webflow usage analytics myself but currently have no need to investigate it further. Either way if you haven’t fixed what I pointed out already you are wasting bandwidth and impacting user experience for visitors.
Sorry to hear you’re running into this! I’ve seen similar cases across multiple client sites — and with Webflow’s bandwidth overview not really being helpful, it can get frustrating fast.
I did a quick check and found this asset loading on your /en/cases page:
64ca5accb29d7962ada0c2b9_case-webc.png
It’s 681 KB and might be contributing significantly, especially if it’s being requested repeatedly (bots, etc.).
A few quick suggestions based on similar cases I’ve handled:
1. Manually validate asset usage
Webflow’s bandwidth report can be vague. Cross-check by using your browser’s Network tab or dev tools to see which pages are loading large assets and how often. GA alone doesn’t reflect asset-level hits — that’s key.
2. Clean up legacy or hidden assets
Even assets not visible (e.g. set to display: none) or no longer listed in the asset panel might still be loading if referenced on a page.
3. Offload large files
For heavier files like images or PDFs, I usually recommend externally hosting via a CDN like Cloudflare (free tier). This can drastically cut bandwidth usage without needing to migrate the whole site.
4. I’ve built a tool for scanning full websites
I help clients reduce bandwidth by scanning all live pages, identifying all assets, and flagging anything above a certain size threshold (e.g. 100 KB) and filling the gaps that Webflow site usage misses.
– Jesse (your Bandwidth Buddy)
Freelance Webflow dev | Helping clients stay within their plan limits with targeted asset optimization
Using the asset 64ca5accb29d7962ada0c2b9_case-webc.png as an example, I did a thorough sweep of the entire site — reducing image sizes, deleting hidden sections, and adjusting background images.
This actually made a big difference. As you can see in the screenshot, the daily bandwidth usage dropped from a peak of 72.94 GB to 15.19 GB.
However, it still doesn’t seem sufficient, mainly because most assets are still being loaded over 6,000 times in a day (April 27 in the screenshot), which seems absurd for a small site that receives no more than 170 daily pageviews at most, according to Google Analytics. Even though GA may not be the most precise tool for this comparison, the gap is simply too large.
Since your custom fonts, webflow.js and webflow.css are at the top, it’s clear your overall traffic load is intense. It also suggests real page views over bots or leeching, since the JS and CSS aren’t likely useful to bots or leeching sites.
Main thing is to communicate with WF support on this, since they’re the only ones that can see the WAF ( web application firewall ). They may be able to block a country that is irrelevant and consuming bandwidth, although I have no information on what’s possible regarding assets which are under a shared domain.
Worst case, it’s usually possible to off-host custom fonts but the transition is tricky to ensure that the designer recognizes them correctly for future edits.
I’ve been away for a while, but I’m back working on this issue. Looking at the screenshot from my previous message showing asset bandwidth usage, you can see that — in addition to the custom fonts, webflow.js and webflow.css — there are many images being loaded over 6,000 times. Couldn’t this indicate something beyond actual page views (like bots or leeching, as you once suggested ruling out)?
This has been my biggest struggle for months. I managed to reduce daily bandwidth usage by resizing images — today, nothing (as far as I could identify) exceeds 50 KB. Still, the number of requests remains very high. If the only solution is to contact Webflow support (which I already did), how can I clearly explain the issue to them? I’ve already tried many times. We ran tests uninstalling Weglot, which didn’t solve it. Eventually, they told me the traffic could be from monitoring tools, especially Datadog, which is used by Weglot. We’ve also disabled that, but the high asset requests continue.
Also, I can no longer find references to some assets on the site — they’re not listed anymore. Here are the filenames:
It takes some setup work but the process I use to find hiding assets is to do a full scrape and mirror of the HTML to a local drive, and then search across that. It’s the only way to ensure you’re finding all references including CMS-content references, and easily track it back to the page.
Obviously that wouldn’t identify anything that’s fetched by scripts but that’s exceptionally rare.
If you’re using RSS feeds on any of your CMS pages, that could be a source as well.
Another thing I’ll often do for client sites is setup the site in a reverse proxy configuration using Cloudflare, on a Cloudflare Pro account ~$25/mo ). In that configuration you have a WAF ( web application firewall ) that you can monitor to learn exactly where traffic is coming from- much like what Webflow support is using. However you can also block IPs, entire countries, or user agents, etc.
However this will only show HTML requests, not asset requests, which could be direct to Webflow’s assets CDN. Rogue traffic will typically be to your webpages and your assets downloaded as a part of that. Leech traffic will typically be directly to your assets, e.g. someone embedded your background vid directly on their site.
The above config would at least help you differentiate.
It’s in a way comforting to read all this because the charity I volunteer for is having the same exact issue!
We were suddenly hit with over $3,000 in unexpected bandwidth costs, which has been hugely problematic for us. That’s almost my entire budget for all web devt for the year blown.
The CSV download of assets using bandwidth is worse than useless. It just repeats what’s in the supremely unhelpful “top 1,000 assets” spreadsheet. In that list, I have an image “2.png” that I cannot find! Why can’t Webflow let me click on a link to the offending asset so I can recognise it? It seems like deliberate obfuscation to squeeze bandwidth ££ out of us!
Can someone explain to me, simply (non-developer), the best way to find that PNG?!
I am gradually working through the site to flush out JPEGs that our team erroneously uploaded. But they are hard to find when they aren’t in the assets bin, but loaded through Cloudflare. I wish the Editor (which is now mysteriously called Legacy Editor – ominous) had a decent search in it.
However, I feel that this is finger-in-the-dyke situation. Removing and resizing images feels incredibly laborious and time-wasting TBH.
Webflow gives you surge protection of a month grace period after the first bandwidth alert, which is when you would have wanted to optimize those assets.
Webflow has asset optimization built-in, you can just use the tools it has provided for both the assets panel and CMS-stored assets.
Your homepage alone has a ton of large images, see below. Optimize those first.
In your site-wide settings dashboard, make sure to block AI buts, they can generate a huge amount of traffic so you want to watch them carefully.
For 2.png, try just searching the assets panel. If you can’t find it there, I use a more complex but comprehensive approach for my clients. Webflow support may be able to help.
Thank you Michael for that detailed answer. Yeah, 2.png isn’t in assets bin. I’ll need an expert to help me discover where it is! I’ve asked webflow support.
I don’t see where to disable AI bots. Will investigate that next…
