JAMstack: alles vooraf klaarzetten in plaats van steeds opnieuw bouwen
Een gewone website bouwt bij elk bezoek een pagina op. De server haalt teksten uit een database, plakt ze in een sjabloon en stuurt het resultaat op. Dat gebeurt duizend keer per dag voor duizend bezoekers die precies hetzelfde te zien krijgen. Dat is werk dat je ook een keer kunt doen.
Dat idee zit achter JAMstack. Je maakt de pagina’s vooraf en zet ze klaar als vaste bestanden.
Ik krijg er af en toe vragen over, meestal van klanten die het ergens hebben opgevangen. Voor het MKB is het zelden de beste keuze, en dat leg ik dan ook eerlijk uit.
De winst zit vooral in snelheid en beveiliging. De prijs zit in beheer en in kosten. Wie zijn eigen teksten wil bijwerken zonder tussenpersoon, is met een gewoon systeem beter af.
Pagina's vooraf klaarzetten in plaats van bij elk bezoek bouwen.
Wat is JAMstack?
JAMstack is een bouwwijze waarbij je pagina’s vooraf klaarzetten als vaste bestanden. De letters staan voor JavaScript, API’s en Markup.
Bij een bezoek hoeft de server niets meer te berekenen. Hij levert een kant-en-klaar bestand af, net zoals hij een afbeelding aflevert.
Waar de inhoud dan staat
Ergens anders. Je teksten kunnen in een los systeem staan dat via een API wordt uitgelezen. Dat noemen we beheer op afstand of headless.
Publiceer je iets, dan draait er een bouwstap die alle pagina’s opnieuw genereert. Pas daarna staat je wijziging online.
Wat het oplevert
Drie dingen, en ze zijn allemaal reeel.
snelheid en beveiliging verbetert, want er wordt niets berekend tijdens een bezoek. Het is de meest extreme vorm van cache die er bestaat.
Je aanvalsoppervlak wordt kleiner. Er draait geen database achter je pagina, dus er valt weinig te misbruiken.
En je site houdt drukte beter aan. Vaste bestanden serveren kost bijna niets, zeker via een CDN.
Wat het kost
De keerzijde die vaak wegvalt in het verhaal
Elke wijziging vraagt een bouwstap, dus je ziet het niet meteen.
Een voorbeeld bekijken voor publicatie is ingewikkelder.
Formulieren, zoeken en reacties vragen extra diensten.
Je hebt vaker een ontwikkelaar nodig voor kleine dingen.
Er zijn minder mensen die ermee kunnen werken.
Dat laatste is een risico dat ondernemers onderschatten. Bij een CMS als WordPress kan bijna elke bouwer verder waar de vorige stopte.
Wanneer is het wel logisch?
Bij een site met veel bezoek en weinig wijzigingen. Documentatie, een nieuwsarchief of een campagnesite die maanden hetzelfde blijft.
Ook bij projecten waar snelheid en beveiliging boven alles gaan, kan het de juiste keuze zijn.
Voor een bedrijfssite die je zelf wilt bijwerken, is het dat zelden. Je koopt dan snelheid die je met goede hosting en caching ook haalt. En je betaalt met beheerbaarheid.
Mijn advies
Kies op basis van wie de site straks beheert. Ben jij dat, en wil je zonder overleg een prijs kunnen aanpassen? Dan is een gewoon systeem beter.
Heb je een ontwikkelteam en verandert je inhoud zelden? Dan is dit een serieuze optie. Meer over de serverkant lees je bij backend.
Wat het beheer betekent in de praktijk
Je past een tekst aan in een los systeem en publiceert. Daarna draait er een bouwstap van tientallen seconden tot enkele minuten.
Voor een tekstwijziging is dat het verschil tussen seconden en minuten. Dat klinkt klein, maar het verandert hoe het voelt om je eigen site te beheren.
Waar de term vandaan komt
De naam is bedacht als tegenhanger van de klassieke opzet met server, database en sjabloon. Inmiddels wordt de term losser gebruikt dan oorspronkelijk bedoeld.
Laat je daarom niet leiden door het woord. Vraag wat er concreet anders is aan bouwen, beheren en onderhouden. Dat gesprek levert meer op dan de afkorting.
Meer vragen over JAMstack
Dit zijn de vragen die ik hierover het vaakst krijg. Ik werk ze los uit.
Wat is JAMstack?
Wat is het verschil tussen JAMstack en WordPress?
Is een JAMstack-website sneller?
Kun je zelf teksten aanpassen bij JAMstack?
Wanneer is JAMstack een goede keuze?
Wat kost een JAMstack-website?
Wat is JAMstack?
Het verschil zit in het moment waarop je pagina wordt gemaakt.
Bij WordPress gebeurt dat op het moment van het bezoek. Bij JAMstack gebeurt dat vooraf, bij het publiceren.
Dat heeft gevolgen voor het beheer. In WordPress pas je een prijs aan, klikt op bijwerken en het staat er. Bij JAMstack start je een bouwstap en wacht je tot die klaar is.
Voor een tekstwijziging is dat een verschil van seconden tegenover minuten. Dat klinkt klein, maar het verandert hoe het voelt om je eigen site te beheren.
Er is nog een verschil dat zwaarder weegt. Bij een CMS kan bijna elke bouwer verder waar de vorige stopte. Bij JAMstack is die groep veel kleiner.
Vraag altijd wie de site straks beheert en hoe een tekstwijziging eruitziet. Dat gesprek zegt meer over de juiste keuze dan welke technische vergelijking ook. Vraag ook hoe lang zo’n bouwstap duurt bij jouw aantal pagina’s.
Wat is het verschil tussen JAMstack en WordPress?
JAMstack is een bouwwijze waarbij je pagina’s vooraf klaarzet als vaste bestanden. De letters staan voor JavaScript, API’s en Markup.
Een gewone website bouwt bij elk bezoek een pagina op. De server haalt teksten uit een database, plakt ze in een sjabloon en stuurt het resultaat op.
Dat gebeurt duizend keer per dag voor duizend bezoekers die precies hetzelfde te zien krijgen. Dat is werk dat je ook een keer kunt doen.
Bij JAMstack hoeft de server bij een bezoek niets meer te berekenen. Hij levert een kant-en-klaar bestand af, net zoals hij een afbeelding aflevert.
Je teksten staan dan vaak in een los systeem dat via een koppeling wordt uitgelezen. Publiceer je iets, dan draait er een bouwstap die alle pagina’s opnieuw genereert. Meer over die koppeling lees je bij API.
Je hoeft deze term niet te kennen om een goede website te hebben. Hij komt vooral langs in gesprekken met bouwers en in offertes waarin techniek wordt verkocht.
Is een JAMstack-website sneller?
In de kern wel. Er wordt niets berekend tijdens een bezoek, dus je server kan direct antwoorden.
Het is de meest extreme vorm van caching die er bestaat. Alles staat al klaar, er hoeft alleen nog verstuurd te worden.
Maar het verschil met een goed ingerichte gewone site is kleiner dan het verhaal suggereert. Met goede hosting, caching en compressie haal je vergelijkbare tijden.
De echte winst zit pas bij zware pieken. Vaste bestanden serveren kost bijna niets, dus je site blijft overeind waar een gewone site het zwaar krijgt.
Voor een bedrijfssite met een paar duizend bezoekers per maand is dat verschil theoretisch. Je koopt dan snelheid die je goedkoper had kunnen krijgen. Meer daarover lees je bij cache.
Meet je huidige laadtijd voordat je iets besluit. Zit je al onder de twee seconden, dan koop je met een verbouwing weinig snelheid en veel gedoe. Doe die meting op een gewone werkdag en niet op een rustig moment.
Kun je zelf teksten aanpassen bij JAMstack?
Ja, maar het voelt anders en het vraagt meer geduld.
Je werkt in een los beheersysteem dat losstaat van je website. Daar pas je je tekst aan en publiceer je.
Daarna start er een bouwstap die alle pagina’s opnieuw genereert. Dat duurt van tientallen seconden tot enkele minuten, afhankelijk van de grootte van je site.
Een voorbeeld bekijken voordat je publiceert is ingewikkelder dan bij een gewoon systeem. Dat is precies waar ondernemers op afknappen.
Daarom stel ik altijd dezelfde vraag: wie beheert de site straks? Ben jij dat, en wil je zonder overleg een prijs kunnen aanpassen? Dan is een gewoon systeem prettiger.
Vraag om een demonstratie van het beheer voordat je akkoord gaat. Tien minuten meekijken vertelt je meer dan een hele uitleg over de techniek. Laat ook iemand anders uit je team meekijken tijdens die demonstratie. Vraag daarbij ook wat er gebeurt als de bouwstap een keer misgaat.
Wanneer is JAMstack een goede keuze?
Bij een site met veel bezoek en weinig wijzigingen. Dan valt de bouwstap niet op en profiteer je maximaal van de snelheid.
Denk aan documentatie, een nieuwsarchief of een campagnesite die maanden hetzelfde blijft. Ook bij projecten waar beveiliging boven alles gaat, kan het de juiste keuze zijn.
Er draait namelijk geen database achter je pagina’s, dus er valt weinig te misbruiken. Dat maakt je aanvalsoppervlak aanzienlijk kleiner.
Voor een gewone bedrijfssite die je zelf wilt bijwerken, is het zelden de beste keuze. Je betaalt met beheerbaarheid en met afhankelijkheid van een kleinere groep bouwers.
Kies dus op basis van wie de site beheert en hoe vaak je inhoud verandert. Niet op basis van wat er technisch indrukwekkend klinkt.
Kies op basis van hoe vaak je inhoud verandert en wie hem beheert. Niet op basis van wat er technisch indrukwekkend klinkt in een presentatie. Schrijf je afweging op, dan kun je hem over twee jaar nog terugvinden.
Heeft iemand je een moderne bouwwijze aangeraden en twijfel je of dat bij jou past? Beschrijf je situatie via het formulier hieronder. Ik kijk naar hoe vaak je inhoud verandert en wie hem beheert, en geef een eerlijk advies. Ook als dat betekent dat je bij je huidige opzet blijft. Vermeld je plaats, dan weet ik meteen waar je zit.
Waar kan ik je mee helpen?
Ook bekend als: Static site, headless, vooraf gegenereerde site
