Zo verkort je de laadtijd van je website

Je draait een snelheidstest en krijgt een score, een lijst met aanbevelingen en bijna geen aanwijzing waar je moet beginnen. Een website sneller maken betekent weten welke verbeteringen bij welk deel van het laadproces horen en welke het meeste opleveren voor de moeite. Dit artikel behandelt de meest effectieve aanpassingen, de volgorde waarin je ze aanpakt en wat een gemiddelde website van een klein bedrijf van elke verbetering mag verwachten.

Websitesnelheid verbeter je niet met één ingreep. Het is het resultaat van een paar losse factoren die samenwerken: hoe zwaar de pagina is, hoe snel de server reageert, hoe efficiënt bestanden worden geleverd en hoeveel werk de browser moet doen om te tonen wat de bezoeker ziet. Pak je eerst de grootste boosdoeners aan, dan zie je het snelst resultaat. Voor achtergrond over welke laadmetrics ertoe doen en waarom, lees je het artikel over wat laadtijd van een pagina is en hoe je die meet.

Wat zijn de meest voorkomende oorzaken van een trage website?

Voordat je iets verandert, helpt het om te weten waar de tijd echt verloren gaat. Trage websites hebben bijna altijd een of meer van deze problemen.

Niet-geoptimaliseerde afbeeldingen

• Afbeeldingen zijn de grootste bestanden op de meeste pagina's en veruit de meest voorkomende oorzaak van trage laadtijden
• Een pagina met vijf ongecomprimeerde foto's kan tien tot twintig keer zwaarder zijn dan nodig
• Afbeeldingen aanpakken levert meestal de grootste snelheidswinst op van alle losse ingrepen

Geen caching

• Zonder caching moet de server bij elk bezoek de pagina opnieuw opbouwen en moet de browser elk bestand helemaal opnieuw downloaden
• Met caching laden terugkerende bezoekers pagina's vanaf opgeslagen kopieën in plaats van alles opnieuw te downloaden

Code die niet is geminificeerd

• CSS- en JavaScript-bestanden bevatten vaak spaties, opmerkingen en opmaak die ze leesbaar maken voor ontwikkelaars, maar browsers onnodig zwaar maken
• Minificatie haalt die overbodige inhoud weg en verkleint bestanden, soms met 30 tot 50 procent

Trage serverreactie

• Alles wacht op de server. Als de server er meer dan 800 milliseconden over doet om te reageren, loopt elke andere meting vanaf het begin vertraging op
• Shared hosting en niet-geoptimaliseerde databases zijn de meest voorkomende oorzaken van een hoge Time to First Byte

Renderblokkerende bestanden

• Scripts en stylesheets die in de head van het document worden geladen, laten de browser pauzeren voordat hij iets kan tonen
• Laad je niet-kritieke scripts pas na de hoofdinhoud, dan verdwijnt dit knelpunt

Hoe optimaliseer je afbeeldingen om de pagina lichter te maken?

Afbeeldingen optimaliseren heeft voor de meeste websites de grootste impact, omdat je er direct de zwaarste bestanden op de pagina mee verkleint. Drie aanpassingen samen leveren de grootste besparing op.

Kies het juiste formaat

• WebP geeft kleinere bestanden dan JPEG bij dezelfde beeldkwaliteit en ondersteunt net als PNG transparantie
• Gebruik WebP voor alle foto's en gewone afbeeldingen. Gebruik PNG alleen als je transparantie nodig hebt

Verklein de afmetingen vóór het uploaden

• Upload je een afbeelding van 4.000 pixels breed die op 800 pixels breed wordt getoond, dan downloadt elke bezoeker vier keer meer data dan nodig
• Pas afbeeldingen aan op hun maximale weergavebreedte voordat je ze uploadt

Comprimeer tot een passend kwaliteitsniveau

• Een kwaliteitsinstelling van 75 tot 85 bij verlieslatende formaten geeft bestanden die 60 tot 80 procent kleiner zijn dan het origineel, zonder zichtbaar verschil voor de meeste foto's
• Het juiste formaat, de juiste afmetingen en passende compressie samen kunnen het afbeeldingsgewicht van een pagina met 80 tot 90 procent verlagen

Een volledige gids over bestandsformaten, compressietypen, lazy loading en responsieve afbeeldingen vind je in het artikel over afbeeldingen optimaliseren voor sneller laden.

Hoe verkort caching de laadtijd?

Caching bewaart kopieën van paginabestanden, zodat ze niet bij elk verzoek opnieuw hoeven te worden gedownload of gegenereerd. Er zijn twee soorten, die op verschillende punten in de keten werken.

Browsercaching

• De browser van de bezoeker slaat na het eerste bezoek CSS, JavaScript, afbeeldingen en lettertypen op
• Bij een volgend bezoek komen die bestanden van het eigen apparaat in plaats van opnieuw van het netwerk, wat de laadtijd voor terugkerende bezoekers sterk verkort
• Browsercaching wordt bepaald door cacheheaders op de server. De meeste moderne hostingplatforms stellen die automatisch in

Servercaching

• De server bewaart kant-en-klare versies van pagina's, zodat ze niet bij elk verzoek opnieuw hoeven te worden opgebouwd
• Dat verbetert de Time to First Byte voor alle bezoekers, ook voor wie voor het eerst komt
• Servercaching heeft de meeste impact op dynamische websites waar pagina's uit databasequery's worden opgebouwd

Een uitgebreide uitleg over hoe browsercaching werkt en hoe je het instelt, vind je in het artikel over wat browsercaching is en hoe het werkt.

Wat doet minificatie voor de laadsnelheid?

CSS- en JavaScript-bestanden die ontwikkelaars schrijven, bevatten spaties, regeleinden en opmerkingen die de code leesbaar en onderhoudbaar maken. Browsers hebben dat allemaal niet nodig. Minificatie haalt het weg, waardoor bestanden kleiner worden en sneller downloaden, zonder dat ze anders werken.

• CSS-minificatie verkleint bestanden meestal met 20 tot 30 procent
• JavaScript-minificatie kan bestanden met 30 tot 50 procent verkleinen, en meer bij grote bestanden met veel opmerkingen en witruimte
• Minificatie is een van de makkelijkere winsten, omdat het niets verandert aan hoe de site eruitziet of werkt en vaak met een plugin of platforminstelling aan te zetten is

Een volledig overzicht van hoe minificatie werkt voor CSS, JavaScript en HTML vind je in het artikel over wat minificatie is en hoe het je website helpt.

Hoe verkort een CDN de laadtijd voor bezoekers?

Een content delivery network (CDN) verkleint de fysieke afstand tussen de bezoeker en de server die je bestanden levert. Zonder CDN verbinden alle bezoekers met één server op één locatie. Met een CDN krijgt elke bezoeker de bestanden van de server die het dichtstbij staat.

• Voor bezoekers vlak bij de oorspronkelijke server is de snelheidswinst van een CDN klein
• Voor bezoekers in andere landen of regio's kan een CDN de Time to First Byte met honderden milliseconden verkorten
• CDN's hebben de meeste impact op websites met een internationaal publiek of veel media
• Sommige hostingplatforms bieden automatisch CDN-levering. Is dat inbegrepen, dan hoef je niets extra in te stellen

Een volledige uitleg over hoe CDN's werken en wie er een nodig heeft, vind je in het artikel over wat een CDN is en hoe het je website helpt.

Wat is lazy loading en hoe verkort het de eerste laadtijd?

Lazy loading stelt het downloaden van afbeeldingen en andere bestanden onder de vouw uit tot de bezoeker er dichtbij scrolt. Zo hoeft de browser minder data te downloaden voordat de pagina bruikbaar is.

• Op een pagina met twintig afbeeldingen downloadt de browser met lazy loading alleen de drie of vier afbeeldingen die bij het openen in beeld zijn
• De rest laadt terwijl de bezoeker scrolt, zodat de download over de tijd wordt verspreid in plaats van vooraf
• Lazy loading verbetert direct de Time to Interactive en kan een merkbaar effect hebben op de Largest Contentful Paint als de inhoud boven de vouw niet vol met afbeeldingen zit
• Gebruik geen lazy loading voor afbeeldingen boven de vouw. Die moeten direct laden

Een volledige gids over hoe lazy loading werkt en hoe je het toepast, vind je in het artikel over wat lazy loading is en hoe het werkt.

Hoe vertragen renderblokkerende bestanden een pagina?

Als een browser een script of stylesheet in de head van het document tegenkomt, pauzeert hij het tonen van de pagina tot dat bestand klaar is met laden. De bezoeker ziet in die tijd niets. Zo'n bestand heet een renderblokkerend bestand.

Zo beperk je renderblokkering

• Laad niet-kritieke JavaScript aan het eind van het document, of gebruik het attribuut defer of async, zodat scripts het tonen van de pagina niet pauzeren
• Bepaal welke CSS direct nodig is (stijlen boven de vouw) en welke later kan laden
• Verwijder of vervang scripts van derden die niet essentieel zijn. Chatwidgets, social media-embeds en trackingscripts zorgen allemaal voor extra blokkeertijd

Hoe zit het met de reactietijd van de server?

Elke andere verbetering is beperkt door hoe snel de server in de eerste plaats reageert. Een trage server zorgt voor vertraging voordat de browser ook maar één bestand kan gaan laden.

Wat de reactietijd van de server bepaalt

• Kwaliteit van de hosting: bij shared hosting delen veel sites processor en geheugen, waardoor reactietijden onvoorspelbaar zijn
• Prestaties van de database: trage of niet-geoptimaliseerde databasequery's vertragen het opbouwen van een antwoord
• Servercaching: zonder caching start elk verzoek een volledige opbouw van de pagina uit de database
• Geografische afstand tot de server: ook zonder CDN zorgt een server ver van de bezoeker voor extra vertraging

Een goede Time to First Byte ligt onder de 800 milliseconden. Zit je TTFB steeds daarboven, dan levert betere hosting of servercaching winst op die geen enkele front-endoptimalisatie kan evenaren.

Waar begin je om een website sneller te maken?

Werk je voor het eerst aan snelheidsverbeteringen, dan geeft deze volgorde de snelste winst voor de minste moeite op een gemiddelde website van een klein bedrijf.

Volgorde van prioriteit voor de meeste websites

• Eerst: optimaliseer afbeeldingen. Dit pakt de grootste bron van paginagewicht aan en is vaak goed voor 60 tot 80 procent van de te vermijden laadtijd
• Daarna: zet caching aan. Browsercaching en servercaching verminderen het werk bij elk bezoek, vooral voor terugkerende bezoekers
• Dan: minificeer CSS en JavaScript. Weinig moeite, betrouwbare verbetering van de overdrachtstijd
• Vervolgens: voeg een CDN toe als je publiek geografisch verspreid is of als media een groot deel van je site zijn
• Tot slot: pak renderblokkerende bestanden en de reactietijd van de server aan als je de stappen hierboven hebt gedaan en de scores nog slecht zijn

Voer na elke reeks aanpassingen een snelheidstest uit om de verbetering te meten voordat je aan het volgende onderdeel begint. Hoe je de resultaten van een snelheidstest goed leest, lees je in het artikel over hoe je de snelheid van je website test. Voor een overzicht van de metrics waar deze verbeteringen invloed op hebben, lees je het artikel over wat Core Web Vitals zijn.

Hoe WEMASY de laadtijd van je website verkort

De Websitebouwer van WEMASY regelt automatisch een aantal van de meest voorkomende snelheidsverbeteringen. Afbeeldingen worden bij het uploaden gecomprimeerd en omgezet naar WebP. Browsercache-headers staan standaard goed ingesteld. CSS- en JavaScript-bestanden die het platform levert, zijn geminificeerd. CDN-levering zit in alle abonnementen, zodat statische bestanden vanaf de locatie het dichtst bij elke bezoeker komen.

Paginasnelheidsscores en Core Web Vitals-gegevens zie je in het analytics-dashboard van WEMASY, met aanbevelingen per pagina die de resterende problemen aanwijzen. Zo volg je verbeteringen na elke wijziging in inhoud of ontwerp, zonder zelf externe tests te draaien.

Bekijk wat erbij zit op de WEMASY Websitebouwer, of vergelijk de abonnementen op de prijzenpagina.

Veelgestelde vragen