Jouw WordPress website sneller maken (de ultieme handleiding)

We hebben de afgelopen jaren veel tutorials gepubliceerd met manieren om WordPress te optimaliseren en te versnellen. Soms kan het echter lastig zijn om alles wat je nodig hebt op één plek te vinden. Daarom vertellen we vandaag hier alles wat we weten over het versnellen van WordPress – gebaseerd op meer dan 15 jaar ervaring en leermomenten, allemaal in één ultieme handleiding. Of je nu net met WordPress begint of een doorgewinterde ontwikkelaar bent, we beloven dat je iets nuttigs zult vinden in deze handleiding!

Meer dan 43.5% van de websites op het internet wordt nu mogelijk gemaakt door WordPress. Dat is natuurlijk geweldig, maar dit betekent ook dat er duizenden verschillende thema’s, plugins en technologieën allemaal naast elkaar moeten leven. Voor de dagelijkse WordPress-gebruiker kan dit snel veranderen in een nachtmerrie, wanneer hun site langzaam begint te worden en ze niet weten hoe ze problemen moeten oplossen.

In onze vorige handleiding over pagina snelheid hebben we veel van de basis van de performance besproken en hoe deze een enorme impact kunnen hebben op het succes van jouw bedrijf. Vandaag duiken we dieper in de toepasbare stappen die je nu kunt nemen om verbeteringen op jouw eigen WordPress sites te zien. We zullen ook enkele bronnen delen die hierin voor ons van onschatbare waarde zijn geweest.

WordPress site types: Statisch of Dynamisch

Voordat we ingaan op de optimalisaties, is het belangrijk te begrijpen dat niet alle WordPress sites hetzelfde zijn. Dit is een reden waarom veel gebruikers problemen hebben – je kunt niet elk issue op dezelfde manier aanpakken. Wij geven WordPress sites altijd een classificatie: statisch of dynamisch. Laten we dus eerst de verschillen tussen deze twee type sites uitlichten.

Voornamelijk statische websites

Statische sites zijn onder meer blogs, kleine bedrijfssites, nieuwssites met een laag volume nieuwe berichten, persoonlijke websites, fotografie websites, etc. Met statisch bedoelen we dat de gegevens op deze WordPress websites niet vaak veranderen (misschien een paar keer per dag). Zelfs de meeste van onze Kinsta sites zouden als een statische website worden beschouwd.

Dit is belangrijk, omdat veel van de verzoeken direct vanuit cache op de server kunnen worden aangeleverd met zeer hoge snelheden! Maak je geen zorgen; we leggen caching later uitgebreid uit. Dit betekent dat ze minder database aanvragen zullen hebben en dat niet zo veel resources nodig zijn om Google-waardige prestaties te bereiken.

Zeer dynamische websites

Aan de andere kant hebben we dynamische sites. Hieronder vallen sites zoals e-commerce (WooCommerce of Easy Digital Downloads), communities, lidmaatschap websites, forums (bbPress of BuddyPress) en Learning Management Systemen (LMS). Met dynamisch bedoelen we dat de gegevens op deze WordPress sites regelmatig veranderen (servertransacties vinden om de paar minuten of zelfs elke seconde plaats). Dit betekent dat niet alle verzoeken aan de server rechtstreeks vanuit de cache kunnen worden geserveerd en daarom aanvullende server resources en database query’s vereisen.

Deze websites hebben meestal ook een groot aantal gelijktijdige bezoekers en sessies. Op een informatieve of zakelijke WordPress site die voornamelijk statisch is, kan een bezoeker vijf of tien minuten blijven zitten totdat hij vindt wat hij nodig heeft (dit is een hoog getal, meestal zijn de bounce-percentages veel hoger). Op dynamische sites gebeurt het tegenovergestelde. Bezoekers komen meestal naar de site om iets te doen. Als ze een online cursus volgen, is het niet ongebruikelijk dat ze uren blijven.

Je kunt zien waar dit naartoe gaat. De gelijktijdige bezoekers die zijn verbonden met jouw WordPress host, tellen snel op. Om het nog erger te maken, heb je vervolgens een groot aantal gelijktijdige bezoekers bovenop een probleem met “niet cache-bare content”.

Kies voor geoptimaliseerde WordPress hosting

Een WordPress host is een bedrijf dat alle gegevens van jouw website opslaat. Je neemt een pakket en al jouw afbeeldingen, inhoud, video’s, enz. bevinden zich op een server in het datacentrum van de host. De WordPress host biedt je een eenvoudige manier om toegang te krijgen tot de gegevens, deze te beheren en aan jouw bezoekers te tonen. Best simpel, toch? Nou ja, niet helemaal.

Er zijn drie heel verschillende types WordPress hosts die je kunt tegenkomen. Laten we kijken naar de voor- en nadelen van elk type. Het is belangrijk dat je vanaf het begin de juiste kiest, anders zal het je uiteindelijk kopzorgen en verspilde tijd opleveren.

1. Shared WordPress hosting

De eerste en meest populaire type WordPress hosting is wat we ‘shared hosting’ noemen. Dit zijn de grootste hosts in de branche, zoals Bluehost en HostGator, evenals providers zoals Siteground, Strato en Mijndomein. Ze maken meestal gebruik van cPanel, en de gemiddelde klant betaalt gewoonlijk tussen $3 en $25 per maand.

Iedereen die dit type hosting gebruikt, ervaart op een gegeven moment traagheid – het is gewoon een kwestie van tijd. Waarom? Omdat shared hosts de neiging hebben om hun servers te overbelasten, wat de prestaties van jouw sites beïnvloedt. Schorsingen van sites van 500 fouten zul je veelvuldig tegenkomen, omdat ze alles moeten beperken en middelen moeten balanceren om te overleven. Of nog erger, downtime van websites. Ook al weet je het niet, jouw WordPress site zit waarschijnlijk op dezelfde server als die van honderden anderen. Alle problemen met andere sites kunnen overlopen naar jouw site.

Het maakt niet uit hoe je ook rekent, $3 per maand genereert geen inkomsten voor het hostingbedrijf. Vooral als je daar support in mee rekent. Eén supportticket en ze staan al rood. De manier waarop ze hun geld vaak verdienen is door up-selling en verborgen kosten. Deze up-sells zijn zaken zoals verhuizingen, domeinregistraties, SSL-certificaten, et cetera. Een andere veelgebruikte tactiek is het bieden van enorme kortingen bij de aanmelding, maar zodra de verlenging komt, krijg je de échte rekening.

De meeste van deze hosts bieden ‘onbeperkte’ pakketten aan. Je hebt dit waarschijnlijk wel eens gezien. Helaas bestaat er in de echte wereld niet zoiets als onbeperkte resources. Wat de hosts achter de schermen doen, is de resources beperken van klanten die grootverbruiker zijn. Dit resulteert op zijn beurt weer in het vertrek van boze klanten, waardoor ruimte wordt gemaakt voor meer klanten die niet veel resources verbruiken. Uiteindelijk heb je een vicieuze cirkel van het hostingbedrijf dat goedkope pakketten pusht en klanten aanmeldt waarvan ze hopen dat ze niet veel resources zullen gebruiken en up-sells aan te kunnen smeren.

Klantenservice en ondersteuning bij shared hosting zijn bijna altijd ondermaats vanwege de enorme hoeveelheid sites versus het aantal supportmedewerkers. Shared hosts moeten zich erg uitgedund houden om winst te maken en dit leidt meestal tot een onaangename ervaring voor de klant.

Lees een diepgaand artikel van onze CFO over de schokkende waarheden over hoe goedkope WordPress-hosting echt werkt.

2. Doe-het-zelf VPS WordPress Hosting

Het tweede type WordPress hosting is DIY VPS, of “doe-het-zelf” op een virtual private server. Op dit type hosting zitten vaak bootstrap startups en technische gebruikers met wat meer ervaring in ontwikkeling, serverbeheer en WordPress. Deze mensen proberen meestal geld te besparen, maar ze zijn ook bezig met prestaties en beseffen het belang hiervan voor het succes van hun bedrijf. Veelvoorkomende setups kunnen het gebruik van een externe VPS-provider zoals Digital Ocean, Linode of Vultr omvatten; samen met een tool zoals ServerPilot om het gemakkelijk te beheren.

Een kleine VPS van DigitalOcean begint bij $5 per maand en het populaire abonnement bij ServerPilot begint bij $10 per maand. Afhankelijk van je opstelling kijk je dus naar een prijs van tussen $5 tot $15 of meer per maand. De doe-het-zelf benadering kan kosten besparen, maar het betekent ook dat jij verantwoordelijk bent wanneer er iets kapot gaat en voor het optimaliseren van jouw server voor performance.

De DIY-aanpak kan effectief zijn, maar het kan ook tegen je werken als je niet voorzichtig bent. Werk niet via deze weg wanneer je niet technisch onderlegd bent of gewoon omdat je wilt sleutelen! Jouw tijd is geld waard en je zou het moeten besteden aan de groei van je bedrijf.

3. Managed WordPress Hosting

Het derde type hosting is wat we aanbieden bij Kinsta en dat is managed WordPress hosting. Dit type host neemt jou al het werk op servergbied af en biedt ondersteuning wanneer je die nodig hebt. Ze zijn vaak nauwkeurig afgesteld om met WordPress te werken en bevatten gewoonlijk functies zoals staging omgevingen die met één klik aan te maken zijn en automatische backups. Hun supportteams zullen meer kennis hebben van het CMS, omdat ze dag in dag uit hierop gefocust zijn.

Als je tijd wilt besparen, is managed WordPress hosting de juiste keuze! 👍

Pakketten voor Managed WordPress hosting variëren doorgaans van $25 tot $150 per maand of meer, afhankelijk van de grootte van jouw site en behoeften. Grote bedrijven zoals jQuery, Intuit, Plesk, Dyn, Nginx en zelfs The White House gebruiken allemaal WordPress om hun website te hosten. Sommige populaire managed WordPress hosts die je waarschijnlijk kent, of misschien ook op dit moment gebruikt, zijn WP Engine, Flywheel, Savvii, Media Temple, Pressidium en Pagely.

Kinsta maakt gebruik van een andere aanpak

Kinsta tilt WordPress hosting echter naar een geheel ander niveau. Ons hosting platform valt niet in een van de traditionele hosting categorieën. Onze volledige infrastructuur is gebouwd op Google Cloud Platform en verschilt van traditionele shared, VPS of dedicated infrastructuur.

Elke WordPress site op ons platform draait in een geïsoleerde softwarecontainer die alle software resources bevat die nodig zijn om de site te laten draaien (Linux, Nginx, PHP, MySQL). Dit betekent dat de software die elke site uitvoert volledig privé is en niet wordt gedeeld, zelfs niet tussen eigen sites.

Elke sitecontainer draait op virtuele machines uit een van de meerdere GC datacenters en maakt gebruik van het Premium Tier netwerk van Google Cloud Platform voor geoptimaliseerde gegevensoverdracht met zo min mogelijk vertraging. Elke machine heeft tot 96 CPU’s en honderden GB aan RAM. Hardwarebronnen (RAM/CPU) worden automatisch toegewezen aan elke sitecontainer door onze virtuele machines, indien nodig.

In tegenstelling tot andere hosts die gebruikmaken van de algemene virtuele machines van Google Cloud Platform, stellen wij voor al onze klanten – in ondersteunde regio’s – compute-optimized C2 VM’s beschikbaar. De C2 machinefamilie van Google Cloud is uitgerust met de nieuwste schaalbare Intel Xeon processoren en bevat een 3,8 GHz sustained all-core turbo. C2machines zijn populair voor taken die veel rekenkracht vereisen, zoals scientific modeling en machine learning, maar ze zijn ook uiterst gechikt voor krachtige WordPress hosting. Uit onze tests bleek dat het verhuizen van een WordPress site van een “general purpose” VM naar een C2 VM resulteerde in 2x betere prestaties!

Thank you @kinsta for handling today's traffic spike without issue. It's comforting to know your site can handle surges. #webperf #webhosting #wordpress pic.twitter.com/fplO87LIu0

— Adam Lundeen (@adam_lundeen_) January 29, 2019

Elk jaar publiceert Review Signal zijn WordPress hosting benchmarks, en we zijn er trots op dat Kinsta al vijf jaar op rij het beste bedrijf op alle niveaus is gebleken! Niet alleen op een of twee van onze pakketten, maar op elk pakket, van Starter helemaal tot aan Enterprise. 🤘

We hebben ook geen supportmedewerkers op niveau 1 of niveau 2. Ons gehele ondersteuningsteam bestaat uit WordPress-ontwikkelaars en Linux hosting engineers, van wie velen hun eigen servers hebben beheerd, thema’s en plugins hebben gemaakt en hebben bijgedragen aan de WordPress core. Dit zorgt ervoor dat je deskundig advies krijgt van iemand die actief gebruikmaakt van en ontwikkelt met WordPress.

Je kunt chatten met het dezelfde supportteam dat onze Quote 500- en zakelijke klanten ondersteunt. We zijn zo kieskeurig over de kwaliteit van ons supportteam dat we minder dan 1% van de sollicitanten aannemen die solliciteren. Je zult nergens anders betere ondersteuning vinden!

Om meer te weten te komen waarom je voor de managed WordPress hosting van Kinsta zou moeten kiezen kun je het artikel Waarom wij – wat maakt Kinsta anders dan de rest. Ongeacht wie je kiest als jouw hosting provider, je moet altijd op zoek naar de volgende server functies om ervoor te zorgen dat jouw website zo snel mogelijk is.

PHP 7 of hoger voor de beste prestaties

PHP is een open-source server-side scripting- en programmeertaal die voornamelijk wordt gebruikt
voor web-ontwikkeling. Het grootste deel van de WordPress core is geschreven in PHP, net als je plugins en thema’s, waardoor PHP een zeer belangrijke taal is voor de WordPress community. Je moet ervoor zorgen dat je WordPress host minimaal PHP 7 of hoger aanbiedt.

Er zijn verschillende versies van PHP die de host je zou moeten aanbieden – vooral de nieuwere PHP 7.3 die enorme prestatieverbeteringen biedt.

In onze recente PHP benchmarks vergelijken we PHP 7.3 met PHP 5.6. Daar kun je zien dat de nieuwe versie 3x zoveel verzoeken (transacties) per seconde kan verwerken! Ook is PHP 7.3 gemiddeld 9% sneller dan PHP 7.2. Dit kan ook invloed hebben op de responsiviteit van jouw WordPress dashboard.

Hogere snelheid en verbeterde beveiliging zijn de redenen waarom Kinsta altijd de meest recente PHP versies aanbiedt. Je kunt de PHP versie wijzigen met een enkele klik.

Wees op je hoede wanneer een WordPress host HHVM aanbiedt als alternatief voor PHP. HHVM is geen geschikte oplossing voor WordPress hosting meer.

Kies een Host die Nginx Gebruikt

Achter de schermen gebruikt elke WordPress host een webserver om jouw WordPress sites te draaien. De meest voorkomende keuzes zijn Nginx en Apache.

We raden ten sterkste aan om met een host te nemen die Nginx gebruikt vanwege zijn oorsprong in performance verbetering op schaal. Nginx presteert vaak beter dan andere populaire webservers in benchmark testen, vooral in situaties met statische inhoud of veel gelijktijdige verzoeken – daarom gebruikt Kinsta Nginx.

Een aantal spraakmakende bedrijven die Nginxgebruiken zijn: Autodesk, Atlassian, Intuit, T-Mobile, GitLab, DuckDuckGo, Microsoft, IBM, Google, Adobe, Salesforce, VMWare, Xerox, LinkedIn, Cisco, Facebook, Target, Citrix Systems, Twitter, Apple , Intel en nog veel meer. (bron)

Volgens W3Techs is Apache verantwoordelijk voor 44,0% van alle websites, waardoor het de meest gebruikte optie is. Maar als je kijkt naar de meest populaire webserver voor websites met veel verkeer (top 10.000), dan is Nginx met 41.9% vertegenwoorigd, terwijl Apache slechts 18,1% aandrijft. Het wordt gebruikt door een aantal van de meest resource intensieve websites, waaronder Netflix, NASA en zelfs WordPress.com.

Lees meer in de onze webserver vergelijking: Nginx vs Apache.

Het Netwerk van Jouw Host is een Factor

Bij het kiezen van een WordPress host denk je misschien niet eens aan vragen naar of onderzoeken welk netwerk ze gebruiken, maar dat zou je wel moeten doen. Het netwerk kan een enorme impact hebben op de prestaties van jouw site en zelfs de “snappyness” van jouw WordPress dashboard. Veel hosts laten dit uit hun marketing omdat ze kiezen voor het goedkoopste netwerk om kosten te besparen.

Hier zijn een paar vragen die je zou moeten stellen:

• Over welke netwerken verzenden jullie gegevens? Is de meerderheid ervan over openbare ISP-netwerken of privé-infrastructuren zoals Google of Microsoft? Deze grote providers hebben netwerken die zijn gebouwd en geoptimaliseerd voor lage latency en snelheid. Ze hebben zelfs hun eigen internet kabels onder de oceaan!
• Zijn de gebruikte netwerken redundant? Wat gebeurt er als er een kabel per ongeluk wordt doorgesneden? Dit komt vaker voor dan je denkt!

In 2017 kondigde Google hun standaard tier netwerk aan, dat is een trager netwerk maar tegen lagere kosten. Bij Kinsta gebruiken we hun premium tier netwerk oor al onze hosting pakketten. Hoewel dit extra kosten met zich meebrengt, zorgt het voor hoge snelheden.

Volgens Google, behaalt het premium tier netwerk de verbeterde netwerkprestaties door de duur van versturen over het openbare internet te verminderen; pakketten gaan (en verlaten) het netwerk van Google zo dicht mogelijk bij de gebruiker en reizen vervolgens via de backbone van Google voordat ze bij de VM aankomen. De standaardlaag levert uitgaand verkeer van GCP naar het internet via openbare (ISP) netwerken in plaats van het Google netwerk.

Om het op een andere manier te verwoorden die makkelijker te begrijpen is:

• Premium tier packets leggen meer tijd en afstand of op het eigen Google netwerk, et minder rond stuiteren waardoor ze beter presteren (maar dit is duurder).
• Standaard tier packets leggen minder tijd en afstand af op het Google netwerk. Deze packets reizen meer via publieke netwerken en presteren daardoor een stuk slechter (maar dit is wel goedkoper).

Hoeveel impact heeft dit nu eigenlijk? Voor gegevens die intercontinentaal reizen, is het premium tier netwerk gemiddeld 41% seller dan het standaard netwerk. Voor gegevens die naar een nabijgelegen regio (hetzelfde continent) reizen, is het premium netwerk ongeveer 8% sneller. Ondanks dat netwerken slechts een fractie vormen van de totale laadtijd van jouw pagina, telt elke milliseconde!

Redundantie is ook een factor en daarom gebruikt Google ten minste drie onafhankelijke paden (N+2 redundantie) tussen elke twee locaties op het Google netwerk, zodat het verkeer tussen de locaties blijft stromen, zelfs in het geval van een storing.

Zoals je waarschijnlijk nu wel zult merken, is er veel gaande achter de schermen als het gaat om netwerken. Zorg ervoor dat jouw WordPress host een gerenommeerde host is en niet voor lagere kwaliteit kiest om kosten te besparen.

HTTP/2 is een Must-Have

HTTP/2 is een web-protocol dat in 2015 is uitgebracht en is ontworpen om sneller te werken bij het afleveren van websites. Vanwege browser-ondersteuning is HTTPS (SSL) vereist. Als jouw WordPress host geen HTTP/2 ondersteunt, moet je op zoek gaan naar een nieuwe provider. Met de verhuizing van het hele web naar HTTPS is het niet langer alleen maar een leuke functie om te hebben; het is noodzaak.

De prestatieverbetering van HTTP/2 is te wijten aan verschillende redenen, zoals ondersteuning voor betere multiplexing, parallellisme, HPACK compressie met Huffman-codering, de ALPN-extensie en server push. Er was nogal wat TLS-overhead bij het gebruik van HTTPS, maar dit is nu een stuk minder dankzij HTTP/2 en TLS 1.3. Kinsta ondersteunt HTTP/2 en TLS 1.3 op al onze servers en CDN.

Een andere voordeel van HTTP/2 is dat je zich bij de meeste WordPress sites niet langer zorgen hoeft te maken over de concatentation (het combineren van bestanden) of sharding van domeinen. Dit zijn nu verouderde optimalisaties.

Kies een server zo dicht mogelijk bij jouw bezoekers

Een van de allereerste dingen die je moet doen bij het hosten van jouw WordPress site is om te bepalen waar de meerderheid van jouw bezoekers of klanten vandaan komt. Waarom dit belangrijk is? Omdat de locatie waar jij jouw website host een belangrijke factor is in het bepalen van jouw algehele netwerk-latency en TTFB. Het heeft ook invloed op de SFTP-snelheden en het reactievermogen van het WordPress dashboard.

Network Latency: dit verwijst naar de tijd en/of vertraging die komt kijken bij het verzenden van gegevens over een netwerk. Met andere woorden: hoe lang het duurt voordat gegevens van het ene punt naar het andere gaan. Tegenwoordig wordt dit meestal gemeten in milliseconden – het kunnen echter seconden zijn, afhankelijk van het netwerk. Hoe dichter bij nul, hoe beter.

Lees ons uitgebreide artikel over network latency.

TTFB: dit staat voor Time To First Byte. Simpel gezegd: dit is de tijd hoe lang de browser moet wachten voordat deze de eerste byte aan gegevens van de server ontvangt. Hoe langer het duurt om die gegevens te krijgen, hoe langer het duurt om jouw pagina weer te geven. Nogmaals, hoe dichter bij nul, hoe beter.

Bekijk onze uitgebreide artikel over TTFB.

We zullen je niet vervelen met alle technische details in deze post. Alles wat je moet weten is dat je wilt dat je netwerk latency en TTFB zo laag mogelijk zijn. Een van de gemakkelijkste manieren om dit te bereiken, is door een server te kiezen die het dichtst bij jouw bezoekers staat. Je kunt de juiste locatie bepalen door de onderstaande tips te volgen.

Tip 1 — Check de geografische locatie van jouw bezoekers in Google Analytics

Een van de allereerste dingen die je kan doen is om te kijken naar de geolocatie van jouw bezoekers in Google Analytics. Je kunt dit vinden onder “Doelgroep → Geo → Locatie.”

In dit onderstaande voorbeeld zie je dat meer dan 90% van het verkeer afkomstig is uit de Verenigde Staten. In dat geval wil je dus jouw WordPress site op een server in de Verenigde Staten plaatsen. Je kunt de gegevens ook nog verder op steden filteren. Dit is vooral belangrijk als je een lokaal bedrijf hebt. In dit geval zouden we een centrale locatie zoals Iowa, VS aanbevelen.

Tip 2 — Bekijk e-commerce data

Heb je een webwinkel? Controleer dan waar je klanten vandaan komen. Je genereert online je inkomsten, dus dit zijn de belangrijkste bezoekers. Dit moet samenvallen met het bovenstaande verkeer; ook al is dit echter niet altijd het geval. Als je e-commerce gegevens of -doelen in Google Analytics gebruikt, kan je die informatie eenvoudig over de geolocatie-gegevens leggen om een onderbouwde beslissing te nemen. Ook kun je locatie-informatie die is opgeslagen in de database van jouw e-commerce-platform controleren.

Tip 3 — Doe een snelle latency Test

Er zijn tal van handige gratis tools om de latency van je huidige locatie te meten voor verschillende cloud dienstverleners. Dit helpt jou om snel te evalueren welke regio de beste keuze voor jouw site is.

• GCP Ping (Meet de latency naar Google Cloud Platform regio’s, inclusief Kinsta servers)
• CloudPing.info (Meet de latency naar Amazon Web Service regio’s)
• Azure Latency Test (Meet de latency naar Azure regio’s)

In het onderstaande voorbeeld kunnen we zien dat de Oregon, VS (us-west1) de snelste is van waaruit wij ons bevinden. Als je klanten in de hele Verenigde Staten bedient, is het misschien beter om te kiezen voor Iowa, VS (us-central1) om een lage latentie voor bezoekers aan de west- en oostkust te garanderen.

Bij Kinsta bieden we 37 verschillende datacentra over de hele wereld aan. Je kunt gemakkelijk kiezen voor een locatie die zowel een lage latency als een lage TTFB heeft! Het helpt ook in het reduceren van netwerk hops.

Andere manieren om latency en TTFB te reduceren

Naast het kiezen van een serverlocatie dichtbij je bezoekers zijn er nog andere manieren om latency te reduceren.

• Implementeer caching op jouw WordPress website. In onze testen reduceerde caching de TTFB met een indrukwekkende 90%!
• Maak gebruik van een content delivery netwerk (CDN) om de gecachete assets via POP’s over de hele wereld uit te serveren. Dit helpt om de netwerk latency te verminderen voor bezoekers die niet dichtbij jouw server zijn.
• Maak gebruik van het HTTP/2 protocol om het aantal round-trips te minimaliseren. HTTP/2 is ingeschakeld op alle Kinsta servers.
• Reduceer het aantal externe HTTP verzoeken. Elk van deze verzoeken kan zijn eigen latency hebben door de locatie van de server vanwaar de verzoeken komen.
• DNS speelt een factor in TTFB. Hierom zou je gebruik moeten maken van een premium DNS provider met snelle lookup tijden.
• Gebruik prefetch en prerender om in de achtergrond al taken uit te voeren terwijl de pagina laadt.

Maak je geen zorgen – al deze aanbevelingen gaan we nog uitgebreid behandelen in dit artikel.

SFTP snelheid en het WordPress admin dashboard

Bezoekers en klanten moeten altijd je prioriteit zijn. Maar een ander aspect van de uitvoering waar veel mensen niet over praten, is hoe sommige van deze beslissingen van invloed zijn op je dagelijkse werk. De datacenter-locatie die je kiest, heeft invloed jouw SFTP-download en -uploadsnelheden (bestanden overzetten met een FTP-client), evenals de reactietijd van je WordPress dashboard.

Dus, hoewel je een locatie kiest die het beste is voor je bezoekers, moet je er rekening mee houden dat dit van invloed kan zijn op het sitebeheer. Taken zoals het uploaden van bestanden naar de WordPress mediabibliotheek zullen sneller zijn wanneer de site wordt gehost in een datacenter dat dichter bij jou staat.

We horen constant van klanten bij Kinsta dat ze verbaasd zijn over hoe veel sneller hun dashboard bij ons is. Er zijn veel factoren die dit beïnvloeden, maar het beschikken over 37 verschillende datacenters speelt een grote rol! Kies een locatie die zowel voor jouw bezoekers als voor jezelf werkt! Jij bent tenslotte degene die waarschijnlijk duizenden uren aan het werk bent op jouw website.

Premium DNS is beter dan een gratis DNS

DNS, afkorting voor Domain Name System, is een van de meest voorkomende en tegelijk onbegrepen componenten van het web. Simpel gezegd: DNS helpt om verkeer op het internet de juiste richting op te wijzen door het verbinden van domeinen met servers. In essentie verwerkt DNS een mens-vriendelijk verzoek — een domein als kinsta.com omzetten naar een computer-vriendelijk server IP-adres — zoals 216.58.217.206.

Je kunt zowel gratis DNS als premium DNS vinden. Alle Kinsta klanten krijgen via Amazon Route 53 toegang tot premium DNS. Over het algemeen zijn wij van mening dat premium DNS een noodzaak is vandaag de dag.

Een belangrijke reden om premium DNS te kiezen, is de snelheid en betrouwbaarheid. Het opzoeken van DNS-records en het sturen van verkeer kost tijd, zelfs als het slechts een kwestie van milliseconden is.

Doorgaans is de gratis DNS die je van jouw domeinnaam registrar krijgt relatief traag, terwijl premium DNS vaak betere prestaties biedt. In onze tests ontdekten we bijvoorbeeld dat de gratis NameCheap DNS 33% langzamer was dan Amazon Route 53 premium DNS. Bovendien kan premium DNS betere beveiliging en beschikbaarheid bieden, vooral wanneer je een DDoS-aanval moet afweren.

Je kunt een tool zoals de SolveDNS snelheidstest gebruiken om de DNS-lookup tijden te controleren. DNSPerf biedt ook uitstekende prestatiegegevens over alle top DNS-providers.

Voor een goed middenweg tussen de gratis DNS die wordt geleverd door je domeinregistrar en premium DNS, is de Cloudflare DNS een gratis service die nog steeds veel van de voordelen van premium DNS biedt. Ze hebben hoge snelheden met minder dan 20 ms gemiddelde reactietijden over de hele wereld (zoals hieronder te zien).

Cloudflare integratie zit inbegrepen bij alle Kinsta pakketten. Als je voornamelijk bezoekers in de Verenigde Staten hebt, is DNS Made Easy een andere geweldige premium DNS provider die je wellicht wilt bekijken. Ze hebben een reputatie voor het leveren van de beste DNS uptime in de afgelopen tien jaar.

In de laatste 30 dagen toont DNSPerf de volgende uptime voor deze providers:

• DNS Made Easy: 99.99% wat gelijk staat aan 4m 23.0s maandelijkse downtime.
• Amazon Route 53: 99.88% wat gelijk staat aan 52m 35.7s maandelijkse downtime.
• Cloudflare: 99.85% wat gelijk staat aan 1h 5m 44.6s maandelijkse downtime.

Is downtime zo belangrijk bij DNS-providers? Het antwoord hierop is ja en nee. DNS wordt meestal in cache opgeslagen bij ISP’s met behulp van de time to live waarde (TTL) op het DNS-record. Daarom zal je waarschijnlijk niets merken als een DNS-provider 10 minuten lang down is. Uitvaltijd is echter van belang als de provider consequent langere en frequente onderbrekingen heeft of als jouw ISP en DNS-records beide erg lage TTL-waarden gebruiken.

Jouw WordPress thema heeft invloed

Iedereen houdt van een gloednieuw WordPress thema, maar wees voorzichtig voordat je iets kiest met allerlei nieuwe shiny functies. Lees eerst ons artikel over de verschillen tussen gratis versus betaalde thema’s. In relatie tot de prestaties heeft elk element dat je in een thema ziet invloed op de algehele snelheid van je website. En helaas zitten er met duizenden beschikbare thema’s ook rotte appels tussen.

Hoe moet je nou weten welk thema je moet kiezen? Wij raden aan om in zee te gaan met 1 van de 2 volgende opties:

• Een snel lichtgewicht WordPress thema dat is gebouwd met alleen de functies die je nodig hebt.
• Een thema met meer features waarvan je functies kunt uitschakelen die je niet nodig hebt.

Zaken zoals Google Fonts, Font Awesome pictogrammen, schuifregelaars, galerijen, video- en parallax-scripts, enz. zijn slechts enkele van de vele dingen die je makkelijk zou moeten kunnen uitschakelen als ze niet gebruikt worden. Je wilt niet dat je dit handmatig moet aanpassen. We zullen je niet 50 verschillende manieren laten zien om dingen eruit te halen. In plaats daarvan moet je starten met of overstappen naar een WordPress thema dat vanaf het begin licht van gewicht is of jou deze opties geeft.

Hieronder staan een paar WordPress thema’s die we aanbevelen en waar je niet mis mee kunt gaan! Vertrouw erop, je zult ons later bedanken. 😉

Elk thema hieronder vermeld is volledig compatibel WooCommerce en Easy Digital Downloads, WPML, BuddyPress en bbPress. We voeren een paar snelheidstests uit met elk thema met behulp van de volgende configuratie:

• Gehost bij Kinsta, WordPress versie 4.9.8
• PHP 7.3 en SSL (HTTPS)
• Kinsta CDN
• Imagify om afbeeldingen automatisch te comprimeren.

GeneratePress

GeneratePress is een snel, lichtgewicht (minder dan 1MB gecomprimeerd), mobiel responsief WordPress thema, gebouwd voor snelheid, SEO en bruikbaarheid. Gebouwd door Tom Usborne, een ontwikkelaar uit Canada. Het thema wordt actief bijgewerkt en goed ondersteund. Zelfs enkele Kinsta teamleden gebruiken GeneratePress voor hun projecten.

Er is zowel een gratis als een premium versie beschikbaar. Als je de WordPress repository bekijkt, heeft de gratis versie momenteel meer dan 200.000 actieve installaties, 2+ miljoen downloads en een indrukwekkende 5 uit 5 sterren (meer dan 850 mensen hebben 5 sterren gegeven).

Een van de geweldige dingen van GeneratePress is dat alle opties de eigen WordPress Customizer gebruiken. Dat betekent dat je elke verandering die je aanbrengt direct kunt zien voordat je op de publicatieknop drukt. Dit betekent ook dat je geen nieuw thema configuratiescherm hoeft te leren kennen.

Hoe snel is het thema? We hebben een nieuwe installatie van GeneratePress gedaan, vijf snelheidstests uitgevoerd in Pingdom en daarvan het gemiddelde genomen. De totale laadtijd was 305 ms met een totale pagina grootte van slechts 16,8 KB. Het is altijd goed om een baseline-test te doen om te zien wat het onbewerkte thema in huis heeft qua prestaties.

Vervolgens hebben we een andere set tests uitgevoerd met een van de vooraf gemaakte thema’s uit de GeneratePress bibliotheek. Dit bevat afbeeldingen, achtergronden, nieuwe secties, enzovoort. Een voordeel van GeneratePress is dat het veel vooraf gebouwde thema’s heeft waardoor er geen plugin voor het maken van een pagina is vereist. Je kunt zien dat het nog steeds onder de 400 ms is.

Nu heb je in een echte omgeving andere dingen draaien, zoals Google Analytics, Facebook-remarketingpixel, Hotjar, enz. Ook dan kun je gemakkelijk onder de 1 seconde kunnen blijven. Lees een uitgebreide review over GeneratePress op woorkup.

We laten je hieronder meer manieren zien hoe je WordPress kunt optimaliseren en versnellen.

OceanWP

Het OceanWP thema is licht van gewicht en uitermate uitbreidbaar en stelt je in staat vrijwel elk type website zoals een blog, portfolio, bedrijfswebsite en WooCommerce winkel met een mooi en professioneel ontwerp te maken. Gebouwd door Nicolas Lecocq. Het thema wordt ook actief bijgewerkt en goed ondersteund.

Net als bij GeneratePress is er zowel een gratis als een premium versie beschikbaar. Als je de WordPress repository bekijkt, heeft de gratis versie momenteel meer dan 400.000 actieve installaties en een nog indrukwekkendere 5 uit 5 sterren beoordeling (met meer dan 2.600 mensen die 5 sterren hebben gegeven).

Hoe snel is het thema? We hebben een nieuwe installatie met OceanWP gedaan, vijf snelheidstests uitgevoerd in Pingdom en het gemiddelde genomen. De totale laadtijd was 389 ms met een totale pagina grootte van slechts 230,8 KB. De scripts in OceanWP zijn iets groter, maar dit is niet significant.

Vervolgens hebben we een andere reeks testen uitgevoerd met een van de demo thema’s uit de OceanWP bibliotheek. Dit bevat afbeeldingen, achtergronden, nieuwe secties en vereist Elementor als page builder. Je kunt zien dat het nog steeds onder 600 ms is.

Je kunt een uitgebreide review over OceanWP lezen op onze blog.

Astra

Astra is een snel, volledig aanpasbaar & mooi thema geschikt voor blogs, persoonlijke portefeuilles, zakelijke websites en WooCommerce websites. Het is een zeer licht (minder dan 50 KB op de front-end) thema en biedt een ongeëvenaarde snelheid. Gebouwd is het thema door het team van Brainstorm Force. Het thema wordt actief bijgewerkt en goed ondersteund. Je herkent ze misschien als de makers van de populaire All In One Schema Rich Snippets plugin die al vele jaren bestaat.

Net als bij GeneratePress en OceanWP is er zowel een gratis als een premium versie beschikbaar. Als je de WordPress repository bekijkt, heeft de gratis versie momenteel meer dan 400.000 actieve installaties, 1,6 miljoen downloads en een indrukwekkende 5 van de 5 sterren beoordeling (meer dan 2500 mensen hebben 5 sterren gegeven).

Hoe snel is het thema? We hebben een nieuwe installatie van Astra gemaakt, vijf snelheidstests uitgevoerd in Pingdom en daarvan het gemiddelde genomen. De totale laadtijd was 243 ms met een totale pagina grootte van slechts 26.6 KB.

Vervolgens hebben we een andere reeks testen uitgevoerd met een van de demo-thema’s uit de bibliotheek van de Astra Starterskit. Deze bevat afbeeldingen, achtergronden, nieuwe secties en vereiste de Elementor page builder. Je kunt zien dat het thema nog steeds onder de 700 ms blijft. Opmerking: de afbeeldingen in deze demo zijn volledig gecomprimeerd, maar de thema ontwikkelaars kozen vanaf het begin voor zeer hoge resolutie.

 Het is belangrijk om de verschillen tussen de snelheidstesten van deze 3 thema’s met een korrel zout te nemen. Het probleem is dat het bijna onmogelijk is om een nauwkeurige vergelijking naast elkaar uit te voeren. Het belangrijkste dat we je wilden laten zien, is dat al deze WordPress-thema’s razendsnel zijn, zowel nieuw uit de doos en volledige demo’s! 🚀

Waarschuwing over page builders

Zoals je waarschijnlijk hebt opgemerkt, vereisen OceanWP en Astra beide page builders om hun thema’s in de bibliotheek te gebruiken. Hier zijn een paar dingen om rekening mee te houden wanneer je een page builder plugin gebruikt:

• Sommige page builders kunnen de laadtijd op je site verhogen. Dit komt omdat ze extra CSS en JS moeten laden om ervoor te zorgen dat dingen zonder code voor je werken. Dat is hoe de magie werkt! Wij raden altijd aan om jouw WordPress site voor en na het installeren van een page builder te testen.
• Wanneer je kiest voor een page builder, wijd je jezelf aan het design dat mogelijk is met die page builder. Zorg ervoor dat je er een uitkiest die regelmatig wordt bijgewerkt en alles heeft wat je nodig hebt voor de lange termijn.

Dat gezegd hebbende, zijn wij nog steeds grote fans van page builders zoals Elementor en Beaver Builder. Voor het grootste deel zijn ze ontwikkeld met het oog op prestaties en voegen ze slechts een klein beetje overhead toe. Voor de meesten zijn de functionaliteit en bruikbaarheid de moeite waard. Deze plugins laten je alles maken wat je maar kunt bedenken! Ze kunnen in sommige gevallen ook sneller zijn, omdat ze mogelijk een vervanging zijn voor meer dan 5 andere plugins die anders gebruikt zouden zijn.

Als je geen page builder plugin nodig hebt, installeer er dan ook geen een. Ook niet voor de kick. Het gaat ook interessant zijn om te zien hoe de nieuwe Gutenberg editor de komende jaren een rol zal spelen in het ontwerpen van een website.

De feiten over WordPress plugins

Nu de scoop over WordPress plugins. Je hebt misschien wel eens gehoord dat je niet te veel plugins moet installeren omdat het je WordPress site zou vertragen. Ondanks dat dit soms waar is, is het niet de meest kritische factor. Het aantal plugins is niet zo belangrijk als de kwaliteit van de plugins. Zo, dat hebben we gezegd. 😜

Net als bij thema’s, maakt het uit hoe de plugin is ontwikkeld en of deze is gebouwd met prestaties in het vizier. We hebben veel klanten bij Kinsta die 30 tot 40 plugins draaien en hun sites nog steeds ruim onder een seconde laden.

Hoewel het leuk is om code toe te voegen aan je site, is dit om de volgende redenen niet altijd praktisch:

1. Je moet de code zelf onderhouden terwijl de standaarden veranderen. Waarom zou je niet vertrouwen op de fantastische ontwikkelaars die de standaarden als geen ander kennen?
2. Meestal zal een goed gecodeerde plugin niet veel meer overhead hebben dan de code zelf.
3. Onthoud dat een meerderheid van de WordPress community niet zo geraffineerd is als ontwikkelaars. Plugins zijn oplossingen die helpen bij het oplossen van problemen.

Met dat gezegd hebbende, zijn er natuurlijk ook minder goede plugins die je niet wilt gebruiken. Geloof ons; we hebben het ergste van het ergste gezien bij Kinsta. Veel, maar niet alle plugins die we bij Kinsta verbieden veroorzaken problemen met prestatie.

Francesco heeft een interessant artikel waarin hij WordPress plugins test om te zien hoe ze presteren op de back-end van een WordPress site, die in de meeste gevallen niet gecached wordt. We zullen hieronder ingaan op het vinden van slechte plugins op jouw website.

We kunnen niet om het feit heen dat de enorme bibliotheek aan plugins een van de grote redenen is waarom mensen van WordPress houden. Maar met de 56.000+ gratis plugins die vermeld staan op WordPress.org alleen en duizenden meer elders, kan het moeilijk zijn om die ene plugin te vinden die je nodig hebt. Een naald in een hooiberg zoeken! Bekijk de lijst die wij hebben samengesteld met alleen de beste WordPress plugins die beschikbaar zijn.

We proberen alleen dingen te delen die wij ook dagelijks gebruiken. En ja, we gebruiken WordPress-plugins op onze site net als de rest van jullie. Veel teamleden bij Kinsta ontwikkelen en verkopen zelfs plugins.

Een groot probleem met WordPress plugins

Een groot probleem met WordPress plugins is het verwijderingsproces. Wanneer je een WordPress plugin of thema installeert, worden gegevens in de database opgeslagen. Het probleem is dat wanneer je een plugin weer verwijdert met behulp van een van de standaardmethoden, dit meestal tabellen en rijen in jouw database achterlaat. In de loop van de tijd kan dit tot heel wat extra gegevens leiden en zelfs je site te vertragen. In ons voorbeeld hebben we de Wordfence Security plugin verwijderd en deze heeft 24 tabellen in onze database achtergelaten (zoals hieronder te zien). Het is nog erger als ze achter data in de tabel wp_options staan.

Naast de database laten veel plugins ook extra mappen en bestanden achter. Onze ervaring is dat dit vaak gebeurt met beveiligings- en caching-plugins die extra mappen creëren voor bijvoorbeeld logboeken. Nadat de plugin voor WordFence was verwijderd, hadden we nog de map “wflogs” in onze wp-content directory. Dit gebeurt niet enkel met Wordfence, de meeste plugins en thema’s op de markt werken op deze manier.

Waarom doen ontwikkelaars dit?

Je vraagt je waarschijnlijk af, waarom hebben ontwikkelaars geen opruim methodes hebben wanneer je een plugin deactiveert en verwijdert? Deze zijn er wel. Maar hier zijn een aantal redenen waarom ze dit waarschijnlijk niet zo zomaar doen.

1. Ze willen de instellingen voor de gebruiker behouden. Als je een WordPress plugin verwijdert en besluit deze later opnieuw te installeren, blijven alle instellingen en gegevens aanwezig. Hoewel dit superhandig is, is dit niet de meest efficiënte manier.
2. Ze geven niets om de prestaties. Sommige ontwikkelaars zouden kunnen beweren dat het achterlaten van tabellen geen invloed heeft op de prestaties. Maar stel je een site voor in de loop van tien jaar, nadat je honderden plugins hebt gebruikt die mogelijk duizenden rijen of tabellen hebben gegenereerd. Database query’s hebben een aanzienlijke invloed op de prestaties van jouw WordPress site, en plugins kunnen veel verzoeken doen als de ontwikkelaar niet voorzichtig is. Over het algemeen vraagt een goed geschreven plugin alleen de tabellen of rijen waarop deze is gekoppeld, maar dit is niet altijd het geval. We hebben dit zelf bij Kinsta gezien, lange database query’s die een site moeten laten crawlen vanwege onnodige geladen gegevens in de wp_options tabel.
3. Ze hebben een fout gemaakt.. Het WordPress plugin handboek zegt zelfs dat “minder ervaren ontwikkelaars soms de fout maken om de deactiverings hook voor dit doel te gebruiken.”

Het goede nieuws? Er zijn altijd manieren op een plugin op de juiste manier te deactiveren en te verwijderen. 👏 Lees hiervoor onze onderstaande handleidingen:

• Hoe verwijder je een WordPress plugin (De juiste manier)
• Hoe ruim je handmatig overgebleven tabellen op

Optimale WordPress instellingen

We gaan verder met de optimale WordPress instellingen. Hier zijn een paar wijzigingen die je kunt aanbrengen om jouw WordPress site sneller te maken. Veel van deze aanpassingen zijn zeer subtiele veranderingen, maar alles helpt!

Wijzig Jouw WordPress Login URL

Standaard is de Login URL van jouw WordPress website jouwdomein.nl/wp-admin/. Een van de problemen hiermee is dat alle bots, hackers en scripts die er zijn, dit ook weten. Door de URL te wijzigen, Kan je jezelf een minder groot doelwit maken, jezelf beter beschermen tegen brute force-aanvallen en de bandbreedte verminderen die wordt verbruikt door de bots die deze URL herhaaldelijk benaderen.

Het wijzigen van je WordPress login URL kan ook helpen veelvoorkomende fouten zoals de “429 Te veel verzoeken” te voorkomen. Dit is niet de oplossing voor alle oplossingen, het is maar een kleine truc die je kan helpen beschermen en de belasting op die pagina kan verminderen.

Om uw login URL voor WordPress te wijzigen, raden wij aan een van de volgende plugins te gebruiken:

• WPS Hide Login (gratis)
• Perfmatters (premium, maar bevat ook andere instellingen voor prestatie optimalisatie en is ontwikkeld door een teamlid van Kinsta)

Bewerk of deactiveer plugin- en thema-updates

Trage WordPress dashboards kunnen worden beïnvloed door het netwerk, de datacenter locatie en zelfs door PHP versies. Maar een andere factor waar niet veel mensen het over hebben, zijn de WordPress update controles die op de achtergrond wordt uitgevoerd. Dit is kan je snelheid schaden als je veel WordPress plugins en -thema’s hebt. WeFoster heeft hierover een geweldige blogpost waarin ze de zin ““Third Party Plugin Update Check Syndrome“” of TPPUCS gebruiken.

Het probleem is dat de ingebouwde WordPress update controle achter de schermen een extern GET-verzoek indient (https://third-party-plugin/update-check.php). Soms is dit periodiek, maar het kan ook heel vaak voorkomen. Als dit de hele tijd gebeurt, kan je dashboard hierdoor langzaam worden.

Dit is meer een probleem van hoe de update checker in WordPress is gebouwd. Als je last hebt van de trage laadtijden van het WordPress dashboard kun je dit proberen. De oplossing is automatische updates uit te schakelen. Waarschuwing: doe dit alleen als je handmatig updates wilt controleren. Veel updates bevatten namelijk beveiliging en bugfixes.

Om automatische updates uit te schakelen raden wij de volgende plugins aan:

• Disable All WordPress Updates: volledig gratis zonder instellingen. Doet precies wat de plugin zegt.
• Easy Updates Manager: geeft een betere controle over selectieve updates. Er is zowel en gratis als premium versie.

Je kunt eenvoudig zelf een herinnering instellen, de plugin één keer per week uitschakelen, controleren op updates en vervolgens weer inschakelen.

Schakel pingbacks uit

Een pingback is een geautomatiseerde reactie die wordt gemaakt wanneer een andere blog naar jou linkt. Er kunnen ook self-pingbacks zijn die worden gemaakt wanneer je naar een artikel in jouw eigen blog linkt.

We raden je aan deze gewoon uit te schakelen omdat ze waardeloze zoekopdrachten en extra spam genereren op jouw website. Vergeet niet dat hoe minder verzoeken jouw WordPress website hoeft te doen, hoe beter het is – vooral op sites met veel verkeer. Om nog maar te zwijgen over het feit dat een pingback op je eigen website gewoon ronduit vervelend is. Volg de onderstaande stappen om pingbacks uit te schakelen.

Stap 1 — Schakel pingbacks van andere blogs uit

Klik in je WordPress dashboard op ‘Instellingen → Discussie’. Schakel in het gedeelte ‘Reactie instellingen’ de optie ‘Sta linkmeldingen van andere blogs (pingbacks en trackbacks) op nieuwe berichten toe’ uit.

Stap 2 — Schakel self-pingbacks uit

Als het gaat om het uitschakelen van self-pingbacks, heb je een aantal opties. Je kunt de gratis plugin No Self Pings plugin gebruiken. Of je gebruikt een premium plugin zoals Perfmatters.

Je kunt ook self-pingbacks uitschakelen door de volgende code toe te voegen aan het functions.php-bestand van je WordPress-thema. Waarschuwing, het bewerken van de bron van een WordPress-thema kan je site kapot maken als dit niet goed wordt gedaan. Tip, je kunt eenvoudig PHP-fragmenten zoals deze toevoegen met de gratis plugin Code Snippets plugin. Dit betekent dat je nooit je thema hoeft te bewerken.

function wpsites_disable_self_pingbacks( &$links ) {
  foreach ( $links as $l => $link )
        if ( 0 === strpos( $link, get_option( 'home' ) ) )
            unset($links[$l]);
}

add_action( 'pre_ping', 'wpsites_disable_self_pingbacks' );

Beperk het aantal berichten in jouw blog feed

Of je blogfeed nu is ingesteld als de startpagina of als een andere pagina van jouw site, je hebt geen 50 thumbnails nodig die allemaal tegelijk worden geladen. Voor blogs met veel verkeer is de startpagina de belangrijkste pagina van de site. Je wilt dat deze snel wordt geladen. Hoe minder aanvragen en media, hoe beter de prestaties.

Dit is ook precies waarom paginering is uitgevonden (zoals hieronder te zien). Paginering is wat je ziet aan het einde van blog feeds waarmee je naar de volgende pagina kunt bladeren. Dit zijn meestal getallen, of ze gebruiken “volgende / vorige”. Jouw WordPress thema heeft hoogstwaarschijnlijk al ingebouwde paginering.

WordPress stelt standaard het limiet voor nieuwe WordPress installaties in op 10 berichten, maar we hebben dit zo vaak veranderd gezien dat we de tel zijn kwijtgeraakt. Controleer dus zeker welke waarde jij gebruikt. We raden aan ergens tussen 8 en 12 te houden. Mocht je nieuwsgierig zijn, wij gebruiken er 12 op onze Kinsta-startpagina.

Je vindt deze optie in het WordPress dashboard onder “Instellingen → Lezen.” Je kunt daar de waarde wijzigen voor “Site-pagina’s tonen maximaal”.

Waarom caching zo belangrijk is

Caching is verreweg een van de invloedrijke en gemakkelijkste manieren om een WordPress website te versnellen! Maar voordat we je laten zien hoe je caching gebruikt, is het essentieel eerst te begrijpen hoe het werkt en welke verschillende soorten caching er beschikbaar zijn.

Wat is caching?

Kort gezegd: elke webpagina die op de WordPress site wordt bezocht, vereist een verzoek aan de server, verwerking door die server (inclusief database queries) en vervolgens een eindresultaat dat van de server naar de browser van de gebruiker wordt verzonden. Het resultaat is: jouw website, compleet met alle bestanden en elementen waardoor het er uitziet zoals het hoort.

Je hebt bijvoorbeeld een koptekst, afbeeldingen, een menu en een blog. Omdat de server al deze verzoeken moet verwerken, duurt het even voordat de volledige webpagina aan de gebruiker is geleverd, vooral bij complexe of grotere websites.

Dat is waar een WordPress caching plugin om de hoek komt kijken! Caching geeft de server opdracht om bestanden op schijf of RAM op te slaan, afhankelijk van de configuratie. Daardoor kan het dezelfde inhoud onthouden die in het verleden gebruikt is. Kortom, het vermindert de hoeveelheid werk die nodig is om een paginaweergave te genereren. Als gevolg hiervan worden de webpagina’s veel sneller geladen, rechtstreeks vanuit de cache.

Enkele andere voordelen van caching zijn onder anderen:

• De server verbruikt minder resources – dit houdt verband met de snelheid, omdat minder resources zorgen voor een snellere site. Het legt echter ook minder belasting op je server. Dit is erg belangrijk als het gaat om zeer dynamische sites, zoals bijvoorbeeld sites met leden, en om te bepalen wat je wel en niet wilt serveren vanuit de cache.
• Je zult een lagere TTFB zien – Caching is een van de makkelijkste manieren om de TTFB te verlagen. Het is zelfs zo dat in onze testen caching de TTFB met tot wel 90% vermindert!

Verschillende soorten caching

Wanneer het aankomt op de soorten caching, wordt er over het algemeen gebruik gemaakt van twee verschillende types:

1. Caching op serverniveau
2. Caching door middel van een plugin

1. Caching op serverniveau

Caching op serverniveau is veruit een van de gemakkelijkste benaderingen voor de eindgebruiker. Dit betekent dat de WordPress hosting provider het voor je afhandelt. Bij Kinsta gebruiken we de volgende vier soorten cache, die allemaal automatisch op software- of serverniveau worden uitgevoerd:

• Bytecode cache
• Object cache
• Page cache
• CDN cache

Dit betekent dat jij je geen zorgen hoeft te maken over gepruts met ingewikkelde en verwarrende caching plugins. Je kunt stoppen met Googlen voor de “beste cacheplugins” en focussen op productievere taken. 👏

An instant 37% reduction in the loading time after moving @WPColt to @kinsta! (NO CACHING PLUGINS) 🚀🚀🚀

— WPColt (@WPColt) January 3, 2018

De pagina cache is zo geconfigureerd dat hij direct werkt met een standaard WordPress. Je hoeft niets te doen! Begin simpelweg je WordPress site en pagina caching staat aan.

We hebben ook caching regels voor e-commerce sites zoals WooCommerce en Easy Digital Downloads. Standaard zijn er bepaalde pagina’s die nooit in de cache moeten worden opgeslagen, zoals de winkelwagen, mijn account en afrekenen. Deze worden automatisch uitgesloten van de cache. Gebruikers omzeilen namelijk automatisch de cache wanneer de woocommerce_items_in_cart cookie of edd_items_in_cart cookies gedetecteerd om een soepel en gesynchroniseerd afrekenproces te garanderen.

Je kunt de cache van jouw WordPress site  eenvoudig op elk gewenst moment legen via de WP-Admin werkbalk.

Dit is ook geïntegreerd in ons MyKinsta dashboard. Klik op “Tools” en klik daarna op “Website-cache legen”.

2. Caching via een Plugin

Als jouw hosting provider geen caching biedt, kun je een WordPress cache plugin van een externe partij gebruiken. Op basis van onze ervaring raden we een van de volgende aan:

1. WP Rocket (Premium)
2. Cache Enabler (Gratis)
3. W3 Total Cache (Gratis)

Je kunt ook enkele extra opties bekijken in ons uitgebreide artikel over plugins voor WordPress.

We ondersteunen WP Rocket ook volledig bij Kinsta! Meestal staan we caching plugins niet toe in onze omgeving omdat deze in strijd zijn met onze ingebouwde caching oplossing. Met ingang van WP Rocket 3.0 wordt de functionaliteit voor het in cachegeheugen opslaan van hun pagina’s automatisch uitgeschakeld als ze op Kinsta-servers worden uitgevoerd.

Hierdoor kunnen Kinsta-klanten onze snelle caching op serverniveau gebruiken en tegelijk nog steeds profiteren van de fantastische optimalisatie functies die WP Rocket te bieden heeft.

Geen caching versus caching

Hoeveel helpt caching? Dat kom je het best te weten wanneer je het ervaart.

We hebben enkele snelheidstests uitgevoerd met Kinsta’s caching op serverniveau, zodat je het verschil kunt zien, zowel in termen van algehele snelheid als de TTFB.

Geen caching

We hebben 5 testen uitgevoerd met Pingdom zonder caching ingeschakeld, daarvan hebben we het gemiddelde genomen.

TTFB zonder caching

Het is ook belangrijk om het verschil in TTFB op te merken zonder en met caching. TTFB in Pingdom wordt weergegeven door de gele “Wait” balk. Zoals je kunt zien is de TTFB zonder caching 192 ms. Je kunt zien dat het niet vanuit de cache wordt weergegeven, aangezien de header x-kinsta-cache-cache een MISS weergeeft.

Caching ingeschakeld

Daarna hebben we de caching op serverniveau weer ingeschakeld heb hebben 5 testen uitgevoerd op Pingdom. Van deze testen namen we weer het gemiddelde.

Zoals je kunt zien nam de laadtijd van onze pagina met 33,77% af met caching op serverniveau! Dat is zonder extra werk. Deze website die we hebben getest, is al redelijk geoptimaliseerd, dus grotere niet-geoptimaliseerde sites zullen waarschijnlijk nog grotere verschillen zien.

TTFB met caching ingeschakeld

Als we nu kijken naar de TTFB terwijl caching is ingeschakeld, kunnen we zien dat het minder dan 35 ms is. Je kunt zien dat het vanuit de cache geserveerd wordt, omdat de x-kinsta-cache header een HIT toont.

De CDN cache is net zo belangrijk als de cache van jouw WordPress host. We kijken hier verder op in het artikel uitgebreid naar.

Problemen met caching en lidmaatschap websites

Lidmaatschap sites bevatten veel niet-cachebare inhoud en pagina’s die voortdurend veranderen. Zaken zoals de inlogpagina voor leden (die constant bezocht kunnen worden afhankelijk van de grootte van de site), afreken pagina’s voor digitale goederen of cursussen, en discussieboards zijn veelvoorkomende boosdoeners en pijnpunten, omdat deze meestal niet in de cache kunnen worden opgenomen.

Daar eindigt het echter niet. Op standaard WordPress sites staat het WordPress dashboard ook niet in de cache voor “ingelogde” gebruikers. Dit is prima als je slechts een paar auteurs en beheerders hebt, maar wanneer je plotseling duizenden leden hebt die het dashboard gebruiken, veroorzaakt dit onmiddellijk prestatieproblemen. Dit betekent dat je achter de schermen de kracht en architectuur nodig hebt om een back-up te maken. Shared hosting providers verlammen meestal onder deze omstandigheden.

Object caching voor extreem dynamische websites

Als het gaat om WordPress lidmaatschap sites zijn de gebruikelijke caching-instellingen meestal niet genoeg omdat ze er niet altijd optimaal gebruik van maken. Dit is waar object caching aan bod komt.

Object cache slaat de resultaten van database query’s op zodat de volgende keer dat die specifieke data nodig is, het uit de cache kan worden afgeleverd zonder de database te hoeven raadplegen. Dit versnelt PHP uitvoer tijden en vermindert de belasting op jouw database. Dit wordt uiterst belangrijk met lidmaatschap sites! In WordPress kan je objectcaching op verschillende manieren implementeren:

1. Een externe caching-oplossing zoals W3 Total Cache
2. Redis (aanbevolen)
3. Memcached

Bij Kinsta bieden we Redis aan als add-on. Op deze manier kun je volledig gebruik maken van object caching op jouw lidmaatschap websites.

Cache analyse

Weet je nog die x-kinsta-cache header die we hierboven noemden? Afhankelijk van jouw hosting provider of caching oplossing kan de header iets anders worden genoemd. Telkens wanneer er vanuit de WordPress site een verzoek wordt ingediend, heeft de header een waarde, Bijvoorbeeld: HIT, BYPASS, MISS en EXPIRED. Hiermee kun je zien hoe jouw cache presteert.

Het verhogen van de cache-hit ratio van de WordPress-site is belangrijk omdat je wilt dat zoveel mogelijk van de site vanuit de cache wordt geserveerd. Bij Kinsta kan je de gegevens analyseren in onze MyKinsta analysetool en de Kinsta cache-logboeken om te bepalen of er cache BYPASSing GET-aanvragen zijn die in de cache kunnen worden geplaatst of POST-aanvragen die kunnen worden geëlimineerd.

Met de stapel met cache-componenten (zoals hieronder weergegeven) kun je de status van elk verzoek zien, of dit nu een HIT, BYPASS, MISS of EXPIRED was. De gegevens kunnen worden gefilterd op: de afgelopen 24 uur, 7 dagen of 30 dagen.

Het cache-component diagram geeft een inzicht in jouw caching-ratio. Hoe meer verzoeken er vanuit cache zijn, hoe beter. Zoals je in het onderstaande voorbeeld kunt zien, heeft deze WordPress site een 96,2% HIT cache-ratio, wat erg goed is!

In de top cache-bypass kan je zien welke aanvragen niet vanuit het cachegeheugen worden aangeboden. Meestal zijn dit cronjobs, admin-ajax aanvragen, e-commerce controlepagina’s, query reeksen,UTM-parameters enzovoort.

Afbeelding optimalisatie is een must

Afbeelding optimalisatie is een ander eenvoudige factor die je kunt uitvoeren en die een aanzienlijke impact heeft op de totale laadtijd van de pagina’s. Dit is niet optioneel; elke site zou dit moeten doen!

Grote afbeeldingen vertragen webpagina’s waardoor een minder dan optimale gebruikerservaring ontstaat. Het optimaliseren van afbeeldingen is het proces van het verkleinen van de bestandsgrootte, met behulp van een plugin of een script, wat op zijn beurt de laadtijd van de pagina versnelt. Lossy en lossless compression zijn twee vaak gebruikte methoden.

Volgens HTTP Archive zijn per november 2019, afbeeldingen sinds augustus 2019 verantwoordelijk voor gemiddeld 34% van het totale gewicht van een webpagina. Dus na video’s, die veel moeilijker te optimaliseren zijn, zijn afbeeldingen verreweg de eerste plek waar je zou moeten beginnen! Het is belangrijker dan JavaScript, CSS en lettertypen. Gek genoeg is een goede workflow voor beeldoptimalisatie een van de gemakkelijkste dingen om te implementeren, maar toch zien veel website-beheerders dit over het hoofd.

Afbeeldingen waren in december 2017 verantwoordelijk voor gemiddeld 54% van het totale gewicht van een pagina. Het lijkt er dus op dat het web als geheel beter wordt van afbeelding optimalisatie! Maar 34% is nog steeds een getal dat niet kan worden genegeerd. Als je geen video-inhoud op je website hebt staan, zijn afbeeldingen waarschijnlijk nog steeds #1 pijnpunt voor het paginagewicht.

Vind de balans (bestandsgrootte en kwaliteit)

Het hoofddoel van het opmaken van de afbeeldingen is om de balans te vinden tussen de laagste bestandsgrootte en de acceptabele kwaliteit. Er is meer dan één manier om bijna al deze optimalisaties uit te voeren. Een van de meest eenvoudige manieren is om ze te comprimeren voordat ze naar WordPress worden geüpload. Meestal kan dit worden gedaan in een tool zoals Adobe Photoshop of Affinity Photo. Of gebruik de nieuwe online Squoosh app van Google. Deze taken kunnen echter ook automatisch worden uitgevoerd door plugins, waar we hieronder meer op ingaan.

De twee belangrijkste dingen om te overwegen zijn het bestandsformaat en het type compressie dat gebruikt wordt. Door de juiste combinatie van bestandsindeling en compressietype te kiezen, kun je jouw afbeeldingsgrootte tot wel 5 keer verkleinen. Je zult moeten experimenteren met elke afbeelding of bestandsindeling om te zien wat het beste werkt.

Voordat je begint met het aanpassen van de afbeeldingen, moet je ervoor zorgen dat het beste bestandstype is gekozen. Er zijn verschillende soorten bestanden die je kunt gebruiken:

• PNG – produceert afbeeldingen van hogere kwaliteit, maar heeft ook een grotere bestandsgrootte. Is gemaakt als een lossless afbeeldingsformaat, hoewel het ook lossy kan zijn.
• JPEG – maakt gebruik van lossy en lossless optimalisatie. Je kunt het kwaliteitsniveau aanpassen om een goede balans tussen kwaliteit en bestandsgrootte te vinden.

Idealiter gebruik je JPEG (of JPG) voor afbeeldingen met veel kleur en PNG voor eenvoudige afbeeldingen.

Ook moet je overwegen om WEBP afbeeldingen op je website te gebruiken.

Hoe zit het met GIF’s? Geanimeerde GIF’s zijn altijd leuk, maar ze maken web-prestaties praktisch onmogelijk. Veel GIF’s zijn meer dan 1 MB groot. We raden aan deze te gebruiken voor sociale media en Slack. Als er een is waar je niet zonder kunt in je blogpost, bekijk dan hoe je geanimeerde GIF’s kunt comprimeren.

Compressie kwaliteit versus Grootte

Hieronder staat een voorbeeld van wat kan gebeuren wanneer je een afbeelding te veel comprimeert. De eerste is een zeer lage compressieverhouding, wat resulteert in de hoogste kwaliteit (maar grotere bestandsgrootte). De tweede is het gebruik van een zeer hoge compressieverhouding, wat resulteert in een beeld van zeer lage kwaliteit (maar een kleinere bestandsgrootte). Opmerking: de oorspronkelijke afbeelding is niet gewijzigd en is 2,06 MB.

Zoals je kunt zien is de eerste afbeelding hierboven 590 KB. Dat is groot voor één foto! Het is over het algemeen het beste als je het totale gewicht van een webpagina kleiner dan 1 of 2 MB kunt houden. 590 KB is daar al een vierde van. De tweede afbeelding ziet er vreselijk uit, maar is dan ook maar 68 kB. Wat je wilt doen is een goede balans vinden tussen de compressiesnelheid (kwaliteit) en de bestandsgrootte.

Daarom hebben we de afbeelding opnieuw met een gemiddelde compressieverhouding genomen en zoals u hieronder kunt zien, ziet de kwaliteit er nu goed uit en is de bestandsgrootte 151 KB, wat acceptabel is voor een foto met een hoge resolutie. Dit is bijna 4x kleiner dan de originele foto met lage compressie. We proberen de meeste van onze afbeeldingen rond de 100 KB te houden voor de beste prestaties.

Lossy versus Lossless optimalisatie

Het is ook belangrijk om te begrijpen dat er twee soorten compressie zijn die er gebruikt kunnen worden, lossy en lossless.

Bij Lossy compressie worden sommige gegevens in de afbeelding verwijderd. Dit betekent dat je degradatie kunt zien (kwaliteitsvermindering of wat sommigen pixelated noemen). Dus je moet voorzichtig zijn met hoeveel je de afbeelding verkleint. Niet alleen vanwege de kwaliteit, maar ook omdat je het proces niet kunt terugdraaien. Natuurlijk is een van de grootste voordelen van lossy compressie en de reden het een van de meest populaire compressiemethoden dat de bestandsgrootte aanzienlijk verminderd kan worden.

Lossless compressie, in tegenstelling tot lossy, vermindert de kwaliteit van de afbeelding niet. Hoe is dit mogelijk? Gewoonlijk wordt dit gedaan door onnodige metagegevens te verwijderen (automatisch gegenereerde gegevens die worden geproduceerd door het apparaat dat de afbeelding vastlegt). Het grootste nadeel van deze methode is echter dat je de bestandsgrootte niet aanzienlijk ziet verminderen. Met andere woorden, het zal in de loop van de tijd toch nog veel schijfruimte innemen.

Je zult willen experimenteren met wat het beste werkt. Maar voor de meerderheid van de gebruikers raden we aan om lossy compressie te gebruiken  omdat je een afbeelding gemakkelijk ruim 70% (soms zelfs meer dan 90%!) kunt comprimeren zonder te veel kwaliteitsverlies. Vermenigvuldig dit met 15 afbeeldingen op een pagina en het heeft belangrijke rol in het verminderen van de laadtijd van de site.

Afbeelding compressie plugins

Het goede nieuws is dat er een aantal fantastische WordPress afbeelding compressie plugins zijn die je kunt gebruiken om het gehele proces te automatiseren. Hieronder staan een aantal plugins die wij aanraden:

• Imagify (Lossy en Lossless compressie — optimaliseert afbeeldingen extern)
• WP Smush (Lossy en Lossless compressie — optimaliseert afbeeldingen extern)
• Optimole (Lossy en Lossless compressie — optimaliseert afbeeldingen extern)

Het belangrijkste bij het kiezen van een afbeelding optimalisatie plugin is om er een te gebruiken die beelden extern comprimeert en optimaliseert op hun servers. Dit vermindert de belasting van jouw site. Alle bovenstaande plugins doen dit.

Mocht je nieuwsgierig zijn: wij gebruiken de Imagify plugin op de Kinsta website. Het comprimeert automatisch afbeeldingen wanneer we ze uploaden naar de WordPress mediabibliotheek. We hoeven ons dus nooit zorgen te maken. Na verloop van tijd kun je een idee krijgen van welk compressie niveau je wilt gebruiken. De plugin biedt Normaal, Agressief en Ultra modussen.

Wij gebruiken de Agressieve modus bij Kinsta en zien meestal een  besparing van 60-70% afhankelijk van de afbeelding. Opmerking: we gebruiken veel meer PNG’s dan JPEG’s vanwege het feit dat de meeste van onze afbeeldingen pictogrammen en illustraties zijn, geen foto’s.

Hoeveel sneller zal jouw WordPress site zijn als er beeldcompressie gebruikt wordt? Het hangt allemaal af van de grootte van de originele afbeeldingen en wat ze zijn na compressie. We hebben echter een aantal snelheidstesten uitgevoerd en hebben vastgesteld dat een goede afbeelding compressie de pagina laadtijden met meer dan 80% kan verlagen!

Lazy Loading

Als je veel afbeeldingen hebt, kun je overwegen om deze te Lazy Loaden. Dit is een optimalisatie techniek die zichtbare inhoud laadt, maar het downloaden en weergeven van inhoud die onder de vouw verschijnt, vertraagt.

Bekijk onze handleiding over het implementeren van Lazy Loading. Dit kan vooral belangrijk zijn op blogposts met veel gravatar afbeeldingen in de reacties. Google heeft ook net hun aanbevelingen uitgegeven voor Lazy loading.

Overige afbeelding optimalisatie tips

Hier zijn nog een aantal laatste optimalisatie tips voor afbeeldingen:

• De dagen dat afbeeldingen worden geüpload die alleen de breedte van de kolom of DIV hebben, zijn voorbij.. Responsieve afbeeldingen werken out-of-the-box in WordPress (sinds versie 4.4) en zullen automatisch kleinere beeldformaten weergeven voor mobiele gebruikers.
• SVG’s kunnen een geweldig alternatief zijn voor het gebruik van afbeeldingen. Alle handgetekende illustraties die je op de Kinsta website ziet, zijn SVG’s (vectoren). SVG’s zijn meestal een stuk kleiner in bestandsgrootte, maar niet altijd. Bekijk onze tutorial over het gebruik van SVG’s op jouw WordPress site.
• Gebruik pictogram lettertypen in plaats van tekst in afbeeldingen te plaatsen – ze zien er beter uit als ze worden geschaald en nemen minder ruimte in beslag. En als je een font-generator gebruikt, kan je deze nog verder optimaliseren. Bekijk hoe we de grootte van ons pictogram met pictogram lettertypen met maar liefst 97,59% hebben verkleind met behulp van een font-generator.

Optimaliseer je database

De volgende tips zijn voor het verfijnen van de WordPress database. Net als een auto heeft jouw database onderhoud nodig omdat het na verloop van tijd kan vervuilen.

Lidmaatschap sites maken het vooral lastig, omdat ze meestal complexere query’s genereren, wat op zijn beurt extra latency toevoegt bij het ophalen van de informatie uit de MySQL database. Een groot deel hiervan is te wijten aan alle extra delen en grote hoeveelheden gegevens. Dit kan ook worden veroorzaakt door sites die sterk afhankelijk zijn van zoekopdrachten voor navigatie of sites die vaak WP_Query gebruiken.

Om nog maar te zwijgen over de grote hoeveelheden gelijktijdige gebruikers die continu de database bevragen.

Maak gebruik van de InnoDB MySQL Storage Engine

Veel oudere websites gebruiken nog steeds de MyISAM storage engine in hun database. InnoDB heeft de afgelopen jaren bewezen beter te presteren en betrouwbaarder te zijn.

Hieronder staan een aantal voordelen van InnoDB ten opzichte van MyISAM:

• InnoDB heeft vergrendeling op rijniveau.
• InnoDB heeft zogeheten referentiële integriteit die betrekking heeft op het ondersteunen van externe sleutels (RDBMS) en relatiebeperkingen, MyISAM niet (DMBS).
• InnoDB ondersteunt transacties, wat betekent dat je kunt binden en terugdraaien. MyISAM doet dat niet.
• InnoDB is more reliable as it uses transactional logs for auto recovery. MyISAM does not.

Nu vraag je je misschien af, gebruik je InnoDB of MyISAM? Als je op een vrij nieuwe WordPress site werkt, is de kans groot dat er al gebruik gemaakt wordt van de InnoDB MySQL storage engine. Maar met oudere WordPress sites wil je misschien een snelle controle doen. Sommige sites hebben zelfs gemixte MyISAM- en InnoDB-tabellen, waarin je dus verbeteringen kunt zien door ze allemaal om te zetten naar InnoDB.

Volg deze eenvoudige stappen hieronder om te controleren welke engine gebruikt wordt.

Stap 1

Log in op phpMyAdmin en klik op jouw MySQL database.

Stap 2

Doe een snelle scan of sorteer op het “Type” kolom. Nu kun je zien welke Storage Engine de tabellen gebruiken. In het voorbeeld hieronder kun je zien dat 2 tabellen nog steeds MyISAM gebruiken.

Verwijder en beperk pagina en post revisies

Telkens wanneer je een pagina of bericht opslaat in WordPress, wordt er een zogenaamde revisie gemaakt. Dit gebeurt voor zowel concepten als reeds gepubliceerde berichten die worden bijgewerkt. WordPress revisies kunnen nuttig zijn voor het geval dat je moet terugkeren naar een vorige versie van de inhoud.

Revisies kunnen echter ook de prestaties van jouw WordPress site schaden. Op grote sites kan dit al snel oplopen tot duizenden rijen in de database die niet perse nodig zijn. En hoe meer rijen je hebt, hoe groter de database in omvang, die opslagruimte in beslag neemt. Hoewel er voor dit doel indexen zijn gemaakt, hebben wij door deze kwestie nog steeds verlamde WordPress sites gezien. Er zijn een aantal dingen die je kunt doen.

1. Verwijder oude revisies

Als je een oudere WordPress site hebt met veel pagina’s en berichten, is het misschien tijd om snel iets op te ruimen en die oude revisies te verwijderen. Dit kan gemakkelijk gedaan worden met MySQL, maar met zoveel slechte codefragmenten op het web raden we aan om een back-up van je site te maken en een gratis plugin zoals WP-Sweep te gebruiken..

Een andere favoriete plugin van ons is WP Rocket, Deze heeft ook een database-optimalisatie functie om revisies op te ruimen.

Als je handig bent met WP-CLI, zijn er een paar commando’s die je hiervoor kunt gebruiken.

Meld je aan bij de server via SSH en voer de volgende opdracht uit om het aantal revisies te bekijken dat momenteel in de database aanwezig is.

wp revisions list

Als je een foutmelding krijgt, moet je wellicht eerst het pakket wp-revisions-cli installeren met de volgende opdracht:

wp package install trepmal/wp-revisions-cli

Je kunt daarna het volgende commando draaien om de revisies op te ruimen:

wp revisions clean

2. Beperk de revisies

Een andere goede strategie en een strategie die we bij Kinsta gebruiken, is om het aantal revisies dat per bericht of pagina kan worden opgeslagen, te beperken. Zelfs als je het op iets als tien zet, blijven revisies niet uit de hand lopen, vooral als je veel bijwerkt.

Om revisies te beperken, kun je de volgende code toevoegen aan het wp-config.php bestand. De onderstaande code moet worden ingevoegd boven het ‘ABSPATH’ anders werkt het niet. Je kunt het aantal wijzigen in hoeveel revisies je in de database wilt bewaren.

define('WP_POST_REVISIONS', 10);

Je kunt ook gebruik maken van een plugin als Perfmatters om revisies te beperken.

3. Schakel revisies uit

Ten slotte kun je ook revisies op de site helemaal uitschakelen. Als je deze route volgt, raden we ten zeerste aan de eerste optie hierboven te volgen om revisies te verwijderen en daarna uit te schakelen. Op deze manier is je database volledig vrij van alle oude revisies en zullen er geen nieuwe worden toegevoegd in de toekomst.

Om revisies uit te schakelen, kan je de volgende code toevoegen aan het wp-config.php bestand.

De onderstaande code moet worden ingevoegd boven het ‘ABSPATH’ anders werkt het niet.

define('WP_POST_REVISIONS', false);

Of je kunt gebruik maken van een plugin als Perfmatters om revisies uit te schakelen.

Ruim jouw wp-options tabel en autoloaded data op

De tabel wp_options wordt vaak over het hoofd gezien als het gaat om algemene WordPress en database prestaties. Vooral op oudere en grote sites kan dit gemakkelijk de boosdoener zijn voor langzame zoekopdrachten op de site vanwege automatisch geladen gegevens die zijn achtergelaten door plugins en thema’s van derden. Geloof ons – we zien dit elke dag!

De tabel wp_options bevat allerlei gegevens voor de WordPress site, zoals:

• Website URL, persoonlijke URL, admin e-mail, standaardcategorie, berichten per pagina, tijdnotatie, enzovoort
• Instellingen voor plugins, thema’s en widgets
• Tijdelijk in cache opgeslagen gegevens

Deze tabel bevat de volgende velden (kolommen)

• option_id
• option_name
• option_value
• autoload (Dit is de kolom waarom het gaat m.b.t. prestaties)

Een van de belangrijke aspecten van wp_options om grip op te krijgen, is het veld autoload. Dit veld bevat ja of een geen waarde (vlag). Dit bepaalt in feite of het al dan niet wordt geladen door de functie wp_load_alloptions(). Autoloaded data is data die op elke pagina van de WordPress site wordt geladen. Net zoals we je hebben laten zien hoe je bepaalde scripts site breed uitschakelt is hetzelfde idee hier van toepassing. Het autoload attribuut is standaard ingesteld op “ja” voor ontwikkelaars, maar niet elke plugin zou hun gegevens op elke pagina moeten laden.

Het probleem waar WordPress sites tegenaan kunnen lopen, is wanneer er een groot aantal automatisch geladen gegevens in de tabel wp_options staat. Dit is meestal een gevolg van het volgende:

• Gegevens worden automatisch geladen door een plugin wanneer deze moet worden ingesteld op “Nee”. Een goed voorbeeld hiervan is een plugin voor contactformulieren. Moet het gegevens laden op elke pagina of alleen op de contactpagina?
• Plugins of thema’s zijn verwijderd van de WordPress-site, maar hun opties worden nog steeds achtergelaten in de tabel wp_options. Dit kan betekenen dat onnodige automatisch geladen gegevens tijdens elke aanvraag worden opgevraagd.
• Plugin- en thema-ontwikkelaars laden gegevens in de tabel wp_options in plaats van hun eigen tabellen te gebruiken. Er zijn argumenten voor beide kanten, omdat sommige ontwikkelaars de voorkeur geven aan plugins die geen extra tabellen maken. De tabel wp_options is echter ook niet ontworpen om duizenden rijen te bevatten.

Hoeveel zijn te veel automatisch geladen gegevens? Dit kan natuurlijk variëren, maar idealiter wil je dat dit tussen de 300 KB en 1 MB is. Zodra je het bereik van 3-5 MB of meer begint te benaderen, zijn er waarschijnlijk dingen die kunnen worden geoptimaliseerd of die automatisch kunnen worden verwijderd. En alles boven de 10 MB moet meteen worden aangepakt. Dit betekent niet altijd dat het een probleem veroorzaakt, maar het is een goede plek om te beginnen.

Omdat dit zo’n probleem is, hebben we een heel afzonderlijke artikel dat je kunt lezen over hoe je het best problemen kunt oplossen met automatisch geladen gegevens en hoe je deze kunt opruimen.

Ruim tijdelijke data op

Tenzij je gebruik maakt van een object cache, slaat WordPress tijdelijke records op in de tabel wp_options. Meestal krijgen deze een vervaltijd en zouden ze na verloop van tijd verwijderd moeten worden. Dat is echter niet altijd het geval. We hebben enkele databases gezien met duizenden oude tijdelijke records. In feite hebben we op één site enkele corrupte tijdelijke records behandeld waarin meer dan 695.000 records werden gegenereerd in de tabel wp_options. Yikes!

Het is ook belangrijk om op te merken dat tijdelijke records niet standaard automatisch worden geladen. Je kunt de onderstaande query gebruiken om te zien of er tijdelijke gegevens zijn die automatisch worden geladen.

SELECT * 
FROM `wp_options` 
WHERE `autoload` = 'yes'
AND `option_name` LIKE '%transient%'

Een betere en veiligere optie zou zijn om een gratis plugin zoals Transient Cleaner of Delete Expired Transients te gebruiken. Deze kunnen de verlopen tijdelijke records uit jouw wp_options tabel opschonen. Het lijkt er echter op dat er nu een functie in WordPress, is toegevoegd (Versie 4.9), die tijdelijke records verwijdert. Hopelijk gebeurt dat nu dus al automatisch op jouw site.

WP Rocket heeft ook de mogelijkheid in hun opties om tijdelijke records op te schonen voor database optimalisatie.

Ruim je WordPress sessies op

Een ander veelvoorkomend probleem dat we hebben gezien, is dat cron-taken soms niet synchroon lopen of niet juist worden geactiveerd en dat sessies daarom niet worden opgeruimd. Je kunt hierdoor een enorme hoeveelheid _wp_session_ rijen in je database krijgen. In dit onderstaande voorbeeld heeft de betreffende site meer dan 3 miljoen rijen in de tabel wp_optionsen is de tabel groter dan 600MB geworden.

Je zou een onderstaande query kunnen gebruiken om te zien of jij dit probleem ook hebt:

SELECT *
FROM `wp_options`
WHERE `option_name` LIKE '_wp_session_%'

In de meeste gevallen kan je deze veilig verwijderen (zoals een cron-taak gedaan zou moeten hebben) met de volgende opdracht:

DELETE FROM `wp_options`
WHERE `option_name` LIKE '_wp_session_%'

Na het opschonen van de _wp_session_ rows rijen had de tabel minder dan 1000 records en was gereduceerd tot een grootte van 11 MB.

Dit loste ook het probleem met pieken in de MySQL op.

Voeg een index toe aan Autoload

Als het opschonen van je wp_options tabel niet genoeg was, kun je proberen een “index” aan het veld autoload toe te voegen. Dit kan helpen om efficiënter te zoeken. Het geweldige team bij 10up voerde enkele testscenario’s uit op een wp_options tabel met een typisch aantal automatisch geladen records om te laten zien hoe het toevoegen van een autoload index aan wp_options query’s de prestaties kan verbeteren.

We raden ook aan om deze twee extra bronnen van WP Bullet te bekijken:

• Hoe voeg je een MySQL index toe aan de wp_options tabel
• Opschonen van de wp_options tabel met WP-CLI

Gebruik Redis als een permanente object cache voor WordPress

Redis is een open-source geheugen datastructuur archief. In de context van WordPress kan Redis worden gebruikt om de waarden die worden gegenereerd door de WordPress’ native object cache van WordPress permanent op te slaan. Zo kunnen de objecten in de cache opnieuw gebruikt worden tijdens het laden van de pagina.

Het gebruik van een permanente object cache zoals Redis zorgt voor het  hergebruik van objecten in de cache, zodat de MySQL database voor hetzelfde object geen tweede keer hoeft worden geraadpleegd. Het resultaat is dat Redis de belasting van de MySQL database van een website kan verminderen en tegelijkertijd de reactietijd van de site kan verkorten. Hierdoor wordt het vermogen van de site om te schalen en extra verkeer af te handelen vergroot.

Zeer dynamische websites (WooCommerce, lidmaatschap sites, forums, discussieforums, blogs met extreem actieve reactiesystemen) die niet optimaal gebruik kunnen maken van pagina caching zijn potentiële kandidaten voor de aanhoudende object cache, zoals Redis.

Als je klant bij Kinsta bent, bieden we een Redis-add-on. Bekijk hoe je Redis aan jouw hostingpakket kunt toevoegen.

Gebruik Elasticsearch om zoekopdrachten op WordPress te versnellen

Elasticsearch is een open-source full-text zoekmachine. Het wordt gebruikt om gegevens te indexeren en ongelofelijk snel in die gegevens te zoeken.

In de context van WordPress kan Elasticsearch worden gebruikt om vragen aan de WordPress database te versnellen. Dit wordt gedaan door een index van de inhoud van de database van jouw site te bouwen en vervolgens Elasticsearch te gebruiken om veel sneller in deze index te zoeken dan met een MySQL query die dezelfde zoekopdracht uitvoert.

Als je de tijd en mogelijkheden hebt, kan Elasticsearch worden geïntegreerd met een WordPress site door een zeer deskundige WordPress- en Elasticsearch-ontwikkelaar. Als jouw site relatief standaard gebruik maakt van WP_Query, kan Elasticsearch ook worden geïntegreerd door ElasticPress te installeren, een gratis WordPress plugin van 10up, verkrijgbaar op WordPress.org. De plugin integreert automatisch met het WP_Query object te genereren met Elasticsearch in plaats van MySQL.

Elke site die veel gebruik maakt van WP_Query kan profiteren van Elasticsearch. Voorbeelden van sites die kunnen profiteren van Elasticsearch:

• Sites waar zoeken het belangrijkste navigatiemiddel is.
• WooCommerce-sites met een groot aantal bestellingen waarbij sitebeheerders de lijst met bestellingen regelmatig moeten kunnen doorzoeken.
• Elke site met een groot aantal berichten waar MySQL zoekopdrachten onacceptabel trage resultaten produceren.

Schakel niet-kritische database-intensieve features uit

Dit lijkt misschien een beetje voor de hand liggend, maar het kan een wereld van verschil maken als je niet-essentiële plugins en themafuncties uitschakelt die wel erg intensief zijn voor de database.

• Populaire en of verwante bericht widgets en plugins zijn vreselijk. Ze hebben meestal zware website-brede query’s.
• Beeldoptimalisatie plugins die afbeeldingen comprimeren met behulp van jouw server. Gebruik altijd een beeldoptimalisatie plugin die extern afbeeldingen optimaliseert.

Als je de Kinsta blog bezoekt en naar het einde van een bericht scrolt, zul je merken dat we zogenaamde ‘Handgekozen gerelateerde’ artikelen hebben. Deze worden door ons handmatig geselecteerd en toegewezen aan de post. Dit reduceert de zoekopdracht tot bijna niets en doet geen afbreuk aan de prestaties van jouw hele site. Heeft het meer werk nodig? Ja, maar het heeft als extra voordeel dat jij zelf kunt kiezen wat je wilt dat lezers zien.

Hoe hebben we dit bereikt? We hebben de fantastische plugin Advanced Custom Fields gebruikt en vervolgens deze velden toegewezen aan ons blogpost type. Dit stelt ons in staat om elke gerelateerde inhoud die we willen op onze blogposts op te zoeken en toe te wijzen (zoals hieronder te zien).

We raden je ook aan om af te blijven van plugins die een weergave / bericht teller toevoegen aan de site, tenzij je deze absoluut nodig hebt. Vermijd bijvoorbeeld dingen als ‘792 berichten’ naast de avatar van een gebruiker in forumberichten of ‘5,243 weergaven’ bij het posten van forumberichten. Als je een lange discussie hebt, zullen deze tellers een grote tol eisen van je database. Vermijd in het algemeen het gebruik van tellers en gebruik ze alleen als dat nodig is.

Dit geldt ook voor veel social counters. Op deze site hieronder zie je bijvoorbeeld dat de reactietijd van de populaire Social Warfare plugin 30x groter is dan de volgende plugin eronder. Caching is ingeschakeld, maar zelfs dan hakt deze deze plugin een aanzienlijke in de prestatie. Na het uitschakelen van de plugin op de site zijn de laadtijden direct verbeterd en is de reactietijd van het WordPress dashboard verbeterd.

Maak gebruik van een Content Delivery Netwerk (CDN)

CDN is een afkorting voor content delivery netwerk. Dit is een netwerk van servers (ook bekend als POP’s) over de hele wereld. Ze zijn ontworpen om kopieën van de statische (en soms dynamische) inhoud van jouw WordPress site, zoals afbeeldingen, CSS, JavaScript en videostreams, te hosten en af te leveren.

Verwar een CDN niet met je WordPress host! Dit zijn volledig afzonderlijke services. Een CDN is geen vervanging voor de hosting provider, maar eerder een extra manier om de snelheid van jouw website te verhogen. Hoewel onze hosting hier bij Kinsta razendsnel is, kan een CDN jouw site nog sneller maken.

Hoe werkt een CDN

Hoe werkt een CDN precies? Als je bijvoorbeeld jouw website host met Kinsta, moet je een fysieke datacenter locatie, kiezen, zoals de VS, Europa, Azië-Pacific of Zuid-Amerika.

Laten we zeggen dat je US Central kiest. Dit betekent dat de website zich fysiek op een “host server” bevindt in Council Bluffs, Iowa. Wanneer mensen in Europa de website bezoeken, zal het langer duren voordat deze wordt geladen dan voor iemand die hem bezoekt vanuit bijvoorbeeld Dallas, TX.

Waarom is dit? Omdat de gegevens een grotere afstand moeten afleggen. Dit is wat bekend staat als latency. Latency verwijst naar de tijd en of vertraging die betrokken is bij het verzenden van gegevens via een netwerk. Hoe verder de afstand, hoe groter de latency.

CDN Types

Er zijn twee verschillende typen content delivery netwerken

1. Traditionele Pull CDN
2. Reverse Proxy CDN

Traditionele pull CDN’s cachen een kopie van alle inhoud en media, maar een verzoek van de bezoeker wordt nog steeds rechtstreeks aan de hosting provider gedaan. KeyCDN en CDN77 zijn voorbeelden van traditionele CDN’s.

Een reverse proxy CDN is iets anders. Hoewel het nog steeds werkt zoals een CDN, onderschept het alle inkomende verzoeken en fungeert het als een server tussen de client en jouw host. Cloudflare en Sucuri zijn voorbeelden van reverse proxy CDN’s. Dit is een reden waarom je de DNS rechtstreeks naar deze providers moet verwijzen in plaats van naar de host.

Het voordeel van het fungeren als een intermediaire server is dat ze sterke webapplicatie-firewalls kunnen bieden die helpen voorkomen dat schadelijk verkeer ooit jouw WordPress site en / of hosting provider bereiken. Een nadeel hiervan is dat het je website licht vertraagt i.v.m. extra overhead, vergeleken met een traditioneel pull CDN. Maar met extra prestaties en beveiligingsfuncties zou dit als verwaarloosbaar kunnen worden gezien.

Hieronder is een voorbeeld van wat er gebeurde na het inschakelen van Sucuri op de site van een klant. Zoals je kunt zien had dit een enorme impact op de hoeveelheid slecht verkeer die er doorheen kwam. Uiteindelijk kunnen dit soort services helpen te besparen op hosting kosten.

CDN snelheidstesten

Eerder hadden we het over de enorme voordelen van WordPress caching. CDN caching is ook super krachtig. Dit komt omdat CDN’s doorgaans veel meer server locaties hebben dan hosting providers. Dit betekent dat ze alle bedrijfs assets (afbeeldingen, JS, CSS) dichter bij jouw bezoekers kunnen opslaan en ze kunnen aanbieden met hoge snelheden.

Laten we een paar snelle testen uitvoeren om te zien hoeveel sneller jouw site kan zijn met een CDN.

Zonder CDN

Onze test website wordt gehost bij Kinsta en bevindt zich fysiek in het datacenter van Iowa, VS. We hebben eerst vijf snelheidstesten uitgevoerd met Pingdom (zonder dat het CDN was ingeschakeld) en hebben het gemiddelde genomen. Belangrijk: We gebruiken de locatie Europa – Verenigd Koninkrijk – Londen bij Pingdom om de echte kracht van een CDN te demonstreren. De totale laadtijd was 1,03 s.

Met CDN

Vervolgens hebben we de CDN ingeschakeld en vijf extra snelheidstesten uitgevoerd met Pingdom. Onze totale laadtijd is nu 585 ms vanaf de testlocatie Europa – Verenigd Koninkrijk – London met Pingdom. Dus met behulp van de CDN konden we de laadtijd van onze pagina’s met 43,2% verlagen! Dat scheelt heel wat.

De reden voor zo’n drastisch verschil is dat het CDN een data centrum in Londen heeft. Dit betekend dat alle assets gecached worden op deze locatie en klaar staan om geserveerd te worden met minimale latency.

TTFB zonder CDN

Onthoud dat de gele balk in Pingdom staat voor wachttijd, wat de tijd is voor de eerste byte (TTFB). Bij onze snelheidstests zonder dat het CDN aan stond, bedroeg de gemiddelde TTFB op assets ongeveer 98 ms.

TTFB met CDN

Nadat we de CDN hadden ingeschakeld, daalde de gemiddelde TTFB op assets tot gemiddeld 15 ms. Dus met behulp van een CDN daalde onze gemiddelde TTFB met 84,69%. Dit komt voornamelijk omdat de assets rechtstreeks vanuit de cache van de CDN worden aangeboden.

Hoe schakel je een CDN in

Het inschakelen van een CDN op jouw WordPress site hoeft niet moeilijk te zijn, het is zelfs vrij eenvoudig! Volg gewoon deze stappen.

Stap 1

Selecteer een CDN-provider en abonneer je op hun service. Deze worden meestal op maandelijkse basis gefactureerd of gefactureerd op gegevensgebruik. De meeste providers hebben een rekenmodule om de kosten in te schatten.

• Als je zelf op zoek bent naar de implementatie van KeyCDN, raden we aan dit artikel te lezen op CDN voor dummies. Elke CDN-provider zal ook documentatie beschikbaar hebben om je op weg te helpen.
• We hebben een uitgebreid artikel over het installeren van Cloudflare en het installeren van Sucuri.

Stap 2

Als je een traditioneel pull CDN gebruikt, kan je de gratis plugin zoals CDN Enabler, WP Rocket, of Perfmatters gebruiken om te integreren met je WordPress site. Deze plugins koppelen de assets automatisch aan het CDN. Er is geen extra werk nodig van jouw kant om de inhoud op het CDN te krijgen; dit is allemaal vanzelfsprekend! Omgekeerde proxy-CDN’s vereisen meestal geen plugins, hoewel ze er soms wel zijn om extra functies in te schakelen.

Hoe schakel je Kinsta’s CDN in

Spraken de bovenstaande CDN snelheidstesten je aan? Wij gebruikten KeyCDN in die tests. Het goede nieuws is dat ons Kinsta CDN wordt aangedreven door KeyCDN. Het is een HTTP/2 en IPv6-content delivery netwerk met 200+ locaties, om jouw assets en media over de hele wereld te boosten. Momenteel aangesloten regio’s zijn onder meer Amerika, Zuid-Amerika, Europa, Afrika, Azië en Australië.

Als je klant bij Kinsta bent, bieden we gratis CDN bandbreedte aan in al onze hosting pakketten. Je kunt he Kinsta CDN in twee eenvoudige stappen inschakelen.

Stap 1

Log in op jouw MyKinsta dashboard. Klik op jouw site en daarna op de Kinsta CDN tab.

Stap 2

Klik vervolgens op “Kinsta CDN inschakelen”. Na een paar minuten wordt het CDN automatisch geïmplementeerd en worden jouw assets vanuit cache over de hele wereld weergegeven. Meer hoef je niet te doen. 😄

Overige CDN Optimalisaties

Hier zijn nog een paar extra CDN optimalisaties die je misschien wilt bekijken of over wil nadenken.

• Als je veel reacties hebt, kunnen gravatars veel verzoeken genereren. Ze laden vanaf secure.gravatar.com. Bekijk deze tutorial over het secure.gravatar.com. Lees deze tutorial over het laden van gravatars vanaf je CDN. Wij doen dit ook op de Kinsta-website. 👍
• Je kunt jouw aangepaste web-lettertypen hosten vanaf het CDN- of zelfs Google-lettertypen via jouw CDN hosten. Bekijk onze uitgebreide handleiding over lokale lettertypen.
• Zorg ervoor dat je jouw favicon vanaf het CDN laadt. Hoewel het klein is, elk verzoek telt!

Offload media en e-mail wanneer nodig

Alles dat een verzoek genereert, heeft op de een of andere manier invloed op de prestaties van een site. Voor sites met honderdduizenden bestanden of grote media, kan het verstandig zijn dit volledig te offloaden. Offloading is anders dan serveren via een CDN..Bij een CDN bevinden de originele gegevens zich nog altijd bij de host, het CDN heeft er simpelweg meerdere kopieën van.

Wanneer caching is verlopen op de CDN items, wordt jouw host opnieuw gevraagd naar de nieuwste exemplaren van de bestanden. CDN’s zijn bedoeld om bestanden voor langere tijd te cachen, maar vanwege het feit dat ze zoveel POP’s hebben kan dit alsnog veel query’s betekenen.

Wanneer je media of bestanden offload, betekent dit dat je de oorspronkelijke fysieke locatie van de items van de hosting provider verplaatst. Dus hoewel het erop lijkt dat de bestanden vanaf jouw site worden weergegeven, bevinden ze zich echt ergens anders. Naast het verminderen van extra query’s aan de host, is de belangrijkste reden natuurlijk ook om op schijfruimte te besparen.

Offload media naar Amazon S3

Een van de meest populaire offload oplossingen is Amazon S3. Amazon S3 is een opslagoplossing en maakt deel uit van veel producten van de Amazon Web Services. Meestal wordt dit gebruikt voor grote sites die extra backups nodig hebben of grote bestanden serveren (downloads, software, video’s, games, audiobestanden, PDF’s, enz.). Amazon heeft een bewezen staat van dienst als zeer betrouwbaar en vanwege hun enorme infrastructuur kunnen ze zeer lage opslagkosten bieden. Klanten S3 zijn onder meer Netflix, Airbnb, SmugMug, Nasdaq, etc.

Omdat ze volledig gefocust zijn op bulkopslag, kun je er vanuit gaan dat de prijzen goedkoper zijn dan die van jouw WordPress host. Het offloaden van media naar AWS kan een geweldige manier zijn om geld te besparen en is gratis voor het eerste jaar (tot 5 GB opslag). Omdat de aanvragen voor de media rechtstreeks vanuit Amazon worden geserveerd, wordt jouw WordPress site minder belast, wat een snellere laadtijd betekent.

Bekijk ons uitgebreid artikel over hoe je WordPress-media kunt distribueren naar Amazon S3. Je kunt ook een CDN met de offloaded media gebruiken voor het beste van beide werelden.

Offload media naar Google Cloud Storage

Een andere populaire oplossing voor offloading is Google Cloud Storage. Omdat Kinsta wordt aangedreven door het Google Cloud Platform, zijn we grote fans van hun technologie en infrastructuur. Vanwege de enorme infrastructuur van Google en het feit dat ze omgaan met opslag in bulk, kunnen ze zeer lage opslag prijzen bieden. Sommige van hun klanten zijn Spotify, Vimeo, Coca-Cola, Philips, Evernote en Motorola.

Bekijk ons uitgebreid artikel over hoe je WordPress media kan distribueren naar Google Cloud Storage.

Offload transactionele en marketing e-mails

Of je het nu gelooft of niet, e-mails hebben wel degelijk invloed op je server- en server resources. Bij sommige hosts, met name shared hosts, kan misbruik hiervan je zelfs een blokkering opleveren. Dit wordt vooral een probleem als je bulkmails probeert te verzenden. Dit is de reden waarom transactionele e-mailproviders van externe partijen bestaan en waarom veel hosting providers e-mailbezorging op standaardpoorten volledig blokkeren. We raden je nooit aan om je hosting provider te gebruiken voor e-mail.

Als je nieuwsbrieven of bulk-e-mails verzendt, raden we altijd de volgende alternatieven aan voor de beste resultaten:

• Gebruik professionele externe e-mailmarketing software die geen deel uitmaakt van WordPress
• Gebruik ten transactionele e-mailservice provider (HTTP API of SMTP) in combinatie met WordPress

Andere voordelen van het gebruik van een externe service zijn:

• Betere e-mail aflevering. Laat de e-mailproviders doen waar ze het beste in zijn!
• Minder kans om op de blacklist te komen.
• Het is niet altijd mogelijk om DMARC-records in te stellen bij jouw hosting provider.

E-mail marketing hulpmiddelen

Enkele voorbeelden van marketing-e-mails omvatten nieuwsbrieven, aankondigingen van producten en functies, verkoop, uitnodigingen voor evenementen, onboarding herinneringen, enz. Hier zijn enkele e-mailmarketing tools die we aanbevelen:

• MailChimp – Wij gebruiken MailChimp bij Kinsta.
• MailerLite
• Drip

Transactionele e-mail diensten

Enkele voorbeelden van transactionele e-mails zijn aankoopbonnen van WooCommerce of EDD, meldien voor het maken van rekeningen, verzendmeldingen, app-foutmeldingen, wachtwoord herstellen, enzovoort. Als je een Kinsta klant bent, vertrouwen we op een externe SMTP-provider om een hoge aflevering te garanderen. Maar afhankelijk van het volume raden we altijd aan dit off-site te verplaatsen. Hier zijn een paar e-mailservices die we aanbevelen:

• SendGrid – Bij Kinsta gebruiken wij SendGrid.
• Mailgun – Lees hier hoe je Mailgun in WordPress kan configureren.
• SparkPost

Hoe vindt je bottlenecks en langzame plugins?

Nu gaan we dieper in op enkele tips voor het vinden van knelpunten op jouw WordPress site en wat je eraan kunt doen.

Gebruik New Relic om langzame plugins en database queries te identificeren

Er zijn een aantal geweldige tools op de markt die je kunnen helpen bij het lokaliseren en identificeren van langzame database queries en plugins die veel tijd kosten. We zijn grote fans van New Relic bij Kinsta en gebruiken het dagelijks. New Relic is een PHP monitoring tool die je kunt gebruiken om gedetailleerde prestatiestatistieken over jouw website te krijgen.

Als je een Kinsta klant bent, kan je zelfs je eigen New Relic-licentiesleutel toevoegen op het MyKinsta dashboard.

Gebruik New Relic echter voorzichtig, aangezien dit invloed heeft op de prestaties van de site. Het voegt JavaScript toe aan de website. We raden aan om New Relic in te schakelen als je problemen met de prestaties moet oplossen en daarna weer uit te schakelen.

Langzame plugins vinden

Wanneer een WordPress plugin zorgt voor algemene traagheid, variëren de symptomen op basis van de activiteit die de plugin uitvoert. In veel gevallen zal je echter merken dat een langzame plugin van invloed is op elke pagina van een WordPress site. In het geval van de site waarvan je de gegevens in de onderstaande afbeelding ziet, werd algemene traagheid waargenomen op elke front-end pagina van de site. Dit is wat New Relic te zeggen had over de prestaties van de plugins op de site.

Je kunt meteen zien dat de adinjector plugin meer dan 15 keer zoveel tijd verbruikt als de volgende langzaamste plugin.

Wanneer je gegevens zoals deze ziet, kan het verleidelijk zijn om de plugin onmiddellijk te sluiten omdat deze slecht gecodeerd is of op de een of andere manier ineffectief is. Hoewel dit soms het geval is, is dit niet altijd zo. Misconfiguratie van de invoegtoepassing, vertraging van de database of externe bronnen die traag reageren, kunnen ervoor zorgen dat een plugin veel tijd verliest.

Wanneer je een plugin ziet die traag reageert, is het een goed idee om verschillende andere schermen in New Relic te controleren om aanvullende informatie te vinden. De transacties, databases en externe bronnen moeten allemaal worden gecontroleerd voordat wordt besloten dat het deactiveren van de plugin de beste of enige manier is om verder te gaan.

Algemene traagheid veroorzaakt door een overbelaste database

Een slecht geoptimaliseerde database kan algemene traagheid veroorzaken op een WordPress website. Eerder hebben we een heleboel verschillende dingen besproken die je kunt doen om dit op te lossen. In New Relic zal deze database gerelateerde traagheid hoogstwaarschijnlijk op twee plaatsen verschijnen:

• Ten eerste zie je een te grote hoeveelheid MySQL-activiteit in het overzicht.
• Ten tweede zie je een of meer databasetabellen die veel tijd kosten op het database tabblad.

Vanaf het overzichtsscherm ziet een site met een worstelende database er ongeveer zo uit:

Ga naar het tabblad ‘Databases’ voor een betere inzicht in welke databasetabel of -query de oorzaak is.

Het database tabblad wijst naar de tabel en het type query dat de meeste tijd in beslag neemt. Als je een van de items in de lijst selecteert, kan je meer details bekijken, inclusief enkele voorbeeld queries.

In dit geval wijst de data met een vinger naar automatisch geladen gegevens in de tabel wp_options. Vergeet niet dat we dit eerder hebben besproken. Het is duidelijk dat een snelle analyse van de tabel wp_options bevestigt dat deze bijna 250 MB aan gegevens bevat. Hierdoor is deze site een voor de hand liggende kandidaat is voor database onderhoud en -optimalisatie.

Zorg ervoor dat je ons uitgebreid artikel leest over hoe je New Relic kunt gebruiken om prestatieproblemen op je WordPress site te debuggen.

Maak gebruik van de gratis query monitor plugin

Je kunt ook de gratis Query Monitor WordPress plugin gebruiken. Gebruik het om trage database query’s, AJAX calls, REST API aanvragen en nog veel meer te identificeren en debuggen. Bovendien rapporteert de plugin website gegevens zoals afhankelijkheid van scripts, WordPress hooks die zijn geactiveerd bij het genereren van pagina’s, gegevens over de hosting omgeving, voorwaardelijke query-tags die worden opgehaald door de huidige pagina en nog veel meer.

De plugin is ontwikkeld door John Blackbourn, een belangrijke WordPress committer die momenteel een ontwikkelaar is bij Human Made en eerder in dienst was bij WordPress.com VIP — met andere woorden, iemand die WordPress als geen ander kent. Query Monitor is in 2013 aan de WordPress-plugin directory toegevoegd en heeft momenteel meer dan 10.000 actieve installaties – een indrukwekkend aantal voor een ontwikkelaars-plugin. De gebruikerswaardering van de plugin van vijf uit vijf sterren verklaart de populariteit onder ontwikkelaars.

Bekijk onze complete tutorial over het gebruik van Query Monitor.

Maak gebruik van staging sites zonder aan de productie omgeving te komen

We weten niet wat we zouden doen zonder staging omgevingen. Deze zijn van onschatbare waarde als het gaat om het oplossen van prestatieproblemen. Gelukkig heeft Kinsta staging-omgevingen met één klik. Als jouw WordPress host geen staging-omgevingen biedt, kan je ook een plugin zoals WP Staging, gebruiken, hoewel dit niet zo eenvoudig is.

Nadat je een staging-site aan hebt gemaakt, is het eerste dat je kan doen alle plugins uitschakelen. Aangezien dit een kopie is van je live site, hoef je je geen zorgen te maken dat je iets breekt. Het is verreweg een van de gemakkelijkste manieren om problemen te beperken. Ga gewoon naar Plugins, selecteer ze allemaal en kies “Deactiveren” uit de bulkopties.

Wanneer je dit hebt gedaan, kan je de responstijden controleren in New Relic of Query Monitor en zien wat er gebeurt. In dit onderstaande voorbeeld vielen de responstijden meteen weer terug naar normaal. Hierdoor wisten we dat het een van de plugins was die het probleem veroorzaakten. Je kunt ze vervolgens één voor één inschakelen, hetzelfde proces herhalen totdat je de boosdoener vindt.

Hier is een voorbeeld van wat er gebeurde toen we de plugin die het probleem veroorzaakte inschakelden. Laadtijden (web-transactie tijden) gingen meteen weer omhoog.

Wat moet je doen nadat je de plugin hebt gevonden die de traagheid veroorzaakt? Dit is wat we adviseren:

1. Werk de plugins en thema’s bij naar de nieuwste versie als je dat nog niet hebt gedaan.
2. Neem contact op met de ontwikkelaar van de plugin of het thema en vraag ze om hulp.
3. Zoek een alternatieve plugin die dezelfde functionaliteit kan bieden.
4. Misschien veroorzaakt de PHP-versie een probleem. Verander je PHP engine naar een lagere versie en kijk of de plugin of het thema dan beter werkt

Je kunt ook een WordPress-ontwikkelaar inhuren om het probleem op te lossen. Als het om prestaties gaat, moeten we Mike Andreason van WP Bullet. een persoonlijke shout-out geven. Hij is een full-time Codeable ontwikkelaar gespecialiseerd in performance optimalisatie, die veel klanten bij Kinsta met complexe installaties geholpen heeft om hun site naar een hoger niveau te tillen.

Controleer je error logs

Het controleren van foutlogboeken is nooit leuk, maar je kan veel te weten komen over prestatieproblemen met WordPress plugins. Als je klant bij Kinsta bent, kan je eenvoudig de error logs, cache logs en access logs bekijken via het MyKinsta-dashboard.

Je kunt ook error logs inschakelen door wat code toe te voegen aan het wp-config.php bestand. Allereerst maak je via SFTP verbinding met je site. Download dan je wp-config.php bestand zodat je deze kunt bewerken. Opmerking: maak altijd eerst een back-up van dit bestand!

Zoek de regel die zegt /* That's all, stop editing! Happy blogging. */ en voeg daarvoor het volgende toe (zoals hieronder te zien):

define( 'WP_DEBUG', true );

Als de bovenstaande code al bestaat in het wp-config.php bestand maar ingesteld is op ‘false’, wijzig deze dan in ’true’. Hierdoor wordt de debug-modus ingeschakeld. Opmerking: je ziet ook waarschuwingen of fouten in de WordPress admin als deze er zijn.

Vervolgens kan je de fout-opsporing-log inschakelen om alle fouten naar een bestand te verzenden door de volgende code toe te voegen net na de WP_DEBUG-regel (zoals hieronder te zien):

define( 'WP_DEBUG_LOG', true );

Sla de wijzigingen op en upload deze naar de server. De fouten worden dan vastgelegd in het bestand debug.log in jouw /wp-content/ map. Als je om welke reden dan ook dit bestand niet ziet, kan je er altijd een maken.

Maak gebruik van MyKinsta analyses

Als Klant bij Kinsta bent, kan je profiteren van de prestatie-inzichten die we hebben ingebouwd in onze MyKinsta Analytics hulpmiddel.

In het gedeelte Prestatieverificatie kan je jouw gemiddelde PHP + MySQL-responstijd, PHP-doorvoer, AJAX-gebruik, gemiddelde upstream-tijd en maximale upstream tijd bekijken.

Gemiddelde PHP + MySQL reactietijd

Wanneer je jouw WordPress site bezoekt, worden PHP en MySQL gebruikt voor het compileren en opvragen van de gegevens die je op de pagina ziet. In deze grafiek zie je de gemiddelde responstijd van de PHP-engine en de MySQL-engine voor elk dynamisch verzoek dat niet in de cache is opgeslagen. Het weten van deze reactietijden kan je helpen traagheid op te lossen.

PHP doorvoer

Doorvoer geeft het aantal transacties per seconde aan dat een toepassing aankan en verwijst in dit rapport naar de PHP-doorvoer van jouw WordPress website. Met andere woorden, het laat zien hoe vaak een PHP item werd aangevraagd.

AJAX gebruik

AJAX is een client-side script dat communiceert van en naar een server / database zonder dat een postback of een volledige paginavernieuwing nodig is. Als het op WordPress aankomt, hebben velen van jullie dit waarschijnlijk in de snelheidstesten gezien. De twee belangrijkste problemen met AJAX zijn onder andere plugins, waardoor spannings- en CPU-problemen aan de back-end optreden.

Zorg ervoor dat je ons uitgebreid artikel leest over het diagnosticeren van hoog Admin-AJAX-gebruik op jouw WordPress site.

Het gebruiksrapport van AJAX in MyKinsta analyses kan een goede manier zijn om je te helpen bij het oplossen van dit soort problemen, zoals je kunt zien wanner er bepaalde AJAX-pieken zijn gedurende bepaalde perioden. Dit diagram toont het aantal aanvragen voor admin-ajax. Je kunt dan een aantal van de tips in de post die we hierboven noemden, gebruiken om te bepalen waar ze vandaan komen.

Top gemiddelde PHP + MySQL reactietijd

Deze lijst toont de gemiddelde responstijden van PHP en MySQL. Deze getallen kunnen eenmalige pieken zijn. Daarom wordt aangeraden deze lijst te vergelijken met ‘Top Maximum Upstream Time’.

Top maximale upstream tijd

Upstream tijd is de totale tijd die het kost om Nginx (en upstream-servers) een verzoek te verwerken en een reactie te verzenden. De tijd wordt gemeten in seconden, met een resolutie van milliseconden. Lees meer over Nginx-statistieken.

Je website is misschien gehackt

Als je problemen ondervindt bij het opsporen van een prestatieprobleem, kan het zeer goed zijn dat de site is gehackt, is geïnfecteerd met malware of een DDoS-aanval heeft ondergaan. Dit kan van invloed zijn op de snelheid van de site en zelfs de reactievermogen van het WordPress dashboard. In deze gevallen raden we het volgende aan:

1. Implementeer een proxyserver en WAF zoals Cloudflare of Sucuri.
2. Blokkeer slechte IP-adressen met behulp van de bovenstaande services of als je een Kinsta klant bent, kan je ook IP-adressen blokkeren vanuit vanuit ons MyKinsta-dasboard.
3. Je kunt ook geo-blocking implementeren. Sommige landen zijn echt slecht als het gaat om de kwaliteit van het verkeer dat ze genereren. Als je wordt aangevallen, moet je het hele land mogelijk tijdelijk of permanent blokkeren.

Problemen oplossen met error codes (HTTP Status Codes)

HTTP statuscodes zijn als het ware een korte notitie van de webserver die bovenaan een webpagina wordt geplakt. Het maakt geen deel uit van de webpagina. In plaats daarvan is het een bericht van de server die je laat weten hoe het ging toen het verzoek om de pagina te bekijken door de server werd ontvangen. Deze kunnen van onschatbare waarde zijn als het gaat om het oplossen van problemen!

Hoewel er meer dan 40 verschillende statuscodes zijn, vind je hieronder de meest voorkomende waarmee we WordPress-gebruikers zien worstelen.

429: “Too many requests.” Gegenereerd door de server wanneer de gebruiker te veel verzoeken binnen een bepaalde tijd heeft verzonden (snelheidsbeperking). Dit kan soms voorkomen bij bots of scripts die proberen toegang te krijgen tot jouw site. In dit geval kan je proberen de login URL voor WordPress te wijzigen.

500: “There was an error on the server and the request could not be completed.” Een generieke code die eenvoudig “interne serverfout” betekent. Er is iets misgegaan op de server en de gevraagde bron is niet afgeleverd. Deze code wordt meestal gegenereerd door plugins van externe partijen, defecte PHP of zelfs de verbinding met de database die niet tot stand komt. Bekijk onze tutorials over het oplossen van de fout bij het tot stand brengen van een database verbinding en andere manieren om een 500 interne serverfout op te lossen.

502: “Bad Gateway.” Deze foutcode betekent meestal dat de ene server een ongeldig antwoord van een andere heeft ontvangen. Soms duurt een query of verzoek te lang en wordt deze daarom geannuleerd of gestopt door de server en de verbinding met de database wordt beëindigt. Bekijk ons uitgebreide artikel over het oplossen van de 502 Bad Gateway-fout.

503: “The server is unavailable to handle this request right now.” Het verzoek kan niet worden voltooid op dit moment. Deze code wordt verstuurd door een server die overbelast is waardoor deze extra verzoeken niet kan afhandelen.

504: “The server, acting as a gateway, timed out waiting for another server to respond.” Deze code wordt gegeven wanneer er twee servers zijn betrokken bij het verwerken van een aanvraag en de eerste server wacht tot de tweede server reageert. Meer informatie over het oplossen van 504 fouten.

Je kan ook in deze HTTP-reactiecodes zoeken in onze MyKinsta Analytics tool. In ons rapport met respons-code verdeling zie je een overzicht van de verdeling van HTTP-statuscodes die voor de aangevraagde bronnen zijn weergegeven.

In het rapport met response statistieken zie je het totale aantal omleidingen, fouten, succespercentages en foutpercentages. Elke WordPress site heeft meestal een kleine foutratio; dit is volkomen normaal.

Er zijn ook overzichtsrapporten voor elke type error code zoals 500 fouten, 400 fouten, redirects, etc.

Aanbevelingen voor back-end optimalisatie

Nu zullen we ingaan op enkele manieren waarop je WordPress kunt versnellen door de back-end te optimaliseren. Back-end bevat zo’n beetje alles dat volledig door de server wordt afgehandeld, zoals PHP, HTTP-cache-headers, GZIP-compressie, enz.

Maak een lichtgewicht 404 Pagina

We hebben zelf gezien dat dynamische sites meestal veel 404 fouten genereren. Jouw website genereert er mogelijk meer dan je denkt! Onze analyse tool in MyKinsta kan je helpen de exacte hoeveelheid te bepalen (zoals hieronder te zien is).

De reden dat deze fouten slecht zijn, is omdat veel 404 pagina’s zeer intensief zijn. Voor een dynamische WordPress site wil je een zware 404-pagina vermijden. Maak een eenvoudige 404 pagina die voorkomt dat de database verder wordt bevraagd. Besteed natuurlijk ook tijd en repareer de 404 fouten, want dit is niet alleen resource intensief, het is gewoon slecht voor de gebruikerservaring.

Naast het gebruik van een lichtgewicht 404 pagina, raden we ook aan om een speciale regel voor je paginacaching in te schakelen. Bij Kinsta cachen we 404 pagina’s automatisch voor 15 minuten. Als onze webserver detecteert dat een nieuwe pagina met de dezelfde URL als een gecachete 404 pagina is aangemaakt, legen we automatisch de cache. Als je WordPress site geen cachebare 404 pagina’s heeft, dan raden we aan om bij je host aan te kloppen om deze mogelijkheid op je webserver in te schakelen.

 

Verhoog het aantal PHP Workers

PHP workers kan een term zijn waarvan je nog nooit van hebt gehoord, maar er zijn veel hosts, inclusief Kinsta, verzoeken beperken (in plaats van je te beperken via CPU of RAM, wat typisch is voor shared hosting providers).

PHP Workers bepalen hoeveel gelijktijdige verzoeken jouw site op een bepaald moment kan verwerken. Om het simpel te houden: elk niet gecacht verzoek voor jouw website wordt afgehandeld door een PHP Worker. Als je bijvoorbeeld 4 verzoeken heeft die tegelijkertijd op de site terechtkomen en de website heeft 2 PHP Workers, dan worden twee van die verzoeken verwerkt terwijl de andere twee in de wachtrij moeten wachten totdat de eerste twee zijn afgerond.

Vergeet niet dat we eerder hebben besproken dat een van de grootste problemen met WordPress lidmaatschap websites al die niet gecachte verzoeken zijn. Dit is de reden waarom PHP Workers heel belangrijk worden omdat zij elk verzoek moeten verwerken. Daarom hebben deze sites doorgaans extra PHP Workers nodig om ervoor te zorgen dat elk verzoek zonder vertraging verwerkt en met succes voltooid wordt.

Wat gegeurt er als je continue het maximale aantal PHP Workers bereikt? In principe begint de wachtrij oudere verzoeken af te stoten, wat kan resulteren in 500 fouten op jouw site. Elk hosting pakket van Kinsta bevat een vooraf gedefinieerd aantal PHP Workers. Als je problemen ondervindt met het inschatten van wat jouw site nodig heeft, kun je altijd chatten met ons sales- of support team.

Maak gebruik van GZIP Compressie

GZIP s een bestandsindeling en software die wordt gebruikt voor bestandscompressie en decompressie. GZIP compressie is server-side ingeschakeld en zorgt voor verdere verkleining van jouw HTML, Stylesheets en JavaScript-bestanden.

Wanneer een webbrowser een website bezoekt, wordt gecontroleerd of de webserver GZIP heeft ingeschakeld door te kijken of de content-encoding: gzip HTTP-header bestaat. Als de header wordt gedetecteerd, dient deze voor de gecomprimeerde en kleinere bestanden. Als dat niet het geval is, serveert de server ongecomprimeerde bestanden. Als je GZIP niet hebt ingeschakeld, zie je hoogstwaarschijnlijk waarschuwingen en fouten in hulpmiddelen voor het testen van snelheid zoals Google PageSpeed Insights en GTmetrix.

Als je GZIP compressie inschakelt, verklein je de grootte van jouw webpagina waardoor de tijd om de bron te downloaden aanzienlijk kan worden verminderd. Het datagebruik voor de klant wordt beperkt en de tijd voor de eerste weergave van de pagina’s verbeterd. Hoewel dit inmiddels vrij standaard is, check altijd of jouw hosting provider dit heeft – we hebben de gekste dingen gezien, ons verbaast niets meer.

Schakel hotlink beveiliging in

Het concept van hotlinking is vrij eenvoudig. Je vindt ergens een afbeelding op internet en gebruikt de URL van de afbeelding rechtstreeks op jouw site. Deze afbeelding wordt op jouw website weergegeven, maar wordt vanaf de oorspronkelijke locatie geladen. Dit is erg handig voor de hotlinker, maar het is eigenlijk diefstal omdat het de resources van de andere site gebruikt. Het is hetzelfde als we in de auto stappen en wegrijden, met de benzine die we uit de auto van de buurman hebben gejat.

Hotlinking kan een enorme impact hebben op de originele server. Stel je voor dat je op een shared WordPress host zit en dat De Telegraaf opeens jouw afbeeldingen hotlinkt. Je zou van een paar honderd requests per uur naar een paar honderdduizend requests per uur kunnen gaan. Dit kan zelfs resulteren in een blokkering van jouw hosting account. Dit is een reden om niet alleen een high-performance host (die dergelijke problemen kan verwerken) te gebruiken, maar ook om hotlink beveiliging in te schakelen, zodat dit niet gebeurt.

Lees onze tutorial over het voorkomen van hotlinken.

Minimaliseer het aantal redirects en voeg ze op serverniveau toe

Te veel doorverwijzingen zijn altijd een factor waar je op moet letten. Een simpele redirection zoals een 301, HTTP naar HTTPS of www naar niet-www (vice versa) is prima. Vaak zijn deze nodig op bepaalde delen van jouw website. Echter heeft elke redirection impact op de prestaties van de website. Als de redirections beginnen op te stapelen dan is het belangrijk om te weten hoe ze een website beïnvloeden. Dit is van toepassing op alle type redirects – posts, pagina’s, afbeeldingen, etc.

Een redirect genereert een 301 of 302 status in de response header.

Hoeveel invloed hebben redirects op jouw website? Laten we hier een kleine test voor doen. Als eerste voeren we een snelheidstes uit op onze contactpagina: https://perfmatters.io/contact/. Zoals je hieronder kunt zien behalen we een totale laadtijd van 417ms.

Daarna hebben we de URL een klein beetje aangepast en voeren daarna een andere snelheidstest uit om de impact van meerdere redirections te zien. Zoals je kunt zien: Die zelfde pagina doet er nu 695ms over om te laden. Dat is een stijging van 66%. Jemig!

Het gebruik van gratis WordPress plugins om redirections te implementeren kan soms prestatieproblemen veroorzaken. De meesten van hen gebruiken de wp_redirect functie, waarvoor aanvullende code en resources nodig zijn. Sommigen van hen voegen ook automatisch geladen data toe aan de wp_options tabel, waardoor de database toeneemt. Redirections zouden op serverniveau moeten worden toegevoegd. Bij Kinsta is dat mogelijk vanuit het MyKinsta Dashboard met onze hulpmiddel voor omleidingsregels.

Je kunt hier ook een compleet overzicht bekijken over de hoeveelheid omleidingen er op jouw website plaatsvinden in de MyKinsta Analyse. Bekijk het totaal aantal 301’s, 302’s en 304’s.

Bekijk ons uitgebreid artikel over WordPress redirects en de best practices voor snellere prestaties.

Laat cron jobs niet uit de hand lopen

CRON jobs (WP-Cron) worden gebruikt om herhalende taken voor jouw WordPress site te plannen. In de loop van de tijd kan dit echter uit de hand lopen en prestatieproblemen veroorzaken. Je kunt de gratis WP Crontrol plugin gebruiken om grip te krijgen op alle Cron Jobs die op jouw site plaatsvinden.

We hebben ook prestatieproblemen gezien met de ingebouwde Cron handler van WordPress: WP-Cron. Als een site niet genoeg PHP Workers heeft en er een Cron Job aangevraagd wordt dan moet deze wachten op de Worker. Dit resulteert in een Cron Job die niets doet en alleen maar wacht. Het is een betere aanpak om WP-Cron uit te schakelen en het Cron Systeem van het systeem te gebruiken. Dit wordt zelfs aangeraden in het officiële Plugin Handboek.

Om WP-Cron uit te schakelen, voeg je het volgende toe aan je wp-config.php bestand. Net voor de regel met de tekst “Dat is alles, stop met bewerken! Veel plezier met bloggen.” Opmerking: dit voorkomt dat Cron Jobs worden uitgevoerd bij het laden van een pagina, niet als je het rechtstreeks via wp-cron.php aanroept.

define('DISABLE_WP_CRON', true);

Je moet daarna wp-cron.php inplannen vanaf jouw server. Als je klant bij Kinsta bent dan zijn systeem cron’s standaard ingeschakeld en worden elke 15 minuten uitgevoerd. Als de frequentie hoger moet zijn kun je dat aanvragen bij onze support medewerkers. Indien je bekend bent met SSH dan kun je de server cron’s beheren vanaf de Command line.

Voeg cache-control en expire-headers toe (bepaal de duur van je cache)

Elk script op jouw WordPress site moet een HTTP-cache-header hebben (of zou moeten hebben) Dit bepaalt wanneer de cache van het bestand verloopt. Om dit op te lossen, zorg je ervoor dat jouw WordPress host over de juiste cache-control headers beschikt en de expires instellingen heeft. Als je dit niet doet, ziet je waarschijnlijk waarschuwingen over het toevoegen van expire-headers of het gebruik van leverage browser caching in hulpprogramma’s voor het testen van de snelheid.

Terwijl de cache-control client-side caching inschakelt en de maximumleeftijd van een resource instelt, wordt de expires eader gebruikt om een specifiek tijdstip op te geven wanneer de resource niet langer geldig is. Hoewel beide headers samen kunnen worden gebruikt, hoef je niet noodzakelijk beide headers toe te voegen. cache-control is nieuwer en meestal de aanbevolen methode.

Kinsta voegt automatisch HTTP-cache-headers toe aan alle server-aanvragen en als je een CDN gebruikt, zullen ze deze headers waarschijnlijk ook voor je toevoegen.

Als jouw server deze headers mist kan je ze handmatig toevoegen.

Cache-control header in Nginx toevoegen

Je kunt de cache-control headers in Nginx toevoegen door het volgende toe te voegen aan de configuratie van jouw server.

location ~* \.(js|css|png|jpg|jpeg|gif|svg|ico)$ {
 expires 30d;
 add_header Cache-Control "public, no-transform";
}

Expire-headers toevoegen in Nginx

Je kunt de expires in Nginx toevoegen door het volgende toe te voegen aan de configuratie van jouw server. In dit voorbeeld zie je hoe je verschillende tijden aan verschillende type bestanden kunt toe kennen.

    location ~*  \.(jpg|jpeg|gif|png|svg)$ {
        expires 365d;
    }

    location ~*  \.(pdf|css|html|js|swf)$ {
        expires 2d;
    }

Cache-control header in Apache toevoegen

Je kunt cache-control headers in Apache toevoegen door de volgende code toe te voegen aan jouw .htaccess bestand. De stukken code kunnen worden toegevoegd aan het begin of het einde van het bestand (Voor #BEGIN WordPress of na #END WordPress).

<filesMatch ".(ico|pdf|flv|jpg|jpeg|png|gif|svg|js|css|swf)$">
Header set Cache-Control "max-age=84600, public"

Expire-headers in Apache toevoegen

Je kunt expires headers headers toevoegen in Apache door het volgende toe te voegen aan jouw .htaccess bestand.

## EXPIRES HEADER CACHING ##

ExpiresActive On
ExpiresByType image/jpg "access 1 year"
ExpiresByType image/jpeg "access 1 year"
ExpiresByType image/gif "access 1 year"
ExpiresByType image/png "access 1 year"
ExpiresByType image/svg "access 1 year"
ExpiresByType text/css "access 1 month"
ExpiresByType application/pdf "access 1 month"
ExpiresByType application/javascript "access 1 month"
ExpiresByType application/x-javascript "access 1 month"
ExpiresByType application/x-shockwave-flash "access 1 month"
ExpiresByType image/x-icon "access 1 year"
ExpiresDefault "access 2 days"

## EXPIRES HEADER CACHING ##

Het is ook belangrijk op te merken dat je alleen HTTP-cache-headers op resources van jouw server kunt toevoegen. Als je daar een waarschuwing voor krijgt, moet je wellicht gebruikmaken van browsercaching voor verzoeken van derden. Hieraan kun je niets doen, omdat je geen zeggenschap hebt op hun server. Veelvoorkomende boosdoeners zijn het Google Analytics-script en marketingpixels, zoals Facebook en Twitter.

Als je dit probeert op te lossen voor het Google Analytics script, kun je dit lokaal of op jouw CDN hosten (hoewel dit niet officieel wordt ondersteund) met een plugin zoals Perfmatters of WP Rocket.

Voeg laatst gewijzigd en ETag headers toe (valideer de cache)

Als volgende hebben we twee andere headers, last-modified en etag.
De cache-control en expires headers helpen de browser om vast te stellen of het bestand is gewijzigd sinds de laatste keer dat het bestand is aangevraagd (of beter gezegd, ze valideren de cache.) De last-modified enetag headers valideren en bepalen de lengte van de cache en moeten bij iedere origin serverrespons inbegrepen worden. Als deze niet correct zijn ingesteld krijg je mogelijk een waarschuwing dat je een “Cache validatie moet specificeren.”

Als de headers niet worden gevonden, genereert deze elke keer een nieuwe aanvraag voor de resource, waardoor de belasting op de server toeneemt.  Het gebruik van caching-headers zorgt ervoor dat volgende aanvragen niet van de server hoeven te worden geladen, waardoor bandbreedte wordt bespaard en de prestaties voor de gebruiker worden verbeterd.

Kinsta voegt automatisch de bovenstaande headers toe aan alle server verzoeken en als je een CDN gebruikt, zullen zij deze headers waarschijnlijk ook voor je toevoegen. Net als bij cache-control en expires, kan je deze HTTP headers niet instellen op externe bronnen.

Last-modified header

De last-modified wordt over het algemeen automatisch van de server verzonden. Dit is een header die je over het algemeen niet handmatig hoeft toe te voegen. Het wordt verzonden om te zien of het bestand in de cache van de browser is gewijzigd sinds de laatste keer dat het werd aangevraagd. Je kan dit zien in Pingdom bij de Header requests of Chrome DevTools gebruiken om de waarde van de last-modified header te bekijken.

ETag header

De ETag header lijkt veel op de last-modified header. Het wordt ook gebruikt om de cache van een bestand te valideren. Als je Apache 2.4 of hoger gebruikt, wordt de ETag-header al automatisch toegevoegd met behulp van de FileETag directive. En wat Nginx betreft, is de ETag-header sinds 2016 standaard ingeschakeld.

Je kunt de enable the ETag header handmatig inschakelen op Nginx met behulp van de volgende code.

etag on

Voeg vary: Accept-Encoding header toe

De vary: Accept-Encoding header moet worden opgenomen in elke oorspronkelijke server reactie, omdat het de browser informeert of de client gecomprimeerde versies van de inhoud kan afhandelen. Als dit niet correct is ingesteld, zie je mogelijk de waarschuwing “Specify a Vary: Accept-Encoding Header.”

Stel dat je een oude browser zonder gzip-compressive en een moderne browser bij de hand hebt. Als je geen gebruik maakt van de: vary: Accept-Encoding header, kan de webserver of CDN de ongecomprimeerde versie cachen en die per ongeluk aan de moderne browser leveren, wat op zijn beurt de prestaties van jouw WordPress site schaadt. Door de header te gebruiken, kan je ervoor zorgen dat de webserver en / of CDN de juiste versie levert.

Kinsta voegt automatisch de bovenstaande headers toe aan alle server-verzoeken en als je een CDN gebruikt, zullen ze deze headers waarschijnlijk ook voor je toevoegen. Net als bij de andere cache-headers die we hierboven hebben besproken, kan je deze header niet handmatig instellen op externe resources.

Voeg de Vary: Accept-Encoding Header toe in Apache

Je kunt de Vary: Accept-Encoding Header in Apache toevoegen door het volgende in jouw .htaccess bestand te zetten.

<IfModule mod_headers.c>
  <FilesMatch ".(js|css|xml|gz|html)$">
    Header append Vary: Accept-Encoding
  </FilesMatch>
</IfModule>

Voeg de Vary: Accept-Encoding Header toe in Nginx

Je kunt de Vary: Accept-Encoding Header in Nginx toevoegen door de volgende code toe te voegen aan jouw configuratie bestand. Alle Nginx configuratie bestanden staan in de /etc/nginx/ directory. Het hoofd configuratie bestand is /etc/nginx/nginx.conf.

gzip_vary on

Wijzig het WordPress geheugenlimiet in wp-config.php

Zoals vermeld in de WordPress Codex kun je vanaf WordPress versie 2.5 met de optie WP_MEMORY_LIMIT de maximale hoeveelheid geheugen instellen die door PHP kan worden gebruikt. Deze instelling kan nodig zijn in het geval dat je een bericht ontvangt zoals “Toegestane geheugencapaciteit van xxxxxx bytes exhausted”.

WordPress probeert standaard het geheugen dat is toegewezen aan PHP te verhogen tot 40 MB voor een enkele site en 64 MB voor multisite. Ze definiëren de geheugenlimieten in het bestand ./wp-includes/default-constants.php, op de regels 32 – 44 (bron).

Je hebt ook PHP memory_limit op de server van je hosting provider. Dit zijn twee verschillende dingen. Bij Kinsta hebben we standaard memory_limit ingesteld op 256M. Als je de exhausted memory size foutmelding krijgt, kan je proberen het PHP geheugenlimiet in WordPress te verhogen.

Voeg het volgende toe aan jouw wp-config.php file bestand, net voor de regel met de tekst “That’s all, stop editing! Happy blogging.”

define( 'WP_MEMORY_LIMIT', '256M' );

Jan Reilink heeft ook een goede blogpost waarin het probleem met de WordPress memory-limit gedetailleerder wordt beschreven. Hij geeft ook een variatie op de code die je zou kunnen gebruiken. In plaats van het limiet handmatig in te stellen, kan het instellen op de PHP memory_limit waarde.

define( 'WP_MEMORY_LIMIT', ini_get( 'memory_limit' ) );

Tips voor front-end optimalisatie en externe diensten

Nu zullen we uitgebreid ingaan op enkele manieren waarop je WordPress kunt versnellen door de front-end te optimaliseren. Front-end omvat doorgaans alles dat volledig wordt afgehandeld door de client-side browser, zoals CSS, JavasScript, afbeeldingen, etc. Dit bevat ook het analyseren van externe services die je op de site laadt en hoe deze jouw totale laadtijd beïnvloeden.

Twee van de belangrijkste doelstellingen die je moet hebben als het gaat om front-end optimalisatie zijn:

• De totale webpagina verkleinen. De grootte van CSS, JavaScript, afbeeldingen is van belang. Een website van 4 MB laad doorgaans veel trager dan een website van 1 MB. Paul Calvano heeft echter een geweldig artikel over de impact van pagina grootte op de laadtijd en hoe het belangrijk het is om ervoor te zorgen dat dit niet het enige is dat je bijhoudt, omdat dit soms misleidend kan zijn.
• Verlagen van het aantal HTTP requests en externe services. met HTTP/2 kunnen meerdere aanvragen en antwoorden tegelijkertijd worden verzonden via een enkele TCP-verbinding. Hoewel dit geweldig is voor prestaties, kan het verminderen van HTTP-verzoeken nog steeds helpen de WordPress site te versnellen. Dit betekend ook het verminderen van het totale aantal externe verzoeken en services. Elk van deze services voegen extra vertragingen toe, zoals DNS lookups, TLS-verbindingen en netwerk latency.

Doe een 0-meting van jouw WordPress snelheid

Als het gaat over het optimaliseren van de front-end van jouw site, is het altijd goed om te beginnen met een baseline. Dit betekent dat je een snelheidstest moet uitvoeren. Je kunt dit op veel verschillende manieren doen, bekijk onze lijst met 15 geweldige test tools voor website snelheid.

Lees onze uitgebreide handleidingen over het gebruik van Pingdom en het gebruik van GTmetrix. Hier zijn een aantal dingen om rekening mee te houden bij het testen van de snelheid:

1. Kiest 1 tool en blijf die gebruiken

Wij zijn grote fans van Pingdom, GTmetrix, WebPageTest, PageSpeed Insights en Chrome DevTools. Het maakt echter niet zoveel uit welke test je gebruikt, als je maar consistent bent. Ze hebben allemaal verschillende manieren om snelheden te meten en te kwantificeren, dus kies een tool en blijf daarbij voor al je testen en optimalisaties. Zelfs Google raadt aan er een te kiezen.

2. Een perfecte score is niet het einddoel

Veel van de tools zoals Google PageSpeed Insights hebben allemaal een soort snelheid of prestatiescore. Het is belangrijk om te onthouden dat de score niet altijd zo belangrijk is als de snelheid van jouw website en de waargenomen prestaties van de gebruiker. De score is er om te helpen bepalen hoe goed je het doet. Maar obsessief zijn voor een perfecte 100/100 of een A-score kan in sommige gevallen een verspilling van tijd zijn. Grotere sites met veel externe scripts en advertenties zullen nooit een perfecte score krijgen, wat nog steeds prima is.

3. De locatie vanaf waar je test maakt uit

De locatie die je kiest wanneer je snelheid test is nogal belangrijk. Zoals we in een eerder gedeelte besproken hebben, is de reden dat dit allemaal relatief is ten opzichte van de datacenter locatie die je kiest. TTFB, netwerk latency, alles heeft invloed. Test jouw site dus zowel op een locatie die dicht bij jouw datacenter ligt als op een locatie die verder weg is. Hiermee kan je ook zien hoeveel invloed een CDN kan hebben op jouw WordPress site.

4. Test meerdere keren vanwege caching

Zoals we eerder in de sectie over caching hebben gehad, als de cache onlangs is gewist of is verlopen op je WordPress host of CDN, gaat deze een “MISS” registreren in de HTTP-header. Dit betekent dat jouw website of item niet via de cache wordt geserveerd.

Om de snelheid van de hele site goed te kunnen zien, moet je alles zien laden vanuit de cache, de startpagina en alle items zouden een “HIT” moeten registreren. Dit vereist soms dat je de snelheidstest meerdere keren uitvoert. Je kunt daarvan het gemiddelde nemen.

Nu kunnen we doorgaan en een kijkje nemen naar de Front-End optimalisaties die je kunt doen op jouw WordPress website.

Elimineer render-blocking JavaScript en CSS

Er kan een waarschuwing verschijnen over het blokkeren van JavaScript en CSS wanneer je bestanden hebt die voorkomen dat de pagina zo snel mogelijk wordt geladen. Specifieke JS en CSS zijn soms voorwaardelijk, wat betekent dat ze niet verplicht zijn om inhoud boven de Fold weer te geven. Je kunt voorkomen dat ze render-blocking worden door async en defer attributen te gebruiken.

Om render-blocking Javascript en CSS te elimineren moet je het volgende doen:

Verwijder JS van het kritische render pad

Het verplaatsen van JavaScript uit het kritieke renderpad wordt meestal gedaan door het kenmerk defer of de async toe te voegen aan de HTML elementen van het script ie JavaScript bronnen aanroepen.

• Het async attribuut  vertelt de browser om de resource te downloaden zonder de HTML parsing te vertragen. Zodra de bron beschikbaar is, wordt het parsen van de HTML gepauzeerd, zodat de bron kan worden geladen.
• Het defer attribuut laat de browser weten dat het moet wachten met het downloaden van de bron totdat de HTML parsing is voltooid. Zodra de browser klaar is met de HTML-code, wordt deze vervolgens gedownload en worden alle uitgestelde scripts weergegeven in de volgorde waarin ze in het document voorkomen.

Optimaliseer het inladen van CSS resources

Het optimaliseren van de CSS betekent in feite dat je moet uitzoeken hoe je het zo kunt maken dat het niet render-blocking is.

• Identificeer de stijlen die nodig zijn om inhoud boven de fold weer te geven en lever die stijlen inline met de HTML af.
• Gebruik CSS alleen voorwaardelijk op apparaten wanneer dat nodig is.
• Laad resterende CSS asynchroon.

Het kan soms een lastig proces zijn om al het bovenstaande te doen en het vereist zeker wat aanpassingen op basis van de scripts die je op de site laadt. Hier zijn een paar WordPress plugins die kunnen helpen:

• Autoptimize
• Async JavaScript
• Hummingbird

Voor een uitgebreidere uitleg en hulp raden we aan om ons artikel over het elimineren van render-blocking JavaScript en CSS te lezen.

Combineer externe CSS en Javascript in WordPress

De CSS waarschuwing voor externe CSS wordt meestal gezien bij het gebruik van een CDN, omdat de CSS-bestanden gehost worden op een extern domein, zoals cdn.domain.com. In het verleden kon je dit oplossen door je CSS bestanden samen te voegen of te combineren, zodat ze in één keer werden geladen.

Als je echter HTTPS gebruikt met een provider die HTTP/2 ondersteunt, is deze waarschuwing niet meer zo relevant als voorheen. Met HTTP/2 kunnen meerdere CSS-bestanden nu via een enkele verbinding parallel worden geladen. Meer dan 95% van de browsers ondersteunt inmiddels HTTP/2.

Maar, dat betekent niet dat deze optimalisatie volledig dood is. In sommige gevallen hebben we gezien dat dit nog steeds WordPress sites versnelt. Het hangt af van de grootte en het aantal bestanden. Daarom is dit één van de optimalisaties die we aanbevelen om te controleren op jouw website.

Een van de gemakkelijkste manieren om externe CSS- en JavaScript-bestanden te combineren, is met de gratis Autoptimize plugin. Na het combineren zie je een bestand “autoptimize_xxxxx.css” of “autoptimize_xxxxx.js”. Het ondersteunt ook het laden vanaf jouw CDN. Je kunt dit ook doen met de WP Rocket plugin.

Bekijk ons uitgebreid artikel over hoe je externe CSS en Javascript kunt combineren in WordPress.

Gebruik Minification voor HTML, CSS en JavaScript

We kunnen de hoeveelheid gegevens die de browser moet downloaden verminderen door HTML-, CSS- en JavaScript-bronnen te verkleinen. Minificatie is het proces waarbij onnodige tekens zoals opmerkingen en witruimte uit de broncode worden verwijderd. Deze tekens zijn erg handig tijdens de ontwikkeling, maar ze zijn nutteloos voor de browser om de pagina weer te geven.

Niet geminificeerde HTML

Hier staat een voorbeeld van HTML code die niet is geminificeerd.

Geminificeerde HTML

Hieronder staat een voorbeeld van geminificeerde HTML code.

Je kunt gebruik maken van de gratis plugin Autoptimize plugin of WP Rocket om jouw bestanden gemakkelijke te minificeren.

Als je een Kinsta klant bent, heb je toegang tot de codeminificatiefeature die rechtstreeks in het MyKinsta dashboard is ingebouwd. Dit stelt klanten in staat om snel en eenvoudig automatische CSS en JavaScript minificatie in te schakelen met een klik op een knop en zal je site versnellen zonder handmatige inspanning.

Gebruik cookie vrije domeinen

Over het algemeen is er, wanneer je inhoud zoals afbeeldingen, JavaScript of CSS gebruikt, geen reden om een HTTP-cookie mee te sturen, omdat dit extra overhead creëert. Nadat de server een cookie voor een bepaald domein heeft ingesteld, moeten alle daaropvolgende HTTP-aanvragen voor dat domein de cookie bevatten. Deze waarschuwing wordt meestal weergegeven op sites met een groot aantal verzoeken.

We hebben een uitgebreid artikel over hoe je om kunt gaan met de waarschuwing betreffende  het serveren van statische inhoud van een cookie vrij domein. Vaak kan je deze waarschuwing negeren, omdat nieuwe protocollen zoals HTTP/2 dit minder belangrijk maken. De kosten van een nieuwe verbinding zijn meestal duurder dan alles via dezelfde verbinding te versturen.

Een eenvoudige manier om deze waarschuwing op te lossen, is door een CDN provider te gebruiken die zowel cookies als strip-cookies kan negeren, zodat de client de response-header Set-Cookie niet ontvangt. KeyCDN is een CDN provider die deze functie aanbiedt. Standaard zie je dat de volgende twee opties zijn ingeschakeld. Dit is een eenvoudig alternatief zonder te hoeven rotzooien met het verplaatsen en configureren van jouw site om statische assets van een afzonderlijk subdomein te serveren.

Als je Cloudflare gebruikt, kan je de cookies niet uitschakelen voor resources die via hun netwerk worden aangeboden. CloudFlare bevat een eigen beveiligingscookie in de header. Nogmaals, deze cookies zijn erg klein en hun impact op prestaties is uiterst minimaal. Maar als je CloudFlare gebruikt, kan je deze waarschuwing niet omzeilen.

Een tweede manier om dit te omzeilen is om jouw WordPress site opnieuw in te stellen om de statische assets van een nieuw domein of subdomein te serveren.

Schakel embeds in WordPress uit

Toen WordPress 4.4 gelanceerd werd, is de oEmbed-functie samengevoegd met WordPress core. Hiermee kunnen gebruikers YouTube-video’s, tweets en vele andere bronnen insluiten op hun sites door simpelweg een URL te plakken, die WordPress automatisch omzet in een embed en een live voorvertoning biedt in de visuele editor. Door deze update werd WordPress zelf een oEmbed-provider.

Deze functie is nuttig voor veel mensen en je wilt deze mogelijk ingeschakeld houden. Dit betekent echter dat het ook een extra HTTP-verzoek op jouw WordPress site genereert om het bestand wp-embed.min.js te laden. En dit wordt site-breed geladen. Hoewel dit bestand slechts 1,7 KB groot is, tellen dit soort dingen na verloop van tijd toch op. Het verzoek zelf is soms een groter dan de download grootte van de inhoud.

Je kunt gemakkelijk voorkomen dat dit bestand wordt ingeladen. Hier zijn de verschillende opties:

• Optie 1 – Zet embeds uit met een plugin
• Optie 2 – Zet embeds uit via code
• Option 3 – Verplaats de Javascript inline

Schakel Emoji’s in WordPress uit

Net als bij embeds hebben ze in WordPress 4.2, ondersteuning voor emoji’s toegevoegd aan de core voor oudere browsers. Het grote probleem hiermee is dat het een extra HTTP-verzoek op jouw WordPress site genereert om het bestand wp-emoji-release.min.js te laden. En dit laadt over de hele site. Hoewel dit bestand slechts 10,5 KB groot is, is het nutteloos als je geen emoji’s op je site gebruikt.

Er zijn een aantal manieren om emoji’s uit te schakelen in WordPress. Je kunt het met een gratis plugin of met code doen.

• Schakel emoji’s uit met een plugin
• Schakel emoji’s uit met Code

Zo versnel je WordPress reacties of schakel je een thema uit

Een druk commentaar gedeelte op een site kan veel prestatieproblemen veroorzaken. Denk maar aan de resources die gebruikt worden om opmerkingen mogelijk te maken:

• Er wordt een database aanvraag uitgevoerd om bestaande opmerkingen op te halen.
• Databasegegevens worden aangemaakt voor elke nieuwe opmerking.
• Opmerkingen en metagegevens over reacties worden ontvangen en verwerkt door de browser van een bezoeker.
• Externe bronnen, zoals Gravatars, worden opgevraagd, gedownload en geladen (waarvoor een afzonderlijke DNS-zoekopdracht nodig is).
• In veel gevallen moeten grote JavaScript- en jQuery-bronnen worden gedownload en verwerkt om het reactiesysteem te laten werken zoals het hoort.

Hier zijn vier verschillende opties die je kunt overwegen om WordPress reacties te versnellen:

Optie 1 — Schakel reacties uit

Als jouw site niet veel reacties heeft en je denkt niet dat ze enige waarde toevoegen, is het misschien beter om reacties helemaal uit te schakelen. Houd er rekening mee dat opmerkingen invloed kunnen hebben op de SEO, omdat Google deze doorgaans als aanvullende inhoud op de pagina crawlt, dus je zou alleen hoogwaardige opmerkingen moeten goedkeuren. Bekijk deze drie eenvoudige manieren om reacties uit te schakelen:

• Schakel reacties uit met de WordPress opties
• Schakel reacties uit met een plugin
• Schakel reacties uit met code

Optie 2 — Optimaliseer de native WordPress reacties

De tweede optie zou zijn om het native WordPress reactiesysteem te optimaliseren. Een manier zou kan zijn om het aantal reacties te verminderen dat wordt geladen bij het laden van de eerste pagina.

1. Ga naar Instellingen → Discussie in het WordPress Dashboard.
2. Zoek naar het gedeelte Overige instellingen voor de reacties..
3. Schakel het selectievakje in naast Opmerkingen pagineren en voeg een waarde toe voor het aantal opmerkingen dat je wil weergeven bij het laden van de eerste pagina.

Een andere optie die je hebt is om Gravatars via je CDN te gebruiken. Dit is de aanpak die we bij Kinsta hebben.

Standaard is bij het laden van WordPress reacties voor elke unieke Gravatar een HTTP-aanvraag vereist. Dus als een pagina is geladen met opmerkingen van 50 verschillende commentatoren, zijn 50 HTTP-aanvragen vereist om al die Gravatars te downloaden. Zoals je je kunt voorstellen, kan dit van invloed zijn op je paginasnelheid. Om nog maar te zwijgen van het feit dat de externe DNS-lookup van gravatar.com soms traag is. In sommige gevallen hebben we zelfs een time-out gezien.

Als je Gravatars op de Kinsta blog bekijkt, kun je zien dat ze worden geladen vanaf Kinsta.com (inclusief ons CDN). Bekijk hoe je Gravatars laadt vanaf jouw CDN.

Optie 3 — Gebruik een extern reactiesysteem

Een derde optie is om een reactiesysteem van een externe partij te gebruiken. Als jouw site wordt gehost op een goedkope, resource arme shared server, kan het gebruik van een reactiesysteem van een externe partij pagina’s met veel reacties versnellen. Het is hetzelfde idee als beeldoptimalisatie, het werk offloaden. Als je echter wordt gehost door Kinsta of een andere webhosting van hoge kwaliteit, zal overschakelen naar een derde partij niet veel doen voor de laadsnelheid van jouw website en misschien zelfs vertragend werken.

Controleer altijd het reactiesysteem van externen dat je probeert door te testen. Bekijk alle afzonderlijke verzoeken die Disqus genereert (zoals hierboven weergegeven). Hoewel de meeste van deze verzoeken asynchroon worden geladen, merk je alsnog enige extra laadtijd als je Disqus gebruikt.

Optie 4 — Lazy Load reacties

Jouw vierde optie is om reacties te lazy loaden, zodat ze de initiële paginaweergave niet vertragen. Hier zijn een aantal plugins die je kunt bekijken:

• Lazy Load for Comments: Met deze plugin kan je de native WordPress reacties lazy loaden.
• Disqus Conditional Load: Als je het Disqus reactiesysteem wilt gebruiken, is dit een onmisbare plugin om reacties te lazy loaden.

Schakel WordPress RSS feeds uit

Als je het bloggedeelte van WordPress op jouw site niet gebruikt, kan je de WordPress RSS feeds uitschakelen. Hoewel dit geen grote invloed heeft op de prestaties – alles helpt. Het is ook weer een item minder waar je je zorgen over hoeft te maken.

Bekijk deze twee verschillende manieren om RSS feeds in WordPress uit te schakelen:

• Schakel de RSS Feed uit met een Plugin
• Schakel de RSS Feed uit met Code

Maak gebruik van Prefetch en Preconnect

Resource hints en directives zoals prefetch en preconnect kunnen een goede manier zijn om WordPress achter de schermen te versnellen. KeyCDN heeft een uitstekend artikel en een overzicht van resource hints.

Prefetch

Met DNS prefetch kan je domeinnamen opzoeken (een DNS-lookup uitvoeren op de achtergrond) voordat een gebruiker op een link klikt, dit kan op zijn beurt de prestaties verbeteren. Het wordt gedaan door een tag rel="dns-prefetch" toe te voegen in de head van jouw WordPress site.

<link rel="dns-prefetch" href="//domain.com">

Andere veel voorkomende dingen om DNS prefetching voor te gebruiken zijn: Jouw CDN URL, Google Fonts, Google Analytics, etc.

 <link rel="dns-prefetch" href="//cdn.domain.com/">
 <link rel="dns-prefetch" href="//fonts.googleapis.com/">
 <link rel="dns-prefetch" href="//www.google-analytics.com">

Prefetch wordt ondersteund door de meeste moderne browsers. Bekijk onze tutorial over het toevoegen van code aan jouw WordPress header.

Of je kunt eenvoudig DNS prefetch implementeren met behulp van een plugin zoals Perfmatters. Klik eenvoudig op het tabblad “Extra’s” in de Perfmatters plugin en voeg domeinen toe. Format: //domain.tld (één per regel)

Preconnect

Preconnect stelt de browser in staat om vroeg verbindingen in te stellen voor een HTTP-verzoek, waardoor round-trip latency wordt voorkomen en gebruikers tijd besparen.

Preconnect is een belangrijk hulpmiddel in de optimalisatie toolbox… het kan vele dure roundtrips van de verzoeken elimineren – in sommige gevallen vermindert de wachttijd van het verzoek met honderden of zelfs duizenden milliseconden. 
 – lya Grigorik (bron)

Dit wordt gedaan door rel=”preconnect” toe te voegen in de header van jouw WordPress website.

<link rel="preconnect" href="//domain.com">

Een paar voorbeelden van items waarvoor je dit wellicht wilt gebruiken, zijn de CDN-URL of Google Fonts.

 <link rel="preconnect" href="https://cdn.domain.com">
 <link rel="preconnect" href="https://fonts.gstatic.com">

Preconnect wordt ondersteund door de meeste moderne browsers, met uitzondering van Internet Explorer, Safari, IOS Safari en Opera Mini. Bekijk onze tutorial over het toevoegen van code aan jouw WordPress header.

Of je kunt preconnect eenvoudig implementeren met behulp van een plugin zoals Perfmatters. Klik eenvoudig op het tabblad “Extra’s” in de Perfmatters plugin en voeg domeinen toe. Format: scheme://domain.tld (één per regel).

Schakel Scripts Uit per Post of Pagina

Een andere zeer krachtige manier om WordPress te versnellen, is om door elke aanvraag te controleren die op jouw pagina’s en berichten wordt geladen. Je zult hoogstwaarschijnlijk scripts vinden die in de hele site worden geladen, waar dat niet het geval zou moeten zijn.

Je kunt een premium plugin goals Perfmatters gebruiken die een ingebouwde “Script Manager” – functie heeft. Hiermee kan je scripts (CSS en JavaScript) op  pagina/post-basis uitschakelen, of zelfs de hele site met een enkele klik. Nogmaals, deze plugin is ontwikkeld door een teamlid bij Kinsta.

Een paar voorbeelden van waar dit voor kan worden gebruikt:

• De populaire plugin Contact Form 7 laadt uit zichzelf op elke pagina en post. Je kunt het overal met één klik eenvoudig uitschakelen en alleen inschakelen op de contactpagina.
• Plugins voor het delen van sociale media mogen alleen in jouw berichten worden geladen. Je kunt het overal gemakkelijk uitschakelen en alleen laden op posttypes, of zelfs op aangepaste posttypes.
• De inhoudsopgave plugin (TOC) wordt op elke pagina en post geladen. Met de script manager kan je gemakkelijk bepalen waar jij het wilt inladen.

Waarom zijn sommige plugins op deze manier geprogrammeerd?

Je vraagt je misschien af waarom alle ontwikkelaars van plugins hun scripts niet alleen laden als de plugin op de pagina wordt gedetecteerd? Welnu, het ligt iets ingewikkelder dan dat. Als je bijvoorbeeld een plugin neemt zoals Contact Form 7, heeft deze ook een shortcode waarmee je deze overal kunt plaatsen. Dit betekent ook het invoegen in een widget. Met WordPress is het veel moeilijker om gegevens op te vragen wanneer je scripts uit de wachtrij haalt, in tegenstelling tot het opvragen van gegevens uit de bericht- of pagina-metadata.

Daarom is dit vaak het gevolg van problemen met de bruikbaarheid. Hoe minder kans er is dat een plugin breekt, des te minder tickets en ondersteuning ze zullen hebben. Met veel plugins op de markt zijn er echter manieren om dit te omzeilen en te programmeren voor prestaties als ze dat wilden. Helaas maakt het grote aantal downloads en gebruikers het programmeren voor bruikbaarheid soms een prioriteit.

Rondreis door de Script Manager

We zullen je een beetje rondleiden door de Script Manager. Nadat je op de werkbalk hebt geklikt, krijg je alle scripts te zien die worden geladen op die huidige URL, zowel JavaScript- als CSS-bestanden. Je hebt dan de volgende opties:

1. Status On (Standaard instelling)
2. Status Off: overal uitgeschakeld (hierna kun je kiezen voor welke posttypes je het ingeschakeld wilt hebben, in combinatie met de huidige URL)
3. Status Off: uitgeschakeld op de huidige URL (dit is heel bruikbaar voor gebruik op de homepagina)
4. Status Off: uitzondering (huidige URL, posttype of archief)

Alles is gegroepeerd op plugin of thema naam. Dit maakt het super eenvoudig om een volledige plugin in een keer uit te schakelen. Meestal heeft een WordPress plugin zowel een JavaScript- als een CSS-bestand. Een WordPress-thema kan uit meer dan 10 bestanden bestaan.

Nadat je de instellingen hebt geselecteerd en de instellingen hebt gewijzigd, klik je onderaan op ‘Opslaan’. Je kunt vervolgens in een website snelheid tool testen of de scripts niet langer op de pagina of post worden geladen. Zorg er wel voor dat je eerst je cache wist! En als er iets verkeerd gaat op jouw site, kan je het altijd weer inschakelen om alles weer normaal te krijgen.

In een snelheidstest van woorkup konden ze de totale laadtijden met 20,2% verlagen. Alleen al op hun homepagina konden ze het aantal HTTP-verzoeken verlagen van 46 naar 30. Hun pagina grootte nam ook af van 506,3 KB naar 451,6 KB.

Voor andere manieren om scripts uit te schakelen, bekijk ons uitgebreid artikel over hoe je WordPress plugins kunt uitschakelen.

Analyseer prestaties van externe partijen

Kortom, alles wat je extern vanaf jouw site aanroept, heeft gevolgen voor de laadtijd. Wat dit probleem alleen maar erger maakt, is dat sommige van hen slechts af en toe traag zijn, waardoor identificatie van het probleem moeilijker wordt.

Een externe service kan worden beschouwd als iets dat communiceert met jouw WordPress site van buiten jouw eigen server. Hier zijn een aantal voorbeelden die we regelmatig tegenkomen:

• Social media platforms zoals Twitter, Facebook en Instagram (widgets of conversiepixels)
• Externe advertentienetwerken zoals Google Adsense, Media.net, BuySellAds, Amazon Associates
• Website-analyse en tracking-scripts zoals Google Analytics, Crazy Egg, Hotjar, en AdRoll
• A/B-testtools zoals Optimizely, VWO, Unbounce
• WordPress reactiesystemen zoals Disqus, Jetpack, Facebook reacties
• Back-up- en beveiligingshulpmiddelen zoals VaultPress, Sucuri, CodeGuard
• Social sharing-tools zoals SumoMe, HelloBar
• CDN netwerken zoals KeyCDN, Amazon CloudFront, CDN77 en StackPath
• Extern gehoste Javascript

Hoeveel invloed hebben sommige van deze services van derden op de prestaties? In onze eigen case study zagen we dat scripts van derden de laadtijd van de pagina met 86,08% verhoogden.

Ghostery heeft ook de top 500 Amerikaanse domeinen in Alexa gemeten en de resultaten waren verbluffend – hoewel, voor ons niet verrassend. Websites waren 2x langzamer wanneer er helemaal geen trackers werden geblokkeerd. Dit betekent dat deze tracking-scripts van externe partijen een van de belangrijkste oorzaken zijn van trage laadsnelheden op het web.

Je moet heel voorzichtig zijn op je WordPress site. Slechts één slechte externe API-aanroep kan je hele site een time-out opleveren! Ja, het zou niet zo moeten werken, maar in veel gevallen is dit wel het geval. We hebben het vaker gezien.

New Relic biedt een uitstekende en eenvoudige manier om jouw externe diensten te controleren. In dit onderstaande voorbeeld kunnen externe oproepen worden weergegeven aan twitcount.com, graph.facebook.com en widgets.pinterest.com.

Het is belangrijk dat elke keer wanneer je een nieuwe functie of plugin aan de site toevoegt, je de externe bronnen die hiermee worden geladen, onderzoekt. Hoe minder hoe beter!

Optimaliseer altijd volgens het Mobile-First principe

Google begon zijn mobile-first index op 26 maart 2018 uit te rollen. Voorheen gebruikten de crawl-, indexerings- en classificatiesystemen van Google de desktopversie van websites. Mobile-first indexeren betekent dat Googlebot nu de mobiele versie van jouw WordPress site gebruikt voor indexering en rangschikking. Dit helpt de zoekervaring voor mobiele gebruikers te verbeteren.

Als het gaat om het optimaliseren van jouw site voor mobiel, is snelheid een van de belangrijkste factoren waarop je kunt concentreren. Snelheid speelt een belangrijke rol bij alles, van bruikbaarheid tot bounce percentages en het bepalen of potentiële kopers terugkomen naar jouw site. In feite is snelheid nu landing page factor voor Google Zoeken en Advertenties voor mobiele zoekopdrachten.

Slechte mobiele ervaringen zullen ertoe leiden dat de meeste gebruikers niet meer terugkomen. Volgens het laatste rapport van de Google Page speed was de gemiddelde laadtijd van een mobiele site in 2018 15 seconden. Kun je je voorstellen dat je zo lang moet wachten om een enkele pagina te laden? Verbazingwekkend.

Gebruikers vragen (en verdienen) beter. Volgens hetzelfde Page speed Rapport verlaat 53% van de bezoekers van mobiele sites pagina’s die langer dan een magere 3 seconden duren om te laden.

Langzame mobiele ervaringen stoppen geen conversies. Ze voorkomen dat je zelfs een kans krijgt om te converteren. Naarmate de laadtijd van pagina’s met slechts een paar seconden toeneemt, neemt de kans dat iemand bounced exponentieel toe. Hier zijn een paar dingen om rekening mee te houden bij het optimaliseren voor mobiel.

Bekijk jouw mobiele verkeer

Het is altijd belangrijk om te kijken hoeveel mobiel verkeer je hebt, omdat dit de prioriteiten misschien een beetje kan veranderen. Je kunt zien hoeveel mobiele apparaten de site bezoeken in Google Analytics onder “Publiek → Mobiel → Overzicht.” Zoals je op deze site kunt zien, is meer dan 67% van het verkeer een mobiele apparaat. Dat is veel!

Als je klant bij Kinsta bent, kan je ook mobiel versus desktop verkeer bekijken in MyKinsta Analytics. Zoals je kunt zien, is meer dan 88% van het verkeer afkomstig van de desktop. Het is altijd belangrijk om te controleren en niet alleen te veronderstellen. Alleen omdat iedereen zegt dat dingen mobiel worden, betekent niet altijd dat het voor jouw site ook zo is. Kijk naar de gegevens.

Zorg ervoor dat jouw site responsief is

In 2020 moet jouw website responsief zijn! Dit betekent dat het media-query’s gebruikt om dingen automatisch te schalen op mobiele apparaten. Als je dit nog steeds niet hebt gedaan, loop je waarschijnlijk al achter op je concurrenten. Alle WordPress thema’s die we eerder in dit bericht noemden, zijn volledig responsief en zien er geweldig uit op alle apparaten.

Gebruik de Mobile-Friendy tool van Google om te testen en er zeker van te zijn dat jouw website aan alle vereisten voldoet.

Controleer dubbel om er zeker van te zijn dat srcset werkt

In het verleden was het erg belangrijk dat je afbeeldingen uploadde om te schalen en CSS niet de grootte ervan te laten wijzigen. Dit is echter niet meer zo belangrijk aangezien WordPress 4.4 nu responsieve afbeeldingen ondersteunt (niet verkleind door CSS). WordPress maakt automatisch verschillende grootten van elke afbeelding die is geüpload naar de mediabibliotheek. Door de beschikbare grootte van een afbeelding op te nemen in een srcset attribuut, kunnen browsers er nu voor kiezen de meest geschikte grootte te downloaden en de andere te negeren. Bekijk hieronder een voorbeeld van hoe de code eruit ziet.

Vanwege alle externe afbeelding plugins en aanpassingen die er zijn, is het vaak voorgekomen dat we hebben gezien dat dit niet goed werkt. Daarom is het belangrijk om te controleren of jouw afbeeldingen correct het srcset attribuut toegevoegd krijgen met verschillende versies voor verschillende schermformaten. Beeldoptimalisatie is vanaf nu voor altijd belangrijk.

Misschien is Google AMP een oplossing voor jou

Google AMP (Accelerated Mobile Pages Project) is oorspronkelijk gelanceerd in oktober 2015. Het project is gebaseerd op AMP HTML, een nieuw open framework dat volledig is opgebouwd uit bestaande web-technologieën, waarmee websites lichtgewicht webpagina’s kunnen maken. Simpel gezegd biedt het een manier om een uitgeklede versie van jouw huidige webpagina te presenteren.

We hebben een soort haat liefde verhouding met Google AMP, en dat geldt voor veel van ons in de community. We hebben dit zelf getest en zagen geen goede resultaten. Dat betekent echter niet dat jij dat niet zult doen. Elke website is anders en Google AMP wordt voortdurend verbeterd.

Je kan snel aan de slag met Google AMP op jouw WordPress site met een van de volgende plugins:

• AMP for WordPress
• AMP for WP

Bekijk ons uitgebreide artikel over hoe je Google AMP kunt instellen. En als je het nodig hebt, hoe je Google AMP uit kunt schakelen. Het is niet iets dat je kunt uitschakelen en je er klaar mee bent.

Sammenvatting

Zoals je waarschijnlijk hebt opgemerkt, wij zijn geobsedeerd door alle verschillende manieren waarop je WordPress sneller kunt maken. Een snelle site helpt je ranking te verbeteren, verbetert de crawlbaarheid voor zoekmachines, verbetert de conversie, verhoogt de tijd van mensen op je site en verlaagt je bounce rate. Om nog maar te zwijgen over het feit dat iedereen graag een snelle website bezoekt!

We hopen dat deze gids over snelheid nuttig was en dat je een aantal dingen hebt kunnen gebruiken en toepassen op jouw WordPress site. Als dat zo is, neem dan even de tijd en deel dat.

Misten wij iets belangrijks? Als dat zo is, horen we dat graag. Laat ons weten wat jouw tips zijn om WordPress sneller te maken in de reacties.