Laadtijd onder 1 seconde: hoe ik dat doe

Amazon heeft het uitgerekend: elke 100 milliseconden vertraging kost hen 1% in omzet. Niet per jaar - per laadmoment. Pagina's die in 1 seconde laden converteren 2,5 keer beter dan pagina's die 5 seconden nodig hebben. En bij elke extra seconde daalt de conversie nog eens met 4,42%. Snelheid is geen technisch detail. Het is een bedrijfskritische keuze.

Toch laadt de gemiddelde WordPress-site traag. Lighthouse-score van 38 op 100. TTFB van 300 tot 900 milliseconden, nog voordat er ook maar een pixel op het scherm verschijnt. 40% van je bezoekers stapt op bij een laadtijd boven de 3 seconden. Bij 5 seconden is het bouncepercentage al opgelopen naar 38%.

Ik bouw alle websites op Next.js. Niet omdat het de hype is, maar omdat het de technische architectuur heeft om structureel onder 1 seconde te landen. Hier is precies hoe ik dat doe.

1. Static Site Generation: de pagina bestaat al voordat de bezoeker aanklopt

Bij traditionele WordPress-sites gebeurt het volgende elke keer dat iemand een pagina opent: de server ontvangt het verzoek, raadpleegt de database, bouwt de HTML op, en stuurt het resultaat terug. Dit kost tijd - gemiddeld 300 tot 900 milliseconden alleen al voor die eerste byte.

Met Static Site Generation (SSG) draai ik dat proces om. De HTML wordt tijdens het bouwen van de site al volledig gegenereerd. Wanneer een bezoeker de pagina opent, ligt de HTML kant-en-klaar op een server die er dicht bij in de buurt staat. Er is geen database-query. Er is geen server-side rendering. De pagina wordt simpelweg geserveerd.

Het resultaat: een TTFB (Time to First Byte) van 20 tot 50 milliseconden in plaats van 300 tot 900. Dat is het verschil tussen een pagina die voelt als direct en een pagina die voelt als wachten.

2. Image optimalisatie: de stille bandbreedtedief

Afbeeldingen zijn verantwoordelijk voor het leeuwendeel van de bestandsgrootte op de meeste websites. Een hero-foto van 4 MB die de ontwerper aanlevert. Een portfolio van 12 ongecomprimeerde JPEG's. Ze laden allemaal in, ook als de bezoeker er nooit bij in de buurt scrolt.

Next.js lost dit op meerdere niveaus op. Automatische conversie naar WebP of AVIF - formaten die 30 tot 50% kleiner zijn dan JPEG bij gelijke kwaliteit. Responsive sizes: de telefoon laadt een 400px brede versie, het grote scherm een 1600px versie. En lazy loading als standaard: afbeeldingen worden pas geladen op het moment dat de bezoeker er naartoe scrolt.

Dat laatste klinkt simpel, maar het effect is groot. De eerste renderbare inhoud van de pagina - de hero, de navigatie, de koptekst - laadt direct. De rest volgt pas als de bezoeker er iets mee wil doen. Voor de bezoeker voelt de pagina daardoor vrijwel onmiddellijk klaar.

Vodafone deed een meting op hun productpagina's. Een verbetering van 31% op de Largest Contentful Paint (LCP) - de tijd tot het grootste zichtbare element geladen is - leverde 8% meer verkopen op. Afbeeldingen optimaliseren is geen kosmetische ingreep. Het is omzetoptimalisatie.

Afbeeldingen optimaliseren is geen kosmetische ingreep. Het is omzetoptimalisatie.

Slechts 48% van alle mobiele pagina's haalt deze drie drempelwaarden. Mijn websites halen ze standaard.

3. Code splitting: laad alleen wat je nu nodig hebt

Traditioneel bundelen websites al hun JavaScript in een of enkele grote bestanden. De bezoeker laadt de homepage - en download tegelijkertijd de code voor de contactpagina, de blogpagina, de projectgalerij, en alles daartussen. Code die de bezoeker op dat moment nooit gebruikt.

Next.js doet dit anders. Elke pagina krijgt zijn eigen JavaScript-bundel, en die bundel bevat uitsluitend de code die die specifieke pagina nodig heeft. Componenten die buiten het scherm staan worden pas geladen als ze relevant worden. Dit heet code splitting, en het reduceert de initieel te downloaden code met 20 tot 50%.

In de praktijk betekent dit: de browser heeft minder te verwerken bij het openen van de pagina. De Main Thread - het stukje van de browser dat de interface responsief houdt - raakt minder overbelast. Klikken voelen direct. Animaties verlopen soepel. De INP-score blijft laag.

Dit is ook de reden waarom de Interaction to Next Paint (INP) - de metric die meet hoe snel een pagina reageert op klikken en invoer - bij Next.js-sites structureel beter scoort dan bij zware WordPress-installaties met meerdere plugins die elk hun eigen JavaScript-ballast meebrengen.

4. Edge caching: de server zit naast je bezoeker

Zelfs een razendsnelle server is traag als die server in een ander land staat. Een bezoeker in Amsterdam die verbinding maakt met een server in de Verenigde Staten ervaart een extra vertraging van 100 tot 150 milliseconden - simpelweg door de fysieke afstand. Dit heet latency, en het is niet op te lossen door de server sneller te maken.

De oplossing is een Content Delivery Network (CDN) met edge caching. De statische bestanden van de website - de HTML, het CSS, de afbeeldingen - worden gekopieerd naar servers verspreid over de wereld. Vercel, het platform waarop ik alle websites deploy, doet dit automatisch op 40 locaties. De bezoeker in Amsterdam krijgt zijn pagina van een server in Amsterdam. De bezoeker in Sydney van een server in Sydney.

Het effect: een TTFB onder de 50 milliseconden, wereldwijd. Niet alleen op kantoor in dezelfde stad als de server, maar overal.

Waarom dit voor jouw bedrijf uitmaakt

De techniek is interessant, maar het gaat uiteindelijk om de bedrijfsuitkomst. En die is duidelijk gedocumenteerd.

40% van de bezoekers verlaat een site die meer dan 3 seconden nodig heeft. Bij een website die 1.000 bezoekers per maand trekt en een laadtijd heeft van 4 seconden, verdwijnen er elke maand 400 potentiele klanten voordat ze iets gezien hebben. Niet door een slechte boodschap. Niet door een slechte prijs. Gewoon door wachten.

Een bouncepercentage van 7% bij een laadtijd van 1 tot 3 seconden loopt op naar 38% bij 5 seconden. Dat is vijf keer zoveel verlies. Voor hetzelfde budget aan advertenties, hetzelfde product, dezelfde dienst.

Google weegt snelheid mee als rankingfactor. Twee websites met vergelijkbare content - de snellere scoort hoger. Een investering in technische snelheid is tegelijkertijd een investering in organisch bereik.

Snelheid is een keuze die je maakt voordat je de eerste regel schrijft

Snelheid is geen feature die je achteraf toevoegt. Het is het resultaat van de technologiekeuze die je aan het begin maakt.

Snelheid is geen feature die je achteraf toevoegt. Het is het resultaat van de technologiekeuze die je aan het begin maakt. WordPress met plugins oplappen tot een acceptabele score kost meer tijd dan het kost om een Next.js-site van scratch te bouwen. En het resultaat is nooit zo goed.

SSG zorgt voor een directe eerste byte. Image optimalisatie halveert de bandbreedte. Code splitting reduceert de JavaScript-belasting met tientallen procenten. Edge caching zet de server naast de bezoeker. Samen leveren ze een Lighthouse-score van 90 tot 100, een LCP onder de 2,5 seconden, en een TTFB onder de 50 milliseconden - consequent, op elke pagina, voor elke bezoeker.

Dat is wat ik bouw. Niet omdat het technisch indrukwekkend is, maar omdat het de beste keuze is voor je bedrijf.

Dennis Wamelink

Designer, developer en oprichter van WAMELINK. Bouwt maatwerk websites vanuit Amsterdam.