July 31, 2018
When a user tries to access a web page, their browser makes a request to the server that hosts it. Either the server answers the page immediately, exactly as it is stored, or the server generates it by executing code on demand. Although the Web was conceived as an entanglement of static files, server-side programming languages appeared very early and are now widely used. More than 80% of servers that use server-side language are running PHP. And hosting providers offering servers without dynamic language support are almost non-existent. Yet, the dynamic generation of HTTP responses presents significant disadvantages in terms of web performance. A dynamic webpage is often built around a web server that loads an execution language that analyzes the HTTP request, often requests a database (sometimes located on another server in the datacenter) and third-party services, populates a logical model that reveals itself through an aggregate of templates to generate the HTML response. Quite logically so, response time is longer. A paradigm shift If you want to deliver your static pages, you must have compiled them up front. This fact, as trivial as it may seem, changes everything. Indeed, compilation turns out to be the main advantage of static: shift the complexity from the Production environment to the integration process. If your pages are served by a web server without being generated first, you have no need for a server-side language to be executed. As a consequence, many attack vectors disappear. You can’t steal confidential data by injecting malicious code if you have neither a database nor a server-side execution language. The static trend allows you to completely transform the way a site is published.
A static site generator (SSG) is a software executed locally or as a service that produces (and sometimes deploys) a static website using some data sources for model and configuration, and templates containing the business logic. The SSG market is booming. Most of them generate a website from a set of files, often written with a lightweight syntax. The responsibility for the conversion to HTML is assigned to both a templating engine and a converter, responsible for transforming the markup into HTML. They are mainly a playground for front-end developers who know how they tick.
It becomes really interesting when you follow the lead of external data sources because then, we can talk about CMS that would not be used to render HTML, but only to store and expose data. They are called Headless CMS.
A headless CMS liberates the development team from the burden of maintaining a database, instead they can focus on the platform’s technical evolution and the assets pipeline while the contribution team can sharpen its content.
Editors and content writers can work on files which are easy to store and modify. Their only common language with developers becomes the metadata passed in each file. Editors can use the editing tool or service of their choosing, even one that ensures collaboration. Editors also can benefit from source code versioning whenever they want to consult the history of their files, merge several versions or branch to write content they don’t want to publish right away.
In essence this means, that we are no longer in a system where the main metric of scalability is the number of simultaneous visitors, but in a system that can adapt to the frequency of generation and deployment requested by editors and content writers.
**A headless CMS, a Static Site Generator and a deployment facility and you are ready to GO. **
JAMStack is a real paradigm shift. The website being served to the visitor becomes, more than ever, a shell in which services, whether self-hosted or third parties, are dynamically injected. It is even possible to rely on several services for the same purpose and switch to a fallback if the main service is not available. And since you’re shifting a lot of the efforts to the Front End, why not go further and build your site with a Single Page App, or transform it into a complete Progressive Web App (PWA), designed to be “mobile and offline first”? This is not inherent to JAMStack, but heavily facilitated by the change of development paradigm.
The biggest risk is to get lost in the plethora of Headless CMS, generators and service platforms. Those risks are greatly diminished when using WebriQ GLUE, basically a set of top of the line Jamstack tools, glued together for you, supported and serviced throughout the lifetime of your website and web application. Once you have fully grasped the specific risks and put in place appropriate workflows, the JAMStack nonetheless presents a tremendous opportunity for aging CMS systems and aging workflows
more in depth details can be read on https://blog.dareboost.com/en/2018/02/static-website-web-performance/