Pingdom snelheid meettool: de ultieme handleiding voor 2024

Vandaag willen we ingaan op hoe we de gegevens van Pingdom, de populaire tool om de snelheid van websites te testen, beter kunnen gebruiken en begrijpen. Je kunt deze tool gebruiken om een zogenaamde watervalanalyse te doen van je WordPress-website. Hiermee kan je gemakkelijk prestatieproblemen diagnosticeren, maar de tool helpt je ook om een foute diagnose te voorkomen.

We zien vaak dat WordPress-gebruikers de gegevens van Pingdom verkeerd interpreteren en dit leidt ertoe dat ze hun site soms naar een nog slechtere staat configureren. Vergeet niet dat geen enkele tool, en Pingdom valt hier dus ook onder, 100% nauwkeurig is en de resultaten slechts als leidraad genomen moeten worden. Het belangrijkste is om consistent te zijn en dezelfde tool te gebruiken voor al je tests.

Pingdom

Pingdom is een in Zweden gevestigd bedrijf (nu eigendom van SolarWinds) en biedt een verscheidenheid aan diensten. Ze bieden monitoring aan van onder ander andere uptime, paginasnelheid, transacties en servers, maar geven ook inzicht in bezoekers van je website (RUM). Waarschijnlijk een van de dingen waar ze het meest bekend om zijn, is hun gratis tool om de snelheid van websites mee te testen. Het is een van de meest populaire hulpmiddelen voor het testen van prestaties binnen de WordPress-gemeenschap.

Waarom is Pingdom zo populair? Allereerst is de tool extreem makkelijk te gebruiken! Niet iedereen is een expert op het gebied van webprestaties en voor de typische gebruiker van WordPress kunnen testtools al snel overweldigend zijn. Soms zit de kracht dus echt in eenvoud. Als puntje bij paaltje komt, draait het om slechts twee dingen: hoe snel is jouw website nu en hoe kan je deze sneller maken?

Met Pingdom kun je de snelheid van een website testen vanaf 7 verschillende locaties (5 continenten), die strategisch zijn verspreid over onze planeet:

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

Opmerking: we hebben gemerkt dat soms niet alle testlocaties beschikbaar zijn. Dit komt hoogstwaarschijnlijk omdat er onderhoud werd gepleegd of omdat er te veel mensen op die server aan het testen waren. Als de locatie die je zoekt niet beschikbaar is, is deze vaak in een uurtje of twee wel weer terug.

De locatie die je kiest is heel belangrijk, omdat deze betrekking heeft op waar jouw website daadwerkelijk wordt gehost. Dit is waar de term netwerklatentie in het spel komt. We zullen daar hieronder in meer detail op ingaan.

Watervalanalyse met de Pingdom Speed Test Tool

Een webpagina bestaat uit verschillende items, zoals HTML, JavaScript, CSS, afbeeldingen en video’s. Elk van deze genereert verzoeken om te renderen wat jij op jouw website ziet. Meestal geldt hoe meer verzoeken je hebt, hoe langzamer de website wordt geladen (dit is niet altijd het geval, maar het klopt vaak wel).

Hieronder gaan we elke Pingdom-sectie ontleden en in meer detail uitleggen wat de informatie betekent, aangezien deze informatie betrekking heeft op de algehele prestaties van jouw website en de manier waarop je de watervalanalyse uitvoert.

• Samenvatting van Pingdom
• Prestatie-inzicht
• Responscodes
• Contentgrootte en aantal verzoeken van elk type
• Contentgrootte en aantal verzoeken van elk domein
• Watervalgrafiek
• Casestudy domeinconfiguratie

Samenvatting van Pingdom

Wanneer je jouw WordPress-website door Pingdom haalt, genereert dit een prestatiescore, een totale laadtijd, de totale paginagrootte en het aantal verzoeken dat je op de website hebt.In ons voorbeeld gebruiken we ons casestudy-domein perfmatters.io, een e-commercesite dat op Easy Digital Downloads draait. De website wordt gehost op de razendsnelle servers van Kinsta.

Zoals je kunt zien hebben we in onze eerste test direct een score van 88/100 en een totale laadtijd van 541ms. Ook laat de tool ons de totale omvang van onze gecombineerde items en het aantal verzoeken weten.

Vervolgens hebben we een aanvullende test uitgevoerd en nu is onze totale laadtijd 392ms, met dezelfde paginalaadtijd en hetzelfde aantal verzoeken! Hoe kan dit? 🤔 Als je jouw website een aantal keren door Pingdom haalt, dan kom je waarschijnlijk hetzelfde tegen. En het verschil is bij grotere sites nog groter.

Er zijn drie redenen waarom dit gebeurt: DNS-caching, CDN-caching en WordPress-caching. Zij zijn de reden dat je je tests altijd meer dan een keer moet uitvoeren. Ook externe verzoeken naar bronnen buiten je site en API’s kunnen hier invloed hebben. In de watervalanalyse verderop in dit artikel leggen we uit waarom dit zo is.

Wil je een betere Pingdom-score krijgen op jouw WordPress-website? Afhankelijk van jouw site en configuratie is het misschien niet mogelijk om een perfecte 100/100 te scoren en dit geldt specifiek voor eigenaren van e-commerce-websites met marketing pixels. Maar het is natuurlijk altijd een goed idee om je score te verbeteren! Snelheid is namelijk misschien wel het belangrijkste onderdeel van een website.

Vergeet de gebruikerservaring niet! Maar wees gerust, we zullen hieronder enkele tips en trucs met je delen over hoe we de bovenstaande site hebben gebracht tot waar hij is, dus blijf lezen!

Paginaprestaties verbeteren

De sectie die eerste ‘Performance insights’ heette, heeft in 2018 de nieuwe naam ‘Improve page performance’ gekregen. Daarnaast zijn een aantal items verwijderd en een aantal nieuwe toegevoegd. Dit komt waarschijnlijk omdat sommige van de suggesties die de tool maakte, tegenwoordig minder relevant zijn. Als het gaat om optimalisatie van webprestaties, zijn zaken continu in beweging. Om die reden kan het problematisch zijn om blind te vertrouwen op een perfecte Pingdom-score.

Toch willen we deze sectie wel behandelen in dit artikel (met oude en nieuwe factoren), omdat het belangrijk is om te begrijpen hoe deze scores tot stand komen. Deze zijn allemaal gebaseerd op de regels van Google PageSpeed Insight. In het algemeen zal je een afname van je totale laadtijden zien wanneer je deze punten verbetert op je website.

Hier zijn een aantal categorieën uit de ‘Improve page performance’-sectie van Pingdom:

• Een Content Delivery Network (CDN) gebruiken
• De HTTP 404 (Not Found)-foutmelding voorkomen
• Redirects minimaliseren
• Expires-headers toevoegen
• Queryreeksen uit statische bronnen verwijderen
• Cookievrije domeinen gebruiken
• Parallelle downloads via alle hostnames
• Een cachevalidator opgeven
• Een ‘Vary: Accept-Encoding’-header opgeven

Laten we nu een paar van deze nader beschouwen en zien welke nog steeds actueel zijn.

Een Content Delivery Network (CDN) gebruiken

Een van de belangrijkste zaken die je vandaag de dag op je WordPress-site moet hebben is een Content Delivery Network (CDN). Een CDN is een netwerk van servers (ook wel bekend als POP’s) die verspreid zijn over de hele wereld. Ze zijn ontworpen om kopieën van de statische (en in sommige gevallen dynamische) content van je WordPress-site op te slaan en te leveren. Denk hierbij aan afbeeldingen, CSS, JavaScript en videostreams.

Als je klant bent van Kinsta, dan zit CDN inbegrepen bij al onze hostingpakketten. Met een paar klikken heb je het ingeschakeld! Enkele voordelen van een CDN zijn verbeteringen in prestatie (lagere TTFB en netwerklatentie), lagere kosten voor bandbreedte en hosting en zelfs SEO-voordelen.

Kinsta klanten kunnen daarnaast genieten van een snelle en gemakkelijke boost voor algehele siteoptimalisatie door je code te minimaliseren met behulp van de codeminificatiefeature die is ingebouwd in het MyKinsta dashboard. Dit stelt klanten in staat om automatische CSS en JavaScript minificatie in te schakelen met een simpele klik, waardoor hun sites worden versneld zonder handmatige inspanning.

Belangrijk: de recentelijk bijgewerkte Pingdom-tool heeft een bug die zorgt dat CDN-providers niet goed worden herkend.

Sommige externe CDN-providers die we aanbevelen zijn:

• KeyCDN (dit is de provider van Kinsta CDN)
• Cloudflare
• StackPath
• CDN77

Uit onze eigen CDN-snelheidstests bleek dat een CDN de laadtijd van pagina’s in sommige gevallen met meer dan 50% kan verlagen!

De HTTP 404 (Not Found)-foutmelding voorkomen

Deze sectie heette eerst ‘bad requests voorkomen’. En dit is altijd relevant! Een ‘bad request’ is een verzoek dat, om welke reden dan ook, niet met succes kon worden voltooid. Meestal gebeurt dit als je handmatig linkt naar een item of afbeelding die sindsdien is verwijderd, wat resulteert in een 404-foutmelding. Dit wordt weergegeven als een oranje cirkel in Pingdom, samen met een 404 op de status van de responsheader.

Zorg er altijd voor dat elk verzoek op je website ergens naartoe leidt. Dit zorgt ervoor dat er geen query’s worden aangemaakt naar items die niet meer bestaan.

Redirects minimaliseren

Iets anders waar je op moet letten is het hebben van te veel redirects. Simpele redirects, zoals een enkele 301-redirect, HTTP naar HTTPS of www naar niet-www (of vice versa) zijn prima, en vaak zelfs ook nodig om bepaalde delen van je website werkend te krijgen. Houd echter wel in het achterhoofd dat elke redirect invloed heeft op de prestaties van je website. En als je redirect op redirect stapelt, is het belangrijk om precies te weten wat de impact is die dit heeft op de prestaties van je website. Dit is van toepassing op alle redirects, van pagina’s, artikelen tot afbeeldingen.

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

Wat is de impact van redirects op je website? Tijd voor een test! Als eerste voeren we een snelheidstest uit op onze contactpagina: https://perfmatters.io/contact/. Zoals je hieronder kan zien, krijgen we een totale laadtijd van 417ms.

Vervolgens passen we de URL aan en voeren een tweede snelheidstest uit om de impact te bekijken van meerdere redirects. http://www.perfmatters.io/contact. Zoals je kan zien, kost het dezelfde pagina nu 695ms om te laden. Dat is een toename van 66%! Niet niks!

Bekijk ons gedetailleerd artikel over WordPress-redirects en de beste tips om je website sneller te maken.

Expires-headers toevoegen

Deze suggestie heette eerst ‘Leverage browser caching’. Eigenlijk komt het erop neer dat elk script op je WordPress-site een HTTP-cache-header moet bevatten (of in ieder geval zou moeten). Deze header bepaalt dus wanneer de cache van het bestand verloopt. Om dit probleem op te lossen moet je ervoor zorgen dat je de juiste cache-control-headers en expires-headers hebt ingesteld. Op de servers van Kinsta staan deze headers automatisch juist ingesteld. Bekijk de stappen voor het handmatig toevoegen van cachingheaders aan je server en lees onze gids over het toevoegen van expires headers.

Externe scripts kunnen soms ook voor problemen zorgen. Wanneer je gebruik maakt van scripts van derden, dan heb je geen toegang tot hun caching-headers, omdat je geen controle hebt over hun webservers. Veelvoorkomende boosdoeners zijn het Google Analytics-script en marketingpixels, zoals die van Facebook en Twitter. Om dit op te lossen kan je je Google Analytics-script lokaal hosten (hoewel dit niet officieel wordt ondersteund) met een plugin zoals Perfmatters. WP Rocket biedt tegenwoordig ook de mogelijkheid om je Facebook-marketingpixel lokaal te hosten.

Wat voor verschil het maakt om zelf de scripts te hosten op de prestaties van je website, hangt voor het grootste deel af van jouw huidige configuratie. Het grote voordeel is dat je volledige controle hebt over het bestand en dit kan leveren via je eigen CDN. Hiermee voorkom je ook extra externe DNS-verzoeken. Het is echter ook belangrijk om te onthouden dat deze bestanden mogelijk al in de browsers van gebruikers zijn opgeslagen.

Bekijk ons uitgebreide artikel over het oplossen van de browser-caching-waarschuwing.

Queryreeksen uit statische bronnen verwijderen

Een ander veel voorkomend probleem is hoe om te gaan met queryreeksen. Jouw 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 queryreeksen niet cachen. Dus door ze te verwijderen, kan je soms je caching verbeteren.

Je kan een premium plugin gebruiken zoals Permatters, waarmee je met een enkele klik queryreeksen kan verwijderen.

Of je kan de volgende code handmatig aan het functions.php-bestand van je thema toevoegen. Mocht je voor de tweede optie gaan, dan raden we de gratis plugin Code Snippets aan om de code toe te voegen. Op deze manier bewerk je niet rechtstreeks de bestanden van je thema.

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 nu meteen begint om alle queryreeksen uit je site te halen, is het misschien goed om even stil te staan bij waar deze reeksen nou eigenlijk voor dienen. Het ‘versieficeren’ van bestanden wordt door WordPress-ontwikkelaars vaak toegepast om problemen met caching te voorkomen.

Als een ontwikkelaar bijvoorbeeld een update uitbrengt en style.css wijzigt van ?ver=4.6 naar ?ver=4.7, dan wordt dit gezien als een compleet nieuwe URL en wordt deze dus niet gecachet. Als je de queryreeks verwijdert en een plugin bijwerkt, dan kan dit ertoe leiden dat de gecachete versie opgevraagd blijft worden. In sommige gevallen kan dit het uiterlijk van je website beïnvloeden, totdat het gecachete item verloopt of de cache is leeggemaakt.

Het is goed om te weten dat sommige CDN’s wél in staat zijn queryreeksen te cachen. De Kinsta CDN kan dit bijvoorbeeld en doet dit ook standaard. Als je dus klant bent van Kinsta, dan worden de queryreeksen van je items automatisch gecachet!

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

Cookievrije domeinen gebruiken

We hebben een uitgebreid artikel geschreven over hoe om te gaan met de ‘serveer statische inhoud vanuit een cookievrij domein‘-waarschuwing. Vaak kan je deze waarschuwing negeren, omdat nieuwe protocollen zoals HTTP/2 dit nu minder relevant maken. De kosten van het opzetten van een nieuwe verbinding zijn meestal duurder dan het alternatief, alles via dezelfde verbinding streamen. Er zijn echter twee manieren om het probleem op te lossen: door een CDN-provider te gebruiken die de cookies verwijdert of een apart domein en/of subdomein te maken.

Compress Components with GZIP

De waarschuwing “Compress Components with GZIP” wordt weergegeven wanneer Pingdom een item detecteert dat niet is gecomprimeerd met GZIP. GZIP is een compressiemethode die wordt gebruikt om de grootte van op tekst gebaseerde bestanden zoals HTML documenten en CSS/JS bestanden te verkleinen. GZIP compressie is ingeschakeld op de server en comprimeert webpagina’s en assets voordat ze naar een bezoeker worden verzonden. Uit onze testen bleek dat het inschakelen van GZIP compressie de bestandsgrootte van een verzoek met meer dan 78% verminderde.

Bij Kinsta hoef je je hierover geen zorgen te maken, omdat GZIP standaard al is ingeschakeld op al onze servers. Als je merkt dat je webhost GZIP niet heeft ingeschakeld, raden we aan om contact op te nemen met hun supportteam om het meteen in te schakelen, want het kan een enorme impact hebben op je paginasnelheid. Als je ook nog het inschakelen van GZIP op je server nog steeds “Compress Components with GZIP” ziet, dan is het mogelijk dat de server een externe asset laadt van een site waarop GZIP niet is ingeschakeld. Als dat het geval is, kan je aan jouw kant niets doen om dit te veranderen.

Parallelle downloads via alle hostnames

De waarschuwing ‘Parallelize Downloads Across Hostnames’ is het gevolg van een beperking van HTTP/1.1 en webbrowsers die beperkt zijn in het aantal gelijktijdige verbindingen die ze kunnen maken met een host; doorgaans zijn dit er 6. Deze waarschuwing wordt vaak weergegeven op websites met een groot aantal verzoeken. In het verleden was de enige manier om deze beperking te omzeilen het implementeren van wat ze ‘sharding’ van een domein noemen. Als je echter een webhost of CDN-provider gebruikt die HTTP/2 ondersteunt, kan je deze waarschuwing vandaag de dag gerust negeren omdat meerdere bronnen nu via één enkele verbinding parallel geladen kunnen worden. Je kunt ook onze tutorial bekijken over het instellen van parallelle downloads via alle hostnames door middel van domeinsharding.

Een cachevalidator opgeven

Deze waarschuwing verwijst naar ontbrekende HTTP-cachingheaders. Deze headers moeten worden opgenomen in elke respons van de oorspronkelijke server, omdat ze de lengte van de cache zowel valideren als instellen. Als de headers niet worden gevonden, wordt de resource elke keer weer opnieuw opgevraagd, wat je server onnodig belast. De headers waar het om gaat zijn last-modified, ETag, Cache-Control en Expires. Net als met de browsercaching-waarschuwing, zouden deze headers automatisch door je WordPress-host moeten worden toegevoegd. Als het verzoeken zijn van externe partijen, dan kan je helaas niets doen, omdat je geen controle hebt over hun webservers.

Lees ons uitgebreide artikel over het oplossen van de waarschuwing ‘een cachevalidator opgeven‘.

Een ‘Vary: Accept-Encoding’-header opgeven

We hebben een uitgebreid artikel geschreven over het oplossen van de foutmelding ‘Specify a Vary: Accept-Encoding header‘. Dit is een HTTP-header en moet worden opgenomen in elke respons van de oorspronkelijke server, omdat het de browser informeert of de cliënt gecomprimeerde versies van de content kan verwerken. Deze header wordt automatisch toegevoegd op alle servers van Kinsta.

Pingdom-responscodes

De volgende sectie in de Pingdom-snelheidstesttool bevat de responscodes. Responscodes, ook wel HTTP-statuscodes genoemd, kan je zien als een klein plakbriefje die de webserver aan de bovenkant van elke pagina plaatst. Het is een bericht van de webserver waarin staat hoe de server jouw verzoek ontving en wat deze precies met het verzoek deed. Enkele veelvoorkomende zijn:

• 200: ‘Alles is in orde.’ Dit is de code die wordt afgeleverd wanneer een webpagina of bron precies werkt zoals verwacht.

  

• 301: ‘De gevraagde bron is permanent verplaatst.’ Deze code wordt weergegeven wanneer een webpagina of bron permanent is vervangen door een andere bron. Het wordt gebruikt voor permanente URL-omleidingen.

  

• 404: ‘De gevraagde bron is niet gevonden.’ Dit is meest voorkomende foutmelding. Deze code houdt in dat de gevraagde bron niet bestaat en dat de server niet weet of deze ooit heeft bestaan.

  

Je kan meer lezen over de verschillende responscodes in ons uitgebreide artikel over HTTP-statuscodes.

Contentgrootte en aantal verzoeken van elk type

De volgende secties gaan over de grootte van de content per type content en het aantal verzoeken van elk type content. Ze zijn beide erg nuttig om snel te zien welke resources de meeste ruimte innemen van elke pagina. Volgens HTTP Archive zijn afbeeldingen over het algemeen goed voor 43% van de totale grootte van een gemiddelde webpagina. Dit staat in lijn met wat wij zelf ook aantreffen. Toch zijn er een boel uitzonderingen op de regel.

Voor het optimaliseren van je afbeeldingen, raden we je ten zeerste aan ons uitgebreide artikel over het optimaliseren van afbeeldingen voor het web en over WebP te lezen. Er zijn veel geweldige tools en plugins beschikbaar om jouw afbeeldingen verder te comprimeren. Hiermee kan je ervoor zorgen dat ze niet meer het grootste deel van je pagina beslaan. En in ons geval hierboven, maakt de perfmatters.io-site gebruik van Fontawesome-pictogrammen in plaats van afbeeldingen. Het is misschien simpel, maar het maakt een enorm verschil. En natuurlijk hebben we enkele extra tips in onze paginasnelheidhandleiding over hoe je de omvang van je content nog verder kan verkleinen.

Contentgrootte en aantal verzoeken van elk domein

Als je de contentgrootte en het aantal verzoeken per domein bekijkt, dan heb je snel een overzicht van welke externe diensten en scripts zich op jouw website bevinden. In ons voorbeeld kan je zien dat al onze items worden geladen vanaf ons CDN. Verder is er de initiële HTML DOC-belasting voor de website vanaf de webserver en een externe oproep naar het Google Analytics-domein. Afhankelijk van jouw site heb je mogelijk veel meer externe diensten, zoals Facebook, Twitter, Hotjar, SumoMe, AdRoll, New Relic, CrazyEgg, etc.

In het algemeen geldt: hoe minder externe verzoeken, hoe beter. Elke externe dienst gaat namelijk gepaard met zijn eigen latentie, vertragingen in TLS-handshakes, DNS-look-ups, etc. Om hier meer over te lezen, ga dan naar ons gedetailleerde artikel over hoe je externe diensten kan identificeren en analyseren op je WordPress-site.

Over het algemeen is het het beste om het aantal verzoeken zoveel mogelijk te beperken en alle items vanuit een enkele plek te laden, bijvoorbeeld door ze naar jouw webserver of CDN te verplaatsen. Fontawesome is hier een voorbeeld van. In plaats van te linken naar het externe script van Fontawesome, kan je deze downloaden en vanuit jouw server leveren.

Watervalgrafiek Pingdom

En als laatste, maar daarom niet minder belangrijk, hebben we de sectie ‘Pingdom speed test tool requests’, waarin je een watervaldiagram met daarin alle individuele verzoeken te zien krijgt (zie hieronder). Je kan vervolgens elk verzoek analyseren om te zien welke vertragingen en problemen met de prestaties van je website veroorzaken. Dit is wat we bedoelen als we zeggen dat we een watervalanalyse doen. Hieronder volgt een uitgebreidere samenvatting en/of definitie van wat elke statuskleur betekent.

DNS (roze)

Wat is DNS? Het makkelijkste is om DNS met een telefoonboek te vergelijken. Er zijn servers die Domain Name Servers worden genoemd. Zij bevatten informatie over jouw website en naar welk IP-adres bezoekers moeten worden gestuurd. Wanneer je je website voor de eerste keer test met Pingdom, voert deze een nieuwe look-up uit en vraagt de testtools de DNS-records op om de benodigde IP-informatie te verkrijgen. Dit resulteert vaak in extra opzoektijd. Ook de locatie van de DNS-server is hierbij van belang.

Wanneer je de website vaker test met Pingdom, dan wordt de DNS in het cachegeheugen opgeslagen, omdat de IP-informatie nu bekend is en deze dus niet opnieuw opgezocht hoeft te worden. Dit is een van de redenen waarom je website sneller lijkt te zijn, naarmate je deze vaker hebt getest in Pingdom.

Zoals je in de onderstaande schermafbeelding kan zien was de DNS-lookup-tijd bij de tweede test 3,6ms. Normaal gesproken daalt dit naar 0ms, of zou in elk geval zo moeten zijn, omdat het verzoek al in de cache is opgeslagen. Het zal je misschien niet verbazen, maar deze sectie wordt vaak verkeerd geïnterpreteerd.

Je kunt het verder optimaliseren door een premium DNS-service te gebruiken, wat niet alleen hierbij helpt, maar ook tal van andere voordelen heeft. Onze gratis DNS van Cloudflare is ook snel! Bekijk Cloudflare’s Automatische platformoptimalisatie.

Er zijn ook nog andere redenen waarom je website er vaak sneller uitziet na een aantal tests. Een daarvan treedt op als je een Content Delivery Network (CDN) gebruikt. Voor degenen die niet bekend zijn met een CDN, het is een netwerk van wereldwijde servers die jouw content cachen (JS, CSS, afbeeldingen, enz.) op locaties die dichter bij de bezoekers liggen. Wanneer je voor het eerst je website via Pingdom test, moet je mogelijk de items van de CDN ophalen. Een CDN-cache werkt ongeveer hetzelfde als die van een DNS, zodra het item in de cache is opgeslagen, wordt deze de keren erna veel sneller geladen.

Een andere tip voor het versnellen van DNS is het gebruik van DNS-prefetching. Hierdoor kan de browser DNS-lookups uitvoeren op een pagina, maar wordt dit op de achtergrond gedaan. Je kan dit doen door enkele regels code toe te voegen aan de header van je WordPress-site. Bekijk enkele voorbeelden hieronder.

<!-- 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">

Als je WordPress versie 4.6 of hoger gebruikt, wilt je mogelijk resource-hints gebruiken. Ontwikkelaars kunnen het filter wp_resource_hints gebruiken om aangepaste domeinen en URL’s toe te voegen voor dns-prefetch, preconnect, prefetch of prerender.

SSL (paars)

De paarse status kleur staat voor de tijd die de browser nodig heeft om een SSL/TLS-handshake uit te voeren. Als je website op HTTPS draait, betekent dit dat er een SSL-certificaat bij betrokken is, waardoor het coderingsproces (SSL/TLS-handshake) extra tijd kost. Op ons voorbeelddomein hebben we een certificaat op zowel onze webserver bij Kinsta als ons CDN, KeyCDN. Er is dus een SSL-onderhandelingstijd op zowel de initiële HTML-docload van de webserver als onze assets.

Van HTTPS werd altijd gezegd dat het gebruik ervan de website vertraagt. Gelukkig is dit verschil tegenwoordig verwaarloosbaar, allemaal dankzij HTTP/2. Dit is een nieuw protocol en heeft voor een enorme versnelling van het internet gezorgd. Vanwege browser-ondersteuning is HTTPS nodig om HTTP/2 te gebruiken. Bekijk onze ultieme gids over HTTP/2.

Het is belangrijk op te merken dat in 2019 nog niet alle providers HTTP/2 ondersteunen. Dit geldt voor zowel webhosts als CDN’s. Dus als je op zoek bent naar hosting en CDN’s, zorg er dan voor dat BEIDE ondersteuning bieden voor HTTP/2. Kinsta is er trots op HTTP/2 te ondersteunen voor al haar WordPress-klanten.

Medio 2018 heeft Pingdom eindelijk haar tool bijgewerkt en werkt deze sindsdien met Chrome 60 of hoger. Je kan de user-agent in de requestheader zien. Eerder maakte de tool gebruik van Chrome 39, terwijl Chrome pas vanaf versie 49 ondersteuning biedt voor HTTP/2. We zijn dus erg blij dat we mogen verkondigen dat Pingdom nu alle voordelen van HTTP/2 meeweegt in haar tests! 👏

Connect (blauwgroen)

De verbindingsduur in Pingdom verwijst naar de TCP-verbinding of de totale tijd die nodig is om een TCP-verbinding tot stand te brengen. We besparen je de technische details, maar dit is slechts een communicatiemethode tussen de host/client en de server die moet plaatsvinden.

Wait (geel)

De wachttijd in Pingdom verwijst naar de tijd tot de eerste byte, ook wel bekend als de TTFB binnen sommige andere tools. TTFB is een meting die wordt gebruikt als indicator van de reactietijd van een webserver of een andere netwerkresource. Over het algemeen is alles onder de 100ms acceptabel en een goede TTFB. Als je website de 300–400ms nadert, dan is er mogelijk iets verkeerd ingesteld op je server of is het misschien tijd om te upgraden naar een betere webstack.

De eenvoudigste manier om jouw TTFB te verlagen? De twee meest effectieve methoden zijn WordPress-caching en het gebruik van een CDN. Tijd voor een paar kleine tests!

TTFB zonder WordPress-cache

We voerden onze eerste test uit nadat we de cache van onze WordPress-site hadden geleegd. Dit betekent dat de cache opnieuw geladen moest worden. Zoals je kan zien was onze totale laadtijd 541ms en de TTFB (wachttijd) van ons initiële verzoek 185,2ms.

TTFB met WordPress-hostingcache

Vervolgens voerden we de test nog een keer uit. In deze test werd alles rechtstreeks vanuit de cache geleverd. Zoals je kan zien was de totale laadtijd naar 392ms gedaald en was de TTFB van het initiële verzoek nu slechts 52,8ms! Wat een verschil!

Als je website bezoekers heeft uit verschillende delen van het land of van over de hele wereld, dan is het gebruik van een CDN een andere, eenvoudige manier om de TTFB drastisch te verlagen. We voerden opnieuw enkele tests uit om het verschil te laten zien.

TTFB zonder CDN

We voerden onze eerste test uit met CDN uitgeschakeld. Je kan zien dat de totale laadtijd 1,93s was. De gemiddelde TTFB van een item was ongeveer 176ms.

TTFB met CDN

Vervolgens schakelden we de CDN in en voerden we de test opnieuw uit. Zoals je kan zien, daalde de totale laadtijd naar 1,21s. De gemiddelde TTFB van een CDN-item is nu 4,6ms. Wederom een enorm verschil!

Another important thing to note is that we chose the “Pacific – Australia – Sydney” location to perform this test. Why? Because we wanted to show you the real improvement that can be had. Our WordPress site in this example is hosted by Kinsta on the Google Cloud and located in a central location in the USA. By performing the test against Australia we are able to show how the Kinsta CDN caching increases the speed and reduces the TTFB.

Ten slotte is het belang van een goede host met een doordachte architectuur niet te onderschatten als het gaat om het verlagen van je TTFB.

Verzenden (oranje) en ontvangen (groen)

De verzend- en ontvangststatus in Pingdom spreekt voor zich. De verzendtijd is de tijd die de webbrowser nodig heeft om gegevens naar de server te verzenden. De ontvangsttijd is de tijd dat het duurt voordat de webbrowser gegevens van de server ontvangt. Doorgaans zijn dit hele lage getallen in de tests.

HTTP-responsheader

Je kunt ook op een individueel verzoek klikken bij het uitvoeren van een watervalanalyse om zo de HTTTP-responsheaders te bekijken. Dit levert waardevolle informatie op. In de onderstaande schermafbeelding kunnen we meteen zaken zien als: is gzip ingeschakeld op de webserver en wordt deze vanuit de cache geleverd (HIT, anders staat er MISS)? Daarnaast kan je informatie vinden over de cache-control-headers, expires-headers, de browser user-agent en meer.

Casestudy domeinconfiguratie

Nu je zover bent gekomen in dit artikel, wacht je een kleine traktatie. Het is altijd vervelend als mensen tips en casestudy’s te laten zien, maar dan niet vertellen hoe ze aan zulke hoge scores zijn gekomen. Hieronder vind je dus de exacte configuratie van ons domein dat we gebruikten in bovenstaande casestudy. Wil je dezelfde opstelling gebruiken? Gebruik onderstaande gegevens gerust!

Architecture

• Het domein uit de casestudy (perfmatters.io) wordt gehost bij Kinsta op het Google Cloud Platform in de VS (Council Bluffs, Iowa, VS (us-central1). Momenteel biedt Kinsta 37 verschillende datacenters aan, waaruit je kan kiezen. Om razendsnelle netwerklatentie te garanderen is elk pakket dat wij aanbieden verbonden met het premium tier-netwerk van Google Cloud Platform.
• Verder maakt Kinsta gebruik van HTTP/2, Nginx, MariaDB, die allemaal bijdragen aan de snelle laadtijden.
• De site maakt gebruik van KeyCDN, het netwerk dat Kinsta CDN aandrijft. In al onze hostingpakketten zit gratis CDN-bandbreedte.
• De website maakt geen gebruik van een cacheplugin. Kinsta cachet alles namelijk op serverniveau, iets dat de boel enorm vereenvoudigt.
• De website gebruikt PHP 7.3. Voor PHP geldt: nieuwe versies van PHP zorgen altijd voor prestatieverbeteringen. Voor meer informatie kan je deze PHP-benchmarks lezen. Met Kinsta kan je met een druk op de knop tussen deze twee wisselen.

WordPress plugins en thema

Hier vind je een lijst met plugins – die invloed hebben op de prestaties van de WordPress e-commercesite.

• De premium Perfmatters-plugin, ontwikkeld door een teamlid bij Kinsta. De plugin verwijdert onnodige HTTP-verzoeken zoals insluitingen, emoji’s en biedt ook scriptbeheer aan om bepaalde scripts in of uit te schakelen – dit kan je instellen per pagina, post of voor de hele website.
• 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 GeneratePress WordPress-thema werd gebruikt om de EDD-site te bouwen.

Aanbevolen tutorials om meer hierover te lezen:

• Hoe elimineer je Render-Blocking JavaScript en CSS
• Hoe emoji’s uit te schakelen in WordPress
• Hoe schakel je embeds uit in WordPress
• Hoe kun je met WordPress 100/100 scoren in Google PageSpeed Insights
• Hoe stel je hoog verbruik van Admin-Ajax vast op jouw WordPress website

Samenvatting

Als het goed is heb je nu het een en ander geleerd over de speedtest van Pingdom en dus een idee hebt gekregen over hoe je de data van de test kan gebruiken om betere beslissingen te maken als het aankomt op prestatie. Een zogenoemde watervalanalyse is een cruciale tool om te weten hoe de individuele items laden en welke dringend verbeteringen nodig hebben. Heb jij nog andere goede Pingdom tips?

Als je meer uitgebreide artikelen, zoals het artikel hierboven, wil lezen, laat het ons dan weten in de reacties!