Bandwidth pricing - ways to optimize

hey! i’m looking for ways to optimize the bandwidth usage of my website, failbondi.fail (failbondi-fail-sveltekit.fly.dev)

my main concern is how i’ve accumulated $7.29 in bandwidth fees in the first few days of my site being live (tbf, with high traffic.) it’s pretty much entirely South America traffic, which is fairly expensive in Fly.io ($40/TB)

I can pay for it, but it seems like a lot. what are the easiest ways to lower the cost without reducing performance? my website is heavily cacheable, so I’m guessing Cloudflare could help, but how bad would it affect performance?

thanks!

Hi,

Absolutely, caching is the way to go.

For static assets that won’t change, make sure your app/site is sending cache-control headers. That way the client’s browser will cache them for you, meaning you only need to send that .jpg, .js file etc once to them. The next time you won’t need to.

Of course files do change and so the common solution for that is to get your site’s bundler/builder to add some kind of hash/id to the file’s name and/or query string. That way it can send e.g chunk.abcde12345.js and that can be cached. If the file ever changes, it will get a new name/hash and so will still be delivered.

However you are still left with the problem of delivering it once. If you have lots of new users, each will still fetch a file, still using a lot of bandwidth. The solution for that is a shared cache - a CDN.

Cloudflare is ideal since it’s free. Cloudflare then caches the file, and a subsequent request hits that rather than your site. Its network is huge and so performance should be fine. You’d just have to make sure you are complying with its ToS e.g HTML files are fine, but big images, videos etc may not be.

That would mean no changes to your app since you’d route via that.

The other option would be something like Tigris. That’s actually run on Fly. You’d move your static assets into a bucket and serve them from there. It looks like they also have zero egress fees (but do have a small per-request fee): Pricing | Tigris Object Storage Documentation

thanks! all of this makes sense, i guess i’ll switch to cloudflare soon.

i switched to granular bandwidth pricing and it seems that the bill went down a bit. i still don’t fully understand the new pricing, even though i’ve read up on it a bit. either way, works for me.

are bandwidth GB on already compressed responses or on uncompressed size? the obvious would be the former, but idk.

thanks!

We count bytes leaving from:

  • Your VMs network interface
  • Our proxy

Compressed responses from our proxy are fewer bytes, so that’s doing what you’d hope.

The Lighthouse utility in Chrome Dev tools can help find some bandwidth bloat. Check this out:

It seems like you’re sending ~400k+ of javascript that isn’t useful to each visitor.

The Network tab is helpful too, you can just sort by response size and locate some problems:

CloudFlare is a viable way to try and get the cost down but I think you’re better off starting with bloat, then seeing where you are. Adding a CDN layer is extra complexity and it won’t necessarily help improve the experience for your users.

You’re basically paying a min of $0.40 per 10,000 visitors in bandwidth right now. The UX/design of that page is relatively simple, I have a feeling you can make that 10x cheaper just by making it perform better.

1 Like

This topic was automatically closed 7 days after the last reply. New replies are no longer allowed.