Why Static?

Netlify’s State of Affairs March. 11, 2015

Ladies and Gentlemen

The current web is a mess. Seriously though. 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 bounce rates 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.

Though not all static glimmers in gold. There is still no CMS, so updating is developer-only. And though static sites are faster in theory, it’s still been a complex process to set it up just right. Which is the whole motivation behind Netlify. We want static sites to be as easy to make as possible, while still gaining all the speed, etc., that static sites promise to deliver.

What is a static site?

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. Basically it’s CSS, HTML, Javascript, and likewise.

What it isn’t is: PHP, Mysql, .net, Ruby, etc. You can use in all of those in creating the site with for example a static site generator. But you can’t actually use them in your hosting environment.

A traditional (dynamic) 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 to host 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 (if one CDN server goes down, traffic just goes somewhere else, but when your Godaddy or One.com server goes down, your site goes offline).

2. Security. As there is no movable parts, no php or scripts being exectuted, there is no way to inject malware. Malware and the inherent structure of traditional web tech is becoming a major issue (we wrote an article about it)

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. Like ponder what’s up with cheese, or if you should sign that petition against the use of daylight savings. (You should. Only God gets to mess with time).

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. As a developer or agency producing just a small amount of sites per year, this alone could be saving you thousands of dollars.

What sites should / could be static?

Most sites would benefit from being “static”. Right now there are two exceptions:

Those that need a CMS (major exception we know, but check in with us regularly - we are working on something huge), and those that need constant updating.

Building a static site takes a while - typically perhaps 20 seconds - and that’s too long a wait if you are updating lets say every minute.
So if you are making a new stack overflow where the site is updated constantly you are fresh out of luck. If not, keep reading!