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
