{"id":65102,"date":"2026-03-27T10:30:43","date_gmt":"2026-03-27T09:30:43","guid":{"rendered":"https:\/\/kinsta.com\/nl\/?p=65102&preview=true&preview_id=65102"},"modified":"2026-04-02T10:56:39","modified_gmt":"2026-04-02T08:56:39","slug":"blokthemas-wordpress-hosting","status":"publish","type":"post","link":"https:\/\/kinsta.com\/nl\/blog\/blokthemas-wordpress-hosting\/","title":{"rendered":"Waarom moderne blokthema\u2019s WordPress-hosting veranderen"},"content":{"rendered":"

Managed WordPress-hosting is er om WordPress goed te laten draaien. Het biedt een omgeving die perfect is afgestemd op hoe WordPress zich gedraagt onder belasting, hoe het omgaat met caching<\/a> en hoe het PHP uitvoert.<\/p>\n

Blokthema\u2019s<\/a> veranderen niets aan de basisprincipes van hosting, maar ze veranderen wel waar prestatieknelpunten ontstaan. En daar wordt de rol van de webhost duidelijker. Infrastructuur alleen maakt een site nog niet snel. Wanneer infrastructuur slecht is afgestemd, wordt dit pijnlijk duidelijk in moderne WordPress-workflows, vooral als er dynamische blokken, de Site Editor<\/a>, previews en ingelogde sessies bij betrokken zijn.<\/p>\n

Om te begrijpen waarom, helpt het om te kijken naar wat er daadwerkelijk gebeurt tijdens een paginaverzoek en hoe hostingbeslissingen de gebruikerservaring be\u00efnvloeden wanneer een op blokken gebaseerde architectuur wordt gebruikt.<\/p>\n

<\/div><\/kinsta-auto-toc>\n

Wat gebeurt er als een WordPress-pagina wordt opgevraagd<\/h2>\n

Laten we eens kijken naar een eenvoudig verzoek dat een 200 OK-respons<\/a> oplevert.<\/p>\n

1. De browser verstuurt het verzoek<\/h3>\n

Een gebruiker voert een URL in of klikt op een link. Als het IP-adres van de server nog niet in de cache staat, voert de browser een DNS-lookup<\/a> uit. Vervolgens opent hij een TCP-verbinding en onderhandelt hij over een beveiligde TLS-sessie<\/a>.<\/p>\n

Voordat WordPress erbij betrokken raakt, gaat het verzoek door de webserver en eventuele geconfigureerde lagen zoals firewalls of reverse proxies.<\/p>\n

2. Cachecontrole<\/h3>\n

De server controleert of er een geldige cacheversie van de opgevraagde pagina bestaat.<\/p>\n

Als er een volledige HTML-cache<\/a> beschikbaar en geldig is, wordt WordPress niet uitgevoerd. Het cache-antwoord wordt onmiddellijk teruggestuurd.<\/p>\n

Als er geen cache-item bestaat, of als caching opzettelijk wordt omzeild voor ingelogde gebruikers, previews of specifieke eindpunten, gaat het verzoek verder naar WordPress.<\/p>\n

3. WordPress wordt geactiveerd<\/h3>\n

WordPress laadt zijn kernbestanden, actieve plugins en het actieve thema. Het initialiseert hooks en maakt zich klaar om het verzoek af te handelen.<\/p>\n

In dit stadium geeft WordPress nog geen uitvoer weer. Het verzoek bepaalt welke inhoud er wordt aangevraagd.<\/p>\n

4. Verwerking van de hoofdquery<\/h3>\n

Met behulp van herschrijfregels en queryvariabelen bouwt en voert WordPress de hoofddatabasequery uit. Het bepaalt of het verzoek voor een enkel bericht, een pagina, een archief, een zoekresultaat of een ander inhoudstype is.<\/p>\n

Pas daarna begint de templatekeuze.<\/p>\n

5. Templateverwerking<\/h3>\n

Hier beginnen blok- en klassieke thema’s structureel van elkaar te verschillen.<\/p>\n

Klassieke thema’s<\/h4>\n

WordPress evalueert de templatehi\u00ebrarchie en selecteert het juiste PHP-templatebestand, zoals single.php, page.php of archive.php. Dat bestand bevat PHP-logica die direct HTML uitvoert.<\/p>\n

Blokthema’s<\/h4>\n

WordPress controleert of er een aangepaste bloktemplate in de database staat. Als die er is, krijgt die voorrang. Zo niet, dan valt WordPress terug op het bloktemplatebestand dat in het thema zit, zoals single.html of index.html.<\/p>\n

De geselecteerde template wordt vervolgens verwerkt via het blokweergavesysteem.<\/p>\n

6. Lay-out samenstellen<\/h3>\n

Klassieke thema’s<\/h4>\n

De lay-out wordt opgebouwd via PHP-templates. Deze templates combineren markup, logica en functieaanroepen om HTML-uitvoer te genereren.<\/p>\n

Blokthema’s<\/h4>\n

De lay-out wordt samengesteld uit blok-templates, templatedelen en berichtinhoud. De opmaak van de blokken wordt geparseerd en elk blok wordt omgezet naar HTML voordat de uiteindelijke uitvoer wordt gegenereerd.<\/p>\n

7. Inhoudsstructuur<\/h3>\n

Klassieke thema’s<\/h4>\n

Berichtinhoud wordt voornamelijk als HTML in de database opgeslagen. Tijdens de uitvoer past WordPress filters, shortcodes en andere bewerkingen toe voordat de inhoud wordt weergegeven.<\/p>\n

Blokthema’s<\/h4>\n

Blokinhoud wordt opgeslagen als HTML met ingebedde blokmetadata, bijvoorbeeld:<\/p>\n

<!-- wp:image {\"id\":123} -->\n\n<img src=\"logo.png\">\n\n<!-- \/wp:image --><\/code><\/pre>\n
Wanneer WordPress deze inhoud verwerkt, parseert het de blokstructuur, begrijpt het attributen en nesting, en past het attributen en stijlen op blokniveau toe, zoals spati\u00ebring, uitlijning en typografie, voordat de uiteindelijke HTML wordt gegenereerd.<\/p>\n
8. Dynamische weergave<\/h3>\n
Dynamische weergave komt zowel in klassieke als in blokthema\u2019s voor. Veel klassieke thema\u2019s maken gebruik van aangepaste queries, widgets of shortcodes die tijdens het uitvoeren output genereren.<\/p>\n
In op blokken gebaseerde architecturen wordt dynamisch gedrag geformaliseerd via dynamische blokken. Een Query Loop-blok genereert bijvoorbeeld zijn markup tijdens het verzoek met behulp van PHP, in plaats van statische HTML in de database op te slaan.<\/p>\n
Wanneer caching van volledige pagina’s wordt omzeild, vindt deze weergaveworkflow bij elk verzoek plaats.<\/p>\n
9. Styling<\/h3>\n
Bij klassieke thema\u2019s wordt styling meestal geleverd via statische CSS-bestanden<\/a> die door het thema in de wachtrij worden geplaatst.<\/p>\n
Bij blokthema\u2019s zorgen globale stijlen die zijn gedefinieerd in theme.json<\/code> en blokmetadata ervoor dat WordPress automatisch consistente CSS kan genereren. Dit vermindert de behoefte aan grote, handgemaakte stylesheets en centraliseert de ontwerpconfiguratie.<\/p>\n
10. Eindresultaat<\/h3>\n
Nadat templates, inhoud, blokken en stijlen zijn verwerkt, produceert WordPress de uiteindelijke HTML-respons.<\/p>\n
De server stuurt de payload naar de browser. Indien geconfigureerd, kan de respons vervolgens worden gecachet voor toekomstige verzoeken.<\/p>\n
Waar blokthema\u2019s de belasting verplaatsen<\/h2>\n
De verzoekcyclus die je zojuist hebt doorlopen, geldt voor zowel klassieke als blokthema’s<\/a>. WordPress lost nog steeds query’s op, selecteert templates, voert PHP uit en retourneert HTML.<\/p>\n
Wat verandert bij blokthema’s is niet de basis, maar waar het werk plaatsvindt en wanneer het niet kan worden overgeslagen.<\/p>\n
Ten eerste kunnen templates<\/a> in de database staan. Wanneer een gebruiker een template bewerkt in de Site Editor, slaat WordPress die versie op en geeft deze voorrang boven het bestand in de themamap. Dit zorgt voor meer flexibiliteit, maar het betekent ook dat bij implementaties en het ongeldig maken van de cache rekening moet worden gehouden met templates die in de database zijn opgeslagen.<\/p>\n
Ten tweede maken dynamische blokken<\/a> runtime-rendering zichtbaarder. Klassieke thema\u2019s kunnen dynamische output genereren via aangepaste queries, widgets of shortcodes. Blokthema\u2019s formaliseren dit patroon via dynamische blokken, zoals het Query Loop-blok. Wanneer caching van volledige pagina\u2019s wordt omzeild, voeren deze blokken PHP uit tijdens het verzoek.<\/p>\n
Ten derde zijn de workflows van de editor sterk afhankelijk van REST-eindpunten. Het opslaan van templates, het bijwerken van globale stijlen, het bekijken van een voorbeeld van wijzigingen en het werken met patronen genereren niet-gecachete verzoeken. Deze paden zijn direct afhankelijk van PHP-uitvoering, databaseprestaties en objectcaching.<\/p>\n
Ten slotte centraliseren globale stijlen die in theme.json<\/a><\/code> zijn gedefinieerd de ontwerpbeslissingen. Wanneer stijlen of templatestructuren veranderen, wordt cacheco\u00f6rdinatie belangrijker om ervoor te zorgen dat bezoekers en redacteuren de bijgewerkte uitvoer onmiddellijk zien.<\/p>\n
Geen van deze veranderingen vereist een ander type hosting. Ze maken bepaalde zwakke punten in de infrastructuur wel duidelijker zichtbaar, vooral in scenario\u2019s zonder cache en bij ingelogde gebruikers.<\/p>\n
Met dat in gedachten is de volgende stap om te kijken wat een goed geconfigureerde hostingomgeving moet kunnen in een op blokken gebaseerde opzet.<\/p>\n
Overwegingen voor hosting van op blokken gebaseerde sites<\/h2>\n
Blokthema\u2019s stellen geen nieuwe hostingvereisten. Ze maken het wel belangrijker om de bestaande goed te regelen.<\/p>\n
Een goed geconfigureerde omgeving moet rekening houden met zowel gecachete als niet-gecachete paden, vooral voor redacteuren en ingelogde gebruikers.<\/p>\n
Geco\u00f6rdineerde caching over verschillende lagen<\/h3>\n
Caching van volledige pagina’s<\/a> blijft de meest effectieve prestatielaag voor anoniem verkeer. Openbare pagina’s moeten agressief in de cache worden opgeslagen, terwijl previews, ingelogde sessies en specifieke eindpunten automatisch worden omzeild.<\/p>\n
Objectcaching<\/a> speelt ook een belangrijke rol. Door herhaalde queryresultaten en berekende datastructuren in het geheugen op te slaan, vermindert een objectcache de belasting van de database en verbetert het de responsiviteit van zowel de frontend als de backend.<\/p>\n
Het ongeldig maken van de cache moet worden geco\u00f6rdineerd. Wanneer inhoud, templates of algemene stijlen worden bijgewerkt, moeten gerelateerde pagina’s onmiddellijk worden vernieuwd. Slechte cacheco\u00f6rdinatie kan leiden tot verouderde lay-outs, inconsistente stijlen of verwarrend preview-gedrag.<\/p>\n
Een CDN vult deze opzet aan door statische assets zoals afbeeldingen, lettertypen en scripts dichter bij de bezoekers te cachen.<\/p>\n
Caching<\/a> gaat niet over \u00e9\u00e9n laag. Het gaat erom hoe deze lagen samenwerken.<\/p>\n
PHP-capaciteit en runtime-prestaties<\/h3>\n
Wanneer caching van volledige pagina’s wordt omzeild, voert WordPress PHP uit om query’s op te lossen, templates weer te geven en dynamische blokken te verwerken.<\/p>\n
Dit maakt PHP-capaciteitsplanning belangrijk. De omgeving moet voldoende PHP-threads<\/a> bieden om de verwachte gelijktijdigheid aan te kunnen zonder dat er wachtrijen ontstaan. Geheugenlimieten<\/a> moeten zo worden geconfigureerd dat er bij hoge belasting geen swapping plaatsvindt.<\/p>\n
OPcache moet worden ingeschakeld en op de juiste grootte worden ingesteld, zodat PHP-bytecode niet herhaaldelijk opnieuw hoeft te worden gecompileerd. Tijdens implementaties moet OPcache worden vernieuwd, zodat bijgewerkte code onmiddellijk wordt uitgevoerd.<\/p>\n
Deze werkwijzen gelden voor alle WordPress-sites, maar bij blokgebaseerde workflows kunnen prestatieproblemen duidelijker merkbaar zijn wanneer het weergeven dynamisch is.<\/p>\n
Database- en objectcaching<\/h3>\n
Bloktemplates die in de Site Editor zijn aangepast, worden opgeslagen in de database. Blokinhoud bevat gestructureerde metadata die WordPress parseert voordat deze wordt weergegeven. Hoewel deze verwerking effici\u00ebnt is, is deze nog steeds afhankelijk van de responsiviteit van de database wanneer caching wordt omzeild.<\/p>\n
Een permanente objectcache vermindert herhaalde query’s en helpt de prestaties te stabiliseren voor zowel frontend-bezoekers als redacteuren die in het dashboard werken.<\/p>\n
Observability en monitoring<\/h3>\n
Naarmate meer activiteiten naar runtime-paden verschuiven, wordt zichtbaarheid steeds belangrijker. Hosts en site-eigenaren moeten het volgende monitoren:<\/p>\n