Static Site Generation - Xuntos Tech Blog

Toen Sir Tim Berners-Lee in 1989 begon aan het ontwikkelen van HTTP, het World Wide Web en de eerste Webbrowser bestond zijn visie uit een netwerk waarin makkelijk documenten uitgewisseld kunnen worden. De documenten in zijn visie zijn statische documenten die met de hand opgemaakt worden in HTML. Hij had nooit kunnen voorzien dat het WWW dertig jaar later vooral zou bestaan uit pagina's die aan de hand van dynamische content in elkaar gezet. Een deel van de webdevelopment wereld is echter bezig met stappen terug te nemen naar statische HTML files op een server. Alleen dan wel met een twist, namelijk het dynamisch genereren van een statische website.

Illustratie van HTML Code

Bestanden serveren aan die browser van de bezoeker is het gene waar webservers het snelst in zijn. Ook al kunnen ze pagina's in elkaar zetten met content uit acht verschillende bronnen, een statische HTML file zal altijd eerder bij de gebruiker getoond kunnen worden dan zo'n dynamische pagina. Puur omdat de server vrijwel niets hoeft te doen, enkel het opgevraagde bestand op te zoeken en naar de bezoeker sturen. Het verschil is zelfs met het blote oog merkbaar. Alrijne.nl is een van de snelste dynamische sites die wij gebouwd hebben, die doet er zo'n anderhalve seconde over voordat de hoofdpagina volledig geladen is. Bij een statische site kan dat zo maar met een factor drie afnemen, de laadtijd van de pagina komt dan dus op een halve seconde te liggen.

Snelheid is maar een van de voordelen van een statische site. Een website die alleen maar bestaat uit vaste bestanden is heel veilig. Het is gewoon lastig om een site aan te vallen waar geen data opgehaald of weggeschreven hoeft te worden. Een statische site staat los van een backoffice om in te loggen en heeft geen connectie met een database, dat is gewoon erg secure.

Statisch maar toch Dynamisch

Maar kunnen we dan helemaal niet meer gebruik maken van een CMS? Moeten we voor ieder nieuws artikel zelf weer de HTML in elkaar sleutelen? Nee zeker niet! Daar komt een Static Site Generator om de hoek kijken. Kort door de bocht gezegd neemt een Static Site Generator (SSG) content uit een los CMS, giet dat in templates en slaat het resultaat op als HTML files die de structuur van het CMS reflecteren. Het koppelt het genereren van de HTML bestanden los van de requests van de bezoeker. Waardoor je een soort tussenvorm krijgt tussen een dynamische CMS site zoals we die de afgelopen jaren gewend zijn en een site die handmatig bestand voor bestand in elkaar is gezet.

Je kunt op zo'n site toch makkelijk nieuwe content publiceren doordat het CMS via een webhook een signaal kan sturen naar de SSG bij het publiceren van een pagina. De SSG gaat dan de nieuwe content binnen halen en in nieuwe files gieten. Hierdoor duurt het wat langer voordat pagina's daadwerkelijk op het internet te vinden zijn. Als ze gegenereerd zijn, dan zijn ze voor bezoekers wel ontzettend snel op te vragen.

Gewenste technologie voor het gebruik van een SSG is geen enkel probleem. StaticGen.com

Haken en ogen

Een statische site is niet voor iedere situatie handig, door het gebruik van een SSG verlies je vaak de mogelijkheid om content te previewen in het CMS voordat het gepubliceerd wordt. Hierdoor hebben content beheerders geen mogelijkheid om te zien hoe de pagina eruit komt te zien wanneer ze bezig zijn met het schrijven. Voor sommige redacteuren is dat geen enkel probleem, maar vaak vinden schrijvers het wel fijn om te kunnen zien hoe een pagina toont voordat ze hem de wereld in sturen.

Een ander nadeel is de tijd die het genereren van de site kost. Doordat je het in templates gieten van de content los trekt van het bezoek van een gebruiker wordt het laden van een pagina voor een bezoeker kort. Die tijd moet echter ergens anders ingehaald worden. Dit gebeurt bij een SSG op het moment dat content gepubliceerd wordt. Dan wordt namelijk de SSG afgetrapt en die gaat op basis van de content de site genereren. De SSG kan lastig bepalen wat er aan de site veranderd is sinds de laatste generatie, dus die zal de hele site opnieuw genereren. Voor een site met een aantal content pagina's en wat nieuwsartikelen zal dat heel erg meevallen. Een site met honderden of zelfs duizenden pagina's kan best een klus worden om bij ieder nieuw artikel helemaal opnieuw te genereren. Dat gaat er ook voor zorgen dat het lastiger is om tijdsgevoelige pagina's op het juiste moment te publiceren. Het specifiek timen van campagne pagina's vergt dus wat meer coördinatie om hem bijvoorbeeld precies om 12:00 's middags openbaar te hebben.

Voor wie is het interessant?

Een SSG leent zich dus vooral voor een relatief kleine website waarop de inhoud zo min mogelijk door bezoekers gemaakt wordt. Een blog of een corporate nieuws site zou er zo een kunnen zijn. Maar ook een vacature site zou zich prima kunnen lenen voor een website die statisch gegenereerd wordt. Al is user generated content ook wel mogelijk, gebruikers comments voor een blog kunnen bijvoorbeeld met Javascript opgehaald en weggeschreven worden vanuit een Web API.

Kortom wij vinden deze ontwikkeling super interessant, want wij zijn altijd bezig om de performance van de sites die wij ontwikkelen zo hoog mogelijk te houden. De bijkomstigheid van extra veiligheid is helemaal mooi meegenomen. We hopen in de toekomst een aantal super snelle sites neer te zetten voor een klant waar dit de beste oplossing voor is.

 

Geschreven door Victor Remmerswaal
- Xunti sinds 2017, webtechniek enthousiast, videogamer en korfballer