Naar
boven

Meten is weten: Maak je WordPress site sneller

Iedereen wil natuurlijk een snellere website. In dit artikel gaan we kijken naar de volgende zaken, specifiek voor WordPress sites: ‘Waarom is een snelle site belangrijk?’, ‘Hoe kan ik zelf m’n sitesnelheid meten?’, ‘Hoe herken ik snelle hosting?’ en als laatste ‘Hoe kan ik zelf m’n WordPress sneller maken?’.

Waarom is een snelle site belangrijk?

Uit onderzoek blijkt dat een snellere site leidt tot een betere conversieratio. Onderzoek van bol.com en measureworks laat zien dat de bouncerate fors toeneemt boven een laadtijd van 2,5 sec.

grafiek met statistieken van bol.com. Snelheid VS Engagement

Effect van laadtijd op bouncerate. Bron: Measureworks presentatie.

Een ander belangrijk punt, maar wat mij betreft niet belangrijker dan bovenstaande is de impact van snelheid op de organische rankings bij Google.

Uit onderzoek van Billy Hoffman blijkt dat sites in de top 5 van Google zoekresultaten aanzienlijk sneller zijn dan sites op lagere posities. Hiermee is overigens alleen een correlatie en geen oorzakelijk verband aangetoond. Het geeft natuurlijk wel een signaal.

Grafiek: Time to First Byte VS Search rank position

 

Over hoe snel, snel genoeg is, verschillen de meningen. Google streeft naar een first byte time (hierover later meer) van 200 ms., Akamai raadt aan onder een laadtijd van 2 sec. te blijven. Ik zelf houd meestal aan dat de eerste content zichtbaar moet zijn binnen 1 sec. Je ziet al dat er nogal wat verschillende metrics aan te pas komen.

Hoe kan ik zelf mijn sitesnelheid meten?

Bij Savvii gebruiken we standaard de tool webpagetest.org. Deze site heeft onze voorkeur boven bijv. pingdom, omdat je uit heel veel verschillende locaties kunt kiezen, je meerdere runs achter elkaar kunt laten uitvoeren en dat de test de real-life situatie het beste benaderd (zo laat webpagetest.org ze de originele caching instellingen intact).

 

Web Page Performance Test

 

Webpagetest.org kan erg overweldigend zijn. We focussen nu op 3 metrics: load time, first byte time en start render. De volgorde in de tabel is vreemd want bij het inladen van een site bereik je altijd eerst de first byte time, vervolgens de start render en als laatste de load time.

De volgorde van stappen bij het ophalen van een webpagina incl. bijbehorende plaatjes is als volgt:

  • DNS Lookup
  • Connectie opzetten
  • Wachten”¦.
  • First Byte terug (=First Byte Time)
  • Assets ophalen (resterende html, plaatjes, CSS, javascript) / Start Render
  • Load Time

First byte time

Zoals eerder aangegeven kijkt Google o.a. naar de first byte time (ze noemen dit ‘Server Response Time’). Dit is de tijd die het duurt voordat de eerste byte van de html-code van je webpagina aankomt bij je browser.

Omdat Google de ‘First Byte Time’ de naam ‘Server Response Time’ geeft, denken veel mensen dat deze tijd alleen door de hosting (server) bepaald wordt. Dat is echter zeker niet waar. Hoe jouw site is gemaakt heeft een hele grote invloed op die tijd (in bijna alle gevallen zelfs de meeste).

Die tijd (hier de ‘wacht’ tijd) zit in het feit dat de webserver eerst HTML moet maken uit een dynamisch PHP applicatie met een database erachter (WordPress), en hoe ingewikkelder de PHP en de database queries hoe langer het duurt.

Start Render

Start Render is het moment dat jouw browser het eerste stukje in beeld brengt van je pagina. Je maakt vast regelmatig mee dat een pagina steeds completer wordt voor je ogen, dat proces heet rendering.

Load time

De Load Time is het moment dat jouw browser helemaal klaar is met het laden van de pagina inclusief alle content (plaatjes, CSS, JS).

Extra tip: Wil je zien hoe snel je website in beeld komt? Kies dan voor ‘visual comparison‘ of download de video onder het tabje ‘screen shot’ in je rapport.

Hoe herken ik snelle hosting?

Aan de bovenkant van je webpagetest rapport vind je een aantal scores. A is het hoogste en F het laagste. De punten die een goede hoster geregeld heeft, is het instellen van ‘Keep-alive Enabled’, ‘Compress Transfer’ en ‘Cache static content’.

Keep-alive Enabled

Keep-alive enabled betekent dat de webserver de verbinding met de client in stand houdt. Daardoor hoeft niet voor elk nieuw request een nieuwe verbinding gemaakt te worden. Dat is uiteraard sneller.

Compress Transfer

Als een webserver ‘compress transfer’ aan heeft staan betekent dat dat assets eerst ingepakt worden (gzip) voordat ze naar de client verstuurd worden. Ingepakte bestanden zijn kleiner en zijn dus sneller binnen bij de client. Als ‘compress transfer’ aanstaat heeft het minify’en van je HTML geen zin meer.

Cache static content

Als ‘cache static content’ staat ingesteld laat de webserver aan jouw browser weten dat deze bestanden in de browsercache mag bewaren. Dat betekent dat jouw browser bij een volgend bezoek aan de site niet meer alle bestanden hoeft op te halen, dat is uiteraard sneller dan alles opnieuw ophalen. Daarnaast belast het de server minder.

Ook belangrijk:

Apache vs nginx
Apache en nginx zijn beide webserver software. Apache bestaat al heel lang en is ook de standaard bij alle grote hostingpartijen. Sinds een aantal jaren bestaat er echter een stabiel en sneller alternatief in de vorm van nginx. Nginx heeft vooral voordelen bij sites met veel bezoek. Nadeel van nginx kan zijn dat je als site eigenaar zelf minder zaken in je webserver kunt aanpassen, maar dat je dit moet aanvragen bij je hosting bedrijf.

Je kunt bij je hostingbedrijf op de site lezen wat ze gebruiken, of vraag het anders aan de support.

SSL Instellingen
Heb je SSL op je website? Dat kan je website vertragen doordat er extra communicatie en versleuteling nodig is bij het ophalen van data. Er zijn een aantal technieken om deze overhead te verminderen: SPDY, OSCP stapling en STS headers. SPDY levert hier veruit het grootste snelheidsvoordeel op.

Je kunt deze instellingen niet via webpagetest inzien, hiervoor gebruik je het beste de Qualys SSL Test.

Voorbeeld Qualys SSl Test

Stukje uit de resultaten van Qualys, zie ‘Next Protocol Negotiation’, OSCP Stapling en Stric Transport Security.

Heb je nog geen SSL maar wil je er meer van weten? Lees dan dit artikel bij karelgeenen.nl.

Hoe kan ik zelf m’n WordPress sneller maken?

Probeer waar mogelijk ook gebruik te maken van webpagetest.org om verschillende versies van je site te testen, dus met plugin X aan of uit, of met thema Y of met thema Z. Je zou ook kunnen proberen de diverse demosites van thema’s met webpagetest.org te testen om te kijken hoe het staat met de laadtijden, CSS, JS e.d. Klik voor de laatste door naar het tabje ‘content breakdown’ in het testrapport.

Daarnaast kun je concreet met de volgende punten aan de slag, ook hier kun je voor en na testen:

De makkelijkste methode om je site sneller te maken is gebruik te maken van caching. In het geval van pagecaching wordt dan op een snel toegankelijke plaats de HTML van de pagina opgeslagen. PHP en de database komen er dan niet meer aan te pas en dat scheelt heel veel tijd.

Pagecaching kan door je hosting geregeld worden (bijv. een proxycache als Varnish), kun je zelf via plugins regelen (bijv. met W3TotalCache) of kun je zelf door een proxycache in te schakelen (bijv. CloudFlare Optimizer).

Wil je meer weten over caching? Lees dan het artikel ‘Caching (tijdelijk geheugen) voor websites toegelicht!’ dat eerder op karelgeenen.nl gepubliceerd is.

De moeilijkere manier om je site sneller te krijgen is door aan je site zelf te werken. Dat bekent dus kritisch kijken naar je thema, je plugins en de content.

Het is erg moeilijk om van tevoren de snelheid van een plugin in te schatten, maar één ding is zeker: géén plugin is altijd sneller (behalve bij caching plugins ;) ). Daarnaast kun je je afvragen of een plugin altijd de handigste plaats is om een probleem op te lossen. Voorbeeld: als je op elke pagina op je website een trackingpixel nodig hebt kun je dit via een plugin doen, maar de snellere optie is om deze pixel in je thema op te nemen.

Functionaliteiten die meestal vertragend werken zijn bijv. gerelateerde posts (of producten) en plugins die je hele site crawlen (broken link checkers, back up tools).

Voor thema’s geldt ook: less is more. Hoe minder (regels) CSS, javascript, externe fonts e.d. hoe sneller je thema zal zijn. Probeer vooral om geen sliders te gebruiken en let erop of je thema onnodig een sessie start, dit laatste zal caching weer moeilijker maken.

Een extra mogelijkheid is om gebruikte CSS en javascript bestanden samen te voegen (combine) in één bestand en om deze minder groot te maken door o.a. witregels te verwijderen (minify). Er zijn diverse plugins voor WordPress die dit kunnen (bijv. W3TotalCache). In de praktijk blijken ze echter vaak de CSS en JS die door plugins gebruikt worden niet mee te nemen, waardoor het effect niet erg groot is.

Conclusie

Wil je een snelle website? Dan is het zaak zowel naar je hosting te kijken als naar het optimaliseren van je eigen site. Een snelle site is alleen maar te realiseren door naar het totaalplaatje te kijken.

Zijn er nog zaken onduidelijk, laat dan gerust je vragen hier achter!

 

Onze Expertise Nodig?

Vul het onderstaande formulier in of bekijk onze online marketing cursussen en online marketing diensten.


Over de auteur:

Dit artikel is geschreven door .

Gijs Hovens
Gijs is marketing manager bij Savvii - Managed WordPress Hosting uit Nijmegen. Hij heeft jarenlange ervaring in online marketing, zowel bij klanten als bureaus en probeert sinds oktober 2013 zoveel mogelijk mensen kennis te laten maken met de voordelen van managed WordPress hosting.
25 reacties op "Meten is weten: Maak je WordPress site sneller"
  • Nicolas zegt:
    04 Dec, 2014 om 15:04

    Goedemiddag Thijs, leuke post heb je geschreven! Zijn er enkele tips die je kan meegeven over onze eigen WordPress site? Link: http://www.noodweer.be

    Reageren
  • Gijs - Savvii zegt:
    04 Dec, 2014 om 16:14

    Hallo Nicolas,

    Dank! Jullie hebben al e.e.a. goed ingeregeld zie ik: XCache, gzip, keep-alive en nog meer. Ook het aantal assets is nog binnen de perken. Goed gedaan dus.

    Mogelijke verbeterpunten zijn het gebruik van een proxycache als Varnish en het verlengen van de max-age voor je statische content.

    Gr. Gijs

    Reageren
  • Nicolas zegt:
    04 Dec, 2014 om 20:59

    Goedenavond Gijs

    Op dit moment werken we ook met een VPS, nginx en varnish maar we vermoeden dat we nog niet het onderste uit de kan halen qua snelheid en het verminderen van requests… Ook enige tips naar de advertenties van Adsense en de vertraging in load? Je mag ons altijd mailen ook.

    Reageren
  • André Huisman zegt:
    10 Dec, 2014 om 09:59

    Als ik de test van http://www.rockstart.com herhaal dan krijg ik hele andere resultaten. Reden voor het zelf uitvoeren van deze test is de “Compress Images N/A” melding. Dat lijkt mij een onmogelijkheid voor een site die zeker wel afbeeldingen gebruikt.

    Een andere goede tool om je site te testen op snelheid is Google PageSpeed: https://developers.google.com/speed/pagespeed/

    Overigens zou ik me van het nut van een CDN niet te veel voorstellen als je klanten maar uit 1 of 2 (aangrenzende) landen komen (dus die laatste “X” in het “rapport” mag je in veel gevallen gerust volledig negeren).

    Reageren
  • Jeroen zegt:
    10 Dec, 2014 om 10:58

    Beste Gijs,

    Ik zal niet de eerste zijn die na het lezen van dit artikel deze pagina door webpagetest.org zal hebben gegooid.

    Het resultaat valt mij echter tegen als ik kijk naar de firstbyte time. Ik zag een resultaat van 11,7 sec.

    Kun je toelichting waarom dit resultaat tegenvalt, tenslotte hosten jullie deze site en zul je ongetwijfeld alle instellingen hebben (laten) aanpassen om zo’n goed mogelijk visitekaartje voor je eigen diensten te maken.

    Reageren
  • Gijs - Savvii zegt:
    10 Dec, 2014 om 11:05

    Hallo André,

    Die melding over compress images n/a komt doordat webpagetest geen analyse kan doen over images die met gzip verstuurd worden.

    Je opmerking over een CDN klopt, dat voegt relatief weinig toe, zeker als je geen internationale bezoekers hebt.

    Gr. Gijs

    Reageren
  • Gijs - Savvii zegt:
    10 Dec, 2014 om 11:06

    Hallo Jeroen,

    Welke site gaat het om? Dan kunnen we even contact met je opnemen.

    We hebben meer klanten die Jeroen heten ;)

    Gr. Gijs

    Reageren
  • Jeroen zegt:
    10 Dec, 2014 om 11:07

    Als ik kijk in diverse resultaten dan zie ik dat vooral admin-ajax.php veel tijd in beslag neemt. Is er een methode omdat te verminderen?

    Reageren
  • Jeroen zegt:
    10 Dec, 2014 om 11:10

    @gijs, je vroeg om welke pagina het ging. Ik testte https://www.karelgeenen.nl/04/meten-weten-maak-je-wordpress-site-sneller/ en daarna ook nog https://www.karelgeenen.nl Van deze test viel het resultaat tegen bij de first byte.

    Reageren
  • Gijs - Savvii zegt:
    10 Dec, 2014 om 11:15

    Hallo Jeroen,

    Begrijp nu dat het over karelgeenen.nl gaat. Admin-ajax.php is vaak traag. Dat is een scriptje wat vaak door plugins gebruikt wordt om opdrachten te geven aan de WordPress site. Je kunt je voorstellen dat afhankelijk van het aantal plugins en type opdrachten daar veel tijd in kan zitten. Een complexe site als deze maakt daar veel gebruik van.

    Er zijn plannen om binnenkort met Karel ook de site zelf onder de loep te nemen qua snelheid.

    Gr. Gijs

    Reageren
  • janis zegt:
    10 Dec, 2014 om 11:38

    @Nicolas

    Geen wordpress gebruiken. een site in python / django of ruby on rails laten bouwen..

    daar zit je kwa snelheid 0,3 – 0,6ms …
    als je geld durft uit te geven heet dat, dan is dat de volgende stap voor je..

    en ik zou voor cloudvps gaan, dan voor bit bv. Object Store is echt geweldig..

    Reageren
  • Patrick zegt:
    10 Dec, 2014 om 12:19

    Perfecte timing Gijs! Ben net bezig om mijn website sneller te krijgen. Het blijkt nogal wat voeten in aarde te hebben. De developer is al 2 dagen bezig :-(

    Wordt de laadtijd vooral langzamer door WordPress?

    Zelf heb ik trouwens http://yslow.org/ gebruikt.

    Reageren
  • Gijs - Savvii zegt:
    10 Dec, 2014 om 14:55

    @Patrick:

    Er zijn snellere CMS’en dan WordPress maar ook een WordPress site kan heel snel gemaakt worden. Het is echt het totaalplaatje wat je moet onderzoeken, dus ook thema, plugins, hosting, enz.

    Wij hebben een dienst waarbij we advies uitbrengen om sites sneller te maken, als je dat interessant vindt kunnen we daar telefonisch wat meer over vertellen.

    Reageren
  • Gijs zegt:
    12 Dec, 2014 om 15:09

    Hoi Gijs,

    Mijn developer geeft aan dat er niet veel meer te winnen is… Hoor graag dat het tegendeel waar is :-)

    Zelf denk ik dat we nog wat kunnen winnen met hosting. Zou websynthesis een goede optie zijn denk je?

    Je kan mij volgende week bereiken op 023-8441422.

    Alvast bedankt!

    Groeten Patrick

    Reageren
  • Patrick zegt:
    12 Dec, 2014 om 15:09

    Hoi Gijs,

    Mijn developer geeft aan dat er niet veel meer te winnen is… Hoor graag dat het tegendeel waar is :-)

    Zelf denk ik dat we nog wat kunnen winnen met hosting. Zou websynthesis een goede optie zijn denk je?

    Je kan mij volgende week bereiken op 023-8441422.

    Alvast bedankt!

    Groeten Patrick

    Reageren
  • Patrick zegt:
    12 Dec, 2014 om 15:15

    Excuus, zie nu dat jullie zelf WP hosting aanbieden. Dan hoor ik graag waarom jullie beter zijn ;-)

    Groeten Patrick

    Reageren
  • Gijs - Savvii zegt:
    12 Dec, 2014 om 15:58

    Hi Patrick,

    We zullen je volgende week even bellen.

    Fijn weekend!

    Gr. Gijs

    Reageren
  • André Huisman zegt:
    16 Dec, 2014 om 08:54

    Gijs: Het Gzippen van afbeeldingen is een nogal onlogische keuze (ik druk me subtiel uit aangezien daar we eigenlijk kunnen spreken van een “kapotte gedachte”). Goed te zien dat dit nu niet meer gedaan wordt op de rockstart.com site…

    Reageren
  • Lucas Vos zegt:
    19 Feb, 2015 om 14:17

    Dank voor het informatieve artikel Gijs! Ik herken zeker de uitdagingen die je beschrijft, een van de voornaamste die voor mijn wordpress sites. Daarom installeerde ik de W3 Total Cache plugin. Het installeren van deze w3 total cache plugin bracht echter conflicten met de yoast plugin met zich mee voor de sitemap, dus helaas heb ik deze moeten uitzetten. Ik ben daarom op zoek naar nieuwe manieren om de snelheid te kunnen verbeteren.

    Even een concrete vraag. Wat raad je aan voor mijn sites (zie http://www.overhemdensale.nl of http://www.chinobroekkopen.nl) om de snelheid te verbeteren, dus afgezien van een caching plugin?

    Alvast dank voor je reactie!

    Reageren
  • Patrick Lotte zegt:
    19 Feb, 2015 om 15:26

    Hoi Lucas,

    Weet je zeker dat het een conflict met Yoast is?

    Wij hebben namelijk beide plugins zonder problemen draaien.

    Groeten Patrick

    Reageren
  • Patrick Lotte zegt:
    19 Feb, 2015 om 15:30

    Ik zou sowieso de Adsense plugin verwijderen. Wellicht nog een paar andere plugins die weinig toevoegen?

    Reageren
  • Gijs zegt:
    19 Feb, 2015 om 15:45

    Hi Lucas,

    Je vertraging zit vooral in de time to first byte. Dat betekent dat je website lang bezig is met vooral database queries.

    Zonder caching kun je de laadtijd versnellen door minder promotieblokken e.d. te gebruiken en/of andere plugins met ingewikkelde logica te verwijderen.

    Ons is een probleem met w3tc en yoast onbekend, wij hebben vele sites gezien met deze combinatie werken.

    Gr. Gijs

    Reageren
  • frans zegt:
    09 Jun, 2016 om 10:34

    Hallo
    sinds enige tijd had ik met google page insight een perfect rapport, zowel mobiel als desktop (100/100) :
    https://www.sud66.com

    Nu na installatie ssl krijg ik plots geen 100 meer voor mobiel met als reden :
    Dit moet worden gecorrigeerd: Reactietijd van server beperken !!!
    In onze test reageerde uw server binnen 1,1 seconden. Er zijn allerlei factoren die de reactietijd van uw server kunnen verlengen. Lees onze aanbevelingen voor meer informatie over hoe u kunt controleren en meten waaraan uw server de meeste tijd besteedt.

    Als ik het goed begrijp moet ik de website trager maken ??? Toch vreemd !!

    Reageren
  • Gijs zegt:
    13 Jun, 2016 om 14:46

    Hallo Frans,

    Mooie score! Google bedoelt dat de server sneller moet reageren, niet langzamer. Ze willen ook uitleggen dat de reactietijd afhankelijk is van veel factoren. Het is wel ongelukkig vertaald zo.

    Gr. Gijs

    Reageren
  • frans zegt:
    20 Jun, 2016 om 15:41

    Hoi Gijs.
    inderdaad Google geeft niet echt een goed verduidelijkte beschrijving ervan.
    Ik vind het alleen vreemd dat die eerste byte zo traag gelezen wordt. Dat was vroeger niet zo en dan gaf Ginsight mij altijd 100% als score. Allicht hebben ze hun algoritme gewijzigd.
    via http://tools.pingdom.com/ zie ik dat het vooral ligt aan de statistiekenlogiciel. Ik heb hen al ondertussen de vraag gesteld waarom statcounter dit probleem geeft, maar nog geen antwoord gekregen.
    Als ik antwoord krijg, laat ik het hier zeker weten.

    P.S. CDN zou mogelijk het probleem kunnen verhelpen, maar ben nog niet thuis in die materie.

    Reageren

Reageren