In de beginjaren van het internet bestonden websites uit losse HTML-bestanden, handgemaakt door ontwikkelaars. Al snel kwamen er hulpmiddelen zoals template-engines – zoals Twig – waarmee je vanuit een CMS (Content Management Systeem) automatisch pagina’s kon genereren. Dit was efficiënt en overzichtelijk: elke klik van een website bezoeker op een link leverde een nieuwe pagina vanuit de server.
Van Strapi naar Statamic en van Vue naar Antlers (SPA vs SSR)
Afbeelding: een visuele weergave van hoe templates de samenwerking tussen mens en systeem ondersteunen.
Een stukje geschiedenis: van server naar browser
In de beginjaren van het internet bestonden websites uit losse HTML-bestanden, handgemaakt door ontwikkelaars. Al snel kwamen er hulpmiddelen zoals template-engines – zoals Twig – waarmee je vanuit een CMS (Content Management Systeem) automatisch pagina’s kon genereren. Dit was efficiënt en overzichtelijk: elke klik van een website bezoeker op een link leverde een nieuwe pagina vanuit de server.
De opkomst van de Single Page Application (SPA)
Met de tijd wilden we snellere en meer dynamische websites. Zo ontstond de Single Page Application (SPA): een techniek waarbij je slechts één keer een pagina laadt, waarna alles binnen de browser gebeurt. Denk aan apps als Gmail of Trello. In plaats van steeds een nieuwe pagina op te vragen bij de server, blijft de site staan en verandert de inhoud via JavaScript.
Om dit mogelijk te maken, splitsten ontwikkelaars de website op in twee delen: een ‘frontend’ (de voorkant) gebouwd in frameworks zoals Vue of React, en een ‘backend’ dat via API’s informatie aanlevert, vaak via een ‘headless CMS’ zoals Strapi.
Waarom SPI niet altijd de beste oplossing is
Er zijn situaties waarin een SPI juist wél de juiste keuze is. Denk aan complexe webapplicaties, interactieve dashboards of tools waarbij gebruikerservaring en snelheid centraal staan. In dat soort gevallen kan een SPI een solide technische basis bieden.
Hoewel Single Page Applications indrukwekkend zijn qua snelheid en gebruikerservaring, zijn er ook duidelijke nadelen:
Browsers doen het zware werk: In plaats van dat de server een kant-en-klare pagina aanlevert, moet de browser alles zelf opbouwen. Dat kan zorgen voor vertraging bij het eerste bezoek of op oudere apparaten.
JavaScript is niet altijd betrouwbaar: Omdat SPI's sterk leunen op JavaScript, kan een klein scriptfoutje of een mislukte API-aanroep al leiden tot een gebroken pagina of incomplete content. Dit maakt foutafhandeling en testen cruciaal, maar ook complex.
SEO-problemen: Zoekmachines zoals Google houden van duidelijke, goed gestructureerde HTML-pagina’s. SPI’s leveren vaak lege pagina’s aan en vullen deze pas in met JavaScript. Dat maakt het lastiger om goed gevonden te worden in zoekresultaten.
Meer complexiteit: Je moet niet alleen een frontend én backend onderhouden, maar ook zorgen dat ze goed met elkaar praten. Dat vraagt meer kennis, meer tijd en meer budget.
Waarom dan toch kiezen voor statische sites en slimme CMS’en
De afgelopen jaren zien we een tegenbeweging. Er is opnieuw aandacht voor eenvoud, snelheid en goede SEO. CMS’en zoals Statamic of OctoberCMS bieden het beste van beide werelden: dynamisch waar nodig, maar met server-side rendering en snelle laadtijden. Bovendien zijn ze toegankelijker voor redacteuren.
Voor veel websites is een SPI overkill. Een goed opgebouwde, klassieke site met server-side rendering is vaak sneller, betrouwbaarder en beter vindbaar én eenvoudiger te beheren.
Onze ervaring bij Key Agency
Binnen Key Agency zijn we altijd op zoek naar oplossingen om onze werkwijze te verbeteren en te versnellen. Onze eerste versie van de Key Agency website was opgebouwd als een Single Page Interface met Strapi en Vue. Dit betekende dat we twee aparte codebases moesten beheren: een voor de frontend en een voor de backend. Dat maakte ontwikkeling en onderhoud onnodig complex. Bovendien merkten we dat onze redacteuren onze SEO niet goed konden beheren, doordat contentbeheer minder inzichtelijk en minder direct beïnvloedbaar was.
Daarbij kwamen regelmatig problemen naar voren bij het upgraden van Strapi, het headless CMS dat we gebruikten. Dit leidde tot vertragingen en extra werk. Daarom hebben we besloten terug te gaan naar één systeem met server-side rendering. Met Statamic kunnen we eenvoudiger werken, sneller ontwikkelen en toch dynamische functionaliteit behouden met een stabiele en betrouwbare basis.
Conclusie: techniek in dienst van de inhoud
Bij het maken van een website is het verleidelijk om de nieuwste technieken in te zetten, maar dat is niet altijd de juiste keuze. Vraag je bij elk project af: wat heeft deze site écht nodig? Soms is eenvoud – met één goed doordacht systeem – veel slimmer dan een complexe architectuur. Voor ons was de overstap naar Statamic precies dat: een stap terug die voelde als een stap vooruit.
Wil je weten welk CMS het beste bij jouw organisatie past? Neem contact op met Remko van Key Agency voor een vrijblijvend adviesgesprek.
Projecten met Statamic: Siblu, Foldam, Team1001, Key Agency