Static Website Hosting Platforms in 2023

Trends in every industry tend to cycle, and web development is no different. The biggest comeback in the past few years? Static websites!  However, the way we build them today has changed, and so has the way we host them. There are numerous static website hosting platforms available today, and we’ve gone over the most popular options to provide you with their advantages and disadvantages.

We don’t really call them Hosting Companies anymore, but PaaS: Platform-as-a-service because they allow developers to deploy sites quickly and easily (more on this a bit later).

Why is this important? To put it bluntly, just about any server can host static pages. BUT not all of them will be able to meet the needs and expectations of modern web development. 

Take the Jamstack approach to web development as an example. With the broader adoption, a couple of platforms were built with it in mind. The rest follow suit.

But I’m getting ahead of myself. Let’s define precisely what we mean by a static website, for starters.

General acceptance is that a static website is made of pre-built static HTML+CSS+JavaScript pages that don’t change between visits and that the server delivers to your browser exactly as stored once requested. Static websites don’t rely on databases, libraries, plugins, or frameworks and, as such, have blazing-fast loading times.

In direct opposition, we have dynamic websites that generate content according to various factors (e.g., your location, your time, new vs. returning visitors, etc.), i.e., the pages are rendered with each browser request.

To help illustrate, one of the biggest popular dynamic websites is Facebook and its news feed. On the other hand, a menu page uploaded to a restaurant's domain would be considered the most rudimentary static website.

Of course, because our needs today have changed, static pages and websites today have morphed into something slightly different. Go ahead and check my colleagues' in-depth explanation of what is a static site today.

Let's clear up the difference between the different software, platform, and infrastructure (SPI) models of cloud computing first.

Today the term hosting, in most cases and for most devs, refers to traditional hosting services, the ones that come with storage, database, monitoring, networking, etc., and on which you have to install your components, configure them, etc., before deploying your application. Today term hosting is encompassed in Infrastructure As A Service (IaaS) solutions. Content Delivery Network (CDN) comes optional with IaaS.

Software As A Service (SaaS), on the other hand, encompasses a software licensing and delivery model in which software is licensed on a subscription basis and is centrally hosted, i.e., you don’t deploy anything when you use a service. Salesforce is one of the best examples of modern SaaS solutions. Then you also have a sub-division like Backend As A Service (BaaS), where the backend is the service. Does that ring a bell? This is exactly what Crystallize is.

A Platform As A Service (PaaS) is a bridge between them both. With a PaaS you don’t care about the infrastructure as it allows you to deploy your web application (which can be a static website or a more complex one).

You describe your architecture in a configuration file, and they take care of the underlying chores, installations, updates, patches, security, network, security, backup, etc. The main goal of a PaaS is to reduce DevOps, reducing your ToC (Total Cost of Ownership). In the case of using PaaS, usually, CDN is included. The content delivery network is made up of the origin server, where you upload your static files and widespread edge servers that deliver the files to your visitors.

It also encompasses CI/CD, or continuous integration/continuous delivery, the former of which ensures all changes are pushed to the testing environment as often as possible. In contrast, the latter ensures all those changes are delivered to the right people for testing before production. PaaS often supports cloud functions/node servers and a whole range of different services and functionalities.

A common misconception about PaaS is the concept of a server. To serve static files, you need a (web) server. With Next JS, for example, everything is generated in advance. True, but how about the /api folder? It’s dynamic, right? So you need a server to compute.

Two key concepts to understand with PaaS are the build and the runtime. The build is the initial step that builds your static files (with NextJS or similar). Once built, the build is deployed on the underlying architecture managed for you: that’s the runtime. The application is actually running.

And the PaaS providers have different approaches here to manage the runtime. To serve static files, it’s really easy, but for the dynamic part (the one that requires computations), some use ServerLess functions, and some keep a server running. That’s their magic.

Understanding the approaches of each one(s) will be a huge factor in determining which solution(s) will be the best for your website.

It’s interesting to mention that you don’t have to pick only one. In many situations, you can have your Frontend with Next JS that runs on Vercel and your Service API that runs on Plaform.sh or AWS ECS.

There are a whole bunch of available static website hosting platforms today, and covering and explaining all is out of the scope of this post. Here we’ll look at nine we've been using so far:

1. Netlify
2. Vercel
3. Cloudflare Pages
4. GitHub Pages
5. Platform.sh
6. Surge.sh
7. Azure Static Web Apps
8. Gatsby Cloud
9. Static.app

Obviously, much more influences your decision besides free plan availability and pricing, right? So, how does one go about comparing static hosting solutions?

Well, there are two ways. You make the same applications/website on each solution and test them, i.e., compare performance and build times results, packages, and pricing (used and offered). I've found this post from Kev Quirk to be a great example of that approach.

The second way, if you don’t have time to go through the offerings page by page, is to utilize one of many available review/comparison pages. I am especially fond of Bejamas’ comparison tool that allows you to pick and choose hosting platforms for a complete head-to-head feature comparison.

Wait, static pages for eCommerce? You have to be kidding. How do you handle the classic dynamic functionalities of an eCommerce website in modern-day static websites? I'm talking about the checkout process, cart setup, search functionalities, etc.

Well, thanks to the capabilities of modern browsers and the power of API microservices, most of the limitations often associated with static websites can be easily overcome.

Take a search, for example. The growing API economy offers many options for your static website, with Algolia and Elasticsearch leading the way.

The second problem is build time. Modern approaches (like Jamstack) require you to rebuild the whole website, however big or small the change you’ve made. That can be problematic for a website with thousands of pages.

This simply is not true anymore. For example, in Gatsby (static site generator), since version 3 Incremental Builds are the thing, i.e., the ability to rebuild only pages that are actually changed. Next.js has Incremental Static Regeneration (ISR) etc.

The old problems are being taken care of, and the rapidly evolving ecosystem and VC support aim to bring the static approach to web development of any kind to new heights.

One of the newest inventions in the static website space is the introduction of on-demand revalidation (in beta at the time of writing). With proper hooks from your eCommerce webhooks, you can play with the Time to live (TTL) of the cache and dynamic triggering cache revalidation for a sound event-based eCommerce cache strategy - when the product information changes.

This means you can generate a static page, let it live for a long time (cache time to live), and generate a new fast cached version when your pricing, stock, or product marketing copy changes. And all of these make your eCommerce static website possible, always fresh and super-fast.

Those approaches become really close (or better?) to what can be done with a good Event-Driven HTTP Caching model.

It looks like I sidetracked a bit. So, static might be hyped right now, but with PaaS and CDNs becoming much more than just a place for your website, the future does seem bright for static. Don't get me started with Edge computing.

Which one is the best? Nowadays, static websites can be used for all kinds of projects, eCommerce included. Most likely, your web application will have a dynamic part, and the PaaS you chose will have pros and cons based on what you’re trying to achieve.

For an enterprise-grade eCommerce project, you will probably have to decouple the front end, the search, and other services and have a service layer of your own that you will have to host as well. Whether you pick the same PaaS for your front and back end is totally up to you and really depends on the features, the project tech stack, scale, and budget for most companies and businesses.

We’d add a level of support in the free and paid tiers and community engagement in the decision-making process as well. It’s not the same if you have a problem and have to wait for 24 hours for someone to answer.

START building for FREE with Crystallize or schedule a 1-on-1 demo so we can show you how you can utilize the power of headless architecture on your preferred static host solution.