Een site waarvan de eerste byte in minder dan 100 ms binnenkomt, geen applicatieserver nodig heeft, en toch geschreven is met dezelfde tools als je SaaS-product. Dat is wat prerendering oplevert. Toch wordt het zwaar onderschat, precies omdát het zo saai klinkt.
Wat prerendering eigenlijk is
Bij prerendering rendert je framework tijdens de build elke route naar HTML en zet die plat op disk. Geen runtime-render, geen Node-server in productie, geen wachten op een database. De output is hetzelfde wat een statische site-generator (Hugo, Astro, Jekyll) zou opleveren, maar je codebase blijft een volwaardige webapp. Componenten, routing, state management: alles werkt zoals tijdens development.
De winst zit in waar het werk gebeurt. Bij Server-Side Rendering on demand passeert elke pageview een server die data ophaalt en HTML rendert; de hydratatie volgt daarna in de browser. Bij prerendering gebeurt dat allemaal één keer per build, en daarna serveer je gewoon bytes vanaf een CDN. Google's web.dev-richtlijnen tonen waarom dat patroon de bovengrens van Core Web Vitals raakt: niets dat sneller kan dan een vooraf gegenereerd bestand.
Belangrijk om duidelijk te zijn: prerendering is een techniek voor websites, niet voor apps. Een marketingsite, blog, documentatie of productpagina rendert voor iedereen identiek. Dat zijn perfecte kandidaten. Een echte applicatie (een dashboard, een inbox, een ingelogd account) toont per gebruiker andere data en hoort dus achter een echte runtime te zitten. We mixen beide: de publieke kant van een SaaS prerenderen we, de app zelf draait als gewone SPA of via authenticated SSR.
De vier echte voordelen
Belachelijk snel
Geen server-render, geen database-roundtrip, geen Node bootstrap. De eerste byte komt van de dichtstbijzijnde CDN-PoP, vaak een paar netwerkhops weg. Met goede beeld- en lettertypechoreografie haal je standaard scores tegen de 100 in Lighthouse.
SEO zonder geneuzel
Elke crawler krijgt op de eerste response volledig gerenderde HTML. Geen tweede passage in de render queue. Metadata, structured data, Open Graph: alles staat in de pagina vanaf byte één.
Bijna nul ops-werk
Geen server om te patchen, geen cold starts, geen uptime-monitoring, geen auto-scalingregels. Wat je serveert is een map met HTML-bestanden. Dat is alles wat er kan stukgaan.
Hosting kost niets
Statische bestanden op een CDN kosten enkele euro's per maand, vaak gratis. Je betaalt geen Node-proces dat 24/7 draait om af en toe een pagina te tonen.
Wanneer je het juist niet doet
Prerendering is geen oplossing voor alles. Een paar duidelijke nee's:
- Pagina's die per gebruiker verschillen (account-dashboard, gepersonaliseerde feed): daar wil je een SPA-modus of echte SSR.
- Content die per minuut wijzigt en niet via een redeploy hoeft te kunnen: denk realtime tickers of chat.
- Pagina's die een gigantisch aantal varianten hebben (miljoenen producten): daar wordt de build-tijd het probleem; dynamische SSR met edge caching is dan beter.
De truc is niet "alles prerenderen", maar weten waar de grens ligt. In de praktijk: marketingsite, blog, docs, productpagina's met beperkte catalogus, alle shells van een SaaS-product. In onze projecten dekt dat het overgrote deel van wat klanten ons vragen te bouwen.
Hoe wij dit aanpakken
Bij Vado Consulting kiezen we wat het beste past bij jouw project. Voor een site die voor iedereen hetzelfde toont, is prerendering vaak een uitstekende kandidaat: geen serverrekening die maandelijks groeit, geen monitoring tool die we niet kunnen missen, geen "waarom crasht SSR nu weer" op een zondagavond. Eén build, één deploy, één CDN. Voor andere projecten kiezen we gewoon iets anders. Het ene project verdient een SPA, het andere een echte backend, een derde een gemixte oplossing. We beslissen samen.
Plan je een rebuild of vraag je je af hoe dit op jouw stack uitdraait?
Stuur ons een berichtje →We lopen graag mee door de afwegingen voor jouw specifieke geval.