|It’s pretty, it’s functional, it’s responsive and interactive… and static generated HTML|
Web development has stagnated on a concept in recent years, the idea of a requisite dynamic content management system (such as WordPress or Drupal), but now there is a resurgence in static website generators. For some time we have recognized the value of using static website generation (including building our own) and wanted to provide some insight into the practical choices made when evaluating the suitability of the static website approach.
Static or Dynamic Website
The term static site describes a website with pre-existing content and available as plain HTML files. This is in contrast to a dynamic site in which content is generated upon request by a series of backend systems (think WordPress or Drupal).
All sites have some static content: the images, the styling, etc… For dynamic sites the HTML markup that brings all of it together is not already available for use, rather it is generated at the time it is needed by a browser. In contrast, a static website has this markup pre-generated and immediately ready to be sent to a browser without delay, having already performed the generation step before the site was made available.
Not taking the performance hit of generating the site content upon request spares the burden of real-time infrastructure, which translates directly to sites exhibiting greater speed and stability at significantly lower costs. The absence of this complex infrastructure results in sites that are more secure and scalable. Cloud hosting has made it such that for almost negligible cost a static website will never be unavailable and can scale to meet any perceivable demand. Static site generation was one of the techniques used to save the healthcare.gov website when it had trouble scaling in it’s initial rollout.
When to use a static website
As the LAMP stack grew in popularity, its use in creating websites became common and many sites that did not have particular needs to be dynamic were created dynamic by default. This is not the best approach.
Imagine you have a website that presents widget information, and you have 1000 widgets in your database. It would be easy to default to creating a dynamic website with a PHP script taking the widget name as input and displaying specific information about that widget when the site was hit. An alternative is to use a static website generator to create the 1000 different pages (one for each widget) and use those to show the widget information. If the widgets ever update, the site may be re-generated to update the content. Now that static website generators have the capability to effortlessly rebuild websites around new content, adding new content to static websites may be configured to as a turnkey operation.
See the aforementioned article for greater details on the process of static website generation.
Generally you should be striving to make your website as static and compressed as possible, while recognizing there are some good reasons it may not be possible:
Information Update Frequency
The information you are trying to convey on your website may require real-time generation to display. If you must display content information accurate to the moment the request for the information was made, it would not be possible to pre-generate the content as you would not know what the information actually is at the time of site generation.
This is not to say that generation cannot be frequent if the data changes frequently. If you have a data set such that generating (and deploying) the site takes 60 seconds, and the data changes every 10 minutes. You still have the opportunity to automate site generation every 10 minutes and have a static website that is relatively current to the information it is conveying.
It makes sense to use a WordPress blog or other service if you simply do not have the expertise to use the generating tools. In these cases the value is not provided by the dynamic generation of the website, but the interfaces give by the CMS tools to customize the site, requiring that the site be able to feed from a dynamic infrastructure stack.
Making the decision to go static
Example: The WordPress Site
WordPress has become a often requested platform for websites. It is requested due to positive word-of-mouth and adoption rates, but rarely is it analyzed beforehand as the proper approach for a site’s needs.
The site requirements were a completely custom design, lots of static text, some data (not altering for the forseeable future), more of a classic corporate home-page, in single-page website format.
Example: The Content Aggregator
This looked, initially, like a standard dynamically generated website. The site was a content aggregator, displaying news from a few third party websites, with some extra value-add information.
After analyzing the requirements, we saw opportunities in the nature of the aggregated data
- We only needed to display the top 50 or so items from each site.
- The sites did not exhibit much data churn within the span of an hour.
Some of the tools we use in creating static sites:
Jekyll is the most widely adopted static site generator, it also powers GitHub pages. It uses the Liquid templating language (like Shopify), and can convert SCSS and has fantastic support for data inclusion.
Is a support library for SCSS to help smooth over some browser rough-edges. We use it and the breakpoint library to handle responsive design.
Amazon Web Services
The premiere provider of web infrastructure service, period. Static sites are inherently fast and stable, you still need to serve them up and AWS is the best place to do it. S3 can host a static site for pennies, and CloudFront can serve it up as a CDN. AWS Lambda is part of a new set of tools enabling better static sites: it lets you run web microservices without bothering about infrastructure.
Choosing smartly in developing your website
Overall we find that a requirements analysis matched with a static-first philosophy and the right tools allows for creative assessment of techniques used to develop fast, stable and vastly scalable websites.
As posited in the introduction, changing the paradigm from being “everything dynamic, why static” to instead be “default is static, why dynamic” can enable you to think strategically about the requirements of your website project, its technical requirements, and how the website will be built and supported in the future. It’s not always about finding the best tool, but instead the right tool for your job.
In order to make an informed strategic decision regarding your website infrastructure, it is necessary to do an in-depth technical requirements gathering phase. But in this phase, rather than starting with assumptions (such as dynamic vs static-generated or a default choice of Content Management System), start by defining the actual project needs and requirements and use that to guide your technical requirements and technology decisions.