Firebase vs Github vs Netlify vs Render vs Cloudflare
One of the early mistakes that we made as a startup was to use one system on one server for both web app and website.
We thought that this would be sustainable, especially since we relied on mostly on interns and volunteers. Everyone would learn one framework and work on one repository and one branch.
The mistake exposed itself when our server actually got website views and web app users. This overloaded our server causing it to either crash or incur charges when it auto-scaled to accomodate the traffic.
The problem is that we had a lot of content waiting to be written for Superphysics and Pantrynomics which were the theory behind the apps. The website would use resources that were supposed to be for the web app users. In addition, our chosen framework was built for web apps and not for CMS or websites.
Solution: Static Site Hosting
Back in 2015, we had very little content, so we put it on wordpress.com as drafts. Over the years, we refined the content and gradually put it as styled pages in our web app which acted like an internal mini-CMS.
The need to keep costs low, while improving SEO and managing content, led us to separate the content to static site generators.
We forked our mini-CMS as a blogging feature in Pantry (Static site hosting was so good we put blogging on it too).
We chose Hugo as the easiest and fastest static site generator. We then deployed our Hugo sites on different hosts that didn’t require credit cards to see the performance and maintainability:
|Github Pages||easy to deploy||content must be public|
|Cloudflare Pages||easy to deploy, integrates with Cloudflare||content must be public|
|Firebase||easiest to deploy, content isn’t public, creates Google Analytics||needs to install Firebase console|
|Netlify||Nice UI||content must be public|
|Render||Nice UI||lets you set up paid services and incur charges, content must be public|
Firebase is the easiest to deploy – just
hugo && firebase deploy. However, this might be a problem if your internet connection is slow.
Github Pages is great even with slow internet connection – just take the public files and push.
Cloudflare Pages deploys automatically and makes it easy to configure DNS. The site loads a bit faster thanks to Cloudflare’s CDN
Netlify automates the deploy just like Cloudflare Pages, which is great for adding content. But it has less features than Cloudflare.
Cloudflare is Great
We decided to use Cloudflare because it’s fast and is easy to deploy. Unlike the others, it does not have bandwidth limits. Instead, it limits the deploys to 500 per month.
For people without coding skills, there are services like forestry.io that allow users to add and edit content just like any CMS.
Update July 2022
- Cloudflare doesn’t seem to work for all domains, so we had to use Netlify in some cases
- Cloudflare enabled IndexNow back in 2021 so it makes sense to push there
- We didn’t use Gitlab Pages because sometimes some internet service providers didn’t allow pushing to Gitlab