Back to Blog

The business case for Static Websites

clock-iconApril 09, 2016

The current web is a mess. Every week we go to Hackernews and follow a broken link. Not long ago 12 million Drupal sites were infected with malware. 79% of all Wordpress sites are vulnerable to known exploits.

The emergence of mobile means a lot of slow loading sites with towering bouncerates and loss of business to follow.

We should do better. We must actually. Because we can.

Static websites have always been faster, safer, simpler and cheaper.

It’s just that browsers and hosting services weren’t good enough, so there were too many compromises. Making the slow, vulnerable and expensive traditional “dynamic” sites the best alternative.

But no more. The browser is all grown-up, and CDNs have really seen the light of day.

We want static sites to be as easy to make and to update as possible, while still gaining all the speed that static sites promise to deliver.

Static websites are faster, safer, simpler and cheaper. Here we explain how. Static sites are simple, but today they can do almost anything a traditional (dynamic)site can.

A traditional (Wordpress or Drupal) site needs to be hosted on a server, and it needs to render every single time a user visits. The difference with a “static” site is that you build it BEFORE you deploy it. So what’s live are only already rendered files. So there are no so-called movable parts live and you get tohost the site on a CDN. (Content Delivery Network). Anything that still needs rendering will be done so by the browser. Pretty cool if you think about it.

This all means a number of things. All of them good if you are going static.

1. Speed & Performance. That your site will be served from a CDN instead of a single server means much lower latency and much higher uptime

2. Security. As there is no movable parts, no scripts being executed, there is no wayto inject malware. Malware and the inherent structure of traditional web tech is becoming a major issue.

3. Simplicity. Again there are no moving parts. You don’t need to optimize your how fast your code will be rendered, as it’s already rendered when you deploy it. So no need to worry about server updates breaking your site, etc. When it’s live it’s live,and you can go on to doing other things.

4. Cost. It’s way way way cheaper to scale. And it all happens automatically. So no having to cover yourself by buying into a larger hosting service than you need, or having your servers cave to traffic spikes.

Mostsites would benefit from being “Static”.

There are two exceptions - sites that absolutely need a database as a back-end and those that need constant updating.

Building a static site takes a while - typically perhaps 10 to 20 seconds - and that’s too long a wait if you are updating lets say every minute.

Have a look at how we have automated the building, management and updating of a typical Portfolio website at WEBRIQ APP