The virtues of a static website.

Static websites are making a big comeback (although not quite fast enough in our opinion). Back in the 90’s it was actually the norm for most individuals and small businesses to have a static website - often put together by hand or using a tool like Dreamweaver or Frontpage.

It’s quite different this time around though - and the name ‘static’ can be a little confusing at first. The term ‘static website’ - in this day and age - generally refers to serving web pages that were generated ahead of time instead of being generated on demand. Generating web pages dynamically on a server and serving them to visitors has been the norm in the 2000’s and most of the 2010’s thanks to languages like PHP and platforms such as WordPress. To shed some light on the matter we’ll discuss this approach first.

The common approach

To this day, the common approach taken for personal and small- to medium business websites is that a single tool such as WordPress or Magento is tasked with handling content management, generating pages on-demand, and integrating services such as user comments, user profiles, and e-commerce as well as securing access to members-only content.

The result of this approach is a website that is in need of constant security monitoring and security updates as it is left with a lot of so-called ‘attack surface’. Most will agree that this is because a lot of functionality in these setups doesn’t actually come from the platform itself, but from 2nd (and more often) 3rd party plug-ins that site owners tend to install. WordPress is in and of itself actually fairly secure (if properly configured). It’s been around for quite a while at this point, so a lot of security bugs have been squashed.

While age may give it that blessing at least, it is also very much a curse - at least for the environment. One of the major issues is that of programming language.

Most of these solutions are generally written in programming languages that are ‘dynamic’ and based on scripting. These languages are easy to learn as most of the difficult parts of programming (such as memory management, parallel processing or even handling data types) are handled by the interpreter - letting the programmer focus on application code instead. While that might sound like a good thing - it really isn’t. Languages of this category (i.e. PHP, Python, Ruby) are terrible for the environment and company budget as they require more hardware and more electricity to get the job done. Generally 4 times or more.

Efforts have been made to mitigate this by replicating some of the benefits of static websites on these platforms, but not very successfully. There are plug-ins that will generate pages ahead of time much like a static website - but it’s not a default feature. Even if it was - it requires interpreted languages considerably more computing power to get the job done. Should websites have large teams that are frequently updating content - the platform won’t be able to keep up unless blessed with unnecessarily high powered hardware. Given that most of these platforms are running on the bare minimum - the delays will cause problems on large sites. One could say that getting these platforms to handle static website pages is therefore rather tricky - but it can be done.

(Environmentally speaking however - a physical server could host a lot more websites if they weren’t written in scripting languages, that much is undeniably true.)

Dynamic data on the other hand is a different story - distributing databases across multiple servers in multiple locations is something that hasn’t been around for all that long, at least not without some major investments in infrastructure and some very clever software developers.

It’s safe to say that it’s not exactly on the roadmap of most integrated platforms either - at least not the free or affordable ones. Distributing dynamic data on these platforms is therefore virtually out of the question. If or when the time comes to scale up when a business or content channel grows the platform will prove inadequate and an entire do-over will become more and more likely.

But at least it’s generally fairly easy to get the data out and migrate it elsewhere with open source platforms. The same cannot be said for fully managed platforms like Wix and Squarespace.

While these platforms scale somewhat better and pollute somewhat less due to their use of ‘classic’ enterprise programming environments such as Java - they make migration as difficult and labour intensive as possible. Easy to get in - hard to get out.

Apart from that - while Java may be more environmentally friendly than the scripting languages mentioned above, it wasn’t designed with cloud in mind as the Java runtime environment is large in size and slow to start. That means servers have to be kept on standby to handle increases in traffic - wasting energy, money and other resources in the process. The same goes for Microsoft’s ‘.NET’ for that matter.

The ‘static’ approach

Static websites are instead a more decentralised approach to the problem. Instead of trying to handle 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 website and application content management - or a full-blown ‘Enterprise Content Management’ (ECM) system that handles every written word and picture inside 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 on. With the web servers only handling static files such as HTML, CSS, fonts and pictures - there’s not a whole lot to attack. Not only that but the web servers will be unburdened to do anything other than what they were designed for - serving files, instead of dragging complicated integration with other software along with it. Needless to say - the web server will be able to handle a lot more requests per second because of it.

The main takeaway here is 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 JavaScript it’s carrying in its payload. Once loaded the JavaScript will fetch data from various servers and render dynamic data such as a secure login page, the users profile, shopping carts and other protected content on the users device. This could 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 - because it kind of is - it’s not without its fair share of caveats. For one - 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. The core website may be largely immune to outside 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.

Which brings us to content management; easy enough for a handful of people working on a single site - but for large teams it certainly requires a proper content management system, which generally doesn’t come cheap.

The takeaway

Static websites are definitely a major improvement in terms of performance, availability, security, independence and environmental responsibility - but there’s a lot of homework to do if a Do-It-Yourself gambit is to be attempted.

Our 2 cents? 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 Netlify or Cloudlfare - both of which also offer very comprehensive free plans.

By the time that’s done - we’ll have written a few more articles discussing how other parts can be done freely, as well as hopefully having finished our free content management tool for small teams.

Until then,