Support Forums

[Support Guide] How to reduce your site's bandwidth usage (without reducing traffic!)

Last checked in November 2021.

Netlify does not want to make money charging you for unnecessary bandwidth overages. Our Starter plans come with 100 GB of bandwidth included. We’ve found over time that this allotment is more than sufficient for most non-commercial websites. What you may not realize is that we don’t want to make money this way - we intend to be a business focusing on collaboration tools and we provide web hosting to achieve that goal - so we don’t want you to waste your money on bandwidth, either!

However, suppose you’ve found yourself with an unexpected bandwidth bill from Netlify for exceeding the 100 GB in a given month. Your site doesn’t get a lot of traffic. So, what could have caused this, and what can you do to prevent future surprises?

There are a few areas that you can investigate and perhaps adjust to minimize bandwidth usage. This Support Guide will walk through various reasons your bandwidth usage may be high, as well as ways to reduce your usage without reducing traffic. Let’s dive in!

Adjust your images

If you have many images, videos, and animations on your site, it is a good idea to ensure that your files are appropriately sized in order to keep bandwidth usage low. While our Post-Processing has an “Image Optimization” feature, this is intended only to do lossless (no visual artifacting) compression, and never resizes images to fit their viewports. This feature does nothing to animations and even some image types, so you can see that some human attention might be beneficial. While helping folks diagnose past unexpected bandwidth situations, we most often see huge images that are shown in a very small size, which wastes your visitors’ time and your bandwidth allocation.

Modify your caching settings

Another way to reduce bandwidth usage is changing fewer files per build where possible. Changing fewer files per build means that browser-based caches can cache more, more effectively.

Our CDN tries very hard to make optimal use of browser caches. This Support Guide discusses how to get the most out of our CDN cache, by building your site smarter. Some people or frameworks decide they want to override our default caching, which we allow you to do - but we suggest you do not, without good reason. This blog post explains why not to increase the cache timeout naively, but it is also worth considering not changing it at all, unless you have a very specific use case: https://www.netlify.com/blog/2017/02/23/better-living-through-caching/

Lazy load images and resources

It’s a web best practice to load images and other resources as used, rather than all upfront. For example, imagine you have an online product catalog. You won’t want to load all images in your catalogue at once. Instead, you create pages of products, and allow your visitor to load additional items and their associated images, as needed, when clicking through to the next page.

One of my colleagues once reduced his monthly usage by a terabyte by changing his event calendar to load no images at first, and only load images of a selected event upon request. This increased the usability of his site, too - the pageload went from >100MByte with hundreds of images down to a few MByte with no images on first load. The page loaded about 30 seconds faster on the average mobile client! This is also true for other resources, such as JSON files that you may load 1-per-product of; don’t load dozens with every pageview, if you don’t need to.

Watch your monitors

If you’re trying to determine if your website is up, rather than how quickly it loads, one way to reduce bandwidth usage is to make a tiny file called /status.txt that contains the text “OK”, and just monitor that file for that string. Loading 2 bytes every minute will not add up to 100 GB over the course of a month. Setting up availability monitors is also popular way to get notified if your site goes down or has loading trouble. However, you’ll want to watch out as those monitors can load huge amounts of data unnecessarily!

Synthetic and Real User monitoring are test types that perform a full pageload, or maybe several. While this could be useful to measure, if you are looking to determine uptime, taking this measurement at a high frequency is not ideal. Alternatively, you could consider doing one of the following:

  1. Choose to load less, or load less frequently - which you can check every 10 minutes instead of every minute.
  2. Choose only the region where most of your customers are, rather than several regions, to load on a schedule.
  3. Use the Lighthouse Build Plugin to test once, right after build.

In the end, you control how much data is used, so configure your monitors wisely!

Consider situations in which caching doesn’t help

It is the case for both synthetic/real user monitoring, and for our prerendering service, that caching is a bit interesting. In these cases, there generally isn’t a single browser making each request. Rather, it is a new instance of the browser each time, for each URL. So, you are penalized for monitoring 2 pages in a way a human visitor using a single browser instance wouldn’t be, for visiting those 2 pages: the human visitor loads all of your dependencies from the first URL; those are then cached for reuse with the second URL. Humans thus don’t load jquery.js twice, even though both pages need it, if it is the same URL across both pageloads due to our default caching behavior .

So, what can you do to minimize the impact, if much of your page traffic comes via social sharing, or you must monitor 10 pages on the same site? Since both of these types of services can require loading all resources with each pageload (prerendering caches by URL, so reloading the same page quickly on facebook shouldn’t cost you money; but if your site has 100000 URL’s, they all have to be fully loaded and cached separately), look to optimize what must be loaded. For instance:

  • Minify your javascript.
  • Don’t include large “common” files which aren’t used (perhaps you can use a subset of jquery as described here, rather than loading the whole thing and using very little of it): https://stackoverflow.com/questions/1333465/is-it-possible-to-extract-a-subset-of-jquery
  • Don’t include wrong-sized images that you scale down to display.
  • For catalog sites and other potentially long lists of content, try not to include your entire catalog/all items in the listing, in every pageload, if you aren’t showing them.
  • Consider doing some “conditional” loading for these monitors; they typically use a standard User-Agent HTTP request header, and your code can use a pattern like this to e.g. not load a “heavy” section of a page (e.g. “items 10-999 in the catalog” or “our support chat widget”) when a link is shared via Facebook or any other social service we prerender for:

const isPrerender = /HeadlessChrome/.test(window.navigator.userAgent)
if (!isPrerender)
  { // do load our helpdesk chat widget in this case }

Note that if your site does not use our prerendering service, our usual caching takes care of most of this for you - so, if you don’t need prerendering for your site to function (e.g. allow a crawler to crawl, or create a fancy social media formatted share), turning it off might save you appreciable bandwidth!

Onwards and downwards

We hope the tips in this guide help you reduce unexpected bandwidth usage. As we stated, there are a variety of ways to reduce unnecessary bandwidth usage for you to pick and choose from! Should any of the above scenarios apply to you and you have further questions, please open a thread in our Forums so that we can further discuss options.

1 Like

The images rebuild aspect of it is a very interesting one, which is correct thinking about it now: for every time a site rebuilds the static images get a unique name/url hence making the cached images on visited clients invalidated.

For those using nuxt like me best suggestion is move all images to static folder. Where it doesn’t get built upon a every rebuild or deploy.