Gevonden worden in Google en AI
Trage website: waarom hij traag is en wat je eraan doet
Waarom je trage website klanten kost, hoe je hem op je telefoon meet zonder jezelf te misleiden, en wat je deze week zelf verbetert.
In dit artikel
- Wanneer is een website te traag?
- Wat kost een trage website je?
- Waar zit de tijd bij een trage website?
- Hoe meet je een trage website zonder jezelf te misleiden?
- Je trage website lichter maken: vier dingen die je zelf doet
- Zelf bijwerken of opnieuw laten bouwen?
- Veelgestelde vragen
- Als bijwerken niet genoeg is
Een trage website van een kleine zaak is meestal traag door wat er bovenaan staat en wat er later is bijgezet. Denk aan een zware foto of video, een kaart of een chatbubbel; soms ligt het aan de server waarop je site draait. Wat het kost, is de bezoeker die terugtikt naar Google voor hij ziet wat je doet.
De grens die telt, ligt in het eerste scherm. Een pagina is snel genoeg als het grootste stuk dat je bezoeker eerst ziet, binnen 2,5 seconden op zijn scherm staat. Meestal is dat de foto bovenaan.
Wanneer is een website te traag?
Te traag is je pagina als het grootste stuk in het eerste scherm er bij meer dan een kwart van de bezoeken langer dan 2,5 seconden over doet. Het gaat om dat ene stuk, vaak de foto bovenaan, en dus niet om de volledige pagina tot onderaan. Search Console is het gratis hulpmiddel van Google dat toont hoe je site het in Google doet. Daar krijgt een pagina tussen 2,5 en 4 seconden het label "Verbetering nodig", boven 4 seconden "Slecht".
Er komen nog twee maatstaven bij. Je pagina moet binnen 200 milliseconden reageren als iemand ergens op tikt, en de inhoud mag nauwelijks verspringen. Ook die grenzen moeten lukken bij drie op de vier keer dat iemand je pagina opent, en ze worden apart gemeten op telefoon en computer.
Je site voelt voor jou vaak sneller dan voor je klant. Jij opent hem op wifi, op een toestel dat de pagina al eens laadde. Je klant komt binnen op mobiel internet, en voor hem is het de eerste keer.
Wat kost een trage website je?
Het kost je vooral de klant die niet wacht. Wie je via Google vindt, heeft de andere resultaten nog één tik achter zich. Staat er na een paar seconden nog een grijs vlak waar je foto hoort, dan tikt hij terug en kiest hij de volgende. Jij merkt daar niets van, want wie niet belt, laat ook geen gemist gesprek achter.
Wie wel blijft, kan alsnog misgrijpen. Een pagina die tijdens het laden verspringt, kan mensen op de verkeerde knop laten tikken. Je bezoeker wil bellen, de foto erboven komt net binnen, de knop zakt een duimbreed en hij tikt op je fotogalerij. Zo'n knop is een van de plekken waar je site aanvragen laat liggen, en je ziet hem zelf zelden, omdat je eigen toestel de pagina al kent.
Dan is er Google, en daar wordt snelheid vaak overdreven. De metingen van echte bezoekers wegen mee in hoe Google je rangschikt. Toch schrijft Google zelf dat het altijd eerst de meest relevante inhoud zoekt, ook als die pagina minder vlot werkt. Snelheid helpt je vooral als er veel even goede antwoorden zijn. Een groene score zet je dus niet vanzelf voor een concurrent met een betere pagina: eerst moet je antwoord kloppen, daarna tellen de seconden.
Waar zit de tijd bij een trage website?
Bij een kleine zaak zit ze op drie plekken: de foto bovenaan, de extra's die je er zelf bij zette en de weg naar de server.
De foto bovenaan
In een grote meting van het web uit 2024 was bij 73 procent van de mobiele pagina's het grootste stuk bovenaan een foto.
Een rekenvoorbeeld. Stel dat je bovenaan een foto zet zoals je telefoon hem maakt: 4000 bij 3000 pixels, 4 megabyte. De test van Google voor telefoons gebruikt een bewust trage verbinding van 1,6 megabit per seconde. Een megabyte is 8 megabit, dus je foto is 32 megabit. Gedeeld door 1,6 geeft dat 20 seconden, alleen voor die ene foto.
In 2,5 seconden komt over die verbinding hoogstens 4 megabit binnen, dat is 500 kilobyte. Daarin moet alles passen wat vóór de foto komt: de pagina zelf, de opmaak, de lettertypes en de foto. Je onbewerkte foto is in zijn eentje acht keer dat budget.
Op maat ziet het er heel anders uit. Op een telefoon vult de foto de breedte van het scherm, en dat is op veel toestellen zo'n 390 punten breed. Een scherp scherm tekent elk van die punten met twee of drie pixels, dus de foto heeft 780 tot 1170 pixels breedte nodig. Reken je breedte maal hoogte, dan heeft je foto van 4000 bij 3000 pixels in oppervlak 12 tot 26 keer zoveel pixels als het scherm kan gebruiken. Verkleind tot 780 pixels breed weegt zo'n foto vaak rond de 150 kilobyte, goed voor driekwart seconde op dezelfde trage verbinding.
Een onbewerkte foto is wel het uiterste geval. Bij de meeste trage sites gaat minder dan een tiende van de wachttijd naar het binnenhalen van de foto zelf. De rest is wachten, bijvoorbeeld op de server of op een browser die de foto pas laat vindt. Weegt je foto bovenaan meer dan het hele budget van 500 kilobyte, dan is zij zelf de oorzaak en wint verkleinen meteen tijd. Is ze al licht en blijft de pagina traag, dan zit het in dat wachten. Kijk dan naar hoe de foto laadt, naar je extra's en naar de server.
Wat je er zelf bij zette
Een ingesloten video, een kaart, een chatbubbel, een blok met Google-reviews of een boekingsvenster van een andere dienst: elk van die extra's haalt zijn eigen code binnen. Standaard laadt die code meteen mee, ook als niemand erop klikt.
Draait je site op een bouwpakket, dan stapelen ook de uitbreidingen zich op. Wie er een uitprobeert en niet weghaalt, laadt die code vaak op elke pagina, ook waar ze niets doet.
De weg naar de server
Voor er iets op het scherm komt, moet de server antwoorden, en ook omleidingen tellen mee in die tijd. Als richtwaarde antwoordt een server binnen 0,8 seconden. Op dat getal beoordeelt Google je niet, maar elke tiende seconde die de server nodig heeft, gaat af van je 2,5 seconden. Antwoordt hij traag, dan ligt het aan de server zelf of aan wat erop draait. Hij moet de bezoekers aankunnen die je site krijgt. Dat nakijken is werk voor wie je site bouwt of beheert, net als caching: kant-en-klare pagina's bewaren zodat de server ze niet telkens opnieuw opbouwt.
Na een vernieuwing blijven soms omleidingen achter elkaar hangen: van het oude adres naar een tussenadres en dan pas naar de nieuwe pagina. Elke stap kost tijd. Bij een vernieuwing zonder verlies in Google gaat elk oud adres in één stap naar zijn nieuwe pagina.
Hoe meet je een trage website zonder jezelf te misleiden?
Open PageSpeed Insights, de gratis meting van Google, op je telefoon en vul het adres van je startpagina in. Je krijgt twee blokken.
Bovenaan staat, als het er is, wat echte bezoekers de laatste 28 dagen meemaakten. Dit is het blok met de 2,5 seconden, de reactie op een tik en het verspringen, en het zijn deze metingen die meewegen in Google.
Bij een kleine zaak kan dat blok leeg blijven. Google schrijft zelf waarom: heeft één pagina te weinig bezoekers, dan toont de meting de cijfers van je hele site. Heeft je hele site er te weinig, dan toont ze geen enkele echte meting. Een leeg blok zegt dus niets over goed of slecht, alleen dat er te weinig bezoeken gemeten zijn.
Daaronder staat een score van 0 tot 100. Die komt uit een nagebootste test: één gemiddeld toestel dat vier keer trager rekent, op dezelfde trage verbinding als in het rekenvoorbeeld. Die verbinding is bewust streng gekozen, zodat ook je trage bezoekers meetellen. Een score van 90 of meer heet goed, onder 50 slecht.
Is het bovenste blok leeg, kijk in de test dan naar één tijd: wanneer het grootste stuk op het scherm staat. In de uitslag heet die tijd Largest Contentful Paint, en er staat ook bij welk stuk het is. Jaag geen 100 na; zorg dat die ene tijd onder 2,5 seconden komt.
Of het aan de server ligt, zie je bij de metingen van echte bezoekers: daar staat ook hoe snel de server zijn eerste antwoord stuurt (in de uitslag: Time to First Byte). Ligt die tijd ruim boven 0,8 seconden, dan zit het probleem daar. Is dat blok leeg, pak dan eerst de foto's en de extra's aan. Blijft de pagina daarna traag, laat dan de server nakijken door wie je site bouwt of beheert.
Je trage website lichter maken: vier dingen die je zelf doet
Verklein de foto bovenaan
Een telefoon heeft voor de foto bovenaan 780 tot 1170 pixels breedte nodig, afhankelijk van hoe scherp het scherm is. Verklein de foto dus in een fotoprogramma voor je hem op je site zet. Bewaar je hem dan in het nieuwere WebP-formaat, dan is hij bij dezelfde kwaliteit vaak nog 25 tot 34 procent kleiner dan als JPEG.
Laat de eerste foto meteen laden
Een veelgehoorde snelheidstip is om alle foto's uitgesteld te laden, pas als ze in de buurt van het scherm komen. Voor foto's lager op de pagina klopt dat. Voor de foto bovenaan werkt het averechts: die wacht dan ook, en je eerste scherm wordt trager. Zoek in je bouwpakket de instelling voor uitgesteld laden, in het Engels vaak "lazy loading", en zet ze voor de eerste foto uit. Vind je ze niet, vraag dan aan wie je site bouwt of de foto bovenaan meteen laadt.

De site van boetiekhotel Casa d'Olivença in Elvas staat vol grote foto's van vijf suites. Alleen de eerste foto, van ongeveer 100 kilobyte, staat ingesteld om meteen te laden. Alle andere foto's staan op uitgesteld laden en komen pas als ze in de buurt van het scherm komen.
Leg je duim op je belknop
Zet de wifi van je telefoon uit, open je site in een privévenster en leg je duim meteen op de plek waar je belknop staat. Springt de knop weg terwijl een foto of de cookiemelding binnenkomt, dan tikt je klant ernaast. De oplossing is dat elke foto en video zijn afmetingen meekrijgt, zodat de pagina er vooraf plaats voor houdt. Een cookiemelding of een balk die later binnenschuift, hoort ook vooraf zijn plek te krijgen.
Schrap wat geen klant oplevert
Schrijf op wat je ooit zelf op je startpagina zette, van de ingesloten video tot het boekingsvenster. Vraag bij elk ervan of een klant erop tikt voor hij belt of boekt. Doet hij dat niet, haal het weg. Wil je het houden, toon dan een stilstaand beeld dat het echte ding pas bij een klik laadt. Je levert daarbij iets in: de video speelt niet vanzelf af en de chatbubbel toont geen teller meer.
Zelf bijwerken of opnieuw laten bouwen?
Zijn het een paar foto's en een extra die je zelf bijzette, dan doe je het zelf met de vier stappen hierboven. Laat je site opnieuw bouwen als een van deze twee dingen klopt:
- de foto is verkleind en de extra's zijn weg, en toch blijft het grootste stuk boven 2,5 seconden;
- je site draait op een bouwpakket met een stapel uitbreidingen die niemand nog durft weg te halen, en de server doet er lang over om te antwoorden.
Blijf je zo'n site toch zelf afslanken, reken dan de avonden mee, net als bij de keuze tussen zelf maken of laten maken.
Wie een website laten maken overweegt, kijkt ook naar wat er in dat eerste scherm staat: wat er op je homepage moet en hoe de webteksten daar klinken. Een snelle pagina die niet zegt wat je doet en waar, levert niemand een klant op.
Veelgestelde vragen
Waarom is mijn site traag op mijn telefoon en snel op de computer?
Je telefoon zit vaak op een tragere verbinding en rekent trager dan je computer, terwijl hij dezelfde grote foto's binnenhaalt. De metingen van echte bezoekers worden voor telefoon en computer apart beoordeeld, dus een snelle computerversie maakt een trage telefoonversie niet goed. En voor wat er op je site staat, kijkt Google naar de telefoonversie.
Hoe snel zie je het resultaat van een verbetering?
De testscore verandert meteen. Het blok met echte bezoekers gaat altijd over de laatste 28 dagen, dus dat draait pas na een paar weken helemaal bij. Meld je een verbetering in Search Console, dan loopt de controle daar ook 28 dagen.
Als bijwerken niet genoeg is
Heb je de foto's en de extra's aangepakt en de server laten nakijken, en blijft je site toch traag, bijvoorbeeld omdat hij op een bouwpakket vol uitbreidingen draait? Dan is een nieuwe site de logische volgende stap. Wij bouwen sites voor kleine zaken om gevonden te worden in Google en in AI-assistenten, en daarvoor tellen dezelfde seconden die je net leerde meten. Plan je gratis demo. In de videocall van 30 minuten klik je dan al door je eigen site, als werkende eerste versie.





