 |
| 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.
When discussing static website generators, most people respond “Why? Why should I make this website static?”… but instead the question should be “Must this website be dynamic?“
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.
It may require creative thought as to how to turn a website that would be obviously dynamic into a static website. At the same time, never before has there been this many quality tools for adding dynamic elements to otherwise static websites: CORS JavaScript, web microservices, and the static site generators themselves. Now that the Google Crawler is executing JavaScript as part of content indexing, the traditional major penalty of this approach has been removed.
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.
If real-time data is of absolute importance, then something like a microservice utilizing client side JavaScript to retrieve the most current information may be used in conjunction with a static website. Possible with some technical creativity.
Personalization
If the page you display is completely customized to your user it would not be possible to pre-generate the pages as you would need authentication and then customization information that is only available at the time of the request. Again, this may be mitigated by using client-side JavaScript to provide some of the personalizing.
Ease-of-use
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.
While it is possible to build this site on WordPress, it did not make a lot of sense. If you take the static-first stance, you would look for a reason to require WordPress here: there was no blog, no news, no login, no personalization, no projected content update, not even web pages in the conventional sense. We instead suggested a static site, and built it with a tool chain including Jekyll, Grunt, Compass and Amazon Web Services. The site uses client-side JavaScript to retrieve and display third-party data, adding a more dynamic feel. The end result was a site that fulfilled the requirements, is editable by anyone who knows HTML/CSS (even more so if they know the toolchain), is lightning fast to deliver and can be hosted anywhere with a webserver.
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.
What we saw here was that the overall site itself was static, the data was the only changing portion and that only needed to change on an hourly basis. After some quick prototyping, we found a good static approach. The website itself is statically generated, and the data is generated hourly into a JSON file which also lives statically on the server. JavaScript is used on the client to display the content in the JSON file and add customization via meta data added as part of the aggregation process.
Tools
Some of the tools we use in creating static sites:
Jekyll
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.
Compass
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.
Grunt
A JavaScript based task runner, invaluable for helping manage the set of tasks used to generate a static site. It allows us to run Jekyll, compile our Compass SCSS, verify our code and markup, watch and LiveReload during development, minify assets and handle deployment to test, staging and release servers.
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.
Leave A Comment