The benefits of a static website.
Static websites are making a big comeback, although back in the 90’s it was actually the norm for all but the largest sites to be ‘static’. Most of the personal and small business sites around were put together by hand-coding HTML or created using a tool like Dreamweaver or Frontpage.
It’s quite different this time around, so the term ‘static website’ can be a little confusing at first. In this day and age the term generally refers to sites that serve web pages that are generated ahead of time, instead of being generated on demand by an application backed by a database. Generating web pages dynamically on a server and serving them to visitors became the norm in the 2000’s thanks to the rising popularity of programming languages such as PHP and platforms such as WordPress.
The common approach
To this day the common approach taken by owners of small- to medium sized websites, is to use a single tool (such as WordPress, Drupal or Magento) that is tasked with almost everything. By that we mean the handling of content management, generating web pages on-demand and integration with services such as user comments, user profiles, e-commerce as well as securing access to members-only content.
The first issue is that we get a website that is left with a lot of so-called ‘attack surface’ because of its complexity. Sites such as these require constant monitoring and security updates, lest they be taken down without serious effort. Hacking would be too flattering a term in these cases as the ‘hacker’ is generally just someone using automated scripts that target well known security exploits.
To be fair, a lot of the security vulnerabilities that are discovered on these platforms can be traced to 3rd party plug-ins. Site owners tend to install those in order to add functionality to their websites. The core of WordPress for example is in and of itself actually fairly secure, if properly configured. It’s been around for quite a while, so a lot of security flaws and bugs have been patched and squashed at this point. But the core of WordPress is quite limited, meaning the installation of 3rd party plug-ins is almost a given for most of the websites that are based on it.
The second issue is efficiency. Most website platforms and content management systems are based on scripting languages (i.e. PHP, Python) that run slowly and inefficiently, but are easy to learn. The preference for these languages is a bad habit taken over from the early days of the world wide web, where the shortage of skilled developers set a precedent of getting things done quickly, instead of properly. Fast forward to today and all but the largest websites are based on software solutions that require 4 to 8 times more hardware and electricity than necessary to get the job done.
Efforts have been made to address some of these issues by means of caching, buffering an the like, but not very successfully. There are plug-ins for example that will generate pages ahead of time much like a static website, but they generally introduce entirely new issues and challenges. Websites with large teams that are frequently updating content have found them wanting, due to frequent delays and distribution issues.
Which brings us to the third and possibly greatest issue of all: growth or scalability. These platforms aren’t designed with (optimised) global distribution in mind. To do that they would need to support distributing data across multiple servers, in multiple locations around the world. While standard webpages could be cached and generated ahead of time to some degree, user comments, discussions, shopping carts are another story. The technology to do that effectively hasn’t been around too long either, at least not without some major investments in infrastructure and some very clever software developers. It’s fairly safe to say that it’s not likely to be on the roadmap of most (free) integrated platforms, meaning an expensive and time consuming migration or an entire do-over from scratch are all but inevitable when the limits of the platform are reached.
When it comes to WordPress and other similar platforms however, it’s at least relatively easy to get most of the data out and migrate it elsewhere. The same cannot be said for fully managed platforms like Wix and Squarespace for example. While Wix and Squarspace scale better and pollute less than WordPress as they’re based on more performant languages (i.e. Java), they tend to make migration as difficult and labour intensive as possible. Easy to get in, hard to get out.
The ‘static’ approach
Static websites are instead a decentralised approach to the problem. Instead of handling everything, they handle one key area: generating and re-generating web pages.
In a static website setup, content is separated from the website. It can be managed with the help of a Git service such as Gitlab or GitHub, a ‘headless’ CMS that deals with content management, or a full-blown ‘Enterprise Content Management’ (ECM) system that handles every written word and picture in an organisation.
The website is instead considered one of potentially many ‘outlets’ of content. A generator is given a nice looking and functional template, pointed in the direction of the content that it is meant to convert and let loose to (re)generate the website.
The result in this scenario is a website with virtually no attack surface save the web server or content delivery network that it’s stored on. With the web servers only serving static files such as HTML, CSS, fonts and pictures, there’s simply not a whole lot left to attack. In this approach web servers are better able to do what they were designed for, serving files, instead of dragging complicated integration with other software along with them. The result is that web servers are able to handle more requests per second, reducing the amount of hardware, electricity and money required to do the job. Aside from that, public content such as the site’s landing page, articles, blog posts and the like are always up and running and virtually immune to attack.
Dynamic data on the other hand isn’t actually handled by the static website, but by the users web browser through the JavaScript that’s included with the site. Once loaded various scripts will fetch data from servers and render dynamic data such as a secure login page, the user’s profile, shopping carts and other protected content on the users device. This can all be handled by a self-hosted solution or a 3rd party provider for each individual service.
The caveats
While all of the above might sound amazing, it’s not without its share of caveats. It’s great if you know what you’re doing. Buying the domain could be the only money that has to be forked over for the first few years in some cases.
But for those less in the know, it could mean a huge stack of monthly subscriptions if they’re not careful. Setting up services to handle the various types of dynamic data and processes is not for the faint-hearted and keeping them secure even less, which is why 3rd party services generally don’t come cheap. The core website may be largely immune to attack, but the dynamic parts certainly aren’t, no more than anything else that is available online; listening to requests and serving responses.
Many not-quite-so-well-prepared-people therefore end up getting a subscription for everything; one for content management, one for a shop, one for user engagement (i.e. user comments), one for email forms and so on.
The takeaway
Static websites are definitely a major improvement in terms of performance, availability, security and environmental responsibility, but there’s a lot of homework to do if a Do-It-Yourself gambit is to be attempted.
Our advice? Start with Hugo and have it run on Gitlab, which is the easiest to set up and 100% free. Then hook it up to either Cloudflare or Netlify. Both offer very comprehensive free plans.We’ll be posting more articles on how to get started with static websites and other related services, so check back soon.
Until then,
Yours,
Netsemblage