Laadtijd website testen: hoe snel laadt jouw site?

SlakHeb je ook zo’n hekel aan trage websites? Je bent niet de enige. Ik vraag me af of er voldoende gekeken wordt naar de laadtijden van websites. Zijn jullie op de hoogte van je website laadtijd? Ben je je ervan bewust wat de gevolgen zijn voor je bedrijf? Een snelle website moet volgens mij een randvoorwaarde zijn. Eerst website snelheid, dan website optimalisatie.

Waarom website snelheid?

Trage sites zorgen voor een slechte klantbeleving. Mensen betalen geld voor een breedbandverbinding juist omdat ze niet willen wachten. Door een trage site te bieden waant een gebruiker zich weer terug in de tijd, de tijd van dial-up modems. Deze klanten zullen erg teleurgesteld zijn.

Daarnaast delen zoekmachines penalties uit voor trage website laadtijden in hun pay-per-click campagnes. Google heeft de laadtijd van de website opgenomen in hun Quality Score. Ook wordt de laadtijd van websites meegenomen in de organische resultaten. Je bent binnen Google dus altijd slecht af met een trage site. En dat is niet onlogisch, een snellere site zorgt voor een betere klantbeleving.

Hoe kan ik mijn website snelheid testen?


Tools Pingdom Google
Je kunt de snelheid van je site op verschillende manieren testen. Een site die ik vaak gebruik is tools.pingdom.com. Deze site geef je op detail inzicht in wat er geladen wordt en waar de knelpunten zitten. Deze rapporten kan je prima gebruiken om je site te verbeteren.

Naast deze website kan je ook de Firefox plugin YSlow gebruiken. Deze tool geeft de ontwikkelaar specifieke aanbevelingen om de snelheid van de website te verbeteren. Voor ontwikkelaars die op OS X werken kan je in nieuwste versie van Safari de optie “developers tools” aanzetten. Als je deze optie aangezet hebt kan je via Develop > Show Network Timeline ook een visuele weergave krijgen van de laadtijd van de pagina waarnaar je aan het kijken bent.

Wat is traag? Benchmark laadtijd website!

Wat te doen als je weet dat je site in 5.6 seconden laadt? Ik raad je aan om te kijken naar je concurrenten, op hetzelfde tijdstip. Het moment van meten is namelijk bepalend voor de uitkomst. Een test om 2 uur ‘s nachts zal andere uitkomsten geven dan een test om 8 uur ‘s avonds. Door je eigen laadtijd te vergelijken met die van je concurrenten (de acceptatie laadtijd website) kan je jezelf een beeld vormen van de performance van je website. Mijn ervaring leert dat bij een snelle website de laadtijd zo rond de seconde ligt.

Wat moet ik doen nu ik weet dat mijn site traag is?

  • Check je website. Het kan goed zijn dat je teveel elementen op je pagina hebt staan die voor een vertraging zorgen. Probeer deze te reduceren.
  • Bel je hosting provider en vraag of ze je server willen bekijken, daar kan het probleem ook liggen.
  • Als je gebruik maakt van gedeelde hosting dan kan je uitzoeken of je hosting provider de server niet overbelast. Zijn er wellicht sites die teveel load vragen van de server waardoor jouw site traag wordt?

Lees meer:
Why is my website so unbearably slow (Paul Holstein)
Tools to detect slow load times (Greg Laptevsky)

Reacties (11)

  1. andre.scholten@gmail.com'

    Verwar de laadtijd niet met de rendertijd. Google haalt alleen de broncode op als platte tekst en is klaar met laden als de tekst binnen is. De tijd die daarvoor nodig is zal Google als laadtijd onthouden.

    Vervolgens gaan de browsers aan de slag met de broncode en bijbehorende plaatjes/css/javascript en maken er een mooie pagina van. Dat renderen kost ook weer tijd en is ook nog tijd die de gebruiker moet wachten voordat hij wat ziet. Deze tijd plus de initiële laadtijd die Google hanteert is tezamen de wachttijd voor een gebruiker.

    Het kan dus zijn dat je server wel snel is en Google de pagina snel kan inladen maar dat door uitgebreide tabellen met rare constructies de gebruiker alsnog lang moet wachten. Hiervoor zul je dus van Google geen ‘penalty’ krijgen.

    Overigens is penalty wel een zwaar woord, het levert je minpunten op in je totale Quality Score. Dat klinkt een stuk vriendelijker 😉

  2. Dank voor de tips en tools Reinout. Nu wachten totdat iemand webanalisten.nl gaat vergelijken met andere weblogs :-). Wij kunnen nog wel het een en ander optimaliseren. Door alle wordpress plugins zijn er vele losse bestanden met dubbele css en javascript zaken, ook hebben we erg veel webanalyse tools met externe javascript draaien.

    Maar goed, als ik even snel kijk met tools.pingdom.com (erg coole tool overigens):
    – webanalisten.nl
    Total loading time: 2.3 seconds Total objects: 65 (233.4 KB) External objects: 15 (100.6 KB)
    – marketingfacts.nl
    Total loading time: 2.6 seconds Total objects: 75 (411 KB) External objects: 6 (40.8 KB)
    – molblog.nl
    Total loading time: 3.8 seconds Total objects: 60 (259 KB) External objects: 3 (24.6 KB)
    – dutchcowboys.nl
    Total loading time: 8.1 seconds Total objects: 132 (1012.8 KB) External objects: 27 (307.3 KB)
    – frankwatching.com
    Total loading time: 4.2 seconds Total objects: 51 (626.2 KB) External objects: 8 (333.7 KB)

    🙂 Slechts 1 test en de resultaten per keer verschillen erg. Wie voert er de komende dagen per site elke 10 minuten een test uit?

  3. willem@jsoft.nl'

    Leuke tool dat pingdom maar qua absolute getallen niet erg betrouwbaar. Een laadtijd van 15 seconden die bij een tweede poging terug valt naar 5 seconden. Firebug geeft voor dezelfde site consistent 2-3 seconden net als YSlow. Ook laat pingdom 10 parallele downloads van dezelfde server zien wat een browser niet hoort te doen (volgens de HTTP 1.1 specs maximaal 2 van dezelfde hostname) en simultane downloads van meerdere javascript bestanden wat de meeste browsers ook niet doen.

    Maar goed de absolute getallen zijn niet heel interessant. Wel interessant is dat javascript het downloaden van de pagina blokkeert tot de javascript gedownload en uitgevoerd is (zie http://yuiblog.com/blog/2008/07/22/non-blocking-scripts/ voor een mogelijke fix) dat je door wat extra (sub)domeinnamen als img.mijnsite.nl je snelheid een flinke boost kan geven. In YSlow en Firebug zie je je download grafiek krimpen 🙂

    Yahoo heeft trouwens erg veel nuttige informatie op het gebied van optimalisatie voor snelheid http://developer.yahoo.com/performance/rules.html. Het onderdeel CSS sprites (http://alistapart.com/articles/sprites) is een aanrader om je site een boost te geven.

    En als je snelheidsoptimalisatie extreem wilt doorvoeren kun je met YUI (Yahoo Interface Library) zelf plaatjes onder de ‘fold’ dynamisch laden nadat de complete pagina beschikbaar is.

    Rendertijd in de browser is weer een heel ander verhaal. Ik krijg jeuk van paginas die na het laden nog enkele seconden nodig hebben om allerlei javascript ‘truuken’ uit te halen. Vaak gaat dit gepaard met het verspringen van de layout (ben je al bezig de pagina te lezen verspring de paragraaf ineens omdat er nog een blok reclame ingevoegd moet worden….) Niet dat ik wat tegen javascript ‘truuken’ heb, is m’n dagelijks brood, maar doe het alsjeblieft netjes 😉 Vraag me af of er onderzoek is gedaan naar bounce rates op paginas met en zonder verspringende layout.

  4. reinoutw@hotmail.com'

    @Willem Joosten: De resultaten van Pingdom heb ik zelf ook gecheckd bij onze IT afdeling en daaruit kwam ook naar voren dat Pingdom rare dingen doet. Volgens mij haalt Pingdom alle verwijzingen op die hij tegenkomt, dus ook images waarnaar verwezen wordt in CSS bestanden, maar die niet op de pagina terugkomen (onzin dus eigenlijk).

    Dank voor de nuttige aanvullingen, heel bruikbaar!
    Helaas werd je reactie als spam gemarkeerd, waardoor hij wat laat op de site is gekomen (pas net). Excuses daarvoor.

  5. willem@jsoft.nl'

    “Volgens mij haalt Pingdom alle verwijzingen op die hij tegenkomt, dus ook images waarnaar verwezen wordt in CSS bestanden, maar die niet op de pagina terugkomen (onzin dus eigenlijk).”

    Eigenlijk wel een leuke vraag of dat onzin is. Als je de plaatjes pas laadt op het moment dat ze nodig zijn zou dat een vertraging in het renderen kunnen geven (aangenomen dat de verwijzing vanuit inline css komt) Maar goed dat gaat wel erg diep voor dit blog.

    Als m’n post om een andere reden dan teveel externe links in de post als spam gemarkeerd is wil je deze reden(en) dan naar me mailen? Niets irritanter dan onterecht in een of ander filter te staan.

  6. reinoutw@hotmail.com'

    @Willem Joosten: Dit blog gaat zo diep als wij zelf willen 🙂 De images stonden niet via inline CSS in de HTML, maar via de link tag. Zou dat btw uitmaken? Je geeft aan dat het rendervertraging kan geven, komt dat omdat de verwijzigingen wel al worden ingeladen? Of wat is hier de oorzaak van?

    Door de vele links werd je bericht als spam gemarkeerd, volgens mij waren er geen andere redenen.

  7. @willem, dank voor je uitgebreiden aanvulling. Je noemt een aantal nuttige tools / informatiebronnen.

    “Vraag me af of er onderzoek is gedaan naar bounce rates op paginas met en zonder verspringende layout”

    Een hele lastige. Ik vermoed weinig verschil in boucerates, maar wel in totale gebruikerservaring, dus onder aan de streep minder conversie. Dat is echter niet te vergelijken bij verschillende sites. Gewoon ouderwets doen wat goed voelt en bezoekers niet te veel verwarren zou mijn tip zijn…

  8. aaronpeters.nl@gmail.com'

    Wil je de echte laadtijden van je bezoekers weten?
    Gebruik dan een meettool die met een echte browser werkt (Pingdom doet dit niet).

    Een aanrader is http://www.webpagetest.org/test
    Kies locatie Amsterdam en pas eventueel de snelheden aan (ik werk altijd met 3000 down, 500 up, omdat dit anno juni 2010 de snelheden zijn van het Ziggo en KPN instapabonnement).

    De test wordt gedaan door op een normale Windows XP pc de IE7 browser te openen en het opgegeven URL te laden.
    De laadtijden die deze tool teruggeeft zijn respresentatief en mijn inziens ‘juist’.

    Je kunt er ook eenvoudig de laadtijden van je concurrenten mee meten.

  9. jandevries@webhelder.com'

    @Aaron bedankt ik kende deze nog niet werkt prima en zeer uitgebreid. Net al even met IT besproken en gedeeld 🙂

Reacties zijn gesloten.