Neem twee websites die hetzelfde verkopen. Open ze naast elkaar. De ene laadt voordat je vinger het trackpad verlaat. De andere doet er vier seconden over voordat er één element verschijnt. Het verschil dat je net ervoer, heeft een naam: laadtijd van een pagina. Maar het getal dat je in een snelheidstool ziet, is maar een deel van het geheel. Laadtijd is niet één meting. Het is een verzameling metingen, die elk een ander moment in de laadreeks vastleggen en elk iets anders vertellen over wat een bezoeker echt ervaart. Dit artikel behandelt wat laadtijd meet, welke meetwaarden tellen en wat ze je vertellen, waarom mobiel en desktop verschillen en hoe je de prestatiedata van je eigen site leest zonder dat een ontwikkelaar het voor je hoeft te vertalen.
De laadtijd van een pagina is de tijd tussen het moment dat een bezoeker een pagina opvraagt en het moment dat die pagina volledig bruikbaar is in zijn browser. Het wordt op meerdere manieren gemeten omdat "geladen" iets anders betekent, afhankelijk van wat je wilt begrijpen. Een pagina kan content tonen voordat elk element is geladen. Hij kan interactief lijken voordat hij echt op klikken reageert. Als je begrijpt welk deel van de laadreeks traag is, wordt snelheidsdata nuttig in plaats van alleen alarmerend. Waarom dit belangrijk is voor je bedrijf en je zoekposities, lees je in het artikel over waarom websitesnelheid belangrijk is.
Wat meet de laadtijd van een pagina eigenlijk?
De term "laadtijd" wordt los gebruikt voor één getal, maar in de praktijk gaat het om een tijdlijn met meerdere controlepunten. Elk controlepunt beantwoordt een andere vraag over wat een bezoeker ervaart terwijl de pagina laadt.
De laadreeks
- De browser stuurt een verzoek naar je server
- De server verwerkt het verzoek en stuurt een antwoord terug
- De browser begint de pagina te ontvangen en te renderen
- Tekst en afbeeldingen verschijnen gaandeweg terwijl ze downloaden
- Scripts worden uitgevoerd en maken de pagina interactief
- Het laatste element is klaar met laden
Verschillende meetwaarden leggen verschillende punten in deze reeks vast. Een goede score voor laadtijd hangt af van welke controlepunten je meet, niet van één verstreken tijd.
Welke specifieke meetwaarden meten de laadtijd van een pagina?
Time to First Byte (TTFB)
- Wat het meet: hoe lang de browser wacht voordat hij de eerste byte data van je server ontvangt
- Goede score: onder 800 milliseconden
- Waarom het belangrijk is: een trage TTFB vertraagt alles wat daarna komt. De browser kan niets renderen voordat er data binnenkomt. Een trage TTFB wijst meestal op serverprestaties, de kwaliteit van de hosting of niet-geoptimaliseerde databasequery's
First Contentful Paint (FCP)
- Wat het meet: het moment waarop de browser het eerste stukje content rendert, of dat nu tekst, een afbeelding of een achtergrond is
- Goede score: onder 1,8 seconden
- Waarom het belangrijk is: dit is het moment waarop de bezoeker voor het eerst ziet dat er iets gebeurt. Een snelle FCP laat zien dat de pagina reageert, ook als hij nog niet klaar is met laden
Largest Contentful Paint (LCP)
- Wat het meet: wanneer het grootste zichtbare element (meestal een hoofdafbeelding of grote kop) volledig is geladen
- Goede score: 2,5 seconden of sneller
- Waarom het belangrijk is: LCP is een van de drie Core Web Vitals die worden gebruikt voor zoekposities. Het komt het dichtst bij "wanneer voelt deze pagina bruikbaar", omdat het grootste element meestal het belangrijkste beeld op de pagina is
Time to Interactive (TTI)
- Wat het meet: wanneer de pagina volledig interactief is en betrouwbaar reageert op klikken en toetsenbordinvoer
- Goede score: onder 3,8 seconden
- Waarom het belangrijk is: een pagina kan geladen lijken terwijl JavaScript nog op de achtergrond draait. TTI legt het gat vast tussen een pagina die klaar lijkt en een pagina die echt klaar is
Total Blocking Time (TBT)
- Wat het meet: de totale tijd dat de hoofdthread geblokkeerd is en niet op invoer kan reageren tussen FCP en TTI
- Goede score: onder 200 milliseconden
- Waarom het belangrijk is: TBT laat zien hoeveel zware JavaScript-verwerking de interactiviteit vertraagt. Een hoge TBT betekent dat bezoekers op knoppen klikken en er niets gebeurt, wat het vertrouwen schaadt, ook als de pagina er visueel geladen uitziet
Volledige paginalading
- Wat het meet: wanneer elke afzonderlijke bron op de pagina, inclusief afbeeldingen, scripts, lettertypen en ingesloten content van derden, volledig is geladen
- Goede score: onder 5 seconden op mobiel
- Waarom het belangrijk is: dit is de meetwaarde waar de meeste mensen aan denken als ze het over "laadtijd" hebben. Het is nuttig om het totale gewicht van je pagina te begrijpen, maar minder belangrijk voor de ervaring van bezoekers dan LCP en TTI, omdat bezoekers meestal al met een pagina bezig zijn lang voordat elk element is geladen
Waarom verschilt de laadtijd op mobiel van die op desktop?
Mobiel en desktop geven voor dezelfde pagina verschillende scores voor laadtijd, ook als de content identiek is.
Redenen waarom mobiel steeds trager is
- Mobiele verbindingen zijn gemiddeld trager dan vast breedband, zelfs op 4G- en 5G-netwerken
- Mobiele processoren zijn minder krachtig dan desktop-cpu's, waardoor JavaScript trager draait
- Mobiele browsers hebben minder geheugen beschikbaar, wat beperkt hoeveel ze tussen pagina's kunnen cachen
- Netwerkomstandigheden schommelen op mobiel meer, wat leidt tot wisselende prestaties per bezoek
Waarom mobiele scores zwaarder wegen
- Zoekmachines gebruiken mobile-first indexing, wat betekent dat ze pagina's crawlen en rangschikken op basis van hun mobiele versie
- Core Web Vitals-scores op mobiel wegen zwaarder voor de ranking dan desktopscores
- Mobiel is goed voor het grootste deel van het webverkeer wereldwijd, dus mobiele prestaties raken het grootste deel van je bezoekers
Voer altijd aparte tests uit voor mobiel en desktop. Een pagina die op desktop goed scoort, kan op mobiel nog steeds flinke problemen hebben, en mobiel is waar de impact op je ranking het grootst is.
Wat veroorzaakt trage laadtijden?
Grote, niet-gecomprimeerde afbeeldingen
- De meest voorkomende oorzaak van een hoog paginagewicht en trage laadtijden
- Een foto die direct vanaf een telefoon is geüpload, kan 4 tot 8 megabyte zijn
- Dezelfde afbeelding kan, goed gecomprimeerd, onder de 100 kilobyte blijven zonder zichtbaar kwaliteitsverschil
- Elke niet-gecomprimeerde afbeelding voegt seconden toe aan FCP en LCP
Scripts en stylesheets die het renderen blokkeren
- Browsers pauzeren het renderen als ze JavaScript- of CSS-bestanden tegenkomen die ze moeten verwerken voordat ze verdergaan
- Scripts die in de head van het document worden geladen, houden de pagina tegen om iets te tonen totdat ze klaar zijn
- Niet-kritieke scripts uitstellen haalt ze uit het kritieke pad en versnelt FCP en LCP
Trage respons van de server (hoge TTFB)
- Elke paginalading begint met een serververzoek. Is de server traag, dan wordt alles wat daarna komt vertraagd
- Shared hosting deelt cpu en geheugen over veel sites, wat onvoorspelbare responstijden geeft
- Niet-geoptimaliseerde databases en server-side rendering zonder caching dragen vaak bij
Te veel scripts van derden
- Chatwidgets, trackingpixels en analytics-tools voegen elk externe verbindingsverzoeken toe
- Reageert een externe server traag, dan blijft je pagina wachten
- Scripts van derden kunnen flink bijdragen aan TBT doordat ze uitvoertijd van JavaScript toevoegen
Geen caching
- Zonder caching veroorzaakt elk bezoek een volledige herbouw van de pagina door de server
- Met caching laden terugkerende bezoekers een opgeslagen versie, wat de responstijd van de server aanzienlijk verkort
- Browsercaching laat terugkerende bezoekers ook bestanden overslaan die ze al hebben geladen
Hoe meet je de laadtijd van je eigen pagina?
Wat snelheidstools meten
- Snelheidstools simuleren een paginalading vanaf een vaste locatie en verbinding en scoren elke meetwaarde tegen standaarddrempels
- Dit heten labresultaten: gecontroleerde tests onder constante omstandigheden
- Labresultaten zijn nuttig om specifieke problemen op te sporen, maar laten niet zien hoe echte bezoekers op andere verbindingen en apparaten je pagina echt ervaren
Labdata versus veldgegevens
- Labdata: gesimuleerde tests in een gecontroleerde omgeving. Snel uit te voeren en goed om specifieke problemen af te zonderen
- Veldgegevens: echte metingen van bezoekers van je site, over tijd samengevoegd. Dit gebruiken zoekmachines voor de scores van Core Web Vitals
- Een pagina kan in een labtest goed scoren maar slecht in veldgegevens als omstandigheden in de praktijk, tragere apparaten, zwakkere verbindingen of geografische afstand tot je server, andere resultaten opleveren voor echte bezoekers
Waar je op let bij het lezen van een snelheidsrapport
- Kijk eerst naar LCP: het is de belangrijkste meetwaarde voor zowel de ervaring van bezoekers als zoekposities
- Bekijk TTFB om te zien of het probleem aan de serverkant of aan de voorkant zit
- Controleer TBT om te zien of JavaScript de interactiviteit blokkeert
- Voer aparte tests uit voor mobiel en desktop
- Vergelijk je scores met de pagina's die boven je staan voor je doelzoekwoorden, en niet alleen met abstracte richtwaarden
Een overzicht van de drempels van Core Web Vitals en hoe zoekmachines pagina's ertegen scoren, lees je in het artikel over wat Core Web Vitals zijn.
Hoe WEMASY omgaat met laadtijd
De websitebouwer van WEMASY is gebouwd om laadtijden snel te houden zonder technische configuratie. Afbeeldingen die je via het platform uploadt, worden automatisch gecomprimeerd en verkleind voordat ze worden getoond. Hostinginfrastructuur zit bij elk abonnement, dus sites komen niet op gedeelde omgevingen met onvoorspelbare responstijden terecht. Caching staat standaard aan, en pagina's die in WEMASY zijn gebouwd, zijn zo opgezet dat bronnen die het renderen blokkeren minimaal blijven.
Core Web Vitals-scores, waaronder LCP, INP en CLS, zijn zichtbaar in het WEMASY-dashboard op basis van veldgegevens van echte bezoekers. Zo controleer je hoe je pagina's presteren ten opzichte van de drempels die tellen voor zoekposities, zonder externe tests uit te voeren.
Bekijk wat er is inbegrepen bij de websitebouwer van WEMASY, of bekijk de mogelijkheden op de prijzenpagina.
Veelgestelde vragen
Wat is een goede laadtijd van een pagina?
Bij Core Web Vitals is de belangrijkste drempel een Largest Contentful Paint onder 2,5 seconden. In de praktijk dekt het streven naar volledige interactiviteit binnen drie seconden op een mobiele verbinding de meeste situaties. Een volledige paginalading onder vijf seconden op mobiel is een redelijke richtwaarde voor de meeste websites van kleine bedrijven. Met de websitebouwer van WEMASY stel je dit direct in op je eigen website.
Wat is het verschil tussen laadtijd van een pagina en Core Web Vitals?
Laadtijd van een pagina verwijst naar de hele reeks metingen van het eerste serververzoek tot het laden van het laatste element. Core Web Vitals zijn drie specifieke meetwaarden binnen die reeks, namelijk Largest Contentful Paint, Interaction to Next Paint en Cumulative Layout Shift, die zoekmachines gebruiken als rankingsignalen. Core Web Vitals zijn een onderdeel van de metingen van laadtijd, gericht op de delen van de laadervaring die bezoekers het meest raken.
Waarom is de laadtijd van mijn pagina op mobiel anders dan op desktop?
Mobiel en desktop geven verschillende scores omdat mobiele apparaten tragere processoren gebruiken, op wisselende netwerkverbindingen werken en minder geheugen hebben dan desktopcomputers. Een pagina die op een desktop met breedband in twee seconden laadt, kan op een mobiel apparaat op een gemiddeld mobiel netwerk vier seconden of meer nodig hebben. Zoekmachines scoren mobiele prestaties apart en laten ze zwaarder meewegen, omdat het grootste deel van het webverkeer van mobiele apparaten komt.
Wat is het verschil tussen labdata en veldgegevens in snelheidstests?
Labdata komt uit een gesimuleerde test onder gecontroleerde omstandigheden vanaf een vaste locatie en een vast apparaat. Veldgegevens komen van echte bezoekers van je site, gemeten op hun eigen apparaten, locaties en verbindingen. Zoekmachines gebruiken veldgegevens voor de scores van Core Web Vitals, niet de labresultaten. Een site kan in een labtest snel lijken maar slecht scoren in veldgegevens als echte bezoekers op tragere verbindingen of apparaten zitten, of geografisch ver van je server zijn.
Wat betekent Time to First Byte?
Time to First Byte (TTFB) is de tijd tussen het moment dat de browser een verzoek naar je server stuurt en het moment dat hij de eerste byte data terugkrijgt. Het meet hoe snel de server reageert. Een trage TTFB vertraagt elke volgende stap in de laadreeks, omdat de browser niets kan renderen voordat hij data begint te ontvangen. Een TTFB boven 800 milliseconden wijst meestal op problemen met serverprestaties, trage hostingomgevingen of niet-geoptimaliseerde verwerking aan de backend.
Beïnvloedt de laadtijd van een pagina je SEO-posities?
Ja. Zoekmachines gebruiken Core Web Vitals, die voortkomen uit metingen van laadtijd, als rankingsignalen. Largest Contentful Paint, Interaction to Next Paint en Cumulative Layout Shift worden gescoord op basis van data van echte bezoekers en gebruikt om de paginaervaring te beoordelen. Pagina's die in het goede bereik scoren, hebben een voordeel in ranking ten opzichte van pagina's die slecht scoren, vooral als concurrerende pagina's een vergelijkbare contentkwaliteit hebben.