Het web wemelt van de tips en trucs om je WordPress-prestaties te optimaliseren. Helaas vallen relevante verklaringen en beoordelingen van de verschillende parameters al snel weg. We laten je de belangrijke uitgangspunten en instrumenten zien - in een zinvolle volgorde en met context. Op deze manier kun je zeer snel succes boeken.
Inmiddels hebben we al zo'n 15.000 WordPress-projecten gehost. Daarbij is een heleboel data verzameld. En we worden voortdurend door klanten gevraagd hoe ze de laadtijd van de pagina's van hun WordPress-projecten verder kunnen reduceren. Daarom hebben we onze bevindingen uit de analyse van onze klantensites uit voorgaande jaren systematisch verwerkt. Het resultaat: 10 maatregelen waarmee je snel en eenvoudig je WordPress-prestaties kunt optimaliseren.
Eén ding in het bijzonder is belangrijk: Sommige gebruikers worden snel afgeschrikt door optimalisatiesuggesties van tools zoals Google PageSpeed Insights. Laat me je dit vertellen: De meeste laadtijd wint u niet met ingewikkelde optimaliseringsmaatregelen, maar met methoden die eenvoudig toe te passen zijn.
Laadtijdoptimalisatie is natuurlijk geen doel op zich. Naast een betere ervaring voor uw gebruikers, levert een kortere laadtijd ook voordelen op voor de zichtbaarheid van uw aanbod in Google. Daarom zal ik ook kort schetsen waar de afzonderlijke optimalisatiestappen eigenlijk over gaan, om de juiste context te scheppen.
Theoretisch kunt u van boven naar beneden werken en de laadtijd van uw pagina stap voor stap verbeteren. Overigens verwijzen de eerste zeven punten ook naar de typische suggesties voor verbetering van Google PageSpeed Insights, waar we in dit artikel bijvoorbeeld dieper op ingaan.
#1 Caching - de belangrijkste prestatiefactor van allemaal
Caching betekent dat je pagina niet eerst door de browser bij de webserver moet worden opgevraagd en vervolgens stap voor stap moet worden opgebouwd. In plaats daarvan wordt je pagina - al volledig gerenderd - vanuit een cache (tijdelijk geheugen) geladen.
Het voordeel van deze cache ligt voor de hand: WordPress hoeft niet bij elke klik de site opnieuw te berekenen. Omdat WordPress op de zeer langzame PHP gebaseerd is, is een cache hier elementair. Het voorkomt onder andere dat PHP moet worden uitgelezen.
In principe zijn er twee uitvoeringsvarianten voor caches:
- Over cachingPlugins: De meerderheid van de gebruikers gebruikt een cachingPlugin, zoals W3 Total Cache of WP Super Cache. Deze zijn soms gemakkelijker, soms wat ingewikkelder op te zetten. In ieder geval is hier een zekere mate van handwerk vereist.
- Over de hoster: Sommige hosters - waaronder Raidboxes - bieden server-side caching. Dit betekent dat je bijna altijd zonder caching plugins kunt. Dit komt omdat je hostingprovider de cache al voor je heeft geconfigureerd.
Als je een performante caching hebt opgezet, heb je al de belangrijkste stap gezet naar meer WordPress performantie. Voor meer details, zie ons artikel over caching basics.
#2 WordPress opruimen - "Ordnung muss sein"
Een van de meest voorkomende oorzaken van lange laadtijden is - volgens onze ervaring - een overbelaste WordPress-installatie. En omdat dit verbeteringspunt niet wordt genoemd door GooglePageSpeed Insights, komt het direct op de tweede plaats in mijn Top 10.
Een overbelaste WordPress-installatie betekent in de meeste gevallen: er zijn te veel plugins geïnstalleerd. In principe geldt: hoe minder plugins, hoe sneller de pagina. Natuurlijk zijn de plugins belangrijk en zonder gaat het niet, maar je moet van tijd tot tijd controleren welke plugins je echt nodig hebt.
En: je moet ervoor zorgen dat je de plugins niet alleen deactiveert, maar echt volledig verwijdert.
Hetzelfde geldt voor themes: je hebt er niet meer dan één nodig.
De achtergrond is als volgt: elke plugin en elk theme voegt een PHP-code toe aan je pagina. Dit geldt ook voor gedeactiveerde plugins. Dit maakt je site in zijn geheel omvangrijker en dus langzamer (en kwetsbaarder voor aanvallen). PHP is een zeer langzame scripttaal. Hoe minder hiervan aanwezig is, hoe beter.
Vaak zijn Plugins en Themes overblijfselen van functionele en ontwerptests. Daarom is het een goed idee om uw WordPress pagina's regelmatig op te schonen en nieuwe functies en ontwerpen te testen in een testomgeving en niet op de live pagina. Op deze manier kunt u voorkomen dat u te veel Plugin overblijfselen opstapelt.
#3 Afbeeldingen: de onderschatte laattijdrem
Een van de meest effectieve en eenvoudigste maatregelen om de laadtijd van pagina's te verkorten, is het verkleinen van afbeeldingen. Omdat je hier soms grote hoeveelheden gegevens kunt opslaan. Met de zogenaamde "lossless image compression" wordt de bestandsgrootte van uw afbeeldingen verkleind zonder zichtbaar kwaliteitsverlies. Uw pagina verandert dus nauwelijks, terwijl u tegelijkertijd de grootte ervan aanzienlijk kunt beperken door beeldoptimalisatie.
HTTP Archive schat dat afbeeldingen regelmatig het grootste deel van het verkeer van een website uitmaken. Het verkleinen van uw afbeeldingen zou daarom een van de eerste optimalisatiestappen moeten zijn. U kunt afbeeldingen handmatig optimaliseren, of u kunt een compressieprogramm Plugina gebruiken .
Het gebruik van één plugin is zeker de handigste oplossing. Niet alleen laten plugins het toe om nieuwe beelden en hun thumbnails te comprimeren, ze pakken ook automatisch alle bestaande afbeeldingen van je site aan. Voor deze dienst wordt echter vaak een vergoeding gevraagd.
#4 CSS en JavaScript - klinkt omvangrijk, maar is eenvoudig te optimaliseren
De op één na grootste hoeveelheid gegevens op je site zijn meestal JavaScript- en CSS-bestanden. Veel gebruikers zijn vooral bang om deze bestanden aan te raken. Maar ook zonder code-expertise kun je gemakkelijk begrijpen waar het bij CSS en JavaScript-optimalisatie om gaat. Want in principe moet je eerst drie dingen doen:
- Samenvatten: CSS en JavaScript zijn verborgen in vele kleine afzonderlijke bestanden. Normaal moet elk van deze bestanden afzonderlijk door de browser bij de webserver worden aangevraagd. Dit genereert HTTP-verzoeken die de laadtijd van uw pagina kunnen verlengen. Indien scripts echter worden gecombineerd, wordt het aantal te laden bestanden verminderd en dus ook het aantal verzoeken. Zo worden 53 afzonderlijke verzoeken iets meer dan een dozijn. Natuurlijk kan Pluginsdit ook voor u doen.
- Verminderen: CSS- en JavaScript-bestanden zijn coderegels die bepaalde functies en ontwerpen op uw pagina mogelijk maken. Deze code is door mensen geschreven. Het wordt echter door machines gelezen. Waarom is dit relevant? Veel van wat een mens nodig heeft om code correct te begrijpen, heeft een computer niet. Dus spaties, commentaar, enz. zijn niet nodig om uw pagina correct op te bouwen. Dit is waar Plugins zoals Autoptimize van pas komt. Zij zetten CSS en JavaScript om van door mensen leesbare naar door machines leesbare code. Dit maakt de afzonderlijke gegevenspakketten kleiner en hun transmissie sneller.
- Comprimeren: Na het samenvatten en verkleinen is de laatste stap dan het comprimeren van de gegevenspakketten die van de webserver naar de browser worden gestuurd. Dit betekent dat de server de bestandsgrootte van de afzonderlijke verzoeken minimaliseert en dat de browser ze uitpakt en berekent. Dit is sneller dan het verzenden van ongecomprimeerde gegevenspakketten. U kunt zo'n GZIP-compressie instellen, bijvoorbeeld via caching-Plugins, via handmatige instellingen in de .htaccess of uw hoster heeft al een compressie aan de serverzijde geactiveerd.
Zelfs zonder kennis van de scripts is het gemakkelijk te begrijpen wat de afzonderlijke maatregelen opleveren. En voor alle drie de stappen is er Plugins, waarmee zelfs leken CSS en JavaScript kunnen optimaliseren. In ons artikel over CSS en JavaScript optimalisatie, leggen we meer details uit en presenteren we verschillende Plugins .
Vier op een rij!
#5 Zonder hosting kom je nergens
De eerste vier optimalisatievelden beloven een bijzonder hoge laadtijdverkorting, maar kunnen op niets uitlopen als uw hosting u vertraagt. Dit heeft niet zozeer betrekking op de hardwarevereisten voor WordPress , maar veeleer op bepaalde technologieën die aantonen dat een hoster u in staat steltWordPress dienovereenkomstig te optimaliseren.
Als vuistregel kan je onthouden dat een krachtige WordPress hosting deze kerngegevens zou moeten hebben:
- SSD Harde Schijf
- PHP geheugenlimiet van minstens 64MB, beter 128MB
- Datacentrum in Europa
- Huidige PHP-versie (7.4)
- HTTP/2 en gratis SSL-certificaat
Dan is er nog het verschil tussen Shared Hosting en een eigen (virtuele) server.
Met Shared Hosting deel je de server en zijn rekenkracht met andere sites. Meestal enkele tientallen tot een paar honderd. Als je een eigen server hebt, hoef je de rekenkracht met niemand te delen. Het biedt dus vooral het voordeel van prestatiezekerheid.
Hoewel een eigen server niet synoniem is aan meer prestaties, leert de ervaring wel dat vooral de goedkope hostingtarieven, die slechts enkele euro's per maand kosten, qua prestaties niet kunnen concurreren met virtuele servers.
De finesse - minder slagkracht, meer inspanning
Alle performancerelevante gebieden die ik tot nu toe heb genoemd, kunnen door vrijwel elke WordPress-gebruiker worden geoptimaliseerd. Hetzij via plugins, eenvoudig uitproberen of de aankoop van geschikte producten. Het wordt ingewikkelder als je deze gebieden al hebt geoptimaliseerd. Want dan moet je dieper ingaan op de structuur van de site. En individuele optimaliseringsmaatregelen hebben niet meer dezelfde slagkracht.
#6 Renderblocking - verkeerde volgorde bij het laden
Een punt dat door tools zoals Google PageSpeed Insights herhaaldelijk bekritiseerd wordt, is een laadvolgorde die de rendering blokkeert.
Dit voorbeeld illustreert het probleem: een Slider bestaat uit afbeeldingen en het animatiecommando dat deze afbeeldingen laat draaien. Als het JavaScript-commando eerst wordt geladen en de afbeeldingen als laatst, beschikt je pagina weliswaar over de functie van de Slider, maar niet over afbeeldingen die weergegeven moeten worden. Het laden van de pagina duurt dus langer. Deze toestand kan voorkomen worden door de juiste laadvolgorde.
Er zijn weliswaar plugins om de laadvolgorde te optimaliseren, maar onze ervaring leert dat deze niet altijd in staat zijn om je site volledig te optimaliseren. De beste resultaten bereikt in dit geval meestal een webdesigner die de site en zijn functies goed kent.
#7 Above the Fold - optimaliseer het zichtbare gedeelte van de pagina
Naast de totale laadtijd van uw pagina is ook de waargenomen laadtijd van cruciaal belang. Dat wil zeggen, de tijd die een bezoeker van uw site als laadtijd beschouwt. Deze waargenomen laadtijd kan met een paar trucs worden verkort. Zo krijgt een gebruiker de indruk dat de pagina al volledig is opgebouwd, hoewel op de achtergrond nog wordt gerekend.
Bijzonder belangrijk voor het optimaliseren van dit gebied, bekend als Above the Fold, is het optimaliseren van de laadvolgorde. Dit betekent dat u voorrang moet geven aan inhoud en functies die uw bezoekers op het eerste schermformaat te zien krijgen.
U kunt dit bijvoorbeeld bereiken door de laadvolgorde te optimaliseren. Er is echter ook Plugins, dat ervoor zorgt dat uw pagina efficiënter laadt. En alleen het zichtbare gebied. Lazy Load of a3 Lazy Load zijn voorbeelden van dergelijke Plugins. Op deze manier krijgt de gebruiker altijd alle inhoud die hij of zij nodig heeft, maar de laadtijd van de pagina kan hier nog van profiteren, vooral als het een pagina is met veel afbeeldingen.
#8 Database schoonmaken
Naast afbeeldingen en scripts, kan je database ook te groot worden. Er zijn ook praktische hulpmiddelen die uw database mooi en slank houden. Bijvoorbeeld, de Plugin WP-Optimize.
#9 Pingbacks en trackbacks
Standaard interageert WordPress met andere pagina's die Pingbacks en Trackbacks toestaan. Elke keer dat je site of een van je blogposts op zo'n pagina wordt vermeld, wordt je site automatisch op de hoogte gebracht - en daarmee de database extra belast.
Als je deze functie niet nodig hebt (de toegevoegde waarde is naar mijn mening te verwaarlozen) moet je Pingbacks en Trackbacks uitschakelen. Ook hier helpt weer de plugin WP-Optimize. Voor de volledigheid moet hier worden vermeld dat dit meer een theoretisch probleem is. Geen van onze klanten heeft hierdoor ernstige prestatieverliezen geleden.
#10 Hotlinking voorkomen
Hotlinking betekent dat iemand rechtstreeks naar een afbeelding op uw server linkt - in feite uw bandbreedte "steelt". Op een Apache webserver kunt u hotlinking voorkomen door de volgende code toe te voegen aan uw .htaccess bestand:
RewriteEngine on
RewriteCond %{HTTP_REFERER} !^$
RewriteCond %{HTTP_REFERER} !^http(s)?://(www.)?deineseite.de [NC]
RewriteCond %{HTTP_REFERER} !^http(s)?://(www.)?google.de [NC]
RewriteCond %{HTTP_REFERER} !^http(s)?://(www.)?google.com [NC]
RewriteRule .(jpg|jpeg|png|gif)$ – [NC,F,L]
Om hotlinking op een NGINX server te voorkomen, voeg je deze regels code toe aan je NGINX config bestand:
location ~ .(gif|png|jpeg|jpg|svg|webp)$ {
valid_referers none blocked server_names
*.example.com example.* www.example.org/galleries/ ~\.google\.;
if ($invalid_referer) {
return 403;
}
}Specificatie van de code:location ~ .(gif|png|jpeg|jpg|svg|webp)$ {
specificeert de bestandsextensies die jou tegen Hotlinking beschermen, als je bijvoorbeeld nog pdf-bestanden wilt beschermen, dan zou de coderegel er als volgt uitzien:location ~ .(gif|png|jpeg|jpg|svg|webp|pdf)$
{valid_referers none blocked server_names*.deineseite.dedeineseite.de ~.google. ~.bing. ~.yahoo.;
Deze regels zijn een beetje uitgebreid, maar het zal je helpen om beter te begrijpen wat er allemaal met deze regel gedaan kan worden. Deze regels geven aan welke domeinen je bestanden mogen hotlinken. In dit voorbeeld uwpagina.nl met alle subdomeinen, zoals Google, Bing en Yahoo.
if ($invalid_referer) {return 403;}
Als er een aanvraag binnenkomt en de aangevraagde bron staat NIET bovenaan je whitelist stuurt de server een 403 (Forbidden) terug.
Andere methoden om hotlinking te voorkomen
"En hoe zit het met CDN?"
Een van de meest gestelde vragen gaat over een Content Delivery Network (CDN). Bijvoorbeeld: "Maakt een CDN mijn site sneller voor bezoekers in Duitsland?", "Waarom heb ik eigenlijk een CDN nodig?", "Zou je me aanraden een CDN te gebruiken voor mijn blog of winkel?". In de meeste gevallen was het antwoord echter: nee.
Om een lang verhaal kort te maken: een CDN heeft de meeste zin als je gebruikers geografisch verspreid zijn. Bijvoorbeeld als je klanten hebt in Centraal-Europa, Zuid-Amerika en Australië. Als je kerndoelgroep beperkt is tot één land, kun je een CDN voor het optimaliseren van je WordPress-Performance direct ad acta leggen.
Tussen haakjes, de WordPress ontwikkelaar Ernesto Ruge heeft een zeer mooi artikel over dit probleem geschreven, dat ik u alleen maar kan aanbevelen.
Conclusie: Wees niet bang voor ingewikkeld ogende optimalisatiestappen
Vaak zijn gebruikers bang om aan dergelijke gebieden te zitten waar bijzonder gemakkelijk laadtijd kan worden bespaard. Of ze verwaarlozen deze gebieden. Andere gebieden daarentegen, zoals CDN, komen steeds weer naar voren tijdens adviesgesprekken, hoewel ze meestal geen effect op de laadtijd van de pagina hebben.
Daarom kan ik alleen maar adviseren dat je je eerst concentreert op het "laaghangende fruit" van optimalisatie. Met relatief weinig inspanning kun je al grote vooruitgang boeken bij het verkorten van je laadtijd. Zelfs als je een leek bent.
Laat je daarom niet door adviezen van tools zoals Google PageSpeed Insights onzeker maken.
Want in de kern gaat het bij de optimalisatie van de laadtijd slechts om een paar onderdelen:
- Verminder de grootte van je pagina
- Vermindering van HTTP-aanvragen
- Compressie van de afzonderlijke datapakketten
- Optimalisatie van de gebruikerservaring
Als je dit hebt begrepen, dan kun je ook de 10 belangrijkste parameters van de WordPress-Performance nuttig verstellen. En voor complexere optimalisatiestappen zijn er ook experts die je site op orde kunnen brengen.
