April 11, 2016
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 websites. For some time we have recognized the value of using static websites and wanted to provide some insight into the practical choices made when evaluating the suitability of the static website approach.
When discussing static websites, most people respond “Why? Why should I make this website static?”, but instead the question should be Why should my website be Dynamic or driven by a database?
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, essentially a database.
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 techniquesused 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 , i.e Wordpress and it’s lookalikes 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 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
Some of the tools we use in creating static sites:
STATIC CMS SYSTEM
It presents a clean UI for editing content stored in a Git repository. As an example WebriQ Blog Admin
You setup a config to describe the content model of your site, and typically tweak the main layout of the CMS a bit to fit your own site.
When a user navigates to /admin she’ll be prompted to login with a Github credential, and once authenticated she’ll be able to create new content or edit existing content.
Register a FREE ACCOUNT to see all the above tools and much more in action.