Static Site Generation - Xuntos Tech Blog
When Sir Tim Berners-Lee started developing HTTP, the World Wide Web and the first Web Browser in 1989, his vision was a network where documents could be exchanged easily. The documents in his view are static documents that are formatted by hand in HTML. He could never have foreseen that thirty years later, the WWW would consist mainly of pages assembled using dynamic content. However, part of the web development world is taking steps back to static HTML files on a server. Only with a twist, namely the dynamic generation of a static website.
Serving files to the visitor's browser is what web servers are the fastest at. Even though they can assemble pages with content from eight different sources, a static HTML file will always be able to be displayed to the user before such a dynamic page. Purely because the server has to do almost nothing, just search for the requested file and send it to the visitor. The difference is noticeable even to the naked eye. Alrijne.nl is one of the fastest dynamic sites we've built, which takes about a second and a half before the main page is fully loaded. With a static site, this can only decrease by a factor of three, so the page load time will be half a second.
Speed is just one of the benefits of a static site. A website that only consists of fixed files is very secure. It's just hard to attack a site where no data needs to be fetched or written down. A static site is separate from a back office to log in and has no connection to a database, which is just very secure.
Static yet Dynamic
But can we then no longer use a CMS at all? Do we have to tinker together the HTML ourselves for every news article? No, definitely not! That's where Static Site Generation comes in. In short, a Static Site Generator (SSG) takes content from a separate CMS, pours it into templates and saves the result as HTML files that reflect the structure of the CMS. It separates the generation of the HTML files from the visitor's requests. This gives you a kind of intermediate form between a dynamic CMS site as we've come to expect in recent years and a site that has been manually assembled file by file.
You can still easily publish new content on such a site because the CMS can send a signal to the SSG via a webhook when publishing a page. The SSG will then bring in the new content and put it into new files. As a result, it takes a little longer before pages are actually found on the internet. Once they have been generated, they can be requested very quickly for visitors.
The desired technology for using an SSG is no problem at all. StaticGen.com
Snags
A static site is not useful for every situation; by using an SSG, you often lose the ability to preview content in the CMS before it is published. As a result, content administrators have no way of seeing what the page will look like when they are writing. That's no problem for some editors, but writers often like to see how a page shows before they send it out into the world.
Another disadvantage is the time it takes to generate the site. Because you separate the casting of the content into templates from a user's visit, loading a page for a visitor becomes short. However, that time must be made up elsewhere. This happens with an SSG when content is published. After all, then the SSG will be kicked off and it will generate the site based on the content. The SSG has trouble determining what has changed about the site since the last generation, so it will generate the entire site again. For a site with a number of content pages and some news articles, that will be very easy. A site with hundreds or even thousands of pages can be quite a job to generate from scratch with each new article. This will also make it more difficult to publish time-sensitive pages at the right time. Specific timing of campaign pages therefore requires a bit more coordination to have it public at exactly 12:00 in the afternoon, for example.
Who is it interesting for?
Static Site Generation is therefore mainly suitable for a relatively small website where the content is created by visitors as little as possible. A blog or corporate news site could be one of them. But a vacancy site could also be ideal for a website that is statically generated. Although user generated content is also possible, user comments for a blog can be fetched and written from a Web API with JavaScript, for example.
In short, we find this development very interesting, because we are always working to keep the performance of the sites we develop as high as possible. The side effect of extra safety is a bonus. In the future, we hope to create a number of super fast websites for a customer where this is the best solution.
Written by Victor Remmerswaal
- Xunti since 2017, web technology enthusiast, video gamer and netball player
Heb je vragen? Of wil je samen sparren?
We denken graag met je mee hoe jouw organisatie digitaal kan versnellen. Of het nu gaat om een UX, technische uitdaging of AI oplossingen. Stuur een berichtje en we nemen zsm contact met je op.
Verder lezen
Nieuwsgierig? Lees onze andere inzichten over webontwikkeling, AI, toegankelijkheid en digitale strategie
.jpg)
