Building DrawKit #2: 3000% over bandwidth limits

This week’s update is a true “two steps forward, one step back” type update.

I mentioned in last week’s post that I had started getting emails that my bandwidth on Webflow was exceeding monthly limits, but I didn’t really know the extent of it.

We’re talking 3341% over the monthly limit. $1200 USD monthly bill.

Uh-oh.

Here’s my last billing month:

Gotta admit, I went into crisis mode. I can’t sustain $1200 USD monthly bills, and it was showing no signs of slowing down.

Before I could properly examine things I looked for immediate solutions. I only have an hour or two to work on DrawKit each day around my full-time job, so I needed to prioritise immediate effects.

As I’ve talked about in last week’s post, DrawKit hasn’t really had any updates in the last few years, and there was a lot to do with asset care and general site organisation, so step 1 was optimising every asset on the site, starting by sorting Webflow’s bandwidth analytics by file size and bandwidth used.

I used Webflow’s built-in AVIF conversion and compression tool for this, which worked wonderfully well. Very smooth, one click, and everything was converted, and much smaller file sizes.

I didn’t examine closely for quality differences, as my priority at the time was bringing file size down as quickly as possible – I could already see I was headed for a second +$1000 month if things kept going at the current trajectory.

However, this compression didn’t stem the tide, and I started looking for further solutions.

I tried out Flowdrive, which I was really impressed by, however they also have bandwidth caps now, and my usage was so high I would have been paying them instead of Webflow (although admittedly a lot less! I still recommend them, just not for my specific use-case), so I bit the bullet and started moving all assets over to Supabase.

This was just as tedious and time-consuming as you’d expect! However, between this, the AVIF conversions, and minifying all CSS and JS files, things finally started slowing down.

Now that things were manageable again, I started looking more deeply at what was going on. However, the more I looked, the clearer it became that this wasn’t normal traffic or normal bandwidth numbers.

For example, here’s an average month’s site usage, from back in June:

Same for May:

But once we look at July, things start getting chaotic, with 500GB+ increases per day:

During the same time period, my average monthly traffic hadn’t changed, and I hadn’t added any new assets to the site – I only started worked on it properly last week!

Here’s another example: this is a chevron SVG on the site, it’s not even 1KB in size, yet it caused 222.29MB of bandwidth usage in a single day. Loaded 128,637 times in just one day.

This had to all be bots.

I'm not an expert in bot traffic, or bandwidth usage, but I was surprised Webflow didn’t block this sort of traffic by default and was disappointed I’d been charged for it automatically.

So I stopped all my work with moving things to an external database, reached out to them, and sent over all this info. And to their credit, they escalated quickly, updated me within two days, confirmed this is all bot traffic, and refunded/exempt the site from future bandwidth overage monitoring.

So unfortunately this means no building this week, no progress on new features and designs, and also means I now have the (just as tedious) task of moving all my assets BACK to Webflow from Supabase, otherwise I’ll be paying Supabase a high monthly bill!

It’s never going to be smooth sailing every week when building something though, and I’m glad the outcome worked out. Excited to get back to building next week.

- James