Nogmaals – Het sneller maken van je website

Hoe je jouw site sneller krijgt!

Het is niet de eerste keer dat ik over het sneller maken van je WordPress website schrijf, en het zal ook beslist de laatste keer niet zijn. Met een druk bezochte site als de WordXPression site (over het eerste half jaar van 2020 gemiddeld 35.000 unieke bezoekers per maand) blijft de performance van de website een grote uitdaging.

En de ervaringen die ik hierbij opdoe is natuurlijk mooi materiaal voor een nieuwe blogpost.

De aanleiding om hier weer eens een artikel over te schrijven was, dat een drietal weken geleden de performance van mijn website ineens enorm terug bleek te lopen. Van een gemiddelde laadsnelheid van 1,7 seconden per pagina was dit nu ineens gemiddeld 7.2 geworden.

En na een grondig onderzoek samen met mijn hoster naar de oorzaak van deze verslechterde performance, kwam uiteindelijk de oorzaak boven water. De plugin die ik gebruik voor de caching -Cache Enabler- bleek na een update ineens nauwelijks meer snelheidswinst op te leveren. Tijd dus om naar een andere plugin voor de caching te gaan kijken. Maar hierover later meer.

Jouw site is niet zo traag als je denkt!

Wanneer jij als beheerder in je website bent ingelogd, dan krijg je eigenlijk een heel slecht beeld met betrekking tot de daadwerkelijke snelheid van je website. Ik durf erom te wedden, dat jouw bezoekers jouw site sneller ervaren, dan dat je dit zelf doet. En dit om een aantal redenen.

Pagina’s worden doorgaans niet gecached, wanneer een gebruiker is ingelogd

Wat een cache precies is en wat hij doet kan je in mijn eerdere artikel over caching lezen. Omdat wanneer iemand ingelogd is, de weergave van een pagina sterk kan veranderen, afhankelijk van wie er is ingelogd, wordt doorgaans een pagina niet gecached, zodra een gebruiker is ingelogd.

Een willekeurige bezoeker aan je website zal dus -indien je een caching plugin gebruikt- netjes de gecachte -snellere- versie van de pagina te zien krijgen, terwijl jij ingelogd als beheerder, altijd een niet gecachte versie te zien zal krijgen.

Het leven van een beheerder is zwaar. Zijn webpage ook!

Een tweede reden dat je als beheerder een tragere webpagina zal krijgen is omdat specifiek voor de beheerders-rol aan de voorkant van de site ook allerlei plugins zullen worden geladen, die voor een ‘gewone’ gebruiker niet zullen worden geladen. Bij het sneller maken van je WordPress website is het dus ook van belang de ervaring van de bezoeker te bekijken en niet je eigen ervaring wanneer je bent ingelogd in je site.

Eén voorbeeld is Yoast SEO. In de zwarte balk bovenaan het scherm laat Yoast je allerlei SEO gegevens van die pagina zien. Maar die moeten natuurlijk wel eerst worden opgehaald.

Een tweede beruchte vertrager wordt gevormd door page builders. Had ik je verteld dat Elementor je site sneller maakt? Dat is helemaal waar, maar dat geldt niet wanneer je bent ingelogd als beheerder. Elementor -en overigens ook iedere andere front-end page builder- laadt behoorlijk wat scripts. Waar dacht je anders, dat Elementor die ‘pagina opbouw’ vandaan haalde, die je als drop down in diezelfde zwarte balk krijgt?

En daarnaast is er nog een aantal andere plugins die geladen kunnen worden uitsluitend voor de gebruikers met een beheerdersrol. Wil je een daadwerkelijke indruk krijgen hoe snel -of traag- je website is, moet je vooral niet ingelogd zijn.

Meten is weten

Het verraderlijke van een ’tragere website voor de beheerder’ is dat je op deze manier soms niet zo snel merkt wanneer de response van je website trager is geworden. Voor jou is het immers altijd trager dan voor de bezoeker, het grootste deel van de tijd, dat jij je website bezoekt zal het zijn om zaken te onderhouden of toe te voegen. Je bent dus ingelogd.

En dat is een heel goede reden om ook altijd de performance van je website te meten. Zelf gebruik ik hier ‘Matomo’ (vroeger Piwik) voor. Bij iedere pagina opvraging wordt aan het begin en het einde de tijd gemeten en dit tijdsverschil wordt vastgelegd. Dit gebeurt door een stukje JavaScript, waardoor je niet meet hoe snel de server de pagina opbouwt (wat een aantal andere performance tools wel doet, maar dit is slecht een fractie van de werkelijke tijd), maar hoe lang het duurt voor de webpagina is ingeladen in de browser van je bezoeker.

En een individuele laadtijd zegt natuurlijk heel weinig, maar wanneer je een gemiddelde laadtijd per dag hebt, dan krijg je toch een goed beeld van wat de gebruiker ervaart.

En dat was de afgelopen weken niet zo best. Dus ik wist, dat ik in actie moest komen.

Wat te doen, wanneer je performance ineens omlaag gaat?

Eigenlijk heb je drie soorten ’trage websites’. Sites die altijd traag geweest zijn, sites die langzaam traag worden en sites die ineens traag worden.

In het verleden heb ik het vaak genoeg gehad over ’trage sites’ in het algemeen, maar wanneer je site ineens traag wordt, dan is dit meestal ook het gevolg van een plotselinge verandering.

Nieuwe plugins of plugin updates

De meest waarschijnlijke oorzaak is een nieuwe versie van WordPress of updates van je plugin of thema. Het vervelende in deze hele situatie was, dat er inderdaad een flinke update had plaatsgevonden. Ik was namelijk van Elementor Pro 2.10.x overgestapt naar Elementor Pro 3.0.x. Een hele overgang! Een dag na deze overgang was mijn site ineens poeptraag.

Het zal je dus weinig verrassen, dat ik in eerste instantie Elementor de schuld gaf. Nu is Elementor één van die plugins, die er rekening mee houdt, dat dingen fout kunnen gaan en in Elementor zelf kan je terug gaan naar een vorige versie van Elementor.

Maar het opnieuw installeren van de oudere versies maakte de website niet sneller. Verder had ik geen noemenswaardige updates gedaan (dacht ik), dus ik ging kijken naar mogelijke oorzaak nummer 2. Een corrupte database.

Database corruptie

Om duidelijk te maken, wat hier aan de hand zou kunnen zijn, moet ik je eerst iets uitleggen over hoe een database ongeveer werkt. De gegevens in een database zijn in tabel formaat opgeslagen.

Nu is een computer niet veel slimmer dan jij bent met zoeken, hij zoekt alleen wat sneller.

Wanneer jij een lijst hebt met namen, gesorteerd op achternaam, dan zal je wanneer je iemand in die lijst op moet zoeken niet die persoon zijn of haar voornaam of geboortedatum vragen. Je vraagt om de achternaam. Dan heb je die persoon namelijk snel in de lijst gevonden. Als iemand bijvoorbeeld ‘Ploeg, van der’ heet, weet je dat als je van ‘Pasen, van’ springt naar ‘Prins’, er geen ‘Ploeg, van der’ in de lijst staat. Zou je naar mijn voornaam hebben gevraagd, dan zou je de hele lijst moeten doorzoeken.

Omdat we computers hebben om juist die lijst ook op andere manieren dan op ‘standaard’ volgorde te kunnen doorzoeken, hebben we zo’n tabel in de computer wat anders georganiseerd. Allereerst hebben we een ‘hoofdtabel’, die we op een unieke code gesorteerd hebben. Andere volgorden doen er nog niet toe.

Daarnaast hebben we ‘hulptabellen’, ‘indexen’. Zo’n index is bijvoorbeeld een lijst gesorteerd op achternaam. Een tweede lijst gesorteerd op voornaam, een derde op geboortedatum.

En bij iedere waarde in die hulptabel wordt verwezen naar die unieke code in de hoofdtabel.

Zoek je bijvoorbeeld op ‘Ploeg, van der’, dan zoek je eerst in de hulptabel voor achternaam, vind je de unieke code, bijvoorbeeld ’42’ en zo vind je alle gegevens. Zoek je op ‘Wilko’ doe je hetzelfde met de hulptabel voor voornaam.

Nu kan het door allerlei oorzaken gebeuren dat zo’n hulptabel beschadigd raakt. Op het moment dat dat gebeurd, kan de computer natuurlijk gewoon zeggen ‘zoek het zelf maar uit’, of hij kan wanneer hij ‘Wilko’ zoekt, geen gebruikmaken van de hulptabel om het snel te kunnen vinden, maar gewoon de hele hoofdtabel doorzoeken, tot hij ‘Wilko’ vindt bij de voornaam.

En je snapt dat gaat een stuk langer duren. En deze corruptie kan gebeuren door bijvoorbeeld een hardware crash.

Een tweede stap bij een plotseling trager worden van een website is bij mij dus altijd naar PHPMyAdmin gaan (mijn beheerstool voor mijn database bij mijn hoster) en de tabellen met de ‘CHECK’ functie te controleren. En omdat ik dan toch bezig ben, voer ik ook altijd graag een ‘OPTIMIZE’ uit, een functie die ervoor zorgt, dat de tabellen opnieuw wat slimmer worden ingedeeld.

Maar dat was het dus ook niet…

Malware

Een plotselinge verandering in de performance van je website kan ook komen door malware. Ongewenste programmatuur die zich een weg in jouw site heeft gevonden. De meest populaire malware zijn spam scripts die in een botnet enorme hoeveelheden spam versturen. En jouw website dus vrijwel stil leggen. Gelukkig is mijn website beschermd tegen malware, en toen ook na het runnen van een extra scan bleek dat er niets aan de hand was, kon ik die oorzaak ook afstrepen.

Omgevingsveranderingen

Dat is voor mij het moment, dat ik een ticket inschiet naar mijn helpdesk. Want het is heel goed mogelijk, dat het een heel andere oorzaak heeft, die buiten mijn gezicht ligt. Er kan bijvoorbeeld sprake zijn van een update van systeemsoftware die niet helemaal goed is gegaan of een defect aan de schijf.

Na een uitgebreid onderzoek plus nog eens een ongevraagd -maar wel welkom- doorlichten van mijn website, kwamen we er achter, dat de reden voor de plotselinge vertraging wel heel onduidelijk was.

Ezels en stenen…

Je kent ongetwijfeld het spreekwoord ‘Een ezel stoot zich in het algemeen, niet tweemaal aan dezelfde steen’. Ik heb dus bewezen geen ezel te zijn, want uiteindelijk bleek, dat ik me voor een tweede maal aan dezelfde steen had gestoten. Ongeveer een jaar geleden had ik vergelijkbare performance problemen. En de oorzaak was toen de cache plugin die ik gebruikte.

Niet al te nozel, dat ik bij nieuwe performance problemen niet ben begonnen met de cache plugin te onderzoeken. Daar staat tegenover, als ik dat wel gedaan had, dan had jij waarschijnlijk dit blogartikel niet gelezen. Alles gebeurt om een reden. En als het niet zo is, dan bedenken we er wel één.

Cache Enabler disabled

De plugin Cache Enabler, die ik sinds een jaar na volle tevredenheid gebruikte, en waar ook veel lezers van mijn blog heel blij mee waren bleek na de laatste update ineens behoorlijk slecht te performen. En ik was niet de enige die hier tegenaan liep. Tot op vandaag is dit probleem niet opgepakt door de maker van de plugin.

Toen ik Cache Enabler uit zette, werd de site ineens 10% sneller. Nog te weinig, maar het gaf wel aan, dat de plugin niet meer deed wat het beloofde.

Tijd voor een nieuwe plugin dus.

Een frisse wind met Breeze

Toen ik onderzoek deed naar cache plugins was de ‘Breeze‘ plugin eigenlijk mijn nummer twee in de vergelijking. Op een aantal punten vond -en vind- ik Breeze eigenlijk niet zo best presteren, maar in zijn algemeenheid doet de plugin het heel goed.

Het grote voordeel van Breeze is, dat je eigenlijk vrijwel niets in hoeft te stellen. Hij werkt ‘out of the box’. En in tegenstelling tot Cache Enabler, hoef je bij ‘Breeze’ niet aan te geven, wat de WooCommerce transactiepagina’s zijn, omdat deze niet gecached mogen worden. Breeze is slim genoeg om dit zelf te ontdekken.

Ik heb eigenlijk maar twee problemen met Breeze. Het eerste probleem is, dat iedere pagina met parameters per default niet gecached wordt. Ziet een url er bijvoorbeeld uit als

https://mijnwebsite.tld/mijn-pagina/?utm_source=mail

dan kan ik met geen mogelijkheid duidelijk maken, dat de pagina hetzelfde behandeld moet worden als

https://mijnwebsite.tld/mijn-pagina/

Bij de meeste cache engines die ik ken, kan dat wel.

Dit heeft dus als nadeel, dat iedereen die bijvoorbeeld vanuit een MailChimp of advertentiecampagne op een pagina komt, deze pagina vers gemaakt krijgt. Hij wordt niet uit de cache gehaald.

Dus de lezers van mijn nieuwsbrief merken pas, dat de site sneller is, wanneer ze doorlezen op andere pagina’s. De pagina’s die gelinkt staan in de nieuwsbrief worden op ‘oude’ snelheid getoond, maar klik je eenmaal door, dan flitsen de pagina’s voorbij.

Een tweede probleem is dat, evenals Cache Enabler overigens, het een zogenaamde ‘koude cache’ plugin is. Pagina’s worden pas gecached bij het opvragen van de pagina. Maar hier is -even als bij Cache Enabler- de Warm Cache plugin een uitkomst.

Wat kan je nog meer doen, om je website sneller te maken?

Of het nu gaat om een nieuwe website, of een website die je al langer hebt, of hij nu langzaam trager wordt, of ineens vertraagde, er is een aantal belangrijke zaken die je kan doen om je website sneller te maken.

Zorg voor een passend hostingplan

Een website met 20 bezoekers per dag kan je makkelijk laten draaien op het goedkoopste hostingplan wat jouw hoster aanbiedt, maar wanneer je een webshop hebt met honderden bestellingen per dag, of een online leeromgeving met tientallen tot honderden cursisten die dagelijks jouw site bezoeken, dan zal je toch echt een wat zwaardere omgeving moeten hebben.

Evalueer dus regelmatig, of jouw hostingplan nog wel bedoeld is voor de aantallen bezoekers die je hebt.

Link zo min mogelijk aan externe diensten!

Het staat zo leuk hè, zo’n ‘smoelenboek’ op je webpage met alle gezichten van mensen die jouw Facebook pagina ‘geliked’ hebben. Het aardige is, dat wanneer een bezoeker aan jouw site dat ‘smoelenboek’ van Facebook ziet, zal Facebook ervoor zorgen, dat daar de afbeeldingen staan van mensen waar hij of zij ook mee bevriend is.

Maar heb je enig idee hoeveel werk er op de achtergrond gebeurd, om zo’n smoelenboek te tonen? Een webpagina waar dit ontbreekt laadt zo’n 3 seconden sneller dan een webpagina met.

Hetzelfde geldt overigens ook voor andere dingen die sommige mensen graag in hun sidebar proppen, als hun laatste muziek uit Soundcloud of hun favoriete playlist van YouTube.

Probeer zo min mogelijk informatie in je webpagina’s uit externe diensten te halen. Dit vertraagt je website enorm.

Gebruik niet teveel plugins. Blijf onderzoeken hoe je plugins kunt ‘schrappen’ en deactiveer plugins die niet altijd nodig zijn.

Iedere actieve plugin kost een ‘beetje tijd’ bij het laden van een pagina, omdat iedere plugin in ieder geval moet ‘controleren’ of hij op die pagina actief moet zijn. Een groot aantal plugins kan dus een flinke vertraging opleveren in de laadtijd van je site.

Een aantal plugins zou je eigenlijk ‘standaard’ moeten deactiveren. Denk hierbij bijvoorbeeld aan plugins voor het onderhoud van je website, zoals een ‘dode link checker’, of een ‘optimizer’, die overbodige entries uit de database verwijderd. Deze acties hoeven niet iedere dag te lopen, het is voldoende wanneer je dit eens in de paar weken uitvoert. Heb je de plugin niet nodig? Zet hem dan tijdelijk uit.

Het fraaie van de pagebuilder Elementor Pro is dat deze een groot aantal plugins overbodig maakt. Laten we duidelijk zijn: Het laden van Elementor plugin kost ook tijd, maar toen ik voor WordXPression Elementor Pro installeerde, kon ik direct (en later nog meer) diverse plugins ‘schrappen’. Ik had geen plugins voor pop ups, social media, flexibele sidebars en andere zaken die ik gebruikte om mijn conversie te optimaliseren meer nodig. Ik kon alles af met Elementor.

Zorg dat je afbeeldingen van het juiste formaat zijn!

Dit heb ik uitgebreid besproken in mijn artikel over de juiste afmetingen voor je afbeeldingen.

Gebruik een caching plugin!

En dit kan ik eigenlijk niet genoeg herhalen. De WordXPression site wordt druk bezocht en enkele weken geleden liep ineens de gemiddelde laadtijd van een pagina op van gemiddeld 2 naar gemiddeld 8 seconden. Dat is natuurlijk niet acceptabel. Nu, na installatie van Breeze is de tijd teruggebracht naar gemiddeld 1,8 seconden. En dat komt vooral omdat er nog behoorlijk wat bezoek naar niet-gecachte pagina’s is vanuit advertenties of mijn nieuwsbrief. (zie hierboven voor de beperkingen van Breeze). Kijk ik steekproefsgewijs naar de laadtijd van willekeurige individuele pagina’s, dan zie ik tijden van 0,09 tot 0,21 seconden. Dat is dus enorm snel.

Blijf bij!

Wanneer je een WordPress website hebt, dan is het goed om bij te blijven met betrekking tot de ontwikkelingen. Sinds oktober 2010 blog ik met WordXPression over diverse onderwerpen rond WordPress, eCommerce, Online Leeromgevingen en Marketing. De WordXPression blog is één van de meest gelezen WordPress blogs voor ondernemers in het Nederlands taalgebied.

Wil jij bij blijven? Dan kan je je inschrijven op de nieuwsbrief of door op de rode bel linksonder op de pagina te klikken je aanmelden voor de push berichten in je browser. Op deze manier blijf je altijd bij.