If you’re building a personal website or small web project, you may be wondering whether you need a Content Delivery Network (CDN) for delivering static assets such as images, CSS and JS files.
Ask yourself these three questions:
- Do you want to improve your site speed for your visitors?
- Are you OK with storing your website data on other people’s servers?
- Is your website getting traffic from around the world?
If you answer yes to all of the above, you should use a CDN.
Do you want to improve your site speed for your visitors?
My site was pretty speedy to start with (I had a perfect 100 Google Lighthouse Score). But I still couldn’t get it to load in under a second.
A WebPagetest waterfall chart of a page on my site prior to using a CDN shows a Time to First Byte of over 1.4 seconds:
Using a CDN would place copies of static assets – my HTML, CSS, JS or images – on servers around the world so visitors from one corner of the globe would receive them from the closest possible server.
Are you OK with storing your data on other people’s servers?
Some might chuckle about the thought of building their own servers to host their own websites – but the IndieWeb is a thing. Some want to stick it to the huge corporations that misuse, lose or abuse personal data. Others (e.g. Low-Tech Magazine) want to make sure their websites are hosted using renewable energy.
When I set out to rebuild my personal blog from the ground up, my guiding principles were: 1) keep things as lean and simple as possible, 2) maintain as much control as possible, and 3) ensure the CO2 footprint of the site was as small as possible.
My tech stack and ecosystem was pretty lean: Eleventy for statically generating the pages, GitHub for version control, and a green web host in Germany where I live. Adding a CDN would mean an additional dependency.
I didn’t build my own machine for web hosting; but I was interested in the environmental impact of CDNs. Aside from general scientific studies about CDNs and energy use, I couldn’t find any information from specific CDNs regarding their energy use. Not knowing how much energy use a particular CDN vendor uses for every MB of bandwidth consumed is for me the biggest drawback of using one.
Is your website getting traffic from around the world?
After deploying my site to a single server, I checked Google Search Console for how visible my site was becoming and what pages were being visited the most.
Over the course of a few weeks, I got more and more traffic from around the globe:
| Top 5 Countries by Clicks | % Clicks |
|---|---|
| United States | 18% |
| India | 8% |
| United Kingdom | 7% |
| Germany | 6% |
| Australia | 4% |
| Others | 57% |
I then tested the page speed of my single-host site using WebPagetest from different locations and found that the Time to First Byte varied quite a bit depending on location:
Since such a large portion of traffic to my site was coming from different corners of the globe (the US, Europe, India and Australia), it made sense to keep my webpages and content as close to the users as possible and thereby reduce energy usage from transmission. So I decided to try out serving my static site from a CDN.
Picking a CDN
After checking out some of the biggest and fastest CDNs, I settled on Netlify because:
- it has a free tier
- it automatically builds and deploys my site directly from my repo whenever I do a
git push - it has very understandable docs
- it has plenty of other cool automations and features (except for server push capability 😞)
And now, I’m a huge fan 🎉
Trying out my website on Netlify was very easy. All I had to do was:
- Create a Netlify account
- Connect Netlify to my GitHub account
- Select the repository that Netlify builds from
- Deploy to a free temporary domain name
Load times with and without a CDN
Hosting a copy of my site on a temporary Netlify domain allowed me to run some tests against my single-server setup.
Using WebPagetest, I tested the same page on both domains from San Francisco. The waterfall chart for my without-CDN site showed a Time to First Byte of over 1.4 seconds.
But with the html document coming from the Netlify CDN, First Byte shrank to .8 seconds.
Comparing the pages’ visual progress showed that serving my static site from a CDN saved me a full second of load time. In other words, the CDN version of the page was completely loaded by the time the non-CDN version started rendering.
Saving a second of load time is certainly an improvement that users can perceive.
Migrating over to Netlify
Needless to say, I decided to migrate my site over completely to Netlify. All I had to do was transfer some DNS records to be able to use my custom domain name. Within a day or so, the records were successfully transfered.
I thought I had to use Git’s Large File Storage for my images, but I just couldn’t get it to work – even after cloning my repo and using a new Netlify account. So I tried just uploading all my images to my GitHub repo; and neither GitHub nor Netlify seemed to have a problem with that.
Conclusion
Although Netlify does add another tool to my toolchain, its automatic deployment certainly saves me time and eliminates the need for any other FTP tools.
Perhaps the biggest drawback:
I don’t know how many servers copies of my website are on and how much energy they use to store them.
My only respite is that a) my pages and assets are very small anyways and b) people from around the world can get the pages faster, thus reducing energy for data transmission.