WordPress website
laten bouwen met vakmanschap.

Waarom bouwen iets anders is dan samenstellen

De meeste WordPress websites in Nederland worden niet gebouwd. Ze worden samengesteld. Een theme uit een marketplace, een pagebuilder als tussenlaag, een handvol plugins die elk een stukje functionaliteit toevoegen. Het eindresultaat functioneert, tot op zekere hoogte. Maar het is geen bouwwerk. Het is een stapeling van onderdelen die nooit voor elkaar bedoeld waren, bijeengehouden door hoop en compatibiliteit.

Bouwen, in de echte betekenis van het woord, begint met een leeg bestand. Het begint met de vraag: wat moet deze website doen, voor wie, en hoe bereiken we dat met zo min mogelijk code en zo veel mogelijk controle? Pas als die vragen beantwoord zijn, schrijven we de eerste regel. Dat is de filosofie die elke WordPress website die wij opleveren doordrenkt. Niet meer code dan nodig. Niet minder dan optimaal. Precies wat het project vraagt, handgeschreven en doordacht.

In de bouwwereld zou niemand accepteren dat een aannemer prefab wanden tegen elkaar plakt en het een huis noemt. In webdevelopment is dat helaas de standaard geworden. Wij kiezen bewust voor het ambacht. Niet omdat het sneller is, niet omdat het goedkoper is, maar omdat het resultaat fundamenteel beter is. Op elk meetbaar criterium: snelheid, veiligheid, onderhoudbaarheid, levensduur en controle.

Performance engineering: hoe wij sub-seconde laadtijden bereiken

Een snelle website is geen toevalligheid en geen kwestie van een caching plugin installeren. Het is het resultaat van tientallen technische beslissingen die samen zorgen voor een totaalervaring waarin elke pagina in minder dan een seconde volledig geladen is. Hier is hoe we dat bereiken, op codeniveau.

Critical rendering path optimalisatie

De critical rendering path is het pad dat de browser aflegt van het ontvangen van de eerste byte HTML tot het tonen van de eerste pixel op het scherm. Hoe korter dat pad, hoe sneller de pagina zichtbaar is voor de bezoeker. Wij optimaliseren dat pad door critical CSS inline te plaatsen in de head van het document. Dat zijn de stijlen die nodig zijn om de bovenste zichtbare helft van de pagina te renderen, de above the fold content. De rest van de CSS laden we asynchroon met rel="preload" en een onload fallback. JavaScript dat niet direct nodig is voor de initiële render wordt deferred geladen of krijgt het async attribuut. Fonts worden gepreload met font-display: swap zodat de tekst direct zichtbaar is, ook als het font nog onderweg is.

Server-side caching strategie

Onze WordPress hosting draait op LiteSpeed met objectcaching via Redis. Maar caching is niet simpelweg een schakelaar die je aanzet. Het vereist een theme dat compatibel is met full page caching, dat geen willekeurige PHP variabelen in de HTML mixt en dat dynamische elementen correct afhandelt via Edge Side Includes of JavaScript hydration. Onze themes zijn gebouwd met caching als uitgangspunt. Geen PHP die bij elke paginaload opnieuw uitgevoerd wordt voor statische elementen. Geen nocache headers waar ze niet nodig zijn. Het resultaat is een Time to First Byte van gemiddeld 80 tot 150 milliseconden, waar een niet-gecachede WordPress installatie gemiddeld op 800 tot 1200 milliseconden zit.

Afbeeldingsoptimalisatie op meerdere niveaus

Afbeeldingen zijn verantwoordelijk voor gemiddeld 60 tot 70 procent van het totale gewicht van een webpagina. Onze aanpak: automatische conversie naar WebP formaat met een AVIF fallback waar ondersteund. Responsive images via het srcset attribuut zodat mobiele apparaten niet dezelfde 2000 pixels brede afbeelding laden als een desktop scherm. Lazy loading met de native loading="lazy" attribuut voor alle afbeeldingen buiten de initiële viewport, gecombineerd met fetchpriority="high" voor de Largest Contentful Paint afbeelding. Aspect ratio attributen op elk img element om layout shifts te voorkomen. Width en height definiëren we altijd, zodat de browser ruimte reserveert voordat de afbeelding geladen is. Die combinatie levert een Cumulative Layout Shift van 0 op, wat rechtstreeks bijdraagt aan een hogere Google ranking.

Resource hints en preloading

Moderne browsers ondersteunen resource hints die de laadstrategie verbeteren: dns-prefetch voor domeinen waar de pagina naar linkt, preconnect voor domeinen waar direct resources van geladen worden en preload voor kritieke bestanden die zo snel mogelijk beschikbaar moeten zijn. Wij configureren deze hints specifiek per pagina op basis van welke resources die pagina daadwerkelijk nodig heeft. Geen generieke lijst met preloads die op elke pagina geladen wordt, maar gerichte hints die de browser helpen om de juiste prioriteiten te stellen. In combinatie met HTTP/2 multiplexing en onze LiteSpeed configuratie levert dat een waterfall diagram op waar vrijwel alle resources parallel geladen worden, zonder onnodige round trips.

Core Web Vitals als meetlat

Google meet de gebruikerservaring van websites via drie Core Web Vitals: Largest Contentful Paint (hoe snel de grootste content verschijnt), Cumulative Layout Shift (hoe stabiel de pagina is tijdens het laden) en Interaction to Next Paint (hoe snel de pagina reageert op interactie). Onze WordPress websites scoren consistent in de groene zone op alle drie de metrics. Niet omdat we achteraf optimaliseren tot de scores kloppen, maar omdat de scores het natuurlijke resultaat zijn van hoe we bouwen. Als je begint met schone code, minimale resources en een doordachte laadstrategie, volgen goede Core Web Vitals vanzelf. Bij pagebuilder sites is het andersom: je begint met een zwaar framework en probeert achteraf de impact te beperken met caching plugins en lazy loading trucs. Dat werkt tot op zekere hoogte, maar het is bestrijding van symptomen in plaats van het wegnemen van de oorzaak.

Beveiliging op codeniveau en toekomstbestendigheid

Een WordPress website beveiligen is meer dan een security plugin installeren en hopen dat het goed komt. Echte beveiliging begint in de code zelf, bij elke functie die data verwerkt, bij elke query die de database raakt en bij elke actie die een gebruiker kan uitvoeren. Hier is hoe wij beveiliging inbouwen op het niveau waar het thuishoort.

Prepared statements voor database queries

SQL injection is een van de oudste en meest voorkomende aanvalstechnieken op webapplicaties. Het principe is simpel: een aanvaller voegt SQL code in via een invoerveld, en als de applicatie die input ongefilterd in een database query stopt, kan de aanvaller data lezen, wijzigen of verwijderen. De verdediging is even simpel: prepared statements. WordPress biedt de wpdb::prepare methode die placeholders gebruikt in plaats van directe string concatenatie. Wij gebruiken prepared statements voor elke custom database query, zonder uitzondering. Het is een absolute regel in onze codebase: geen enkele variabele van buitenaf komt ooit direct in een SQL query terecht.

Nonce verificatie voor formulieren en AJAX

Nonces in WordPress zijn eenmalige tokens die verifiëren dat een actie uitgevoerd wordt door een geautoriseerde gebruiker via het verwachte formulier of endpoint. Zonder nonce verificatie kan een kwaadwillige website een verzoek doen namens een ingelogde gebruiker. Dat heet cross-site request forgery en het is verrassend eenvoudig uit te voeren op websites die geen nonces gebruiken. Wij genereren nonces voor elk formulier en elke AJAX call, verifiëren ze server-side met wp_verify_nonce en weigeren elk verzoek dat de verificatie niet doorstaat. Het is een extra stap in de code die een groot verschil maakt in de beveiliging.

Capability checks voor admin functies

WordPress heeft een uitgebreid rollen- en rechtensysteem. Niet elke ingelogde gebruiker mag dezelfde dingen doen. Een redacteur mag content bewerken maar geen plugins installeren. Een abonnee mag een profiel bewerken maar geen pagina's publiceren. Wij controleren bij elke actie of de huidige gebruiker de juiste rechten heeft via current_user_can. Custom admin pagina's, custom REST API endpoints en custom AJAX handlers: ze bevatten allemaal een capability check voordat ze een actie uitvoeren. Het voorkomt dat een gebruiker met beperkte rechten per ongeluk of opzettelijk functies bereikt die niet voor hen bedoeld zijn.

Toekomstbestendigheid door standaarden

WordPress brengt meerdere keren per jaar updates uit. Major versies voegen nieuwe functies toe en wijzigen soms de manier waarop het platform werkt. Themes die gebouwd zijn met shortcuts, deprecated functies of directe database manipulatie breken bij zulke updates. Onze themes gebruiken uitsluitend de officiële WordPress API's en functies. Geen directe $wpdb queries waar een WordPress functie beschikbaar is. Geen directe bestandsmanipulatie waar de WordPress Filesystem API gebruikt kan worden. Geen hardcoded paden waar WordPress constanten bestaan. Die discipline betekent dat onze themes compatibel blijven met toekomstige WordPress versies zonder aanpassingen. We hebben themes draaien die vijf jaar geleden zijn gebouwd en die na elke WordPress update feilloos blijven functioneren.

Het contrast met een pagebuilder website

Een Elementor of Divi website is afhankelijk van een jaarlijkse licentie. Als je stopt met betalen, krijg je geen updates meer. Geen updates betekent geen beveiligingspatches. Het betekent ook dat bij een WordPress major update de pagebuilder mogelijk niet meer compatibel is. Je bent overgeleverd aan het updateschema van een commercieel bedrijf. Bij een custom theme heb je die afhankelijkheid niet. De code is van jou, volgt WordPress standaarden en is niet gekoppeld aan een licentiemodel. Als WordPress over vijf jaar versie 8 draait, werkt jouw theme nog steeds. Omdat het gebouwd is op de fundamenten die WordPress zelf gebruikt, niet op een laag erboven die elk moment kan veranderen.