Wat is Static Site Generation (SSG)?

Het antwoord: het compleet statisch genereren van een website, zodat de server alleen nog maar HTML, CSS en JavaScript hoeft te serveren.

Eigenlijk doet dit heel erg denken aan de begin tijden van het web. We met zijn allen handmatig onze HTML, CSS en JavaScript. Iedereen die de website bezocht kreeg precies dezelfde content. Kortom alles was statisch?

Tegenwoordig is "alles statisch" weer helemaal terug van weggeweest!

Hoe werkt SSG?

Bij een SSG heb je twee werelden / omgevingen die compleet los van elkaar staan:

  • De build server aka de Static Site Generator die de website bouwt. Dit kan in React bijvoorbeeld met Next.js of met Astro.

    Deze wereld bestaat alleen compile time / wanneer je op de "build" knop drukt.

  • De webserver die de website uiteindelijk serveert aan de browser / eindgebruiker. Dit kan bijvoorbeeld apache of nginx zijn, maar ook een Content Delivery Network.

    Deze wereld bestaat runtime, en is altijd aanwezig zodat de website online staat.

Het doel van de Static Site Generator is een compleet statische website opleveren, in een folder / zip archief. In deze folder staan dan weer een zwik statische HTML, CSS en JavaScript files.

Een statische file is een file die niet veranderd per gebruiker, en ook niet veranderd met de tijd.

Schematisch ziet dat er zo uit:

Een diagram: de static site generator haalt data uit een database / CMS, en genereerd alle HTML / CSS / JS van de website. Vervolgens upload je alle files naar een webserver, deze serveert vervolgens aan de browser / bezoeker de statische files.

Het idee is om je website telkens opnieuw te genereren wanneer de content van de website verandert. Het process is dan als volgt:

  • De build wordt getriggered door één van de volgende zaken:

    • Een content editor veranderd iets in het CMS zoals bijv WordPress

    • De klok passeert een heel uur / dag / arbitraire tijds interval.

    • Een externe API roept een webhook aan die de build triggered, omdat er nieuwe data is.

    • De database meld dat er iets in de data is gewijzigd / toegevoegd / verwijderd.

  • Op de build server wordt de build getriggerd, de Static Site Generator (misschien wel Next.js) gaat aan de slag.

  • De build is klaar en heeft een folder opgeleverd, in die folder staan statische HTML-bestanden voor elke pagina. Maar natuurlijk ook de CSS, JavaScript, en mogelijk ook afbeeldingen.

  • De folder (wordt gezipped) en geüpload naar de web server.

  • De webserver serveert nu de nieuwe versie van de website!

Waarom is SSG zo snel?

Een maxim binnen het programmeren zegt het volgende: Je kan een programma alleen sneller maken door minder te doen en toch hetzelfde resultaat op te leveren.

Een SSG heeft per request van een eindgebruiker minder te doen met een Server Side Rendering (SSR) model. Bij Server Side Rendering moet per request een database / CMS worden aangesproken, en ook een programmeer taal zoals PHP / Java worden uitgevoerd.

Server Side Generation (SSG) hoeft al deze dingen niet te doen. De webserver heeft maar één ding te doen: zo snel mogelijk content over de lijn sturen!

Dat maakt het SSG model lekker snel.

Is een SSG veiliger qua security

Ja, want een SSG heeft minder bewegende onderdelen. Wanneer je server een runtime nodig heeft zoals Java, PHP, JavaScript of Python is dat een aanvals vector.

Hoe complexer je server is hoe meer vectoren / ingangen een hacker heeft. Door een CDN / simpele webserver te gebruiken maak je het moeilijker voor de hacker om een gat te vinden.

Wanneer de hacker toch een gat vindt bij SSG dan zit je natuurlijk in de problemen, de hacker beheerst nu de website. Maar hij beheerst (wanneer je het CMS en Database gescheiden houdt) niet de data!

Wat maakt SSG minder geschikt voor interactieve websites?

Een "build" draaien kost tijd, en dat maakt je website minder interactief. In ieder geval minder realtime!

Stel je de volgende scenario's voor:

  • Een bezoeker plaatst een stukje commentaar.

  • Een bezoeker laat een review achter.

  • Een bezoeker liked / geeft iets een hartje / duim omhoog.

Voor elk van deze scenario's moet je iets verzinnen. Het makkelijkst is gewoon de website opnieuw builden. Wil je het echter realtime hebben dan moet je misschien delen van de website met JavaScript gaan inladen.

Een andere aanpak is gebruik maken van Incremental Static Regeneration (ISR) . Met ISR is het idee dat je niet alles opnieuw bouwt, maar slechts een klein deel van de website. Bijvoorbeeld: plaatst iemand commentaar bij een nieuws artikel, dan herbouwen we alleen dat nieuws artikel.

Nadeel van ISR is dat je dan wel weer een runtime op je web server nodig hebt... dit doet het security voordeel weer te niet.

De grootste doodsteek van SSG is echter gepersonaliseerde content aan een gebruiker tonen! Denk aan winkelwagens, inloggen / uitloggen, een persoonlijke feed van video's. Je moet dan per gebruiker pagina's gaan genereren. Dit is al snel onbegonnen werk.

SSG en React

Er zijn een aantal frameworks binnen het React ecosysteem die Static Site Generation ondersteunen:

Contact

Neem contact op via e-mail, phone of app, als je vragen hebt of een offerte wilt aanvragen.

Vraag een offerte aan Boek kennismakingsgesprek