Hoe we de laadtijd van een site tot onder een seconde hebben teruggebracht
Snelheid is geen vanity-metric — het beïnvloedt rankings en omzet. Hier is het exacte performance-werk dat we op elke build uitvoeren, in de volgorde die er het meest toe doet.
De meeste trage websites zijn niet traag om mysterieuze redenen. Ze zijn traag vanwege een handvol voorspelbare problemen die zich opstapelen — en ze worden in een voorspelbare volgorde opgelost. Wanneer een klant bij ons komt met een laadtijd van drie seconden, hebben we zelden exotische trucs nodig. We hebben discipline nodig.
Dit is dezelfde checklist die we bij elk performance-traject doorlopen, grofweg in volgorde van prioriteit. Elke stap is goedkoop in verhouding tot de impact, en de meeste sites voelen na de eerste drie stappen al aanzienlijk sneller aan.
Meet voordat je iets aanraakt
Je kunt niet verbeteren wat je niet meet, en je kunt een verbetering zeker niet bewijzen zonder een nulmeting. We starten elk traject met veldgegevens (field data), niet alleen met laboratoriumscores.
- Lab — Lighthouse en WebPageTest voor een gecontroleerde, herhaalbare momentopname.
- Field — real-user metrics (CrUX / RUM) voor wat mensen daadwerkelijk ervaren.
- Budget — een hard plafond per route, zodat regressies in de CI worden opgevangen en niet in productie.
Een labscore of 100 betekent niets als je echte gebruikers op telefoons uit het middensegment en onstabiele netwerken zitten. Optimaliseer voor de praktijk.
Elimineer resources die het renderen blokkeren
De grootste winst op de meeste sites is het weghalen van CSS en JavaScript uit het kritieke pad. De browser kan pas renderen als het parseren van renderblokkerende resources is voltooid — dus hoe minder er zijn, hoe sneller er iets op het scherm verschijnt.
// defer everything that isn't critical
const load = () => import('./analytics.js');
if ('requestIdleCallback' in window)
requestIdleCallback(load);
else setTimeout(load, 2000);Inline de kleine hoeveelheid CSS die nodig is voor de eerste viewport, en laad de rest asynchroon. Stel niet-kritieke scripts uit (defer). Het doel is een first paint die op niets wacht wat hij niet absoluut nodig heeft.
Behandel afbeeldingen als een budget
Afbeeldingen zijn meestal het zwaarste onderdeel van een pagina, en het makkelijkst om fout te doen. Drie regels dekken negentig procent van de gevallen:
- Serveer moderne formaten — AVIF of WebP — met een fallback.
- Pas de grootte van afbeeldingen aan aan hun gerenderde afmetingen; stuur nooit een hero-afbeelding van 3000px naar een slot van 600px.
- Lazy-load alles onder de vouw en reserveer ruimte om lay-outverschuivingen (layout shift) te voorkomen.
Cache aan de edge
Zodra de pagina slank is, is de volgende vraag hoe snel bytes de gebruiker bereiken. Een CDN met verstandige cache-headers verandert een origin-trip van 600 ms in een edge-hit van 30 ms. Voor dynamische content geeft stale-while-revalidate je direct antwoord terwijl de content op de achtergrond wordt vernieuwd.
Performance is een feature. We budgetteren ervoor op dezelfde manier als we budgetteren voor elk ander deel van de build.
Het resultaat
Bij het project dat de aanleiding vormde voor dit artikel, ging de homepage van een largest contentful paint van 3,1s naar 0,9s, en de organische conversies stegen binnen een maand meetbaar. Niets daarvan was magie — gewoon de bovenstaande checklist, in volgorde toegepast.
Als je site traag aanvoelt en je weet niet waar te beginnen, neem dan contact met ons op — een korte audit brengt meestal de twee of drie veranderingen in beeld die er het meeste toe doen.