Nog vijf manieren om een snellere WordPress website te krijgen.
In het eerste deel van deze blogpost heb ik je laten zien, hoe je een snellere WordPress website kan krijgen. Een aantal van deze mogelijkheden is vooral een zaak van ‘een goede hostingpartij kiezen’, een aantal andere zaken heb je zelf helemaal in de hand.
In dit vervolg kijken we naar de vijf laatste tips in deze reeks. En hier hebben we het niet meer over hostingpartijen die je eventueel als ‘schuldige’ voor een langzame site aan kan wijzen, want alle mogelijkheden om jouw site te versnellen heb je geheel zelf in de hand.
6. Afbeeldingen in het juiste formaat
Voor veel websites zijn het vooral de afbeeldingen die een fikse bijdrage leveren aan de laadtijd van een pagina. De WordXPression website is hier geen uitzondering op.
Er is een tijd geweest, dat ik in de blogpost heel spaarzaam was met afbeeldingen. Iedere post had één afbeelding en die was behoorlijk klein. Ideaal voor het laden van een pagina natuurlijk.
Maar zoals je weet, ik speel regelmatig met A/B testen en ik merkte na enkele tests al snel, dat mensen verder doorlezen, naarmate er meer afbeeldingen op een pagina staan. En dat is precies wat ik wil bereiken, dus dan maar meer afbeeldingen.
Nu heb ik een uitgebreid artikel geschreven over het gebruik van afbeeldingen in WordPress en daar vind je bijna alles in wat je moet weten. De informatie die hierin nog ontbreekt heeft betrekking op het converteren van die afbeeldingen naar WebP afbeeldingen, maar gelukkig heb ik daar ook uitgebreid over geblogd.
Gebruik geen geanimeerde GIF bestanden!
Recent kreeg ik te maken met een nieuwe klant, die vond, dat zijn website te traag was. We hebben die website behoorlijk wat sneller weten te krijgen, maar één van de grootste problemen met zijn homepage was, dat hij daar een geanimeerde GIF afbeelding gebruikte. En een flinke. Hij had er nooit zo bij stil gestaan, maar het bestand (7MB groot) blokkeerde het laden van de pagina. In een fraaie animatie werd het één en ander uiteengezet over zijn dienstverlening en omdat hij er flink voor had moeten betalen, en het zeer gewaardeerd werd door zijn bezoekers, wilde hij er natuurlijk niet zomaar vanaf.
Wat we dus gedaan hebben is eens kijken naar wat er gebeurt, wanneer we deze GIF afbeelding om zouden zetten naar een video. Deze video werd iets groter dan de GIF afbeelding. Op het eerste gezicht zou je misschien denken, dat hij hierdoor geen snellere WordPress website zou krijgen. Maar dan zien we twee belangrijke dingen over het hoofd.
Allereerst wordt de video aangeleverd door een video platform (in zijn geval Vimeo), wat min of meer werkt als een ‘CDN’. De video wordt dus apart geladen.
Daarnaast wordt de video gestreamd. Er wordt dus niets geblokkeerd en in een fractie van een seconde stond het eerst frame van de video al online. Hoewel het bestand groter was, was de vertraging in de opbouw van de webpagina ineens drie seconden minder!
7. Leverage Browser Caching
Laten we eerlijk zijn. ‘Leverage Browser Caching’ zal in veel gevallen je website niet super snel maken. Wanneer je er wel rekening mee houdt, dan zal dit overigens wel aan de ‘positieve kant’ in jouw Core Web Vitals meetellen. En het kost je weinig tijd om hier rekening mee te houden.
Wat je in principe doet, is dat je de server aan de browser van je bezoeker laat vertellen hoe lang hij bestanden in de cache van de browser moet bewaren. Hoewel dit wel enige snelheidswinst oplevert, is dit alleen voor regelmatige bezoekers die ook regelmatig dezelfde pagina’s bezoeken van toepassing.
Er zijn twee manieren om dit in te stellen. De makkelijkste manier is via de WordPress plugin die origineel genoeg ook ‘Leverage Browser Caching’ heet. Houd er rekening mee, dat deze plugin je .htaccess bestand op de server aanpast. Wanneer je hem deïnstalleert, dan blijven de instellingen voor de browser caching gewoon staan. Wil je de instellingen ongedaan maken, zal je handmatig het .htaccess bestand aan moeten passen.
De tweede manier is door mijn blogartikel over ‘Leverage Browser Caching’ te lezen, en de instructies hierin te volgen.
8. Beperk het aantal plugins -Wees selectief
Door het aantal plugins de minimaliseren krijg je al snel een snellere WordPress website. Je zal het regelmatig in mijn blogs hebben gelezen, maar iedere plugin die je activeert op je site kost extra tijd. En afhankelijk van de plugin kan dit veel of weinig zijn, maar… het kost tijd. En wel om een aantal redenen.
Iedere actieve plugin kost tijd om te laden
Eén van de redenen dat je niet al te veel plugins op je site wilt hebben is dat zelfs wanneer de plugin niets doet op die specifieke pagina, hij toch even wordt geladen, om te kijken of het de bedoeling is, dat hij wel wat doet op die pagina. Stel je voor, dat je in een vergadering met tien mensen zit. En bij ieder onderwerp de voorzitter vraagt aan iedereen persoonlijk, of ze iets toe te voegen hebben. Dat vertraagt de vergadering natuurlijk enorm, zelfs wanneer niemand ooit iets toe te voegen heeft.
Zit je met 100 personen in eenzelfde vergadering, vertraagt dat het geheel nog meer.
Wanneer deze 10 of 100 mensen allemaal wel iets toe te voegen hebben, dan zal dit de voortgang zelfs nog meer vertragen.
Je gebruikt meestal maar een deel van de functies
Het gebeurt zelden, dat je alle functies nodig hebt, die een plugin te bieden heeft. Wanneer je een plugin met vele mogelijkheden installeert, maar hiervan slechts één of enkele van deze functies gebruikt, zal dat je beslist geen snellere WordPress website opleveren. Er moet namelijk heel wat overbodige code worden geladen, die nergens wordt gebruikt.
Nu wordt dit door de server zelf geladen, en gaat dit meestal behoorlijk snel. Bij één plugin met veel overhead zal dat dus niet direct een merkbare vertraging opleveren, maar gebruik je hier meerdere plugins met veel overhead, zal dit al snel merkbaar zijn.
Bovendien krijg je hier de uitdaging van een tweede probleem. Het vertalen van ‘leesbare tekst’ uit de PHP bestanden naar machine instructies voor de server moet ‘in memory’ plaatsvinden. En om dat goed te laten verlopen, moet je aan PHP een bepaalde hoeveelheid intern geheugen toekennen, die per proces gebruikt mag worden. Nu zal een standaard WordPress website met niet al te veel toeters en bellen aan 48MB voldoende hebben. Dat wil zeggen, dat voor iedere page-hit in WordPress tijdelijk 48MB van het beschikbare geheugen voor PHP wordt gereserveerd. Is dat onvoldoende, dan krijg je een ‘Out of Memory’ fout en breekt het proces af.
Bij het gebruik van WooCommerce heb je minimaal 128MB nodig, liefst 256MB. WooCommerce is namelijk een plugin die heel wat vergt van het systeem. Maar omdat je per proces meer geheugen nodig hebt, heb je minder bezoekers die je gelijktijdig kan helpen, indien de totale hoeveelheid computergeheugen in beide situaties hetzelfde zou zijn.
Grote plugins vergen dus veel geheugen, wat minder gelijktijdige bezoekers = minder snelle response betekent.
Oplossing is bijvoorbeeld plugins te gebruiken die een veelheid van functies hebben, waarvan je een groot aantal functies ook daadwerkelijk gebruikt.
Oplossing voor ‘veel plugins’: Gebruik functions.php indien mogelijk
Eén manier om dit soort vertragingen te voorkomen, is door voor kleine aanpassingen in je layout bijvoorbeeld geen aparte plugin in te schakelen, maar deze losse functionaliteiten in de ‘functions.php’ van je thema op te (laten) nemen. Natuurlijk maak je dan eerst een ‘child theme’ van je thema. En even vanzelfsprekend, je doet dit alleen in een staging omgeving.
Plugins voor koppelingen naar externe diensten
Wanneer je een ondernemerssite hebt, dan wil je natuurlijk graag weten, wie er zoal je website bezoeken. Dus een koppeling met Google Analytics, met een Facebook Pixel of wellicht met andere externe diensten als bijvoorbeeld Microsoft Clarity kunnen heel handig zijn. En er zijn allerlei plugins om je website met deze diensten te verbinden. Eén groot nadeel hierbij is echter, dat je al snel een groot aantal verschillende plugins hebt, die allemaal maar één klein dingetje doen.
Alles wat deze plugins doen, is het toevoegen van een klein stukje JavaScript aan je website. Dat moet handiger kunnen, dacht je niet? En gelukkig kan dat ook handiger.
Er zijn diverse plugins waarmee je speciale code in headers en footers op je site kan zetten. Daarnaast wil ik toch ook even een tweetal andere mogelijkheden onder jouw aandacht brengen.
Elementor ‘Custom code’
Sinds versie 3.1 heeft Elementor een ‘Custom Code’ optie waarmee je makkelijk codefragmenten aan je website toe kan voegen. De mogelijkheden heb ik onder punt 8 van mijn blogartikel met 10 tips voor Elementor besproken.
Google Tag Manager
Een andere optie is alle ‘externe code’ helemaal buiten je site te brengen met behulp van Google Tag Manager. In één externe applicatie houd je alle extra codefragmenten bij. Met behulp van slechts één code ‘link’ je al die codes aan je website en deze codes worden op de juiste momenten ingevoegd.
Page builders
Wanneer we het over ‘vertragende plugins’ hebben dan verdienen ‘Page Builders’ hier speciale aandacht. Wanneer je een snellere WordPress website wilt, dan zal je heel kritische moeten zijn bij het gebruik van pagebuilders.
Grofweg zou je kunnen zeggen dat er een tweetal soorten page builders is. De eerste generatie pagebuilders -voornamelijk de wat oudere- maken gebruik van ‘shortcodes’ om een pagina op te bouwen. Het nadeel van zo’n shortcode is dat iedere shortcode een functieaanroep is. Laad ik als bezoeker dus een pagina, dan worden er tientallen, honderden functies aangeroepen om de HTML te genereren die uiteindelijk naar de browser wordt verzonden.
De server wordt dus hard aan het werk gezet. Bij het gebruik van deze generatie van plugins hoef je zeker geen snellere WordPress website te verwachten.
Enkele voorbeelden hiervan zijn Divi en WPBakery.
De tweede generatie page builders heeft geleerd van de eerste generatie. In plaats van bij het tonen van de pagina iedere keer opnieuw een shortcode uit te voeren, worden de pagina’s op een andere manier opgeslagen.
In de ‘meta informatie’ van de post wordt een behoorlijk ingewikkelde structuur opgeslagen, waarin alle paginadefinities staan opgenomen. Deze definities worden uitsluitend geladen, wanneer je de pagina aan wilt passen. Pas je de pagina aan en sla je hem weer op, dan wordt die hele structuur weer weggeschreven en daarnaast wordt de HTML gegenereerd die de pagina zal tonen.
Vraagt een bezoeker de pagina op, dan wordt direct de HTML getoond. Er worden dus niet honderden PHP functies aangeroepen, iedere keer dat iemand de pagina wilt zien. En dat scheelt heel wat in de performance. Enkele bekende ‘generatie 2’ pagebuilders zijn Thrive Architect en natuurlijk Elementor (Pro).
Bloat
Toch heb je zonder pagebuilders mogelijk een snellere WordPress website dan met toepassing van een pagebuilder. En dat komt vooral door de ‘bloat’, al de overbodige code die mee wordt geladen. Dit is overigens niet een probleem wat uniek is aan page builder plugins, maar ook aan zogenaamde ‘premium thema’s’, de CSS en JavaScript bestanden worden -ongeacht of een functie nu wel of niet gebruikt wordt op die pagina- met iedere pagina meegezonden.
Wanneer je dus een snellere WordPress website wilt, is het onder meer zaak, dat je gebruik maakt van de ‘Leverage Browser Caching’ optie, waardoor deze bestanden niet iedere keer opnieuw verzonden zullen worden. Gebruik maken van GZip en HTTP/2 zal ook voor een snellere WordPress website zorgen.
9. Uitgesteld laden van hulpbestanden (deferred asset loading)
Een andere manier om een snellere WordPress website te krijgen is het uitgesteld laden van ‘hulpbestanden’ zoals CSS, JavaScript en afbeeldingen.
Dit heb ik heel recent uitgebreid besproken, dus hiervoor verwijs ik je graag naar het betreffende blogartikel. Hier wordt ook een aantal plugins besproken wat je helpt een snellere WordPress website te krijgen.
10. ‘Externe’ versnellers gebruiken
Al enkele jaren geleden heb ik Cloudflare genoemd als een mogelijke manier om je website te versnellen. Hoewel dit enige snelheidswinst op zal leveren, zijn er inmiddels veel betere mogelijkheden om een snellere WordPress website te krijgen.
Een dienst waar ik zelf goed over te spreken ben is de ‘SpeedKit’ van BaqEnd.
Veel van de websites die ik bouw hebben maar beperkt profijt van caching. Dat komt omdat ik voornamelijk online leeromgevingen en webshops maak. Caching heeft maar heel beperkt nut, wanneer een bezoeker is ingelogd op een site en bij een online leeromgeving is zo’n 80% van de bezoekers ingelogd, bij een webshop, afhankelijk van je success met die shop, tot zo’n 50%.
En hoewel ‘ingelogde pagina’ niet worden gemeten voor de Core Web Vitals, zijn ze natuurlijk wel van groot belang voor het gevoel van tevredenheid van je bezoeker.
En van alle snelheid verhogende tips in dit en het voorgaande blogartikel, is juist caching de methode die de meeste zoden aan de dijk zet.
Enige tijd geleden besloot ik mijn belangrijkste websites die al in de cloud op een VPS stonden over te brengen naar een andersoortige configuratie en deze configuratie te gaan beheren met het Plesk beheerpanel. Via dat beheerpanel kwam ik voor het eerst in aanraking met SpeedKit van BaqEnd.
Intelligente caching
SpeedKit is een externe dienst die verschillende van de in dit artikel genoemde technieken gebruikt om jouw website sneller te maken, maar hier nog een aantal ‘eigen’ methoden aan toevoegt. Het meest interessant is denk ik wel de caching methode die er gebruikt wordt. Een caching methode die gebaseerd is op AI en machine learning.
Wat is bijvoorbeeld het probleem de gemiddelde online leeromgeving, wanneer je inlogt? Wanneer je bij mij een online cursus doet, dan is het verschil tussen jouw ‘les scherm’ en het les scherm van Jan, dat bij jou in de rechterbovenhoek jouw naam staat, en bij Jan staat er ‘Jan’.
Voor de rest krijg je dezelfde pagina’s te zien.
SpeedKit kijkt bij ‘ingelogde pagina’s’ naar de opbouw van de pagina naar de veranderende en de constante elementen en zal in de cache de pagina intelligent zo aanpassen, dat er een verschil wordt gemaakt tussen ‘dezelfde’ data en veranderende data.
En op deze manier kan -ook wanneer je bent ingelogd- een deel van de pagina die je opvraagt direct uit de cache komen.
Daarnaast worden er allerlei andere technieken gebruikt om de pagina’s behoorlijk te versnellen. Wil je weten, hoeveel winst jij op je pagina kan hebben, doe dan de test eens.
Prijsstelling
Nu is SpeedKit geen gratis dienst. En ik moet eerlijk zeggen, dat ik de prijsstelling van SpeedKit alles behalve transparant vind.
Er zijn drie manieren om gebruik te maken van SpeedKit.
De ‘lastige manier’, waar ik ook verder niet op in wil gaan, is via de ‘SpeedKit API’. Daarnaast komt SpeedKit als een WordPress plugin of als een uitbreiding op het Plesk beheer panel.
Vooral op het gebied van de prijs voor de dienst met de WordPress plugin is BaqEnd heel onduidelijk. De pagina in de WordPress repository geeft aan, dat het gebruik van de dienst een eerste maand gratis is, maar na die maand 9,99 dollar per maand gaat kosten.
De link naar de ‘Pricing’ pagina op de BaqEnd site vertelt mij, dat de tarieven afhankelijk zijn van het aantal pagina’s per maand, en dat ik een persoonlijke offerte aan moet vragen. Doe ik dat, dan krijg ik een antwoord, dat ik Plesk gebruik, en het gebruik maken van de diensten in Plesk veel goedkoper is.
Een goed antwoord wat het mij zonder Plesk zou kosten om een snellere WordPress website te hebben krijg ik dus niet.
Ik zal mij dus beperken tot de kosten via Plesk.
Heb jij een WordPress website gebouwd door WordXPression en kies je voor WordXPression Hosting dan is het gebruik van SpeedKit inbegrepen in de prijs voor WooCommerce Webshop of Online Leeromgeving hosting. Heb je een VPS met Plesk, dan kost -voor een enkel domein- Speedkit je op dit moment 5,99 euro ex BTW per maand.
Heb je meerdere websites op dezelfde VPS server, dan worden de kosten per website al snel een stuk lager. Voor 10 websites betaal je bijvoorbeeld slechts 19,99 euro ex BTW per maand.
WordXPression hosting
Wil je werkelijk een snellere WordPress website, dan is wellicht WordXPression hosting een goede oplossing voor je. Om maar gelijk één misverstand uit de weg te ruimen, ik bied geen hostingdiensten in zijn algemeenheid aan. Ik heb er weinig zin in, om in een toch al overvolle markt een nieuwe dienst aan te gaan bieden. WordXPression hosting is een dienst exclusief voor ondernemers die een WooCommerce Webshop, een Online Leeromgeving of een ‘reguliere website’ -en hierbij maakt het niet uit of het een WordPress XPress of een WordXPression Basix website it- door WordXPression hebben laten bouwen.
WordXPression Hosting is uniek, omdat het een resultaat gerichte hosting is. Of in eenvoudig Nederlands : Wanneer gemiddeld over een maand, de site niet snel genoeg blijkt, krijg je een extra maand hosting gratis.
Het aardige is, dat hierbij al die punten die in deze tien tips worden aangegeven niet langer jouw probleem zijn, maar het probleem van WordXPression. En dat je de garantie hebt, dat al het mogelijke om jouw site zo snel mogelijk te maken uit de kast gehaald zal worden.
Zoek je dus naar snellere WordPress hosting en is jouw website aan vernieuwing toe, dan kan WordXPression jou het ideale pakket aanbieden.