Pingdom snelheidstest: de ulltieme gids

Vandaag duiken we in hoe je de gegevens van de populaire website-snelheidstest Pingdom beter kunt gebruiken en begrijpen. Je kunt de tool inzetten om een watervalanalyse van je WordPress site te maken. Daarmee diagnosticeer je prestatieproblemen sneller en voorkom je dat je een probleem verkeerd inschat.

We zien vaak dat WordPress gebruikers de gegevens in de Pingdom snelheidstest verkeerd interpreteren. Soms leidt dat ertoe dat een website wordt geconfigureerd in een staat die slechter is dan voorheen. Onthoud dat tools als deze bedoeld zijn als richtlijn. Ze zijn nooit 100% nauwkeurig. Het belangrijkste is dat je consistent bent en dezelfde tool gebruikt voor al je tests.

Wat is de Pingdom snelheidstest?

Pingdom is een Zweeds bedrijf (nu eigendom van SolarWinds) dat verschillende diensten aanbiedt, zoals uptime monitoring, pagina-snelheidsmonitoring, transactiemonitoring, servermonitoring en visitor insights (RUM). Een van de dingen waar ze het meest om bekendstaan is hun gratis website-snelheidstest. Het is binnen de WordPress community een van de populairste tools om prestaties te testen.

Waarom is de tool zo populair? Om te beginnen is het waarschijnlijk de eenvoudigste snelheidstest die er is. Niet iedereen is een expert op het gebied van webprestaties, en sommige alternatieve tools kunnen behoorlijk overweldigend zijn voor de doorsnee WordPress gebruiker. Soms is minder meer, zoals ze zeggen. Uiteindelijk gaat het er alleen om hoe snel je website is en hoe je hem sneller kunt maken.

Met Pingdom test je de snelheid van elke website vanaf 7 verschillende locaties (5 continenten), strategisch verspreid over de wereld:

• Azië – Japan – Tokio
• Europa – Duitsland – Frankfurt
• Europa – Verenigd Koninkrijk – Londen
• Noord-Amerika – VS – Washington D.C.
• Noord-Amerika – VS – San Francisco
• Pacific – Australië – Sydney
• Zuid-Amerika – Brazilië – São Paulo

Opmerking: We hebben gemerkt dat niet alle testlocaties altijd beschikbaar zijn. Waarschijnlijk komt dat door onderhoud, of doordat een locatie overbelast is geraakt door te veel gelijktijdige tests. Is een testlocatie die je gebruikte er niet meer? Kom dan over een uur of twee terug. Meestal verschijnt hij dan weer.

Welke testlocatie je kiest, hangt af van de fysieke locatie waar je website wordt gehost. Dit is waar netwerklatency om de hoek komt kijken. Daar gaan we hieronder dieper op in.

Watervalanalyse met de Pingdom snelheidstest

Een webpagina bestaat uit verschillende onderdelen, zoals HTML, JavaScript, CSS, afbeeldingen en video’s. Elk onderdeel genereert verzoeken om te renderen wat je op je webpagina ziet. Over het algemeen geldt: hoe meer verzoeken je hebt, hoe trager je website laadt. Dat is niet altijd zo, maar meestal wel.

Hieronder splitsen we elk onderdeel van Pingdom uit en leggen we in meer detail uit wat de informatie betekent voor de algehele prestaties van je website en hoe je een watervalanalyse uitvoert.

• Pingdom samenvatting
• Prestatie-inzichten
• Responsecodes
• Contentgrootte en -verzoeken per contenttype
• Contentgrootte en -verzoeken per domein
• Watervalgrafiek
• Casestudy domeinconfiguratie

Pingdom samenvatting

Wanneer je je WordPress site door Pingdom haalt, genereert de tool een prestatiecijfer, een totale laadtijd, de totale paginagrootte en het aantal verzoeken op je website. Ons voorbeeld is een e-commerce site die draait op Easy Digital Downloads. Hij wordt gehost op de razendsnelle servers van Kinsta.

Zoals je ziet hebben we onze eerste test uitgevoerd en een score van 88/100 behaald op Pingdom, met een totale laadtijd van 541 ms. De test laat ook de totale grootte van onze gecombineerde assets en het aantal verzoeken zien.

Vervolgens voerden we een extra test uit, en nu is onze totale laadtijd 392 ms, bij dezelfde paginagrootte en hetzelfde aantal verzoeken. Hoe kan dat? 🤔 Dit gebeurt zodra je je website meerdere keren door de Pingdom snelheidstest haalt. Bij grotere sites zijn de verschillen nog groter.

Er zijn drie belangrijke oorzaken: DNS-caching, CDN-caching en WordPress–caching. Daarom moet je altijd meerdere tests uitvoeren. Externe aanroepen naar externe bronnen en API’s kunnen hier uiteraard ook invloed op hebben. Hieronder lees je waarom in onze watervalanalyse.

Wil je een betere Pingdom score voor je WordPress site? Afhankelijk van je site en configuratie is een perfecte 100/100 niet altijd haalbaar, zeker niet voor wie e-commercesites en marketingpixels beheert. Maar wat tijd steken in het verbeteren van je score is een uitstekend beginpunt. Het gaat uiteindelijk om de algehele snelheid.

Soms is de gebruikerservaring net weg belangrijker dan het uitvoeren van bepaalde trucs voor webprestaties die je online tegenkomt. Vergeet de gebruikerservaring dus niet! Wees gerust: hieronder delen we een aantal tips en trucs waarmee we de bovenstaande site hebben gebracht waar hij nu is. Blijf dus lezen.

WinningWP voerde onafhankelijke snelheidstests uit waarbij Kinsta werd vergeleken met andere toonaangevende hostingproviders. De conclusie: Kinsta was “veel sneller”, met een gemiddelde tijd van slechts 394 ms.

Paginaprestaties verbeteren

Het onderdeel Performance Insights, tegenwoordig “Improve Page Performance” is in 2018 bijgewerkt: er zijn oude items verwijderd en nieuwe toegevoegd. Hoogstwaarschijnlijk omdat sommige suggesties niet meer zo relevant zijn als vroeger. Op het gebied van webprestatie-optimalisatie verandert er namelijk voortdurend iets. En het kan lastig worden zodra mensen alleen nog maar de perfecte Pingdom score najagen.

We laten dit hele gedeelte toch in ons artikel staan (oud en nieuw), omdat het essentieel is om te begrijpen hoe deze scores worden berekend. Ze zijn in de kern allemaal gebaseerd op de regels van Google PageSpeed Insights. Over het algemeen geldt: verbeter je deze punten op je site, dan dalen je laadtijden.

Hier zijn een paar categorieën uit het gedeelte Improve Page Performance:

• Een Content Delivery Network (CDN) gebruiken
• HTTP 404 (Not Found) fout vermijden
• Redirects minimaliseren
• Expires headers toevoegen
• Query strings verwijderen uit statische bronnen
• Cookievrije domeinen gebruiken
• Downloads parallelliseren over hostnamen
• Een cache-validator opgeven
• Een Vary: Accept-Encoding header opgeven

Laten we er een paar bekijken en zien welke vandaag de dag nog relevant zijn.

Een Content Delivery Network (CDN) gebruiken

Een van de belangrijkste diensten die je tegenwoordig op je WordPress site moet instellen, is een Content Delivery Network (CDN). Dit is een netwerk van servers (ook wel POP’s genoemd) verspreid over de hele wereld. Ze zijn ontworpen om kopieën van de statische (en soms dynamische) content van je WordPress site te hosten en uit te leveren, zoals afbeeldingen, CSS, JavaScript en videostreams.

Ben je klant bij Kinsta? Dan krijg je een CDN bij onze hosting pakketten. Inschakelen kost een paar klikken. Denk hierbij aan voordelen als een prestatieverbetering (lagere TTFB en netwerklatentie), lagere bandbreedte- en hostingkosten en zelfs SEO-voordelen.

Belangrijk: De onlangs bijgewerkte Pingdom-tool heeft op dit moment een bug bij het correct detecteren van CDN-providers.

Een paar CDN-providers van derden die we aanraden:

• KeyCDN (dit is wat het Kinsta CDN aandrijft)
• Cloudflare
• CDN77

In onze eigen CDN-snelheidstests zagen we dat een CDN de laadtijd van pagina’s in sommige gevallen met meer dan 50% kan verlagen.

HTTP 404 (Not Found) fout vermijden

Dit onderdeel heette eerder “avoid bad requests”. En het is altijd relevant. Deze waarschuwing is precies wat de naam zegt: het gaat om een verzoek dat niet succesvol kon worden afgerond. Dit gebeurt meestal wanneer je handmatig naar een asset of afbeelding linkt die inmiddels is verwijderd, met een 404-fout als gevolg. In Pingdom verschijnt dit als een oranje cirkel, samen met een 404 in de status van de response header.

Zorg er altijd voor dat elk verzoek op je site terugkomt met een successtatus. Zo voorkom je dat er verzoeken worden gegenereerd naar onderdelen die niet meer bestaan.

Redirects minimaliseren

Te veel redirects zijn altijd iets om voor op te passen. Eenvoudige redirects, zoals een enkele 301-redirect, HTTP naar HTTPS of www naar non-www (of andersom), zijn acceptabel. Vaak zijn ze zelfs nodig in delen van je website. Toch hebben ze allemaal een prijs voor je prestaties. En zodra je redirects op elkaar gaat stapelen, is het essentieel om te beseffen hoe ze de prestaties van je site beïnvloeden. Dit geldt voor pagina- en bericht-redirects, afbeeldingsredirects, alles.

Een redirect verschijnt in Pingdom als een blauwe cirkel, samen met een 301 of 302 in de status van de response header.

Hoeveel invloed hebben redirects op je site? Laten we een kleine test doen. Eerst voeren we een snelheidstest uit op onze contactpagina. We krijgen een totale laadtijd van 417 ms, zoals je hieronder ziet.

Vervolgens passen we de URL iets aan en voeren we nog een snelheidstest uit om het effect van meerdere redirects te zien. Zoals je ziet duurt het laden van dezelfde pagina nu 695 ms. Dat is een toename van 66%. Au!

Bekijk onze uitgebreide post over WordPress redirects en de best practices voor snellere prestaties.

Expires headers toevoegen

Deze suggestie heette eerder “leverage browser caching”. Eenvoudig gezegd: elk script op je WordPress site moet een HTTP cache header hebben. Die bepaalt wanneer de cache van het bestand verloopt. Om dit op te lossen, zorg je dat je WordPress host de juiste cache-control headers en expires headers heeft ingesteld. Kinsta heeft deze headers op al onze servers staan.

Bekijk de stappen om handmatig caching headers aan je server toe te voegen en lees onze handleiding voor het toevoegen van expires headers.

Het andere probleem: je kunt geen caching headers toevoegen aan scripts van derden, omdat je geen controle hebt over hun webservers. Veelvoorkomende boosdoeners zijn het Google Analytics-script en marketingpixels van bijvoorbeeld Facebook en Twitter. Een oplossing is om je Google Analytics-script lokaal te hosten (al wordt dit niet officieel ondersteund) met een plugin van derden. WP Rocket heeft nu ook een optie om je Facebook-marketingpixel lokaal te hosten.

Hoeveel het lokaal hosten van scripts oplevert voor je prestaties, verschilt per geval. Het voordeel is dat je volledige controle over het bestand hebt en het vanaf je CDN kunt uitleveren. Bovendien verdwijnt er weer een DNS-verzoek naar een derde partij. Houd er wel rekening mee dat deze bestanden mogelijk al in de browsercache van bezoekers staan.

Bekijk ons uitgebreide artikel over hoe je de waarschuwing voor leverage browser caching verhelpt.

Query strings verwijderen uit statische bronnen

Een ander veelvoorkomend punt is het omgaan met query strings. Je CSS- en JavaScript-bestanden hebben meestal de bestandsversie aan het einde van hun URL’s, zoals https://domain.com/file.min.css?ver=4.5.3. Sommige servers en proxyservers kunnen query strings niet cachen. Door ze te verwijderen verbeter je dus soms je caching.

Of je voegt de volgende code handmatig toe aan het bestand functions.php van je thema. Een beter alternatief is een gratis plugin zoals Code Snippets om de code toe te voegen. Zo hoef je je thema niet rechtstreeks aan te passen.

function remove_query_strings() {
   if(!is_admin()) {
       add_filter('script_loader_src', 'remove_query_strings_split', 15);
       add_filter('style_loader_src', 'remove_query_strings_split', 15);
   }
}

function remove_query_strings_split($src){
   $output = preg_split("/(&ver|?ver)/", $src);
   return $output[0];
}
add_action('init', 'remove_query_strings');

Voordat je query strings van je site verwijdert, is het belangrijk om te weten waarom ze worden gebruikt. WordPress ontwikkelaars gebruiken meestal versiebeheer op bestanden om cachingproblemen te omzeilen.

Brengen ze bijvoorbeeld een update uit en verandert style.css van ?ver=4.6 naar ?ver=4.7, dan wordt dit als een compleet nieuwe URL behandeld en niet gecached. Verwijder je de query strings en werk je daarna een plugin bij, dan kan het zijn dat de gecachte versie wordt blijven geserveerd. In sommige gevallen verstoort dat de weergave van je site, totdat de bron in de cache verloopt of de cache volledig wordt geleegd.

Sommige CDN’s kunnen query strings wél cachen. Het Kinsta CDN kan dat en doet dat standaard. Ben je dus Kinsta-klant, dan worden query strings al gecached op je assets.

Bekijk onze uitgebreide tutorial over het verwijderen van query strings uit statische bronnen.

Cookievrije domeinen gebruiken

We hebben een uitgebreid artikel over het omgaan met de waarschuwing serve static content from a cookieless domain. Vaak kun je deze waarschuwing negeren, omdat nieuwe protocollen zoals HTTP/2 dit minder belangrijk maken. Een nieuwe verbinding is meestal duurder dan alles over dezelfde verbinding streamen. Twee manieren om dit op te lossen: een CDN-provider gebruiken die de cookies wegstript, of een apart domein of subdomein aanmaken.

Bekijk voor meer informatie onze post over het gebruik van cookievrije domeinen.

Componenten comprimeren met GZIP

De waarschuwing “Compress components with gzip” verschijnt wanneer Pingdom een bestand vindt dat niet is gecomprimeerd met GZIP. GZIP is een compressiemethode om de grootte van tekstgebaseerde bestanden zoals HTML-documenten en CSS/JS-bestanden te verkleinen. GZIP-compressie wordt ingeschakeld op de server en comprimeert webpagina’s en bestanden voordat ze naar bezoekers worden gestuurd. Uit onze tests bleek dat het inschakelen van GZIP-compressie de bestandsgrootte van een verzoek met meer dan 78% verkleinde.

Bij Kinsta hoef je je geen zorgen te maken over het inschakelen van GZIP, want elke Kinsta-site profiteert al van Brotli-compressie, een sneller alternatief voor GZIP-compressie. Dat is allemaal te danken aan onze unieke Cloudflare integratie. Het betekent dat je Kinsta-site sneller is dan concurrenten die GZIP gebruiken en snel laadt voor mensen op kleinere apparaten.

Zie je “Compress components with gzip” nog steeds nadat je GZIP op je server hebt ingeschakeld? Dan is het mogelijk dat een server die een externe applicatie host die je site nodig heeft, geen GZIP- of Brotli-compressie heeft ingeschakeld. In dat geval kun je zelf niets doen om het gedrag van die server te veranderen.

Downloads parallelliseren tussen hostnames

De waarschuwing “Parallelize Downloads Across Hostnames” komt voort uit een beperking van HTTP/1.1: webbrowsers kunnen maar een beperkt aantal gelijktijdige verbindingen met een host maken, meestal zes. Je ziet deze waarschuwing vooral op websites met een groot aantal verzoeken. Vroeger was de enige manier om deze beperking te omzeilen het toepassen van zogeheten domain sharding.

Maar stel dat je een webhost of CDN-provider gebruikt die HTTP/2 ondersteunt. In dat geval kun je dit veilig negeren, omdat meerdere bronnen nu parallel via één verbinding worden geladen. Je kunt ook onze tutorial bekijken over hoe je de waarschuwing voor parallelle downloads tussen hostnames met domain sharding.

Een cache-validator opgeven

Deze waarschuwing verwijst naar ontbrekende HTTP caching headers die in elk antwoord van de origin server moeten zitten, omdat ze zowel de cache valideren als de duur ervan bepalen. Worden de headers niet gevonden, dan wordt er telkens opnieuw een verzoek voor de bron gegenereerd, wat de belasting van je server verhoogt. Tot deze headers behoren last-modified, ETag, Cache-Control en Expires. Net als bij de leverage browser caching-waarschuwing zou je WordPress host deze headers automatisch moeten toevoegen. Zie je dit bij verzoeken van derden, dan kun je er niets aan doen, omdat je geen controle over hun webservers hebt.

Lees onze diepgaande post over hoe je de waarschuwing specify a cache validator oplost.

Een Vary: Accept-Encoding header opgeven

We hebben een uitgebreid artikel over het oplossen van de waarschuwing Specify a Vary: Accept-Encoding header. Dit is een HTTP-header die in elk antwoord van de origin server hoort, omdat hij de browser vertelt of de client gecomprimeerde versies van de content aankan. Deze header wordt automatisch toegevoegd aan alle servers van Kinsta.

Pingdom responsecodes

Het volgende onderdeel van de Pingdom snelheidstest zijn de responsecodes. Responsecodes, ook wel HTTP-statuscodes genoemd, zijn als een kort briefje van de webserver dat bovenaan een webpagina wordt geplakt. Het is een bericht van de webserver dat je laat weten hoe het verzoek om de pagina te bekijken is verlopen. Een paar veelvoorkomende:

• 200: “Everything is OK” Dit is de code die je krijgt wanneer een webpagina of bron precies werkt zoals verwacht.

  

• 301: “The requested resource has been moved permanently.” Deze code krijg je wanneer een webpagina of bron permanent is vervangen door een andere bron. Hij wordt gebruikt voor permanente URL-redirects.

  

• 404: “The requested resource was not found.” De bekendste foutmelding van allemaal. Deze code betekent dat de opgevraagde bron niet bestaat en dat de server niet weet of die ooit heeft bestaan.

  

Meer over de verschillende responsecodes lees je in ons uitgebreide artikel over HTTP-statuscodes.

Contentgrootte en -verzoeken per contenttype

De volgende secties zijn de contentgrootte per contenttype en de verzoeken per contenttype. Beide secties zijn handig om snel te zien wat de meeste resources op je webpagina opslokt. Volgens HTTP Archive vormen afbeeldingen gemiddeld 43% van de totale grootte van een webpagina. Dat zien wij meestal ook. Maar zoals je hieronder op deze site ziet, is dat niet altijd zo.

Wil je je afbeeldingen optimaliseren? Dan raden we je sterk aan onze uitgebreide post te lezen over het optimaliseren van afbeeldingen voor het web en over WebP. Er zijn veel goede tools en plugins om je afbeeldingen verder te comprimeren, zodat ze niet het grootste deel van je paginalading vormen. In ons voorbeeld hierboven gebruikt de site grote font awesome-icons in plaats van afbeeldingen. Dat kan een uitstekende strategie zijn die een enorm verschil maakt. En natuurlijk vind je in onze paginasnelheidgids nog meer tips om je content verder te verkleinen.

Contentgrootte en -verzoeken per domein

De sectie Content size by domain is een uitstekende manier om snel te zien welke externe diensten en scripts op je website draaien. In ons voorbeeld zie je dat al onze assets vanaf ons CDN worden geladen. Daarnaast is er de initiële HTML DOC-load voor de website vanaf de webserver en een externe aanroep naar het Google Analytics-domein. Afhankelijk van je site heb je misschien meer externe diensten, zoals Facebook, Twitter, Hotjar, SumoMe, AdRoll, New Relic, CrazyEgg, enzovoort.

Over het algemeen geldt: hoe minder externe verzoeken, hoe beter, want elke externe dienst brengt vertraging, TLS-handshake-vertragingen, DNS-lookups en dergelijke met zich mee. Lees zeker ons diepgaande artikel over het identificeren en analyseren van externe diensten op je WordPress site.

Het is doorgaans het beste om het aantal verzoeken zoveel mogelijk te beperken en de assets op één plek te hosten, bijvoorbeeld door ze naar je webserver of CDN te verplaatsen. Een voorbeeld is font awesome. In plaats van naar het externe script voor font awesome te linken, kun je het downloaden en rechtstreeks uitleveren.

Pingdom watervalgrafiek

En last but not least is er de sectie met verzoeken in de Pingdom snelheidstest, die een watervalgrafiek genereert van alle individuele verzoeken op je webpagina (zie hieronder). Daarmee analyseer je elk verzoek om te zien wat vertragingen en prestatieproblemen op je site veroorzaakt. Dít bedoelen we wanneer we zeggen dat we een watervalanalyse uitvoeren. Hieronder vind je een uitgebreidere samenvatting en definitie van wat elke statuskleur betekent.

DNS (roze)

Wat is DNS eigenlijk? Zie het als een telefoonboek. Er zijn servers, Domain Name Servers genaamd, die informatie over je website bevatten en naar welk IP-adres die moet worden doorgestuurd. Wanneer je je website voor het eerst door Pingdom haalt, voert de tool een verse lookup uit en moeten de DNS-records worden opgevraagd om de IP-informatie te krijgen. Dat kost wat extra opzoektijd. Ook de locatie van de DNS-server speelt mee.

Haal je je website meer dan eens door Pingdom, dan wordt de DNS gecached, omdat de IP-informatie al bekend is en de lookup niet opnieuw hoeft. Daarom verschijnt je website sneller wanneer je hem meerdere keren door Pingdom haalt.

Zoals je in het scherm hieronder ziet, was bij onze 2e test de DNS-opzoektijd bij de eerste DOC-load 3,6 ms. Normaal gesproken daalt dit naar 0 ms, zoals het hoort, omdat het verzoek al gecached is. Dit is een onderdeel dat veel mensen verkeerd interpreteren!

Je kunt het verder optimaliseren door een premium DNS-service te gebruiken, die bovendien een heleboel extra voordelen meebrengt. Onze gratis DNS van Cloudflare is ook snel! Bekijk de Automatic Platform Optimization van Cloudflare.

Er zijn nog andere redenen waarom je website sneller kan lijken na meerdere tests. Eén daarvan is het gebruik van een content delivery network (CDN). Voor wie niet bekend is met een CDN: het is een netwerk van wereldwijde servers die je content (JS, CSS, afbeeldingen, enz.) cachen op locaties dichter bij de bezoeker. Wanneer je je website voor het eerst door Pingdom haalt, moeten de assets misschien vers van het CDN worden gehaald. Een CDN-cache werkt ongeveer hetzelfde als DNS. Eenmaal gecached is het veel sneller bij volgende ladingen.

Nog een tip om DNS te versnellen, is DNS-prefetching. Daarmee kan de browser op de achtergrond DNS-lookups uitvoeren op een pagina. Je doet dit door enkele regels code toe te voegen aan de header van je WordPress site. Hieronder een paar voorbeelden.

<!-- Prefetch DNS for external assets -->
 <link rel="dns-prefetch" href="//fonts.googleapis.com">
 <link rel="dns-prefetch" href="//www.google-analytics.com"> 
 <link rel="dns-prefetch" href="//cdn.domain.com">

Gebruik je WordPress versie 4.6 of nieuwer, dan kun je ook resource hints gebruiken. Ontwikkelaars kunnen het filter wp_resource_hints inzetten om aangepaste domeinen en URL’s toe te voegen voor dns-prefetch, preconnect, prefetch of prerender.

SSL (paars)

De paarse statuskleur staat voor de tijd die je browser nodig heeft voor een SSL/TLS-handshake. Wanneer je een website over HTTPS draait, is er een SSL-certificaat en extra tijd nodig voor het encryptieproces (de SSL/TLS-handshake). Op ons voorbeelddomein hebben we een certificaat op zowel onze webserver bij Kinsta als op ons CDN, KeyCDN. Er is dus een SSL-onderhandelingstijd voor zowel het laden van de HTML-documenten van de webserver als voor onze assets.

HTTPS heeft een kleine overhead, maar die is dankzij HTTP/2 niet langer cruciaal. HTTP/2 is een nieuw protocol dat het web helpt versnellen. Vanwege browserondersteuning is HTTPS vereist om HTTP/2 te kunnen gebruiken. Bekijk onze ultieme gids voor HTTP/2.

Het is ook goed om te weten dat zelfs in 2018 nog niet alle providers HTTP/2 ondersteunen. Dat geldt zowel voor de webhostingkant als de CDN-kant. Ben je dus op zoek naar hosting en een CDN, zorg er dan voor dat beide het ondersteunen! Kinsta is er trots op HTTP/2 te ondersteunen voor al haar WordPress klanten.

Vanaf medio 2018 heeft Pingdom zijn tool eindelijk geüpgraded naar Chrome 60 en hoger. Je ziet de user-agent terug in de request header. Voorheen gebruikten ze Chrome 39, en Chrome ondersteunde HTTP/2 pas vanaf versie 49. We zijn dus blij dat de Pingdom-tool nu alle voordelen van HTTP/2 laat zien bij het uitvoeren van tests! 👏

Connect (groenblauw)

De connect-tijd in Pingdom verwijst naar de TCP-verbinding, oftewel de totale tijd die nodig is om een TCP-verbinding op te zetten. Je hoeft niet te begrijpen hoe dit precies werkt; het is simpelweg een communicatiemethode tussen de host/client en de server die moet plaatsvinden.

Wait (geel)

De wait-tijd van Pingdom verwijst naar de time to first byte, in sommige tools ook bekend als TTFB. TTFB is een meting die de reactiesnelheid van een webserver of andere netwerkbron aangeeft. Over het algemeen is alles onder de 100 ms acceptabel en een goede TTFB. Kom je in de buurt van 300-400 ms, dan is er mogelijk iets verkeerd geconfigureerd op je server of is het tijd om te upgraden naar een betere webstack.

De eenvoudigste manier om je TTFB te verlagen? De twee beste manieren zijn effectieve WordPress caching en een CDN. Laten we een paar tests uitvoeren.

TTFB zonder WordPress host-cache

We voerden eerst een test uit nadat we de cache van onze WordPress site hadden gewist. Dat betekent dat de cache opnieuw moet worden opgebouwd. Onze totale laadtijd was 541 ms en de TTFB (wait-tijd) op ons eerste verzoek was 185,2 ms.

TTFB mét WordPress host-cache

Vervolgens voerden we de test opnieuw uit. De site serveert nu rechtstreeks vanuit de cache. Zoals je ziet, zijn onze totale laadtijden gedaald naar 392 ms en is de TTFB op het eerste verzoek nu 52,8 ms! Dat is het verschil dat caching maakt.

Heb je een website die bezoekers in verschillende delen van het land of over de hele wereld bedient? Dan is een CDN de andere eenvoudige manier om je TTFB drastisch te verlagen. Ook hiervoor voerden we een paar tests uit om het verschil te laten zien.

TTFB zonder CDN

We voerden eerst een test uit met een uitgeschakeld CDN. Zoals je ziet was onze totale laadtijd 1,93 s en onze gemiddelde TTFB op een asset ongeveer 176 ms.

TTFB mét CDN

Vervolgens schakelden we ons CDN in en voerden we de test opnieuw uit. Onze totale laadtijden daalden naar 1,21 s en onze gemiddelde TTFB op een CDN-asset is nu 4,6 ms! Wat een verschil maakt een CDN.

Nog iets belangrijks: we kozen de locatie “Pacific – Australië – Sydney” voor deze test. Waarom? Omdat we je de werkelijke verbetering wilden laten zien. Onze WordPress site in dit voorbeeld wordt door Kinsta gehost op een centrale locatie in de VS. Door de test vanuit Australië uit te voeren, laten we zien hoe de Kinsta CDN-caching de snelheid verhoogt en de TTFB verlaagt.

En natuurlijk is een goede WordPress host met een doordachte architectuur ook cruciaal voor een lagere TTFB.

Send (oranje) en Receive (groen)

De send- en receive-status in Pingdom hebben weinig uitleg nodig. De send-tijd is simpelweg de tijd die de webbrowser nodig heeft om gegevens naar de server te sturen. De receive-tijd is de tijd die de webbrowser nodig heeft om gegevens van de server te ontvangen. Beide zijn in je tests meestal erg laag of zelfs afwezig.

HTTP response headers

Tijdens je watervalanalyse kun je ook op een individueel verzoek klikken en de HTTP response headers bekijken. Die leveren waardevolle informatie. In het scherm hieronder zien we meteen of gzip is ingeschakeld op de webserver en of het verzoek vanuit de cache wordt geserveerd (HIT, wat anders MISS zou tonen), plus de cache-control headers, expires headers, de browser-user-agent en meer.

Casestudy domeinconfiguratie

Nu je helemaal hier bent gekomen in dit deel over de watervalanalyse, dan staat je iets moois te wachten. Het is altijd vervelend wanneer mensen tips en casestudies delen, maar niet hoe ze alles precies hebben opgezet. Hieronder vind je onze exacte configuratie voor het casestudydomein dat we hierboven hebben gebruikt. Je mag het gerust kopiëren.

Architectuur

• Het casestudydomein wordt gehost bij Kinsta in de Verenigde Staten. Kinsta biedt momenteel 27 verschillende datacenters om uit te kiezen.
• Kinsta gebruikt HTTP/2, Nginx en MariaDB, wat bijdraagt aan de snelle laadtijden.
• De site gebruikt KeyCDN, dat het Kinsta CDN aandrijft. Gratis CDN-bandbreedte zit bij alle hosting pakketten inbegrepen.
• De site gebruikt geen caching plugin. Kinsta cacht alles op serverniveau, wat de zaken enorm vereenvoudigt!
• De site gebruikt PHP 7.3. Nieuwere PHP-versies laten steevast flinke prestatieverbeteringen zien. Bekijk deze PHP benchmarks. Bij Kinsta wissel je met één druk op de knop tussen de twee.

WordPress plugins en thema

Hier is een lijst met plugins die de prestaties van de WordPress e-commerce site beïnvloeden.

• De premium Imagify plugin wordt gebruikt om afbeeldingen te comprimeren.
• De gratis Safe SVG plugin wordt gebruikt om SVG-afbeeldingen te uploaden naar de WordPress site.
• Het premium WordPress thema GeneratePress is gebruikt om de EDD-site te bouwen.

Aanbevolen tutorials om verder te lezen:

• Render-blocking JavaScript en CSS elimineren
• Emoji’s uitschakelen in WordPress
• Embeds uitschakelen in WordPress
• 100/100 scoren in Google PageSpeed Insights met WordPress
• Een hoog Admin-Ajax-gebruik op je WordPress site diagnosticeren

Samenvatting

Zoals je ziet: als je weet hoe de Pingdom snelheidstest werkt en wat alle grafieken betekenen, kun je met alle data een betere beslissing nemen op het gebied van prestaties.

Een watervalanalyse is cruciaal om te weten hoe je resources worden geladen en hoe ze worden beïnvloed door je WordPress host, fysieke locatie, een CDN, enzovoort. We hopen dat deze post je heeft geholpen om problemen met de snelheid en prestaties van je site beter op te lossen.

Heb je nog andere goede Pingdom-tips? Laat het ons weten in de reacties hieronder!