Yacine Rezgui

Creative software engineer
Developer advocate at IBM

Where should I host my static website?

When I recreated my website last April, I had to choose a hoster.

For a while, I have been using GitHub Pages for different projects with Jekyll, and it worked well. However, since I joined IBM as a developer advocate, I’ve been travelling in many countries around the world, and it has been such a pain to visit websites which are hosted in East America (I’m looking at you us-east-1). Even with fibre optic connection, I still struggle to display pages in a reasonable time.

I didn’t want to have this experience for my website. Also, I didn’t want to maintain any infrastructure, so I chose to a static geneToday many solutions to host static websites exist, so I had to find, test and compare them to figure out which one suits me. Here are the parameters I was testing:

  • No lock-in
  • Easy onboarding
  • Caching flexibility
  • Extendibility
  • Network performance (latency, speed)

After searching around (ProductHunt, Medium articles and Twitter reviews), I compiled this list:

No lock-in

Among the list I gathered, I didn’t see a specific lock-in. You still have different configurations files for each provider, but my content format (Markdown) and my layout (pure HTML/CSS) doesn’t have to be changed to be transferred somewhere else. Squarespace and similar solutions are the kind of solutions where you can’t change everything, but it’s made for people who don’t have design skills and I’m not their targetted user.

Easy onboarding

Most of them are onboarding you through a CLI where you sign in/ sign up and deploy with a single command. Now by Zeit.co is by far the nicest one I found as they’ll create a different URL whenever you deploy to avoid you having to overwrite your current website to test something. You can swap a deployment for your real website with their CLI. GitHub has tight integration with Jekyll, avoiding you to build your website before deploying it (they’ll do it for you). Netlify, Surge and Firebase are quite similar in this case. Amazon S3 is the hard beast as you need to upload with a 3rd party more simple tool rather like s3cmd than the official CLI.

Caching flexilibity

Most of them propose the option to customise your HTTP headers and set the right expiry time. Netlify invalidates instantly the cache among all its CDN points of presence whenever you deploy.


Now by Zeit.co is indefinitely extensible as you can create your server within the same project. However, for my website, I was looking for something simpler. AWS Lambda was the first one to offers FaaS (Functions as a Service) where you don’t have to deal with your router, deployment, health checking but its setup is quite cumbersome. Firebase functions and Netlify have much more excellent integration. It’s convenient to write some logic in a function and automatically get a URL that points to it. With Firebase, you can even handle specific URL patterns of your website with these FaaS.

Network performance (latency, speed)

I didn’t try enough all of them to be able to make a proper benchmark. Now by Zeit.co disappointed me when I used it a while ago. I got some downtime that gave me a bad feeling. GitHub Pages is acceptable if you don’t have substantial content. Amazon S3 (if you only stick to the default region us-east-1) was horrible when I tried in Asia. I remember having a transfer speed of 2 kbps!

Firebase, bundled with a CDN, was a delight. The performance was outstanding. In fact, when I’m travelling in Asia, only Google (and Netflix) services were adequately usable. They got a good experience of networking at scale.


So here are my (personal) conclusions:

  • If you’re used to GitHub environment and don’t have specific needs, go with GitHub Pages.
  • If you want simple static page deployment with a custom router that handles nicely different languages content, choose Netlify
  • Now by Zeit.co is good but better bundle it with a CDN like Cloudflare
  • Surge has a pleasant experience, but it lacks some features its competitors already have. Still, watch it as I’m pretty sure they’re going to be much better soon
  • Amazon S3 is cheap at scale but its network performance force you to use it with Amazon CloudFront (which is not cheap)

I mentioned only Amazon S3 as it’s the reference for this hosting, but you should also look at IBM Cloud, Google Cloud, Microsoft Azure and Digital Ocean similar offerings.

In my case, I chose Firebase, and I’m pleased with it. It doesn’t mean the alternatives are inadequate. This kind of services tends to improve their offering continuously. Netlify got close to the all in one platform, specifically with their great support of i18n.

In case you need more customisation, you can still create your server. If you choose this type of architecture, I recommend Next.js, a lightweight framework for static and server-rendered applications using ReactJS. For hosting my go to would be Heroku or Google App Engine (flexible environment).