Websites bouwen we al heel lang op ongeveer dezelfde manier. Ergens staat een server. Daarop draait een CMS. Een bezoeker vraagt een pagina op, de server gaat aan het werk, haalt informatie uit een database, voert code uit en bouwt daar een webpagina van.
Dat model werkt. Ik bouw er al jaren websites mee. Maar de vraag is of iedere website dat allemaal nog nodig heeft.
Voor antal.studio experimenteer ik daarom met een andere manier van bouwen. Ik ontwerp en beheer de website in Etch, maar wat jij als bezoeker te zien krijgt, wordt gepubliceerd via Cloudflare. Dat klinkt als een technisch detail. Dat is het niet. Het verandert behoorlijk fundamenteel wat een website eigenlijk is.
Moet een website altijd een applicatie zijn?
Neem een website van een adviesbureau, advocaat, fotograaf of creatief bureau. Je bezoekt de homepage, leest wat ze doen, bekijkt een case, misschien lees je een artikel en klikt uiteindelijk op contact.
Waarom zou er voor ieder bezoek aan zo'n pagina opnieuw een complete applicatie wakker moeten worden? Waarom moet er PHP-code worden uitgevoerd, een database worden geraadpleegd en van alles bij elkaar worden gebouwd voor een pagina die gisteren inhoudelijk precies hetzelfde was?
Het alternatief is verrassend eenvoudig: bouw de pagina één keer en publiceer het eindresultaat. HTML, CSS, JavaScript, afbeeldingen. Klaar. Cloudflare kan zulke statische bestanden rechtstreeks vanuit zijn wereldwijde netwerk serveren, zonder dat er eerst een traditionele webserver aan te pas komt. Dat maakt een website ineens een stuk simpeler, en simpel is vaak heel aantrekkelijk.
Minder bewegende onderdelen
Een traditionele WordPress-website is een indrukwekkend samenspel van onderdelen: WordPress, PHP, een database, een theme, plugins, caching, een webserver, updates, beveiliging. Dat geeft veel mogelijkheden, maar iedere laag die je toevoegt is ook een laag die onderhouden moet worden en waar iets fout kan gaan.
Bij een statisch gepubliceerde website ziet de publieke kant er heel anders uit. De bezoeker vraagt een pagina en krijgt die pagina. Geen databasequery om de tekst van mijn homepage op te zoeken, geen PHP die de pagina nog moet samenstellen. En als iets niet nodig is om een website aan bezoekers te tonen, hoeft het daar ook niet voor open te staan. Dat laatste vind ik minstens zo interessant als snelheid.
Snelheid zonder een halve gereedschapskist
We zijn gewend geraakt aan het optimaliseren van websites: cachingplugins, servercaching, object caching, CDN's, minification, database-optimalisatie. Allemaal oplossingen voor problemen die voor een deel ontstaan doordat we een dynamisch systeem gebruiken om relatief statische informatie te presenteren.
Wat als je een deel van die complexiteit gewoon wegneemt? Cloudflare serveert statische bestanden vanuit zijn wereldwijde infrastructuur, met ondersteuning voor moderne compressie. Dat betekent niet automatisch dat iedere statische website razendsnel is. Je kunt nog steeds enorme afbeeldingen uploaden, beroerde JavaScript schrijven en je pagina volstoppen met externe scripts. Maar de uitgangspositie is bijzonder prettig. Performance wordt minder iets dat je achteraf moet repareren en zit veel meer in de architectuur zelf.
En dan de veiligheid
Dit is misschien wel het onderdeel dat mij het meest aanspreekt. Een publieke WordPress-website is een draaiende applicatie. Die moet bereikbaar zijn om zijn werk te kunnen doen, en dat betekent ook dat bots ermee kunnen praten: loginpagina's proberen, endpoints benaderen, kwetsbaarheden in WordPress, themes of plugins proberen te misbruiken.
Bij een statische website kan dat aan de publieke kant fundamenteel anders zijn. Staat daar alleen het gepubliceerde eindresultaat, dan valt er veel minder aan te vallen. Cloudflare beschrijft zelf een architectuur waarbij WordPress wordt gebruikt om de site te beheren, waarna een statische versie op Cloudflare wordt gepubliceerd. Het CMS en de website die bezoekers daadwerkelijk zien, hoeven dus niet dezelfde omgeving te zijn. Het CMS is de werkplaats. Niet noodzakelijk de website.
Maar doet een website niet meer?
Zeker. En precies daar zit de grens van dit verhaal. Een statische architectuur is geen wondermiddel en zeker niet voor iedere website de juiste oplossing.
Een site die vooral bestaat uit pagina's, cases, artikelen en informatie is een uitstekende kandidaat: corporate websites, websites van consultants en adviesbureaus, portfolio's, advocaten- en accountantskantoren, campagne- en landingspagina's, kenniswebsites, blogs, eenvoudige leadgeneratie.
Daar staat tegenover dat sommige websites juist leven van dynamiek. Een webshop moet weten wat er in je winkelmandje zit. Een leeromgeving moet weten wie je bent en welke lessen je hebt gevolgd. Een boekingssysteem moet actuele beschikbaarheid kennen. Een community heeft accounts, rechten en voortdurend veranderende informatie. Dan heeft een server of andere vorm van backendlogica ineens wél een functie.
En zelfs daar is de grens niet meer zwart-wit. Cloudflare biedt met Workers en Functions de mogelijkheid om server-side code alleen uit te voeren waar die daadwerkelijk nodig is. Formulierafhandeling, authenticatie en andere dynamische functies kunnen daardoor naast statische pagina's bestaan, zonder dat iedere pagina onderdeel hoeft te zijn van een traditionele serverapplicatie.
Dat maakt de discussie interessanter dan statisch versus dynamisch. De vraag wordt: welk deel moet dynamisch zijn? Niet alles hoeft WordPress te zijn. Niet alles hoeft statisch te zijn.
Ik ben niet klaar met WordPress
Voor complexe websites kan WordPress juist fantastisch zijn. WooCommerce, geavanceerde formulieren, gebruikersaccounts, boekingen, koppelingen, grote hoeveelheden gestructureerde content: er zijn genoeg situaties waarin een dynamisch CMS precies het gereedschap is dat ik wil hebben.
Maar ik wil ook niet meer automatisch een complete dynamische infrastructuur inzetten omdat dat nu eenmaal is hoe we websites bouwen. Als een organisatie in essentie een geweldige website nodig heeft die informatie publiceert, waarom zou ik daar dan meer techniek achter zetten dan noodzakelijk? Dat is een andere manier van denken. Niet beginnen met het gereedschap, maar met wat de website moet doen.
antal.studio als proefkonijn
Deze website is mijn eerste serieuze experiment met deze manier van werken. Het is bij uitstek een website waarop ik dat kan onderzoeken: design en typografie mogen de hoofdrol spelen, de inhoud moet razendsnel beschikbaar zijn, en er is geen winkelmandje, klantportaal of ingewikkeld gebruikersaccount nodig. Wel cases, artikelen, informatie en contact.
Precies het soort website waarbij ik mezelf de vraag kan stellen: hoeveel techniek heb ik eigenlijk nodig om iets heel goeds te maken?
Ik bouw de site momenteel met Etch. Daarbij onderzoek ik niet alleen hoe prettig het ontwerpproces is, maar ook wat er gebeurt wanneer de traditionele koppeling tussen CMS, server en publieke website verdwijnt. Wat betekent dat voor performance, beveiliging, onderhoud, SEO, formulieren en analytics? En misschien nog interessanter: wat betekent het voor de websites die ik de komende jaren voor klanten bouw?
Ik weet het antwoord nog niet op iedere vraag. Dat is precies waarom ik het doe. Na ruim twintig jaar websites bouwen vind ik het bijzonder leuk dat er weer iets te ontdekken valt.
Nieuwe werkelijkheid. Nieuwe kansen. Nieuwe techniek. En antal.studio mag als eerste mee.