Een trage WordPress-website is geen zeldzaam fenomeen, integendeel! Het is enorm frustrerend en dramatisch voor de resultaten die je haalt met WordPress.
Heb jij ook te maken met een traag ladende WordPress-website?
Of denk je dat de laadtijd nog verbeterd kan worden?
Dan heb ik goed nieuws voor je! Een WordPress-website sneller maken is geen ‘rocket science’ en kun je helemaal, of grotendeels, zelf doen.
Hoe?
Dat vertel ik je in dit artikel aan de hand van 19 optimalisaties, waarmee je de snelheid van je WordPress-site kunt optimaliseren.
Volg je deze adviezen op, dan wordt jouw WordPress-website mogelijk tot 5 keer sneller. Dus 80% minder laadtijd! Of zelfs nog meer…
En hoe sneller je WordPress-site is, des te beter is het resultaat dat je ermee haalt!
Jarenlang heb ik mij verdiept in snelheid optimalisatietechnieken en heb ik me deze eigen gemaakt. Deels uit natuurlijke interesse, maar vooral omdat ik als online marketeer weet hoe belangrijk een snelle website is!
In dit uitgebreide blog deel ik mijn kennis van dit onderwerp met jou, zodat jij ook jouw WordPress-website sneller kunt maken.
Lees snel verder en dit kom je te weten:
- Het belang van een snelle (WordPress) website
- Breng de knelpunten in kaart en doe nulmetingen voordat je begint
- WordPress snelheid optimalisatie best practices
- Software die je nodig hebt bij het sneller maken van WordPress
- 19 optimalisaties die je WordPress-website sneller maken
- De belangrijkste optimalisatie: kies snelle hoogwaardige hosting
WordPress website sneller maken: waarom belangrijk?
Een website moet tegenwoordig snel zijn om de aandacht van de bezoeker te verdienen. WordPress is een CMS dat in de basis niet heel snel is. Het belang van optimalisatie voor snelheid is groot!
De tijd die een bezoeker neemt om een webpagina te openen en te beoordelen is een kwestie van enkele seconden. Deze tijd wordt steeds korter, naarmate het internet en technologie zich verder ontwikkelen.
Wie ergert zich niet aan een traag ladende website op een smartphone? De doelgroep van jouw website heeft steeds minder geduld.
Wat te denken van grote zoekmachines zoals Google. Hoge posities in de zoekresultaten zijn voor de meeste websites van strategisch belang. Google houdt tegenwoordig rekening met de snelheid van websites (bron), dus de laadtijd kan maar beter optimaal zijn!
Snelheid beïnvloedt ook de resultaten in de vorm van conversie. 1 seconden daling in laadtijd betekent 7% minder conversie. (bron)
Maar denk ook aan jezelf als ‘wp-admin’. Jij wilt toch lekker snel door de beheeromgeving kunnen navigeren en zo efficiënt mogelijk kunnen werken?
En dus geldt…
Doet jouw WordPress-website er langer over dan 3 seconden om volledig te laden? Dan mag je spreken van een probleem!
Is er werk aan de winkel voor wat betreft de snelheid van jouw WordPress-site? Lees snel verder of ga direct naar de 19 optimalisaties.
Breng de knelpunten in kaart en doe nulmetingen voordat je begint
Als je tot hier bent gekomen neem ik aan dat je de snelheid van jouw WordPress-website gaat optimaliseren. Heel goed, want daar ga je geen spijt van krijgen!
Om te bepalen wat je moet optimaliseren en wat het resultaat is van je optimalisaties, raad ik aan om nulmetingen te doen voordat je begint. Met deze metingen breng je meteen de knelpunten naar boven.
Na het verbeteren van de snelheid doe je vervolgens exact dezelfde metingen. De resultaten hiervan vergelijk je met de nulmeting, zodat je de snelheidswinst kunt zien.
Bepaal de laadtijd van je WordPress-website met deze online tools:
Waar moet je op letten?
Allereerst: hoe snel laadt mijn WordPress-website?
Daarnaast: in hoeverre is mijn site geoptimaliseerd om snel te laden?
Hoe snel laadt mijn WordPress website?
Webpagetest.org biedt op dit gebied de meest uitgebreide inzichten. Het is belangrijk om te kijken naar de eerste rij met cijfers van het testresultaat, de rij First View.
Belangrijke getallen zijn:
- First Byte
Geeft aan hoe snel een verbinding met de webserver gemaakt kan worden en de eerste byte opgehaald kan worden. Rond 200 ms is prima. - Speed Index
Dit cijfer staat uitgedrukt in milliseconden en geeft aan hoe snel de content op de webpagina visueel zichtbaar is. Streef naar 2000 of minder. - Fully Loaded Time
Geeft aan hoe lang het duurt om de pagina volledig te laden. Streef naar minder dan 3.000s. - Fully Loaded Requests
Geeft aan hoeveel connecties er nodig zijn om de webpagina volledig te laden. Hoe lager dit getal, des te beter.
De tests van Pingdom en GTmetrix geven alleen een totale laadtijd en het aantal requests. Deze tools hebben weer andere voordelen. Keep reading!
In hoeverre is mijn website geoptimaliseerd om snel te laden?
Pingdom en GTmetrix geven uitgebreid inzicht in hoe geoptimaliseerd jouw website al is. Dit doen de tools aan de hand van een score. GTmetrix laat een Google PageSpeed Score en YSlow Score zien. Pingdom laat een eigen waardering zien.
Webpagetest.org laat geen score in de vorm van een getal zien. Deze tool waardeert enkele belangrijke aspecten met een gradatie van A (goed) tot F (slecht).
Het principe van een WordPress-website sneller maken en optimaliseren is dat je probeert een score van 100 (bij Pingdom en GTmetrix) en A-grades (bij Webpagetest.org) probeert te bereiken of benaderen.
De tools geven precies aan welke punten je nog kunt verbeteren, waarbij de suggesties van Pingdom en GTmetrix het meest uitgebreid zijn.
Dat ziet er als volgt uit:
Testresultaat en verbetersuggesties Pingdom
Testresultaat en verbetersuggesties GTmetrix
Testresultaat en verbetersuggesties Webpagetest.org
Bijna alle verbeterpunten die vaak naar voren komen uit deze tests, los je op met de optimalisaties die ik in dit blogartikel beschrijf.
Zoek binnen dit artikel eenvoudig op benamingen van knelpunten die de tools aangeven, met toetsencombinatie CTRL+F voor Windows en CMD+F voor Mac. Zo vind je de informatie die je nodig hebt om die punten te optimaliseren.
Let op de instellingen van de meettools
Bij de bovengenoemde tools kun je de instellingen voor het testen wijzigen. Enkele instellingen en tips die belangrijk zijn voor een goed meetresultaat:
- Testlocatie
Gebruik dezelfde testlocatie voor de nulmeting en de resultaatmeting na het optimaliseren. Persoonlijk kies ik altijd de dichtstbijzijnde testlocatie. Zo krijg je een realistisch beeld van de laadtijd voor een Nederlandse bezoeker van jouw WordPress-website. Vaak is Amsterdam of Londen de dichtstbijzijnde testserverlocatie. - Aantal metingen
Voer de metingen meerdere keren uit. Soms kan een tool haperen en een rare uitslag geven. Voer een test minimaal 5 keer achter uit. Bij Webpagetest.org is het ook mogelijk om de test automatisch meerdere keren achter elkaar uit te voeren. Verhoog bij Webpagetest.org het aantal metingen tot het maximum van 9.
Hieronder laat ik je de instellingen zien zoals ik ze gebruik:Vi
Webpagetest.org instellingen
Pingdom Tools Full Page Test instellingen
GTmetrix instellingen
Bij GTmetrix is het aan te raden een account aan te maken. Daarin kun je de bovenstaande instellingen opslaan en vervolgens standaard voor elke test gebruiken.
Voordat je overgaat tot optimalisatie, is het goed om nog bij de best practices voor WordPress-website snelheid optimalisatie stil te staan.
WordPress website snelheid optimalisatie best practices
Het beste resultaat haal je wanneer je de volgende werkmethode hanteert en regels aanhoudt:
Test het resultaat van elke wijziging aan je WordPress-website
Elke wijziging heeft een bepaald effect. Hopelijk levert iedere aanpassing een verbetering van de snelheid op. Controleer of de snelheid beter is geworden na het aanbrengen van een wijziging, door de snelheid opnieuw te meten met de eerder besproken tools. Doe je meerdere wijzigingen en ga je dan pas meten, dan weet je niet welke wijziging welk effect heeft gehad.
Optimaliseer zoveel mogelijk aan de buitenkant van WordPress
Alles wat je buiten de installatie van WordPress kunt optimaliseren moet je ook buiten WordPress om optimaliseren. Zo houd je je WordPress-omgeving schoon en verlaag je de kans op negatieve bijeffecten binnen de installatie.
Gebruik zo weinig mogelijk WordPress-plugins
Voor veel optimalisaties zijn plugins beschikbaar. Maar je hebt deze plugins niet altijd nodig om de optimalisatie te doen. Het toevoegen van een plugin levert per definitie namelijk ook extra last op je WordPress-installatie op. Misschien heb je al meer gelezen over de plugins W3 Total Cache en WP Super Cache. Vermijd deze vanwege hun logheid. Er zijn betere oplossingen en die ontdek je in dit artikel!
Staar je niet blind op de Google PageSpeed en YSlow scores
Leuk die score van 100 nastreven, maar optimaliseren doe je voor meer snelheid en niet voor de score. Het wil namelijk niet altijd zeggen dat een score van 100 beter is dan bijvoorbeeld 95. Laat je niet leiden door deze score, maar door de laadtijd!
Bij het beschrijven van de optimalisaties in dit artikel zijn de bovenstaande vuistregels ook als uitgangspunt genomen.
Software die je nodig hebt bij het sneller maken van WordPress
Om de snelheidsoptimalisaties aan je WordPress-site uit te kunnen voeren, heb je een paar programma’s nodig. Je moet de code in bestanden op de webserver kunnen aanpassen, waarvoor je een text editor nodig hebt. Daarnaast moet je bestanden van de webserver kunnen downloaden en uploaden met een FTP-client. Ook moet je afbeeldingen kunnen bewerken.
Text editor
Met een text editor kun je de bestanden op de webserver aanpassen. Bij sommige optimalisaties is dit noodzakelijk. Het gaat dan vaak om de bestanden die onderdeel uitmaken van je WordPress theme, of bestanden die in de hoofdmap van je website staan.
Text editors waarmee ik goede ervaringen heb zijn:
- Sublime Text (Windows/OS X) – Download hier
- Notepad++ (Windows) – Download hier
FTP-client
Voordat je bestanden kunt verwerken, moet je ze eerst downloaden van de webserver. Dit doe je met een FTP-client. Na het aanbrengen van wijzigingen moet je ze weer uploaden. Ook via de FTP-client.
Je hostingprovider heeft de gegevens gestuurd die je nodig hebt voor het maken van de verbinding met je website. Deze FTP-gegevens kun je vaak ook achterhalen door in te loggen op de beheeromgeving van de hostingprovider. Opvragen kan natuurlijk ook.
De FTP-client die ik al jaren gebruik is:
- FileZilla (Windows/OS X) – Download hier
Beeldbewerkingsprogramma
De manier waarop je een afbeelding bewerkt en opslaat heeft invloed op de grootte van het uiteindelijke bestand. Afbeeldingen optimaliseren is belangrijk bij een WordPress-website sneller maken.
Het beeldbewerkingsprogramma dat ik gebruik:
- GIMP (Windows/OS X) – Download hier
Lokale testserver (optioneel)
Voor de meer gevorderde gebruiker is het ook aan te raden om een testserver in te richten op je eigen werkstation. Hierop kun je een kopie van je WordPres website draaien en de wijzigingen aan bestanden eerst testen, voordat je ze weer uploadt.
Er zijn twee gangbare oplossingen waarmee je een kant en klare testserver installeert:
- MAMP (Windows/OS X) – Download hier
- WampServer (Windows) – Download hier
Klaar om te beginnen met het optimaliseren van je WordPress-website snelheid? Let’s start optimizing!
Hieronder staan 19 optimalisaties beschreven die je WordPress-website sneller maken:
1. Kies snelle hoogwaardige webhosting voor WordPress
De eerste optimalisatie in dit artikel is cruciaal! Van essentieel belang.
Wanneer je deze niet gaat uitvoeren, hoef je de rest van het artikel niet eens te lezen…
Waarom?
Goede hosting is bepalend voor de snelheid van een WordPress-website én het succes van de overige optimalisaties!
De kwaliteit van de hosting die jouw WordPress-website aandrijft heeft de grootste impact op de uiteindelijke snelheid. Voor zowel de bezoeker, als voor jou als beheerder die moet werken in de WordPress-beheeromgeving!
Een grove schatting op basis van mijn ervaringen:
Een WordPress-website op de juiste webhosting draaien is goed voor de helft tot driekwart van het optimalisatiewerk. De andere optimalisaties beschreven in dit artikel zijn slechts de overige 25-50%.
Daarnaast is het zo dat overige optimalisaties ook in relatie staan tot de kwaliteit van de hosting. Je kunt je WordPress-site optimaliseren tot je een ons weegt, maar als de webserver niet snel genoeg is, kom je nooit tot acceptabele laadtijden…
Durf een paar euro’s extra per maand uit te geven en kies de beste WordPress hosting!
Waar moet een goede WordPress hostingprovider aan voldoen?
Deze vraag is de basis van WP Hosting Blog, deze website. Op de homepage staat een uitgebreide beschrijving van wat naar mijn mening echt goede WordPress-hosting is.
Daarbij staan ook andere aspecten dan snelheid beschreven, aangezien je hosting voor WordPress niet alleen op basis van snelheid kiest.
Dit artikel gaat echter wel over de snelheid. Goede WordPress-hostingproviders hebben op dat gebied de volgende zaken geregeld:
- Server side caching oplossing (Varnish caching bijvoorbeeld)
- Hoogwaardige webserver/datacenter/locatie combinatie (wat voor een wenselijke lage Time To First Byte zorgt)
- Voldoende capaciteit (om bezoekerspieken op te vangen)
- Goede serverconfiguratie, geoptimaliseerd voor WordPress
- GZIP compressie is geconfigureerd en staat automatisch ingeschakeld
Welke WordPress hostingproviders zijn geschikt?
Er zijn genoeg geschikte WordPress-hostingproviders. Maar helaas ook heel veel ongeschikte…
Kies je een hostingprovider die zich Managed WordPress Hosting noemt, dan zit je bijna altijd goed. Dit zijn hostingproviders die zich specifiek toeleggen op het hosten van WordPress-websites.
Binnen dit blog kun je op de pagina WordPress hosting vergelijken diverse aanbieders van WordPress-hosting met elkaar vergelijken. Deze providers bieden allemaal supersnelle hosting. Met deze hostingproviders heb ik de beste ervaringen en deze raad ik dus graag aan!
Op dit moment is mijn eigen blog gehost bij Xel Media, één van mijn favoriete WordPress hostingproviders:
WordPress Hosting voor elk niveau gebruiker:
Xel Media Premium WordPress Hosting
Vanaf €9,90 excl. BTW per maand
Lees hier ook mijn uitgebreide Xel Media review.
Andere hostingproviders die ik net als Xel Media blindelings vertrouw zijn Savvii Managed WordPress Hosting en mijn.host. Beide uitstekende hostingproviders uit Nederland.
Op dit blog lees je ook mijn Savvii review en mijn.host review.
Zie je op tegen een verhuizing naar een andere hostingprovider? Niet nodig!
Aangezien echt goede WordPress-hosting vaak iets prijziger is dan een doorsnee shared hostingpakket, bieden WordPress-hostingproviders meestal een gratis verhuisservice aan.
Dat geldt ook voor bovengenoemde provider Xel Media.
Maak je dus geen zorgen over de verhuizing van je WordPress-website. Hier kun je vaak kosteloos hulp bij inschakelen!
Kies je voor goede hosting, dan los je deze performance knelpunten op
Een goede hostingprovider heeft z’n configuratie op orde en weet hoe een webserver geconfigureerd moet worden voor de beste prestaties.
Kies de beste WordPress webhosting, dan los je vier belangrijke optimalisatiepunten op, die door de meettools als ‘high priority’ worden aangemerkt:
- Improve server response time / First byte time
- Enable gzip compression / Compress transfer
- Enable Keep-Alive
- Specify a Vary: Accept-Encoding header
Bij sommige hostingproviders (zoals Xel Media en Savvii) ook:
- Leverage browser caching / Add Expires headers / Specify a cache validator / Cache static content
De eerste en belangrijkste stap naar een snelle WordPress-website is dus een heel eenvoudige: ga voor goede WordPress hosting!
2. Kies een betrouwbare en snelle DNS-provider
DNS staat voor ‘Domain Name System’. Het is een netwerkprotocol dat een domeinnaam (en subdomeinen) koppelt aan IP-adressen. De belangrijkste is het IP-adres van de webserver, waarop de bestanden van jouw WordPress-website zijn ondergebracht.
Door in een webbrowser in de adresbalk een domeinnaam in te typen, bijvoorbeeld ‘wphostingblog.nl’, wordt een lookup gedaan. Via de stub resolver wordt een vraag gesteld aan de recursor (meestal je internetprovider): aan welke IP-adres is deze domeinnaam gekoppeld?
Deze vraag stelt de recursor aan de DNS-rootserver, die vraag eventueel doorstuurt naar andere DNS-servers, totdat het antwoord bekend is en wordt teruggestuurd. Dit heet recursie.
Technisch verhaal. Waarom is DNS belangrijk?
Op het DNS-netwerkprotocol moet je ernaar streven zo weinig mogelijk tijd verliezen, aangezien dit het eerste proces is dat gaat lopen nadat iemand de domeinnaam van je WordPress-website in de adresbalk heeft ingetypt. Daarnaast wil je dat jouw WordPress-site altijd bereikbaar is.
Kies dus voor een snelle en betrouwbare DNS-provider!
Wat is een goede DNS-provider?
Een DNS-provider die:
- Snelle servers gebruikt in Nederland (als je doelland Nederland is en de webserver daar ook staat)
- Optimale vrijheid en gebruiksvriendelijkheid biedt in het instellen van DNS-records
- Een lage tijd aanbiedt voor de TTL-instelling (Time To Live – de tijd dat een record wordt gecached)
- Gebruikmaakt van DNSSEC
Deze laatste optie – DNSSEC – is erg belangrijk voor extra beveiliging voor je WordPress-website. Het DNS-systeem is namelijk te omzeilen, waardoor het mogelijk is om gehackt te worden. DNSSEC is een extra beveiliging voor het DNS-netwerkprotocol en is vergelijkbaar met SSL.
Ik kies er altijd voor om mijn DNS-provider te scheiden van de hostingprovider en/of de mailprovider. Zoals hosting en e-mail aparte specialismen zijn, is DNS dat ook.
Daarnaast wil ik alle domeinnamen die ik bezit in één overzichtelijk en gebruiksvriendelijk systeem kunnen beheren. En bij vragen wil ik graag snelle en goede support.
Daarom vertrouw ik voor DNS en domeinnamen al jaren op TransIP.
TransIP DNS-provider
.nl-domeinnaam €7,49 excl. BTW per jaar (eerste jaar €3,99)
Waarom is TransIP zo goed? Ze hebben zich gespecialiseerd in DNS. Dat heeft geresulteerd in de ontwikkeling van TransDNS. TransIP is tevens de grootste provider ter wereld op het gebied van DNSSEC. Lees hier meer over TransDNS.
Hoe bepaal ik of mijn DNS op dit moment goed is?
Je kunt online diverse tests uitvoeren. Bijvoorbeeld de ‘traceroute’ test van Pingdom. Voer je domeinnaam in en kies voor ‘traceroute’.
Wanneer je alleen maar groene balkjes ziet, is de snelheid in ieder geval goed:
Daarnaast kun je de gezondheid van de diverse technische onderdelen van de DNS van jouw domeinnaam testen. Als je een .nl-domeinnaam hebt kun je gebruikmaken van de SIDN DNS Check.
Als alles technisch in orde is zie je een testresultaat zoals hieronder van domein ‘wphostingblog.nl’ afgebeeld:
Dit optimalisatiepunt los je op met een goede DNS-provider
Kies je een snelle betrouwbare DNS-provider, dan draagt dit bij aan het ‘high priority’ optimalisatiepunt:
- Improve server response time / First byte time
3. Gebruik een ‘light weight’ WordPress theme
Een website wordt in de basis opgebouwd door HTML, in combinatie met CSS-bestanden voor opmaak en JavaScript-bestanden voor functionaliteiten.
Bij een WordPress-website is dat hetzelfde.
Daarnaast geldt: hoe minder HTML, CSS en JavaScript er wordt gebruikt binnen een website, des te sneller de laadtijd.
Streef naar een website die zo weinig mogelijk HTML, CSS en JavaScript nodig heeft!
Vaak is het ook zo dat, wanneer er weinig JavasScript wordt gebruikt, deze scripts in de footer van de website geladen kunnen worden in plaats van in de website <head></head>. Ook dit levert snelheidswinst op.
Daarom is het belangrijk om een WordPress theme te gebruiken, dat is opgebouwd met zo weinig mogelijk code en alleen de functionaliteiten biedt die je daadwerkelijk nodig hebt. Een dergelijke thema wordt een ‘light weight’ WordPress theme genoemd.
Dat is een uitdaging, want de meeste WordPress themes zijn tegenwoordig ‘multi purpose’ en heel uitgebreid. Zo kan een brede doelgroep aan potentiële gebruikers aangesproken worden.
Dit heeft als nadeel dat er vaak veel CSS en JavaScript in de WordPress-website wordt geladen. Ook worden pagina’s vaak traag opgebouwd, omdat er vele configuratieopties geladen moeten worden om de pagina’s op te bouwen.
Op zich hoef je van dit laatste weinig hinder te ondervinden wanneer je optimalisatie #1 goed uitvoert en kiest voor hosting met een server side caching oplossing.
Wat is een goed lichtgewicht WordPress theme?
Het is lastig om hier in één zin een antwoord op te geven. Maar ik heb hiervoor zelf wel een vuistregel:
In principe is een thema ‘light weight’ en dus geschikt, als het weinig opties tot aanpassing heeft via de WordPress-beheeromgeving. Dus geen uitgebreid menu met honderden configuratieopties.
Zelf vertrouw ik al jaren op het Genesis Framework van StudioPress. Hierover heb ik ook een artikel geschreven: Genesis Framework review.
Het Genesis Framework is een clean basis theme, dat via CSS in eigen stijl gemaakt kan worden. Er zijn ook tientallen ‘child themes’ beschikbaar. Bekijk hier de Genesis Child Themes.
Genesis Framework WordPress Theme
Framework: $59.95 | Framework + Child Theme: $99.95
Ik beheers geen CSS en wat is een ‘Child Theme’?
Is CSS niet je sterkste kant en heb je geen kennis van WordPress child themes, dan kun je beter voor een WordPress theme kiezen dat al in de gewenste stijl is vormgegeven.
Ga hiervoor naar ThemeForest. Hier kies je uit duizenden thema’s en koop je een WordPress theme al vanaf $29 en voor maximaal $64.
Heb je een WordPress theme gevonden, maar twijfel je of deze wel ‘light weight’ is, stuur me een e-mail met daarin een link naar het thema. Ik beoordeel het WordPress theme graag voor je. Kostenloos!
Deze knelpunten los je op met een ‘light weight’ WordPress theme
Met een ‘light weight’ theme beperkt je de omvang van de code en de hoeveelheid CSS- en JavaScript-bestanden. Dit draagt bij aan de optimalisatie van:
- Make fewer HTTP requests / Reduce the number of DOM elements
- Minify HTML / Minify CSS / Minify JavaScript
- Put JavaScript at bottom / Defer parsing of JavaScript
4. Verklein statische content met GZIP compressie
GZIP compressie is een techniek die statische content, bestaande uit tekst (JS/CSS/HTML/HTM/PHP/XML), kan verkleinen tot minder dan 30% van de originele grootte. Zo wordt een HTML-pagina, die oorspronkelijk 10 kB groot was, gereduceerd tot zo’n 3 kB.
Bij mijn eigen blog levert GZIP compression van de homepage de volgende winst op (getest via GIDNetwork GZIP test):
Size, Markup (bytes): 62,175 (61 kB)
Size, Compressed (bytes): 16,271 (16 kB)
Compression: 73.8 %
Maar, GZIP beperkt zich dus niet tot de HTML. Ook de CSS- en JS-bestanden worden verkleind via compressie.
Wanneer je optimalisatie #1 al hebt uitgevoerd, dan hoef je niets te doen om te profiteren van GZIP compression. GZIP is een serverconfiguratie, die je hostingprovider simpelweg goed ingesteld moet hebben!
Staat GZIP compressie niet aan voor jouw WordPress website?
Geeft de test aan dat je GZIP compressie niet in orde is? Dan moet je je zorgen gaan maken.
Er bestaan namelijk hostingproviders die ervoor kiezen deze serveroptie niet in te schakelen. Vraag me niet waarom… Als dat bij jou het geval is, begin dan bij de eerste optimalisatie in dit artikel.
Soms ondersteunt een hostingprovider het wel, maar staat de optie niet standaard aan. Je kunt GZIP dan zelf aanzetten door het toevoegen van een paar regels code. Waar je dit moet en met welke code hangt af van het type webserver waarop je WordPress-site draait.
De meestgebruikte webservers zijn Apache en NGINX. wphostingblog.nl draait op een Apache-server van Xel Media. De GZIP regels, die staan opgeslagen in het .htaccess bestand in de hoofdmap, zien er als volgt uit:
Zo schakel je GZIP compression regels zelf in
GZIP inschakelen kan via je FTP-client en text editor, of via een plugin. De eerste methode heeft de voorkeur, zodat het aantal plugins wordt beperkt.
Via FTP-client en text editor
Maak verbinding met je website via je FTP-client. Download uit de hoofdmap het .htaccess bestand. Voeg de regels voor GZIP compression toe (aan het eind van het bestand) en upload het bestand weer naar de webserver. Overschrijf het oude bestand.
Welke regels je moet toevoegen hangt af van het type webserver. Een duidelijke uitleg van hoe je dit zelf kunt instellen vind je in het artikel Enable GZIP Compression op varvy.com.
Via een WordPress plugin
Installeer en activeer de plugin WordPress Gzip Compression of Far Future Expiry Header (ondersteunt ook toevoegen van browser caching waarover de volgende optimalisatie gaat).
Deze performance knelpunten los je op met GZIP compressie
Zorg je ervoor dat je statische content comprimeert met GZIP, dan los je de onderstaande ‘high priority’ optimalisatiepunten op:
- Enable gzip compression / Compress components with gzip / Compress transfer
5. Bewaar statische content in de browser cache
Wanneer je een webpagina aanroept in je browser, wordt er HTML gedownload en meestal meerdere afbeeldingen, CSS-bestanden en JavaScript-bestanden. Deze typen content worden statische content genoemd.
Vaak wordt deze statische content, grotendeels, op meerdere pagina’s binnen dezelfde website gebruikt. Zo is CSS, en afbeeldingen die via CSS worden geladen, vaak op elke pagina hetzelfde. Dat geldt ook voor de meeste JavaScript.
Omdat de content statisch is, en dus niet verandert, is één keer downloaden genoeg. Om te voorkomen dat deze statische inhoud op elke pagina opnieuw gedownload moet worden, is het mogelijk om statische content op te slaan in de browser cache.
In plaats van dat de statische inhoud opnieuw wordt gedownload, wordt deze uit de browser cache geladen, wat vele malen sneller gaat!
Alle moderne browser hebben een browser cache. Je moet de browser alleen vertellen dat de statische content opgeslagen moet worden.
Dit kan met regels, die instellingen op de server wijzigen, en daardoor een opdracht naar de browser versturen om bestanden op te slaan voor een bepaalde periode.
Hoe worden browser caching regels ingesteld?
Dit hangt er vanaf welk type webserver je gebruikt. Apache en NGINX zijn de meest voorkomende, zeker bij WordPress.
In de basis komt het er op neer dat je een aantal regels tekst moet opnemen in het .htaccess bestand in de hoofdmap van je website.
WP Hosting Blog draait op een Apache-webserver van Xel Media. De caching regels, die staan opgeslagen in het .htaccess bestand in de hoofdmap, zien er als volgt uit:
Hoe werkt browser caching in de praktijk?
Via de developer tools van een browser kun je zien hoeveel bestanden gedownload moeten worden om de webpagina te laden. Ik gebruik persoonlijk graag de Google Developer Tools (standaard ingebouwd in Chrome) of de Firebug extensie in Firefox.
Als ik de homepage van deze website – wphostingblog.nl – voor de eerste keer laadt, vertelt Firebug me dat hiervoor 23 bestanden gedownload moeten worden:
Bij een reload van de pagina, dus de tweede visit van dezelfde pagina, geeft Firebug nog maar 1 connectie aan:
De overige 22 bestanden worden dus uit de browser cache geladen!
Het verschil in laadtijd tussen de eerste keer aanroepen en de tweede keer is het verschil tussen 1.1 seconden en 600 milliseconden!
Het wordt pas echt interessant wanneer ik doorklik naar een andere pagina binnen de website. Dan doet de browser caching namelijk echt wonderen.
Bijvoorbeeld wanneer ik navigeer naar de pagina WordPress Hosting Vergelijken. Firebug geeft nu aan dat hiervoor 9 verzoeken nodig zijn. Zou ik deze pagina als eerste pagina van mijn sessie bezoeken, dan zou het laden van de pagina 29 verzoeken in beslag nemen.
Browser caching zorgt er in dit geval voor dat ik 20 bestanden niet opnieuw hoef te downloaden van de server. Deze komen uit de browser cache. Dit scheelt de helft van de laadtijd voor het laden van de pagina!
Zo stel je browser caching regels voor je WordPress website zelf in
Caching regels toevoegen kan via je FTP-client en text editor, of via een plugin. De eerste methode heeft de voorkeur. Zo beperk je het aantal benodigde plugins.
Via FTP-client en text editor
Maak verbinding met je website via je FTP-client. Download uit de hoofdmap het .htaccess bestand. Voeg de regels voor GZIP compression toe (aan het eind van het bestand) en upload het bestand weer naar de webserver. Overschrijf het oude bestand.
Welke regels je moet instellen hang af van het type webserver. In dit uitgebreide artikel Leverage Browser Caching op varvy.com lees je welke regels je nodig hebt voor Apache en NGINX.
Via een WordPress plugin
Installeer en activeer de plugin Add Headers of Far Future Expiry Header (ondersteunt ook inschakelen van GZIP waarover de vorige optimalisatie ging).
Deze optimalisatiepunten los je op met browser caching
Wanneer je de juiste caching regels toevoegt, los je de onderstaande ‘high priority’ punten op:
- Leverage browser caching / Add Expires headers / Specify a cache validator / Cache static content
6. Verklein de omvang van HTML, CSS en JavaScript en combineer bestanden
HTML-, CSS- en JavaScript-code wordt vaak geschreven met veel witruimte, in de vorm van witregels, tabs en spaties. Daarnaast worden er comments toegevoegd, die voor de werking van de website nutteloos zijn.
Ontwikkelaars van websites doen dit voor de overzichtelijkheid. Dit verduidelijkt de code en versnelt zo het ontwikkelproces.
Maar, al die witruimte heb je niet nodig om de website goed te laten functioneren…
Het is dan ook mogelijk om deze witruimte uit de inhoud te verwijderen, zonder dat de lay-out en opmaak van de website stuk gaan of functionaliteiten niet meer werken.
Deze techniek heet ‘minifying’ (minimaliseren) en zorgt ervoor dat de code compact(er) wordt.
Geminimaliseerde code is qua omvang kleiner dan code met witruimte en comments. Daardoor kan deze sneller geladen worden.
Hoe simpel kan het zijn?
Daarnaast is het in de meeste gevallen zo dat er meerdere CSS- en JavaScript-bestanden per pagina worden geladen. Elk thema en bijna elke plugin voegt CSS- en/of JavaScript-bestanden toe. Deze kunnen samengevoegd worden in gecombineerde bestanden.
Dit beperkt het aantal bestanden, en daarmee het aantal http-connecties, die nodig zijn om de webpagina op te bouwen. Dit kan het proces drastisch versnellen. Deze techniek wordt ‘combining’ (combineren) genoemd.
Hoe kun je HTML, CSS en Javascript verkleinen en bestanden combineren?
Er zijn diverse WordPress-plugins die één of beide opties bieden, maar ik op basis van mijn ervaringen raad ik hiervoor één plugin aan en dat is Autoptimize:
Deze plugin biedt hiervoor de juiste opties en mogelijkheden tot configuratie. Ook heeft deze plugin zowel de minify functionaliteit als de combine functionaliteit.
Het heeft daarnaast geavanceerde functies voor de echte front-end developer. Zo kun je zelf bepalen waar binnen de broncode de geoptimaliseerde bestanden worden geplaatst.
Met deze functie kan de volgorde van het laden van CSS- en JavaScript-bestanden worden geoptimaliseerd. Dat is belangrijk om de beste performance te halen.
Dit kan met bepaalde filters binnen de plugin. Zie hier de Autoptimize documentatie op Github.com voor alle mogelijkheden.
Minifying en combining instellen met Autoptimize
Installeer de plugin Autoptimize en activeer deze. Er gebeurt nu nog niets. Ga in de WordPress-beheeromgeving naar:
Instellingen > Autoptimize
Het eerste wat je daar moet doen is op de knop ‘Toon geavanceerde instellingen’ klikken bovenaan in het scherm:
Vervolgens vink je de volgende opties aan:
- Optimaliseer HTML Code
- Optimaliseer JavaScript Code
- Optimaliseer CSS Code
De standaardopties doen meestal goed hun werk, maar ik kies er zelf altijd voor om JavaScript niet te optimaliseren (waarom lees je later) en aanvullend alleen de volgende opties aan te vinken (de rest staat uit):
- Vervang image-links in CSS door data: URIs?
Daarnaast verdient de CSS- en JS-optimalisatie extra aandacht…
Belangrijk bij CSS optimaliseren
Het is belangrijk om te checken of de originele CSS-bestanden die worden geladen op elke pagina van de WordPress-website hetzelfde zijn. Als er CSS-bestanden zijn die alleen op sommige pagina’s worden geladen, moet je deze uitsluiten van optimalisatie:
Als je dit goed hebt gedaan, dan wordt op elke pagina binnen de website hetzelfde gecombineerde Autoptimize CSS-bestand ingeladen.
Dit kun je controleren door alle verschillende typen pagina’s te openen in een browser, de broncode weer te geven, en de bestandsnaam te vergelijken.
Je herkent het bestand door naar de benaming van het gecombineerde CSS-bestand te kijken. Deze is als volgt opgebouwd:
http(s)://{{domeinnaam}}/wp-content/cache/autoptimize/css/autoptimize_{{unieke-combinatie-cijfers-letters}}.css
Doe je dit niet goed, dan krijgt elke (type) pagina een apart gecombineerd CSS-bestand. Van grote omvang! Dit vertraagt het laden juist, omdat hierdoor het effect van browser caching (deels) verloren gaat.
Overweeg: JavaScript wel of niet optimaliseren
Daarnaast kies ik er meestal voor om JavaScript niet te optimaliseren. Dit omdat de bestanden vaak enorm verschillen per pagina. Dit zou als resultaat hebben dat je per pagina een verschillend samengevoegd .js-bestand krijgt en dat kan juist vertragen.
Het effect van browser caching gaat hierdoor (deels) verloren.
Ook zorg ik voor zo weinig mogelijk JavaScript-bestanden. Ik heb mijn WordPress theme zo geconfigureerd dat alleen de nodige JavaScript-bestanden op een pagina worden geladen.
Daarnaast zijn de meeste JavaScript-bestanden, die door plugins worden toegevoegd, al geminimaliseerd. Dit kun je herkennen aan hoe het bestand is genoemd. In plaats van .js eindigen deze bestanden vaak op -min.js. Hierbij staat ‘min’ voor minified (dus geminimaliseerd).
Ook kan het minimaliseren van JavaScript leiden tot fouten, waardoor sommige functionaliteiten stuk kunnen gaan. Test dit dus heel goed, wanneer je de optie wel gebruikt!
Speel met de configuratieopties en kijk wat werkt voor jouw WordPress-website.
Deze WordPress snelheid knelpunten los je op met ‘minify’ en ‘combine’
Minimaliseer je HTML, CSS en JavaScript en voeg je waar mogelijk bestanden samen, dan los je deze optimalisatiepunten op:
- Minify HTML / Minify CSS / Minify JavaScript
- Combine external CSS / Combine external JavaScript
- Make fewer HTTP requests / Reduce the number of DOM elements
7. Verklein de omvang van afbeeldingen en optimaliseer ze
Naast diverse CSS- en JavaScript-bestanden, zijn afbeeldingen vaak ook in relatief grote aantallen aanwezig binnen een WordPress-website. Ook deze bestanden kun je optimaliseren!
Een geoptimaliseerde afbeelding is kleiner in omvang en laadt daardoor sneller.
Op twee manieren kun je afbeeldingen verkleinen:
- Afmetingen aanpassen
- Compressie en optimalisatie
Afmetingen van afbeeldingen aanpassen
Bepaal waarvoor je een afbeelding wilt gebruiken binnen je WordPress-website. Waarschijnlijk is er een maximale beschikbare ruimte aan pixels waarbinnen de afbeelding wordt gebruikt.
Verklein de afmetingen door de breedte van de afbeelding gelijk te maken aan de maximaal beschikbare ruimte waarbinnen deze wordt geplaatst.
Uiteraard moet je daarbij wel de hoogte van de afbeelding schalen in de hoogte-breedte-verhouding van de oorspronkelijke afbeelding.
Gebruik je een grotere afbeelding dan nodig is binnen de ruimte waarbinnen je deze gaat gebruiken, dan is dit nutteloos. De bestandsgrootte is dan onnodig te groot.
Daarnaast moet de afbeelding in dat geval door de browser geschaald worden, wat extra tijd kost.
Op WP Hosting Blog is de breedte van een blogartikel maximaal 808 pixels. Daarom gebruik ik afbeeldingen met maximaal die breedte.
Hoe pas je de afmeting van een afbeelding aan?
De afmeting van een afbeelding kun je aanpassen met een beeldbewerkingsprogramma. Ik gebruik daarvoor bijvoorbeeld GIMP; een gratis programma.
Daarnaast kan het ook met de OS X preview functie, wanneer je op een Mac werkt (zoals ik). Hiermee kun je ook meerdere afbeeldingen tegelijk schalen.
Wil je in Windows meerdere afbeeldingen tegelijk schalen, dan is het programma Multiple Image Resizer aan te raden.
Compressie en optimalisatie van afbeeldingen
Een afbeelding die je opslaat vanuit een beeldbewerkingsprogramma, bestaat niet alleen uit pixels. Er wordt ook van allerlei informatie over de afbeelding opgeslagen in het bestand.
Deze informatie is voor gebruik binnen een website vaak nutteloos en kun je dus verwijderen, wat de omvang van de afbeelding reduceert.
Daarnaast kun je een afbeelding ook technisch verkleinen, door de kwaliteit van het beeld te optimaliseren. Zelfs zonder verlies of met een klein acceptabel verlies van kwaliteit in de scherpte van een afbeelding.
Dit kan de omvang van een afbeelding soms tot wel 20% van de oorspronkelijke omvang reduceren!
Hoe kun je een afbeelding comprimeren/optimaliseren?
Hiervoor zijn verschillende mogelijkheden:
- Via bepaalde websites (dus via de browser)
- Via programma’s voor Windows
- Via programma’s voor OS X/Mac
- Via WordPress-plugins
Via bepaalde websites (dus via de browser)
Zoek maar eens in Google op online image compression, dan vind je verschillende websites waarop je online je afbeelding kunt optimaliseren.
Een website die je dan ongetwijfeld tegen zult komen is Kraken.io. Dit is mijn persoonlijke favoriet, omdat deze een afbeelding ook kan schalen. Hier vind je de gratis online image compression web interface van Kraken.io.
Via programma’s voor Windows
Voor Windows heb je ook diverse programma’s die je kunt installeren en waarmee je afbeeldingen kunt optimaliseren. Ik ken ze niet allemaal, maar ik kan Fileminimizer Pictures nadrukkelijk aanbevelen!
Via programma’s voor OS X/Mac
Voor Mac zijn er ook diverse apps beschikbaar die afbeeldingen kunnen optimaliseren. Ook hiervoor geldt: ik ken ze niet allemaal, maar kan er wel één aanbevelen en dat is ImageOptim.
Via WordPress-plugins
Er bestaan ook diverse plugins die afbeeldingen automatisch optimaliseren tijdens het uploaden van een afbeelding in de WordPress-beheeromgeving.
Er zijn meerdere opties, maar er is één plugin die echt aan te raden is en dat is WP Smush.
Mijn advies is om de WP Smush plugin te installeren en daarnaast één van de andere methoden te hanteren. Zo kom je tot het beste resultaat en worden je afbeeldingen zo klein mogelijk zonder (nauwelijks) kwaliteitsverlies.
Deze optimalisatiepunten los je op met afbeelding optimalisatie
Zorg je ervoor dat afbeeldingen de juiste afmetingen hebben en dat ze qua omvang zijn geoptimaliseerd, dan draagt dit bij aan het optimaliseren van:
- Optimize images
- Do not scale images in HTML / Serve scaled images
8. Laad alleen JavaScript die een pagina nodig heeft
Een WordPress-webpagina laadt meestal meerdere JavaScript-bestanden. Deze scripts zijn bedoeld om bepaalde functionaliteiten mogelijk te maken.
Deze functionaliteiten kun je opdelen in:
- Functionaliteiten die op elke pagina terugkomen
- Functionaliteiten die voor specifieke pagina’s zijn bedoeld
De JavaScripts die zijn bedoeld voor functies, die op elke pagina terugkomen, moeten ook op elke pagina worden geladen.
Maar, de scripts die zijn bedoeld voor functionaliteiten op specifieke pagina’s, hoeven alleen op de pagina’s geladen te worden waar deze functies worden gebruikt.
Vaak is het zo dat alle JavaScript bestanden op alle pagina’s binnen een WordPress-website worden geladen. Dus ook de scripts van functies die niet nodig zijn.
In dat geval worden er dus onnodig JavaScript-bestanden geladen, wat de laadtijd negatief beïnvloedt. Immers, hoe meer bestanden en hoe groter de code, des te langer het duurt om deze te downloaden.
De optimalisatie is simpel in uitleg, maar lastig om uit te voeren:
Sluit het laden van specifieke JavaScripts uit op pagina’s waarbinnen deze geen functionaliteit toevoegen.
Hoe sluit je het laden van JavaScript-bestanden uit op specifieke pagina’s?
Dit is mogelijk door PHP-code toe te voegen aan je functions.php bestand, dat een onderdeel is van het WordPress theme dat je gebruikt. Elk thema heeft zo’n bestand.
Download dit bestand en voeg op onderstaande manier code toe. In het voorbeeld zorg ik ervoor dat de JavaScript-bestanden, die onderdeel zijn van de Contact Form 7-plugin, alleen worden geladen op mijn contactpagina:
Dit doe je vervolgens voor JavaScript-bestanden die je op bepaalde pagina’s wilt uitsluiten.
Let op! Dit is een geavanceerde manier van optimaliseren. Je moet goed weten wat je doet en kennis hebben van PHP en bepaalde WordPress-functies en -principes, zoals ‘action hooks’ en specifiek de wp_enqueue_scripts() hook en wp_dequeue_script() functie.
Deze optimalisatiepunten los je op
Laad je alleen de noodzakelijke JavaScript die een pagina nodig heeft, dan draagt dit bij aan het optimaliseren van:
- Minify JavaScript
- Make fewer HTTP requests / Reduce the number of DOM elements
9. Laad Javascript in de footer en stel het parseren uit
Om een pagina te laden, moet een webbrowser eerste alle <script> tags voor JavaScript parseren. Dit zorgt voor extra benodigde tijd om de webpagina te laden.
Door JavaScript in de footer van de website te laden, in plaats van in de <head></head>, wordt (deels) voorkomen dat JavaScript het laden van andere bronnen blokkeert. Andere bronnen zijn bijvoorbeeld CSS, die zorgen voor de visuele opbouw van een pagina.
Zo wordt prioriteit gegeven aan HTML en CSS, zodat de pagina sneller visueel opgebouwd wordt en op het scherm verschijnt.
JavaScript wordt alsnog geladen, maar de pagina is al zichtbaar en dit maakt een groot verschil in de beleving van de bezoeker.
Die ervaart namelijk een snelle visuele zichtbaarheid van de webpagina, wat zal aanvoelen als een snelle laadtijd. Dat is essentieel voor de gebruikservaring!
Pas wel op met deze techniek, want het verplaatsen van JavaScript naar de footer is niet altijd mogelijk. Het kan functionaliteiten stuk maken. Test dit dus goed!
Extra winst door het laden van JavaScript uit te stellen (defer)
Het verplaatsen van JavaScript naar de footer van de website is een goede manier om het laden van de visuele content te versnellen. Een extra optimalisatie is om de JavaScript ook nog uitgesteld te laden.
In dat geval wordt de HTML volledig geladen en opgebouwd en wanneer dit klaar is, dan pas wordt JavaScript geladen en uitgevoerd.
Hoe JavaScript verplaatsen en parseren uitstellen?
Let op! Dit is een geavanceerde techniek. Je hebt veel kennis nodig van WordPress en WordPress-functies.
In de basis is het verplaatsen van JavaScript mogelijk middels WordPress-functies die je opneemt in het functions.php bestand van je theme, via de text editor.
Deze methoden ga ik in dit artikel niet uitgebreid beschrijven. Wil je hiermee aan de slag, dan verwijs ik je graag door naar het blogartikel How To Defer Parsing JavaScript in WordPress van laplacef.com.
In het artikel Defer Loading JavaScript van varvy.com wordt het principe van deferring ook duidelijk uitgelegd.
Deze performance knelpunten los je op
Laad je JavaScript in de footer en maak je gebruik van uitgesteld parseren van JavaScript, dan los je de volgende optimalisatiepunten op:
- Put JavaScript at bottom
- Defer parsing of JavaScript
10. Voeg achtergrondafbeeldingen samen in een ‘image sprite’
Dit is één van mijn favoriete optimalisatietechnieken.
Waarom?
Omdat het principe heel simpel en ontzettend logisch is.
In vele websites wordt vanuit CSS verwezen naar afbeeldingen. Deze worden middels CSS als achtergrondafbeelding van een bepaald element ingesteld. Dit zijn meestal de vaste elementen binnen de lay-out en vormgeving van een website, die op elke pagina terugkomen.
Denk aan het logo van een website, iconen en andere afbeeldingen die op elke pagina, of minstens op meerdere pagina’s, terugkeren.
Bij veel WordPress themes is dit ook zo.
Vaak is het zo dat al deze afbeeldingen als aparte afbeeldingen worden opgeslagen en dat elke individuele afbeelding apart wordt aangeroepen vanuit de CSS. Het aantal bestanden dat geladen moet worden kan hierdoor flink oplopen.
Nu is het zo dat een webbrowser slechts een beperkt aantal bestanden tegelijk (per hostname) kan downloaden. Hoeveel precies, dat verschilt per browser.
Wanneer de browser klaar is met die hoeveelheid bestanden, wordt doorgegaan naar de volgende batch bestanden van hetzelfde aantal. Dit proces duurt net zo lang, totdat alle bestanden zijn geladen die onderdeel zijn van de webpagina.
Wanneer je dus het aantal benodigde bestanden verlaagt, heeft de browser minder batches van connecties nodig om de pagina op te bouwen. De pagina laadt dan sneller!
Dit kan met achtergrondafbeeldingen in CSS heel eenvoudig: door ze samen te voegen in één afbeelding. Zo’n verzamelafbeelding heet een ‘image sprite’.
Via CSS wordt vervolgens aangegeven welk gedeelte van de sprite binnen een bepaald HTML-element getoond moet worden.
Hoe ziet zo’n sprite er uit? Bekijk hier een Google icon image sprite.
Wat is het effect? Dit verschilt. Wanneer je bijvoorbeeld oorspronkelijk 13 achtergrondafbeeldingen gebruikt en deze samenvoegt in één nieuwe image sprite, dan bespaar je 12 connecties. Dus 2 batches van 6 connecties. Afhankelijk van hoe snel de webserver en de internetverbinding is, kan dit aanzienlijk schelen!
Hoe kun je zelf achtergrondafbeeldingen samenvoegen in een sprite?
Je hebt een beeldbewerkingsprogramma nodig en belangrijker nog: kennis van CSS en specifiek het positioneren van achtergrondafbeeldingen binnen HTML-elementen.
Via het beeldbewerkingsprogramma voeg je alle afbeeldingen samen in één nieuwe afbeelding. Zorg dat ze elkaar niet overlappen en houd genoeg ruimte om de afbeeldingen volledig binnen de HTML-elementen inclusief eventuele margin/padding te laten passen.
Pas de CSS van je WordPress theme aan via de text editor en positioneer de achtergrondafbeelding voor alle elementen met een background image. Dat kun je doen via onderstaande manier middels een relatieve positie:
Je kunt ook gebruikmaken van de tool SpriteMe, die het je gemakkelijk kan maken.
Het is een geavanceerde manier van optimaliseren die kennis vereist van WordPress themes en CSS. Heb je dit niet, dan kun je deze optimalisatie beter overslaan of een developer inhuren.
Nog een stap verder: zet je background image om naar data: URIs
Nu wordt het helemaal technisch. Maar ik ga het simpel proberen te verwoorden:
Je kan een afbeelding omzetten naar een ‘text format’ en dat heet een ‘data: URI’. Wanneer je deze tekst opneemt in de CSS, hoef je helemaal geen achtergrondafbeeldingen meer te laden.
Het ziet er precies hetzelfde uit en is nog sneller. En het scheelt weer één connectie per afbeelding.
Wanneer je de eerder besproken combine + minify optimalisatie hebt uitgevoerd, dan heb je ook de plugin Autoptimize geïnstalleerd.
Deze plugin biedt de optie om CSS images automatisch om te zetten naar data: URIs. Doen dus!
Je vindt de optie onder ‘CSS Opties’ onder de naam ‘Vervang image-links in CSS door data: URIs?’. Aanvinken en de instellingen opslaan!
Met image sprites los je deze optimalisatiepunten op
Voeg je achtergrondafbeeldingen samen in een image sprite, dan draagt dit bij aan de optimalisatie van:
- Make fewer HTTP requests / Reduce the number of DOM elements
- Optimize images
11. Laad statische content via een CDN (Content Delivery Network)
CDN staat voor Content Delivery Network.
De naam zegt het al: het is een content-uitserveer-netwerk. Een netwerk van webservers die alleen maar statische content serveren, vanaf vaste punten over de hele wereld.
Door je statische content via een CDN over een subdomein van je website in te laden, kan statische content vanaf elk punt in de wereld snel geladen worden. Een Content Delivery Network zorg ervoor dat deze content vanaf de dichtstbijzijnde server wordt geserveerd.
Op deze webservers staan dus kopieën van je statische content opgeslagen. Dit geldt alleen voor de static content. De webpagina’s worden nog wel vanaf de ‘origin’ server geserveerd.
Welke CDN is voor WordPress goed en eenvoudig te configureren?
Hoewel ik zelf op dit moment geen CDN gebruik (omdat de impact voor mijn website nihil is), heb ik wel ervaringen met Content Delivery Networks. De beste ervaringen op het gebied van eenvoud, prijs en support is MaxCDN.
Bij MaxCDN kun je je statische content onderbrengen vanaf $9 per maand.
Hoe laadt je statische content via een CDN in WordPress?
Stap 1 is het aanmelden bij een CDN. MaxCDN is mijn eerste keuze.
Stap 2 is het configureren van het CDN. MaxCDN heeft hiervoor uitgebreide en duidelijke handleidingen. Het is de bedoeling dat je een ‘pull zone’ creëert. Hier lees je hoe je een MaxCDN pull zone maakt.
Vervolgens moet je de statische content van je WordPress-website inladen via het subdomein van je website dat je hebt gekoppeld aan de CDN pull zone. Hiervoor kun je de plugin WP CDN Rewrite gebruiken.
De plugin WP CDN Rewrite configureren
Bekijk voor de instellingen van de plugin WP CDN Rewrite het optimalisatiepunt over statische content via cookieless domains.
Deze optimalisatiepunten los je op met een CDN
Laad je de statische content van je WordPress-website in via een content delivery network, dan draagt dit bij aan het oplossen van:
- Effective use of CDN / Use a Content Delivery Network (CDN)
- Use cookie-free domains / Serve static content from a cookieless domain
- Parallelize downloads across hostnames
12. Voorkom verwijzingen naar bronnen die niet bestaan
Wanneer je in de HTML van je WordPress-website verwijst naar bronnen, zoals afbeeldingen, CSS en JS, die niet bestaan, dan besteedt de browser tijd aan het laden van content die niet gevonden kan worden.
Dat is verspilde tijd!
Zorg ervoor dat alle interne en externe bronnen waarnaar je WordPress-site verwijst, ook daadwerkelijk beschikbaar zijn op die locaties.
De optimalisatie is heel simpel uit te voeren:
Download de gratis tool Screaming Frog en scan je WordPress-website. De tool geeft aan of er foutieve verwijzingen zijn. Mochten die er zijn, onderzoek dan waarom deze verwijzing foutief is en corrigeer deze.
Daarnaast is de Screaming Frog tool voor diverse SEO optimalisaties ook onmisbaar! Sowieso installeren dus…
Deze punten los je op met het corrigeren van foutieve verwijzingen
Wanneer je alle foutieve verwijzingen naar interne en externe bronnen oplost, dan draagt dit bij aan de optimalisatie van:
- Avoid HTTP 404 (Not Found) error / Avoid bad requests
13. Serveer statische content vanaf ‘cookieless domains’
Het hoofd (sub)domein van een website is vaak ‘www.domeinnaam.ext’. Dit hoofddomein is tevens het domein waarvoor de browser de benodigde cookies zet om de website te laten functioneren.
Wanneer statische content, zoals CSS, JS en afbeeldingen, ook via het hoofddomein worden geserveerd, probeert de browser cookies te zetten voor deze content.
De webserver negeert deze cookies en dus is het proces nutteloos. Maar het is wel een proces en processen kosten tijd.
Dit kan worden opgelost door statische content vanaf een ‘cookie free domain’ te laden, bijvoorbeeld een subdomein van het hoofddomein. Voorbeelden:
- media.domeinnaam.ext
- static.domeinnaam.ext
- cdn.domeinnaam.ext
De subdomeinen zetten geen cookies, wanneer je WordPress-website op een ander subdomein zoals ‘www’ draait. Als de website op topdomain level draait, zoals https://www.hostingreview.nl, dan worden ook voor subdomeinen cookies gezet en heeft de optimalisatie geen nut.
Helaas kwam ik hier zelf een beetje te laat achter…
Hoe laad je statische content vanaf een subdomein?
De eerste stap die je moet zetten is zorgen dat het subdomein beschikbaar wordt. Meestal kun je dit subdomein zelf aanmaken via de hosting beheeromgeving. Zo niet, dan kun je het vragen aan de hostingprovider.
De tweede stap is om de DNS aan te passen. Het subdomein moet toegevoegd worden en verwijzen naar hetzelfde IP-adres als het hoofd subdomein waarop de WordPress-website draait.
De laatste stap is het aanpassen van de verwijzing naar CSS, JS en afbeeldingen (en andere statische content indien gewenst). Hiervoor zijn plugins beschikbaar en de meest geschikte daarvoor is mijns inziens WP CDN Rewrite.
Deze plugin kan ook gebruikt worden wanneer je een CDN – Content Delivery Network – wilt configureren. Hierover ging één van vorige optimalisaties.
De plugin WP CDN Rewrite instellen
Nadat je de plugin hebt geïnstalleerd en geactiveerd, ga je naar:
Instellingen > CDN Rewrite
Hier stel je op drie plaatsen de URL in met het subdomein dat je hebt aangemaakt en geconfigureerd voor het laden van de statische content:
In het voorbeeld heb ik ‘static.wphostingblog.nl’ ingesteld als CDN subdomein.
Sla de instellingen op, leeg de cache van je website, en kijk of alles er nog goed uit ziet aan de voorkant van de website.
Bekijk de broncode van je WordPress-website in de browser. Als het goed is worden afbeeldingen, CSS en JavaScript nu geladen via het ingestelde subdomein.
Gaat dit niet goed en kom je er zelf niet uit, neem dan contact op met je hostingprovider (als deze behulpzaam is). Xel Media biedt hiervoor bijvoorbeeld support.
Deze punten los je op met het laden van content via een subdomein
Laad je statische content in via een apart subdomein dat geen cookies plaatst, dan draagt dit bij aan de optimalisatie van:
- Use cookie-free domains / Serve static content from a cookieless domain
- Parallelize downloads across hostnames
14. Verwijder query variabelen van externe CSS en JS bestanden
In het verlengde van browser caching is het goed om stil te staan bij query variabelen.
Een query variabele is een stukje tekst achter de URL die een extern bestand (bijvoorbeeld CSS of JavaScript) laadt en die begint met een vraagteken.
Voorbeeld:
https://www.hostingreview.nl.nl/wp-includes/js/jquery/jquery.js?ver=1.2.3
Het vetgedrukte gedeelte ‘?ver=1.2.3’ is de query variabele. WordPress voegt deze standaard toe aan alle externe bronnen, behalve afbeeldingen.
Een query variabele geeft de versie van een bestand aan. Als er een nieuwe versie van hetzelfde bestand beschikbaar is, dan verandert het nummer en daarmee wordt afgedwongen dat de browser deze nieuwe versie download.
Echter, query variabelen zorgen er ook voor dat sommige proxy servers externe bronnen niet opslaan in de cache. Dit zorgt voor vertraging, aangezien de bronnen bij elke request opnieuw opgehaald moeten worden.
Hoe verwijder je deze query variabelen?
Om van deze query variabelen af te komen kun je een paar dingen doen.
Je kunt de query strings simpelweg verwijderen door de plugin Query Strings Remover te installeren en te activeren. Doe je dit, wees je er dan van bewust dat wanneer er nieuwe versies van dezelfde CSS en JS bestanden worden toegevoegd (bijvoorbeeld door plugin of thema updates), deze dan mogelijk niet worden geladen wanneer je browser caching toepast en je veel terugkerende bezoekers hebt.
De tweede optie is query strings verwijderen door CSS en JS bestanden samen te voegen, zoals eerder besproken in de optimalisatie combine & minify.
De plugin Autoptimize maakt namelijk gecombineerde bestanden zonder een query variabele in de URL. In plaats van een query variabele wordt een bestand gemaakt met een unieke naam, elke keer wanneer de cache wordt geleegd (bijvoorbeeld na een wijziging in CSS of JavaScript).
Ik gebruik een combinatie van bovenstaande en combineer alle CSS. JavaScript voeg ik niet samen, omdat ik weet dat mijn JavaScript-code niet of nauwelijks verandert.
Daarnaast kies ik ervoor om jQuery te laden via de Google Hosted Libraries. Door dit te doen zit de versie van jQuery in de URL verwerkt als een folder, in plaats van een query variabele:
<script type=’text/javascript‘ src=’//ajax.googleapis.com/ajax/libs/jquery/1.12.2/jquery.min.js‘></script>
Dit los je op door query strings te verwijderen
Verwijder je de query strings van statische externe bronnen binnen je WordPress-website, dan optimaliseer je het volgende knelpunt:
- Remove query strings from static resources
15. Beperk de hoeveelheid WordPress plugins
Elke plugin die je installeert binnen de WordPress-beheeromgeving voegt een functionaliteit toe. Extra functionaliteiten betekent extra code om uit te voeren, wat een langere laadtijd met zich meebrengt.
Hoe meer code uitgevoerd moet worden, des te langer het laden duurt. Minder plugins betekent minder code en dus minder laadtijd.
Deze tip is dan ook heel simpel: beperk de hoeveelheid WordPress-plugins zoveel mogelijk.
Heb je een plugin niet nodig, zoals de ‘Hello Dolly’ plugin? Verwijder deze in dat geval. Plugins pauzeren is (vaak) niet genoeg.
Overweeg je een nieuwe plugin? Bedenk dan of de functie die deze plugin toevoegt ook op een andere manier gerealiseerd kan worden.
Dat geldt bijvoorbeeld ook voor diverse optimalisaties die in dit artikel staan beschreven. Deze zijn soms via een plugin uit te voeren, maar vaak ook via het handmatig toevoegen van een stukje code.
Waarom zou je daar dan een plugin voor gebruiken?
Bedenk ook of je een functionaliteit wel echt nodig hebt. Voeg je met een nieuwe WordPress-plugin een belangrijk functie toe, of is het slechts opvulling voor de leuk?
Deze optimalisatiepunten los je op met het beperken van plugins
Verwijder je WordPress-plugins die je niet nodig hebt en los je uitdagingen anders op dan met een plugin, dan draagt dit bij aan het optimaliseren van:
- Improve server response time / First Byte Time
- Make fewer HTTP requests / Reduce the number of DOM elements
- Minimize request size
16. Houd de database zo schoon mogelijk
Hoe groter de database, des te meer tijd het kost om de gegevens op te halen die worden gevraagd tijdens het aanroepen van een webpagina. Houd deze dus zo schoon en zo klein mogelijk.
Hoe?
- Gooi regelmatig alle post revisies weg
- Check regelmatig de hoeveelheid SPAM reacties en verwijder deze
- Gooi oude posts en afbeeldingen weg die je niet meer denkt te gaan gebruiken
- Verwijder plugins die je niet nodig hebt
- Optimaliseer regelmatig de database
Een goede plugin die je kan helpen bij dit onderhoud is WP-Optimize. En niet te vergeten Akismet voor het verminderen van SPAM reacties.
Overweeg ook om je website volledig over HTTPS te laten draaien. Zo zul je minder last hebben van SPAM comments. Daarnaast is HTTPS ook gunstig voor de vindbaarheid van je website in zoekmachine Google.
Ga je voor een website die volledig draait op HTTPS, vergeet dan niet de extra tips voor HTTPS snelheid optimalisatie te raadplegen.
Overigens zou een bezoeker van jouw WordPress-website van de omvang van de database weinig tot geen traagheid moeten ondervinden. Want, je gebruikt natuurlijk een server side caching oplossing zoals beschreven in optimalisatie #1 van dit artikel.
Dit optimaliseer je met het onderhouden van je database
Zorg je ervoor dat jouw database zo klein mogelijk blijft en optimaliseer je de database regelmatig, dan draagt dit bij aan het verbeteren van:
- Improve server response time / First Byte Time
17. Gebruik de nieuwste versie van PHP
Eens in de zoveel tijd komt er een nieuwe versie van PHP uit. Hierin zijn vaak verbeteringen aangebracht die ook de performance, dus de snelheid van het uitvoeren van de code, ten goede komen.
Indien mogelijk, stap dan altijd over op de nieuwste stabiele versie van PHP. Bij mijn.host kun je zelf kiezen welke versie van PHP je wilt draaien per domeinnaam.
Test wel goed van tevoren of jouw WordPress thema en plugins compatible zijn met die versie van PHP.
De WordPress core is nagenoeg altijd compatible met de nieuwste versie van PHP, maar in een thema of in plugins kunnen functies worden gebruikt die met de komst van een nieuwe PHP-versie niet meer werken. Dan werkt je WordPress-site dus niet meer naar behoren.
De snelheidswinst van een nieuwe PHP-versie merk je als het goed is voornamelijk in de WordPress-beheeromgeving. Voor de website pagina’s gebruik je uiteraard, als je optimalisatie #1 in dit blogartikel goed hebt uitgevoerd, een server side caching oplossing. Dan speelt PHP nog maar een (heel) kleine rol.
WordPress beheeromgeving supersnel met PHP7
De nieuwste versie van PHP is PHP7. Dit is een volledig nieuwe versie, die echt wordt gekenmerkt door een enorme snelheidswinst. Hier wordt je WordPress-beheeromgeving echt vele malen sneller van.
Tot wel 2 tot 3 keer sneller volgens Savvii WordPress Hosting!
Maar wees voorzichtig, want er is veel veranderd en de kans is groot dat je WordPress theme en plugins niet compatible zijn met PHP7. Mijn advies is: zoek dit heel goed uit, of heb gewoon nog een poosje geduld.
Deze punten optimaliseer je met de nieuwste PHP-versie
Zorg je ervoor dat jouw WordPress-website draait op de nieuwste (stabiele) versie van PHP, dan draagt dit bij aan het verbeteren van:
- Improve server response time / First Byte Time
Bonustips voor WordPress sites die volledig op HTTPS draaien
Laden alle pagina’s van je WordPress-website over HTTPS? Dan heb je al snel te maken met snelheidsverlies, doordat bij het laden van de website het SSL certificaat gevalideerd moet worden.
Hieronder volgen enkele bonustips voor het sneller maken van WordPress-websites die volledig over HTTPS geladen worden.
18. HTTPS bonus 1: Kies een hostingprovider die Varnish op HTTPS ondersteunt
Als je optimalisatie 1 over hosting goed hebt uitgevoerd, beschik je over een hostingpakket met server side caching oplossing. Hopelijk WordPress Varnish Hosting, want dit maakt je WordPress-website écht snel.
Het lukt de meeste hostingproviders niet om Varnish ook te ondersteunen op HTTPS-pagina’s. Maar het is wel mogelijk!
Het vereist alleen aanvullende configuratie en de kennis daarvoor ontbreekt bij de meeste providers. Maar er zijn wel hostingproviders die de moeite nemen deze kennis op te doen.
Kies voor een hostingprovider die Varnish wel ondersteunt op HTTPS-pagina’s.
Mijn tip:
Ga voor Xel Media WordPress Hosting of mijn.host Hosting!
19. HTTPS bonus 2: implementeer een HSTS header en meld je site aan bij Chrome preload
HSTS staat voor: HTTP Strict Transport Security.
In het kort: deze HTTP-header zorgt ervoor dat webservers aan browsers de opdracht geven alle content over HTTPS te laden. Dit om de veiligheid te verhogen tegen downgrade attacks en cookie hijacking.
Websites die deze header (correct) hebben geïmplementeerd, komen in aanraking voor opname in de Chrome HSTS preload list. Dit is een lijst van websites die volledig op HTTPS draaien en waarvan meerdere browsers gebruik maken.
Is je WordPress-website opgenomen, dan wordt deze een klein beetje sneller, aangezien de browsers minder checks op je SSL-certificaat hoeven uit te voeren. Immers, opname in de lijst gebeurt aan de hand van een SSL-check en deze check hoeft dan niet telkens volledig opnieuw uitgevoerd te worden.
Hoe voeg je de HSTS header toe aan je WordPress website?
De header implementeren zoals staat beschreven op de website van Chrome HSTS preload list is geen lastige klus.
Download via FTP het bestand functions.php dat zich in de map van je (child) theme bevindt. Daarin voeg je de onderstaande code toe:
Sla het bestand op en upload het weer naar dezelfde locatie. Overschrijf het bestaande bestand. Test of je website nog normaal functioneert.
Daarna ben je klaar om je WordPress-website te testen en aan te melden via Chrome HSTS preload list.
Wacht niet, maar begin vandaag met WordPress sneller maken
Ben je tot hier gekomen, dan weet je inmiddels dat een snelle website belangrijk is. Maak je je WordPress-website sneller, dan:
- Krijg je sneller de aandacht van je bezoekers en blijven ze langer
- Wordt je website beter vindbaar in grote zoekmachines zoals Google
- Haal je meer resultaat uit je website in de vorm van een hogere conversie
Een WordPress-website sneller maken is geen rocket science. Sommige optimalisaties zijn eenvoudiger dan de ander, maar het begint allemaal bij die ene belangrijke optimalisatie:
Maak gebruik van hoogwaardige WordPress-hosting en begin daarna met de overige optimalisaties!
Met welke optimalisatie(s) ga jij aan de slag? Laat het me weten door hieronder een reactie toe te voegen.
Kom je er niet uit of heb je een vraag? Ook dan kun je een reactie achter laten, of je vraag aan mij stellen via het contactformulier.
Ik help je graag met het sneller maken van jouw WordPress-site; advies is gratis en vrijblijvend!
Xel Media Premium WordPress Hosting
Vanaf €9,90 excl. BTW per maand
mijn.host Hosting
Vanaf €1,99 per maand (contract 12 maanden)
Links naar handige hulpmiddelen
- Google PageSpeed Insights: test je WordPress-website op snelheid en krijg aanbevelingen over optimalisatie.
- Varvy.com: test je WordPress-website op snelheid. Uitgebreide informatie over website snelheid optimalisatie.
- GTmetrix recommendations: overzicht van alle aanbevelingen voor snelheid optimalisatie.
- Speeding Up WordPress: de beste en meest complete Engelstalige handleiding voor het sneller maken van WordPress.
Er zijn 18 reacties op dit artikel. Ook reageren? Ga naar het reactieformulier.
Een helder en zeer uitgebreid betoog. Veel ervan was ik al van op de hoogte, een paar tips nog niet, zoals de HSTS header. Die ga ik zeker proberen.
Wellicht zinvol om ook een gratis cdn als Cloudflare een keer onder de aandacht te brengen? Ook hier is veel winst mee te behalen.
Hallo Ronald, bedankt voor je reactie en goed om te horen dat je er nog een tip uit hebt kunnen halen die je kunt proberen. CloudFlare zal ik in m’n achterhoofd houden, is zeker nog een interessant punt.
Hey Rick
Altijd leuk om optimalisatie tips te vinden. Ik las je eerste tip over de hosting provider en viel bijna van mijn stoel: vanaf 10€ per maand? Ik betaal zelf 10€ voor de hosting … per …. jaar (dat is zonder wat ik betaal voor de naam). Mijn site is af en toe ’s nachts eruit, maar voor de rest is stabiliteit goed en responsitiviteit is ook ok. Is er een bepaald volume aan bezoekers vanaf wanneer jij zou adviseren om 12 peer meer geld uit te geven aan de hosting vanwege performantie bezorgdheden ?
Groetjes
Svend
Hallo Svend,
Ik weet dat er hele goedkope hostingmogelijkheden zijn. En er zullen wellicht ook goede bij zitten. Maar het is hoogstwaarschijnlijk niet te vergelijken met de service en continue kwaliteit die je krijgt wanneer je meer betaalt, zoals bij bijvoorbeeld Xel Media.
Om een echt goed antwoord te geven zou ik beide pakketten naast elkaar moeten leggen en beide grondig testen en tegen elkaar afzetten.
Wat betreft je opmerking ‘Mijn site is af en toe ’s nachts eruit…’, daar zou ik als het mijn website betrof niet mee akkoord gaan. Continue online zijn is ontzettend belangrijk, ook ’s nachts. Denk aan het belang van bereikbaarheid wanneer zoekmachines ’s nachts jouw website crawlen. Wil je dan dat deze onbereikbaar is?
Wat mij betreft is het omslagpunt om meer te betalen heel simpel: als je een commerciële doelstelling hebt met je website, moet je meer gaan betalen voor hosting. Dus als je doel is: geld verdienen.
Groet, Rick
Hey Rick,
Goed artikel, alleen jammer dat je mijn populaire ‘Optimize Database after After deleting Revisions’ plugin hebt gemist ;-)
https://wordpress.org/plugins/rvg-optimize-database/
Rolf
Hallo Rolf,
Interessante plugin; ga ik bekijken!
Ik optimaliseer de database in PhpMyAdmin. Dat scheelt weer een plugin.
Mooi artikel en dank voor de duidelijke uitleg!
Gr.
Maarten
Hallo Maarten, fijn om te horen dat je iets aan het artikel hebt gehad!
Wat een hoop goede tips. Ik ga zeker er mee aan de gang, kijken wat ik zelf voor elkaar kan krijgen. Bedankt.
Hallo Sophie, bedankt voor je reactie. Succes met de optimalisatie van jouw WordPress website!
Prachtig en duidelijk artikel. Bedankt.
Dankje, Johan!
Dit is nog eens goede informatie! Niet geschreven om te schrijven (zoals veel blog artikelen). Een prachtig artikel Rick. Compliment!
Goed om te horen, Marcel! Succes met de optimalisatie van jouw WordPress website(s).
Beste Rick,
Dank voor je duidelijke uitleg! Ik heb eens uitgeprobeerd of ik dat HSTS ging lukken maar m`n website houdt dan gelijk op met werken gelijk een foutmelding 500 dacht ik.
Inmiddels wel weer terug gezet.
Heb jij een idee vat ik niet goed doe?
Groet Niels
Hallo Niels,
Ik adviseer je om deze vraag aan je hostingprovider te stellen. 500 codes hebben te maken met de server.
Groet, Rick