SSG, oftewel static site generation, betekent dat je website wordt omgezet naar kant-en-klare HTML-bestanden voordat iemand hem bezoekt. Een tool draait één keer tijdens het deployen, haalt je content op en maakt een map met afgeronde pagina’s. Komt er een bezoeker, dan geeft de server gewoon een bestand terug. Er hoeft niets ter plekke berekend te worden.
Zie het als een drukgang bij een uitgever. Het boek wordt één keer opgemaakt en gedrukt, daarna rollen er duizenden identieke exemplaren uit. Een statische site werkt net zo: het zware werk gebeurt tijdens de build en elke bezoeker krijgt diezelfde snelle kopie. Dat is het idee achter de JAMstack en de reden dat een framework als Astro er zo op leunt.
De winst zit in snelheid en stabiliteit. Platte bestanden kun je op een CDN dicht bij je bezoekers zetten, dus pagina’s verschijnen vrijwel direct en je Core Web Vitals zien er meestal prima uit. Ook beveiliging wordt simpeler: zonder database of servercode die bij elk verzoek draait, valt er voor een aanvaller veel minder te porren.
Het nadeel is de herbuild. Omdat pagina’s bij de build vastliggen, betekent content wijzigen dat je de build opnieuw draait, prima voor een blogpost maar onhandig voor een prijs die elke minuut verandert. Daar combineer je het met SSR of haal je dat live stukje in de browser op. Voor de meeste marketingsites, blogs en documentatie is dat een makkelijke keuze.
De buildtijd is het andere om in de gaten te houden. Een kleine site bouwt in seconden, maar een webshop met vijftigduizend productpagina’s kan veel langer duren, dus moderne tools bouwen alleen de pagina’s die echt veranderd zijn opnieuw. Bij een paar honderd pagina’s staat de hele site in een oogwenk klaar en gaat hij meteen naar de edge.
Bij TopDevs kiezen we standaard voor static generation bij content-gedreven sites, en zetten we server rendering alleen in voor de paar onderdelen die het echt nodig hebben.
