99
Delen

We hebben de afgelopen jaren veel tutorials gepubliceerd met manieren om WordPress te optimaliseren en te versnellen. Maar soms is het lastig zijn om alles wat je nodig hebt op één plek te vinden. Dus vandaag gaan we alles wat we weten over het versnellen van WordPress, meer dan 15 jaar aan ervaring en harde lessen, allemaal in één ultieme gids met jou delen. Of je nu net met WordPress begint of een doorgewinterde ontwikkelaar bent, we beloven dat je iets nuttigs zult vinden in deze blog!

Meer dan 34% van het internet wordt nu mogelijk gemaakt door WordPress. Hoewel dit geweldig is, betekent dit ook dat er duizenden verschillende thema’s, plug-ins 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 waarom of zelfs waar 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. Maar vandaag duiken we 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 van onschatbare waarde voor ons 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, omdat je niet elke kwestie op dezelfde manier kunt aanpakken. We geven WordPress sites altijd een classificatie: statisch of dynamisch. Laten we dus eerst de verschillen tussen deze twee type sites onderzoeken.

Voornamelijk Statische Websites

Statisch zijn meestal sites zoals blogs, kleine bedrijfssites, nieuwssites met een lager volume, 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 ongelooflijk belangrijk omdat veel van de verzoeken direct vanuit cache op de server kunnen worden aangeleverd met razendsnelle snelheden! Maak je geen zorgen; we duiken verderop in het onderwerp caching. Dit betekent dat ze minder database aanvragen zullen hebben en dat niet zo veel resources nodig zijn om de prestaties van Google te bereiken.

Zeer Dynamische Websites

Aan de andere kant hebben we dynamische sites. Hieronder vallen sites zoals eCommerce (WooCommerce of Easy Digital Downloads) websites, communities, lidmaatschap websites, forums (bbPress of BuddyPress) en Studeer management-systemen (LMS). Met dynamisch bedoelen we dat de gegevens op deze WordPress sites regelmatig veranderen (server transacties 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 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”.

Je kan niet alle WordPress websites hetzelfde behandelen als het gaat om prestaties. Statische en zeer dynamische websites zijn twee verschillende beesten! 🦖 Click to Tweet

Kies voor Hoog Presterende WordPress hosting

Een WordPress host is een bedrijf dat alle gegevens van jouw website opslaat. Je schrijft in voor 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 naar jouw bezoekers te leiden. Best simpel, toch? Nou ja, niet helemaal.

Er zijn drie heel verschillende types WordPress hosts die je op internet tegenkomt. 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 hoofdpijn 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 EIG-bedrijven zoals Bluehost en HostGator, evenals providers zoals Siteground, GoDaddy en InMotion Hosting. 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 gedeelde hosts de neiging hebben om hun servers te overbelasten, wat op zijn beurt de prestaties van jouw site kan beïnvloeden. Site schorsingen of het zien van 500 fouten zijn veelvoorkomende dingen die je zult ervaren, omdat ze alles moeten beperken en middelen moeten balanceren om te overleven. Of nog erger, down-time van websites. Ook al weet je het niet, jouw WordPress site zit waarschijnlijk op dezelfde server als 200+ andere mensen. Alle problemen met andere sites, kunnen overlopen naar jouw site.

Shared WordPress hosting

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

De meeste van deze hosts bieden ‘onbeperkte’ pakketten aan. Je hebt dit waarschijnlijk allang een keer gezien. Helaas, er bestaat niet zoiets als onbeperkte resources in de echte wereld. Wat de hosts achter de schermen doen, is de resources beperken van klanten die grootverbruiker zijn. Dit resulteert op zijn beurt weer met 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 plannen pusht en klanten aanmeldt waarvan ze hopen dat ze niet veel resources zullen gebruiken en up-sells aan kunnen kopen.

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.

Als het gaat om shared hosting, krijg je ook meestal waar je voor betaalt. 😒 Click to Tweet

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

2. DIY VPS WordPress Hosting

Het tweede type WordPress hosting is DIY VPS, of “Do it yourself” op een virtual private server. Deze groep bestaat meestal uit bootstrap start-ups en gebruikers met wat meer ontwikkeling, serverbeheer en WordPress-ervaring. Ze zijn de doe-het-zelf menigte. 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. Veel voorkomende instellingen 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. Dus, afhankelijk van je opstelling, zou je kunnen kijken 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 geweldig 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 verwerkt alle back-end server gerelateerde taken voor jou en bieden 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 back-ups. Hun ondersteuningsteams zullen meer kennis hebben als het gaat om het kennen van hun weg in het CMS, omdat ze dagelijks op één platform zijn gericht.

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

Plannen voor beheerde WordPress-hosting variëren doorgaans van $ 25 tot $ 150 per maand of meer, afhankelijk van de grootte van uw 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 beheerde WordPress-hosts die u waarschijnlijk kent, of misschien ook op dit moment gebruiken, zijn WP Engine, Flywheel, Pressable, Media Temple, Pressidium en Pagely.

Kinsta maakt gebruik van een andere aanpak

Kinsta tilt managed WordPress-hosting echter naar een hoger 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 speciale infrastructuur.

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

Kinsta hosting architectuur

Kinsta hosting architectuur

Elke site-container wordt uitgevoerd op virtuele machines in een van meerdere GC-datacenters. Elke machine heeft maximaal 96 CPU’s en honderden GB RAM. Hardware resources (RAM / CPU) worden automatisch toegewezen aan elke site-container door onze virtuele machines op basis van behoefte (een handige functie die wij automatische schaling noemen).

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. 🤘

In essentie had Kinsta de perfecte LoadStorm- en Blitz-test resultaten. Ook in de andere testen waren er geen tekortkomingen. Er zijn niet genoeg woorden om hun prestaties aan te prijzen.
Kevin Ohashi
Kevin Ohashi
Founder en WP consultant, ReviewSignal

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 plug-ins hebben gemaakt en hebben bijgedragen aan de WordPress kern. 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 die onze Fortune 500- en zakelijke klanten ondersteunen. We zijn zo kieskeurig over de kwaliteit van ons ondersteuningsteam dat we minder dan 1% van de sollicitanten aannemen die solliciteren. Je zult nergens anders betere ondersteuning vinden!

Bij WP Engine worden basisproblemen meestal snel opgevangen. Voor problemen die complexer zijn, zal een oplossing enige tijd in beslag nemen en zal er veel communicatie heen en weer zijn. Dit is een probleem wanneer je een high-end WordPress site hebt en er een dringend probleem is dat snel moet worden aangepakt. Als je om mijn aanbeveling tussen de twee vraagt, is Kinsta naar mijn mening beter. Ze bieden veel meer dan ze beloven. Je hoeft nooit zorgen te maken over traagheid van de site, downtime, kwaliteitsondersteuning of andere hosting gerelateerde problemen.
Harsh Agrawal
Harsh Agrawal
Award winnende Blogger, ShoutMeLoud

Om meer te weten te komen waarom je voor de managed WordPress hosting van Kinsta zou moeten kiezen kun je het artikel Waarom wij — Hoe Kinsta anders is. Maar 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 kern is geschreven in PHP, samen met je plug-ins 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 zal bieden, 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.

WordPress 5.0 PHP benchmarks

WordPress 5.0 PHP benchmarks

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.

Wijzig PHP versie

Wijzig PHP versie

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 prestatieverbetering. 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.

Nginx

Een aantal spraakmakende bedrijven die NGINX gebruiken 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 voor 41.9% van hen verantwoordelijk, 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 showdown van onze webserver: 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.

Kinsta maakt gebruik van het premium netwerk van Google Cloud Platform. Simpel weg omdat jouw website het beste verdient. ⚡ Click to Tweet

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.

Google Cloud Platform premium tier network

Google Cloud Platform premium tier network (Image source: Google)

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!

Voor gegevens die intercontinentaal reizen is het premium netwerk van Google Cloud gemiddeld 41% sneller! 💥 Click to Tweet

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 betrokken is bij het verzenden van

gegevens over een netwerk. Met andere woorden: hoe lang het duurt voordat een gegevenspakket van het ene punt naar het andere gaat. Tegenwoordig wordt dit meestal gemeten in milliseconden; het kan echter seconden zijn, afhankelijk van het netwerk. Hoe dichter bij nul, hoe beter.

Bekijk ons uitgebreide artikel over network latency.

TTFB: dit betekent Tijd Voor De Eerste Byte. Simpel gezegd: dit is de tijd hoe lang de browser moet wachten voordat hij zijn 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 het beste locatie bepalen door de onderstaande tips te volgen.

Tip 1 — Check de Geologische Locatie van Jouw Bezoekers in Google Analytics

Een van de allereerste dingen die je kan doen, is 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 de meeste gevallen 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.

Google Analytics Geolocatie

Google Analytics Geolocatie

Tip 2 — Bekijk E-commerce Data

Als u een eCommerce winkel hebt, moet je ook controleren waar de klanten vandaan komen. Dit is natuurlijk hoe jij inkomsten genereert, dus dit zijn de belangrijkste bezoekers. Dit moet samenvallen met het bovenstaande verkeer; ook al is dit echter niet altijd het geval. Als je eCommerce 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 eCommerce-platform controleren.

Tip 3 — Doe een Snelle Latency Test

There are a lot of handy free tools out there to measure latency from your current location for different cloud providers. This can help you quickly evaluate which region might be the best choice for your site.

  • 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 dit 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.

Meet de latency van het Google Cloud Platform

Meet de latency van het Google Cloud Platform

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

Locaties van Google Cloud datacentra

Locaties van Google Cloud datacentra

Andere Manieren om Latency en TTFB te Reduceren

Naast het kiezen van een server locatie dichtbij de 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 verbazingwekkende 90%!
  • Maak gebruik van een content delivery netwerk (CDN) om de gecachde assets via POPs over de hele wereld 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 achter de schermen al taken uit te voeren terwijl de pagina laad.

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. Het datacenter locatie die je kiest, heeft invloed op hoe snel jouw SFTP-download en upload snelheden (bestanden overzetten met een FTP-client) zijn, evenals de reactietijd van je WordPress dashboard.

Dus terwijl je zeker wilt zijn en een locatie kiest die het beste is voor je bezoekers, moet je er rekening mee houden dat dit van invloed kan zijn op het site beheer. 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 consequent 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 20 verschillende datacenters hebben is een grote factor! 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 Domein Naam Systeem, is een van de meest voorkomen maar onbegrepen component van het web landschap. Simpelweg: DNS helpt om het verkeer van het internet de juiste richting in te wijzen bij het verbinden van domeinen met de actuele servers. In essentie: DNS verwerkt een mens-vriendelijk verzoek — een domein als kinsta.com om te zetten naar een computer-vriendelijk server IP-adres — zoals 216.58.217.206.

Hoe DNS werkt

Hoe DNS werkt

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 registreerder krijgt relatief traag, terwijl premium DNS vaak betere prestaties biedt. In onze tests vonden 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 verwerken.

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 gratis DNS snelheidstest

Cloudflare gratis DNS snelheidstest

Eén kanttekening bij Cloudflare is echter dat het ook meer downtime heeft dan veel andere providers. Als je voornamelijk bezoekers in de Verenigde Staten van hebt, is DNS Made Easy een geweldige premium DNS-provider die je misschien wilt bekijken. Ze hebben de reputatie de beste DNS-uptime te bieden in het afgelopen decennium.

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

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 value (TTL) op het DNS-record. Daarom, als een DNS-provider 10 minuten lang niet doorgaat, zal je waarschijnlijk niets merken. 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 er eentje kiest met allemaal nieuwe shiny functies. Eerst moet je ons artikel over de verschillen bekijken als het gaat om gratis versus betaalde thema’s. In relatie tot de prestaties heeft elk element dat je in een thema ziet, enige invloed op de algehele snelheid van je website. En helaas, met duizenden thema’s in het wild, zijn er goede en slechte.

Jouw WordPress thema maakt uit in relatie met de snelheid. Kies de juiste vanaf het begin. 💪 Click to Tweet

Hoe moet je nou weten welk thema je moet kiezen? Wij raden aan om 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, niets meer.
  • Een meer feature-rijk WordPress thema, maar je kunt functies uitschakelen die niet in gebruik zijn.

Dingen zoals Google Fonts, Font Awesome pictogrammen, schuifregelaars, galerijen, video- en parallax-scripts, enz. Dit zijn slechts enkele van de vele dingen die je 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 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 is gebruikt 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).

GeneratePress

GeneratePress

Een van de geweldige dingen van GeneratePress is dat alle opties de native 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 thema kan in termen van onbewerkte prestaties.

GeneratePress snelheidstest voor een nieuwe installatie

GeneratePress snelheidstest voor een nieuwe installatie

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 plug-in voor het maken van een pagina is vereist. Je kunt zien dat het nog steeds onder de 400 ms is.

Complete website snelheidstest voor GeneratePress

GeneratePress full website speed test

Nu heb je in een echte omgeving andere dingen draaien, zoals Google Analytics, Facebook-remarketingpixel, Hotjar, enz. Maar je zou gemakkelijk onder de 1 seconde kunnen blijven. Bekijk 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).

OceanWP Thema

OceanWP Thema

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 niet waard om over naar huis te schrijven.

OceanWP snelheidstest met een nieuwe installatie

OceanWP snelheidstest met een nieuwe installatie

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.

 Complete website snelheidstest voor OceanWP

OceanWP full website speed test

Je kunt een uitgebreid 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 door het team van Brainstorm Force en 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).

Astra WordPress Thema

Astra WordPress Thema

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.

Astra snelheidstest met een nieuwe installatie

Astra snelheidstest met een nieuwe installatie

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.

Complete website snelheidstest voor Astra

Complete website snelheidstest voor Astra

 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 Ware Feiten over WordPress Plugins

Nu de scoop van WordPress plugins.Je hebt misschien wel eens gehoord dat j 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 het 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 normen veranderen. Mensen zijn druk bezig, 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. Je moet onthouden dat een meerderheid van de WordPress community niet zo slim is als de grote groep 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. Vertrouw 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 in 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 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.

WordFence tabellen

WordFence tabellen

En 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. En dit is niet WordFence specifiek, de meeste plugins en thema’s op de markt werken op deze manier.

WordFence logs

WordFence logs

Waarom doen Ontwikkelaars dit?

Je vraagt je waarschijnlijk af, waarom hebben ontwikkelaars geen opruim methodes hebben wanneer je een plugin deïnstalleerd en verwijdert? Nu, 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 plug-ins 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 deïnstaleren en te verwijderen 👏 Lees hiervoor onze onderstaande handleidingen:

Optimale WordPress Instellingen

Om verder te gaan naar 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 domain.com/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 raken.

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 truck 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)
Wijzig de WordPress Login URL via Perfmatters

Wijzig de WordPress Login URL via Perfmatters

Schakel uit of Tweak 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 een factoren wanneer het hebben van veel WordPress plugins en -thema’s je kunnen schaden. WeFoster heeft hierover een geweldige blogpost waarin ze de zin ““Update Controle van externe partijen syndroom“” of TPPUCS gebruiken.

In feit is het probleem 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 en soms is dit heel vaak. 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 heeft van de trage laadtijden van het WordPress dashboard, dan wil je dit misschien proberen. De oplossing is automatische updates uit te schakelen. Waarschuwing: doe dit alleen als wanneer je handmatig updates wilt controleren. Veel updates bevatten namelijk beveiliging en bugfixes.

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

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 ‘Instellingen voor discussie’ de optie ‘Meldingen van andere blogs toestaan (pingbacks en trackbacks) op nieuwe artikelen’ uit.

Disable pingback in WordPress

Disable pingback in WordPress

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.

Pingbacks Uitschakelen in WordPress

Pingbacks Uitschakelen in WordPress

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 breken 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 Posts 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 degenen die blogs met veel verkeer hebben, is de startpagina de belangrijkste pagina van de site en wil je dat deze snel wordt geladen. Hoe minder aanvragen en media hoe beter het is in termen van 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.

Paginering

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 “Blog-pagina’s tonen”.

Blog feed limiet instellen in WordPress

Blog feed limiet instellen in WordPress

Waarom is Caching zo belangrijk

Caching is verreweg een van de belangrijkste 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 query’s) 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 eruitziet zoals het eruit ziet.

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 met onhandige/ grotere websites.

Dat is waar een WordPress caching plugin om de hoek komt kijken! Caching geeft de server opdracht om sommige bestanden op schijf of RAM op te slaan, afhankelijk van de configuratie. Daarom kan het dezelfde inhoud onthouden die het 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 andere:

  • De server gebruikt 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 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 gebruik de TTFB verminderd tot wel 90%!

Caching Types

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

  1. Caching op server niveau
  2. Caching door middel van een plugin

1. Caching op Server Niveau

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:

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 van 2019” en focussen op productievere taken. 👏

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 check-out, uitgesloten van caching. Gebruikers omzeilen automatisch de cache wanneer de woocommerce_items_in_cart cookie of edd_items_in_cart worden gedetecteerd om een soepel en in-sync checkout proces te garanderen.

Je kunt de cache van jouw WordPress site  eenvoudig op elk gewenst moment wissende beheerders werkbalk.

Wissen van de Cache vanuit de WordPress Admin Toolbar

Wissen van de Cache vanuit de WordPress Admin Toolbar

Dit is ook geïntegreerd in ons MyKinsta dashboard. Klik op “Tools” en klik daarna op “Verwijder Cache.”

Verwijder de WordPress site cache

Verwijder de WordPress site cache

2. Caching via een Plugin

Als de hosting provider geen cache biedt, kan 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, maar nog steeds profiteren van de fantastische optimalisatie functies die WP Rocket te bieden heeft.

Geen Caching versus Caching

Hoeveel helpt caching? Hiervoor moet je het zelf ervaren.

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.

Geen caching snelheidstest

Geen caching snelheidstest

Geen Caching TTFB

Het is ook belangrijk om het verschil in TTFB op te merken zonder en met caching. TTFB in Pingdom wordt weergegeven door de gele “wacht” 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.

TTFB Geen Cache

TTFB Geen Cache

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.

Snelheidstest met caching ingeschakeld

Snelheidstest met caching ingeschakeld

Zoals je kunt zien met caching op serverniveau, nam onze laadtijd van de pagina met 33,77% af! 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.

TTFB met caching ingeschakeld

TTFB met caching ingeschakeld

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

WordPress caching kan makkelijk de pagina laadtijd met meer dan 33% verminderen! ⚡ Bekijk de resultaten. Click to Tweet

Problemen met Caching en Lidmaatschap Websites

Lidmaatschap sites bevatten veel niet-cachebare inhoud en pagina’s die voortdurend veranderen. Dingen 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 in the picture 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 header een waarde, Bijvoorbeeld: HIT, BYPASS, MISS en EXPIRED. Hiermee kunt u 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) kan 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.

Kinsta Cache component Stack

Kinsta Cache component Stack

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!

Kinsta cache component Diagram

Kinsta cache component Diagram

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

WordPress top cache bypasses

WordPress top cache bypasses

Afbeelding optimalisatie is een Must

Afbeeldings optimalisatie is een ander eenvoudige factor die je kunt doen 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 as of November 2018, 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. En ironisch genoeg is een goede workflow voor beeldoptimalisatie een van de gemakkelijkste dingen om te implementeren, maar toch zien veel website-eigenaren dit over het hoofd.

Gemiddelde bytes per Pagina (KB)

Gemiddelde bytes per Pagina (KB)

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.

Afbeeldingen zijn gemiddeld gezien verantwoordelijk voor 34% voor de pagina grootte. 😮 Optimaliseer ze! Click to Tweet

Vind het 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, kan 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.

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.

Lage compressie (Hoge kwaliteit) JPG — 590KB

Lage compressie (Hoge kwaliteit) JPG — 590KB

Hoge compressie (Lage kwaliteit) JPG — 68KB

Hoge compressie (Lage kwaliteit) JPG — 68KB

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.

Gemiddelde compressie (Goede kwaliteit) — 151KB

Gemiddelde compressie (Goede kwaliteit) — 151KB

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.

Lossy compressie vergelijking

Lossy compressie vergelijking

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)
  • EWWW Cloud (Lossy en Lossless compressie — optimaliseert afbeeldingen extern)
  • ShortPixel (Lossy en Lossless compressie — optimaliseert afbeeldingen extern)

Het belangrijkste bij het kiezen van een beeldoptimalisatie 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.

Als je nieuwsgierig bent: 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.

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.

Afbeelding compressie bij bestands opslag

Afbeelding compressie bij bestands opslag

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 waarop 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, hoewel 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.

Fine-tune Jouw 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.

InnoDB is als synthetische olie, waar MyISAM genoegen neemt met standaard olie. ⛽ Click to Tweet

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

  • InnoDB heeft vergrendeling op rijniveau. 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.

phpMyAdmin Database

phpMyAdmin 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.

MyISAM database tabellen

MyISAM database tabellen

Als je tabellen met MyISAM Storage Engine hebt gevonden, is het waarschijnlijk tijd om ze naar InnoDB te verplaatsen. We raden je altijd aan contact op te nemen met jouw host en te vragen of zij dit kunnen doen. Bij Kinsta worden de databasetabellen van elke klant automatisch geconverteerd naar InnoDB door ons migratieteam.

Uiteraard kun je ook deze tutorials hieronder volgen om de MyISAM-tabellen handmatig naar InnoDB te converteren:

Verwijder en Limiteer 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. Revisies kunnen nuttig zijn voor het geval dat je moet terugkeren naar een vorige versie van de inhoud.

WordPress Revisie

WordPress Revisie

Revisies kunnen echter ook de prestaties van jouw WordPress site schaden. Op grote sites kan dit zeer 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 alle slechte codefragmenten op het web raden we aan om een back-up van uw 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.

WP Rocket database Optimalisatie

WP Rocket database Optimalisatie

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

WP-CLI revisie lijst

WP-CLI revisie lijst

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. Limiteer de Revisies

Een andere goede strategie en een strategie die we bij Kinsta gebruiken, is om het aantal revisies dat per post 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, 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. Je kunt het aantal wijzigen in hoeveel revisies je in de database wilt bewaren.

define('WP_POST_REVISIONS', 10);

Limiteer het aantal post revisies in wp-config.php

Limiteer het aantal post revisies in wp-config.php

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

Limiteer het aantal post revisies met Perfmatters plugin

Limiteer het aantal post revisies met Perfmatters plugin

3. Schakel revisies uit

En last but not least, kan 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 uw 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);

Schakel post revisies uit in wp-config.php

Schakel post revisies uit in wp-config.php

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

Schakel post revisies uit met Perfmatters plugin

Schakel post revisies uit met Perfmatters plugin

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. Vertrouw 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
wp-options tabel in de WordPress Database

wp-options tabel in de WordPress Database

Deze tabel bevat de volgende velden (kolommen)

  • option_id
  • option_name
  • option_value
  • autoload (Dit is de kolom waarom het gaat in relatie tot prestaties)
Autoload gegevens

Autoload gegevens

Een van de belangrijke dingen om te begrijpen over de tabel wp_options 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 plug-in 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.

Wanneer heb je voor het laatst jouw wp_options tabel opgeruimd? Jep… dat dachten we al. 😉 Aan de slag ermee! Click to Tweet

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 na verloop van verwijdert 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!

Corrupt transients in wp_options table

Corrupt transients in wp_options table

Het is ook belangrijk om op te merken dat tijdelijke records niet standaard automatisch worden geladen. Je kunt een 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.

Opruimen van tijdelijke records met WP Rocket

Opruimen van tijdelijke records met WP Rocket

Ruim je WordPress Sessions 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 tonnen _wp_session_ rijen in je database krijgen. In dit onderstaande voorbeeld heeft de betreffende site meer dan 3 miljoen rijen in de tabel wp_options. En de tafel was groter dan 600MB geworden.

wp_options tabel met miljoenen rijen

wp_options tabel met miljoenen rijen

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_%'
wp_session rijen

wp_session rijen

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.

WP Sessions opgeruimd

WP Sessions opgeruimd

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

MySQL web transacties

MySQL web transacties

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.

wp_options query tijd

wp_options query tijd (Afbeelding bron: 10up)

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

Gebruik Redis als een Aanhoudende 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.

Redis

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 s 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.

Elasticsearch

Als je 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.orgDe 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.

Net als bij Redis hebben we ook een add-on voor Elasticsearch. Bekijk hoe je Elasticsearch aan jouw hostingpakket kunt toevoegen.

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 ‘Zelf gekozen’ 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 kan nog beter omdat jij zelf kunt kiezen wat je wilt dat lezers zien.

WordPress gerelateerde artikelen

WordPress gerelateerde artikelen

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).

Wijs gerelateerde artikelen toe

Wijs gerelateerde artikelen toe

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.

Social Warfare laadtijden

Social Warfare laadtijden

Maak gebruik van een Content Delivery Netwerk (CDN)

CDN iis 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.

Ten eerste wil je niet dat een CDN verward raakt 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 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 type 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 hiervan is dat ze fungeren als een intermediaire server, ze kunnen sterke webapplicatie-firewalls bieden die kunnen helpen voorkomen dat slecht verkeer ooit jouw WordPress site en / of hosting provider bereiken. Een nadeel hiervan is dat ze met een beetje extra overhead in termen van prestaties komen 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 dramatische impact op de hoeveelheid slecht verkeer die er doorheen kwam. Uiteindelijk kunnen dit soort services helpen te besparen op hosting kosten.

Resource verbruik na inschakeling van Sucuri WAF

Resource verbruik na inschakeling van Sucuri WAF

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 de 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.

Snelheidstest zonder CDN

Snelheidstest zonder CDN

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 is enorm veel.

De Reden voor zo’n drastisch verschil is dat de 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 zonder CDN

TTFB zonder CDN

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.

TTFB met CDN

TTFB met CDN

Een CDN verlaagde onze pagina laadtijd met 43.2%! Lees nu waarom jij ook een CDN zou moeten gebruiken. 🚀 Click to Tweet

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 rekenmachine om de kosten in te schatten.

Stap 2

Als je een traditionele pull CDN gebruikt, kan je de gratis plugin zoals CDN EnablerWP Rocket, of Perfmatters gebruiken om te integreren met de 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.

Schakel een CDN in op WordPress met Perfmatters

Schakel een CDN in op WordPress met Perfmatters

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 34 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ë.

Kinsta CDN netwerk

Kinsta CDN netwerk

Als je klant bij Kinsta bent, bieden we gratis CDN bandbreedte aan in al onze hosting pakketten. Je kunt de 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.

Kinsta CDN

Kinsta CDN

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. Dat is alles wat je hoeft te doe. 😄

Kinsta CDN inschakelen

Kinsta CDN inschakelen

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. Check out this tutorial on how to laden van gravatars vanaf je CDN. Wij doen dit ook op de Kinsta-website. 👍
  • U kunt uw aangepaste web-lettertypen hosten vanaf de CDN- of zelfs Google-lettertypen via jouw CDN hosten. Bekijk onze uitgebreide handleiding over lokale lettertypen.
  • Zorg ervoor dat je jouw favicon vanaf de CDN laadt. Hoewel het klein is, elk verzoek telt!

Offload Media en Email 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 verloopt 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 s een opslagoplossing en maakt deel uit van veel producten van de Amazon Web Services. Meestal wordt dit gebruikt voor grote sites die extra back-ups 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. Sommige klanten van S3 zijn 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.

Google Cloud storage

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

Offload Transactionele en Marketing Emails

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 voor degenen die bulkmails proberen 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 nooitann 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.

Email 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:

Transactionele Email Services

Enkele voorbeelden van transactionele e-mails zijn aankoopbonnen van WooCommerce of EDD, meldingen 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:

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 query’s 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.

New Relic Monitoring

New Relic Monitoring

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.

Langzame plugins

Langzame plugins

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 Overweldigde 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:

Web transactie tijd

Web transactie tijd

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

MySQL overzicht

MySQL overzicht

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 query’s.

Langzame query’s — wp_options tabel

Langzame query’s — wp_options tabel

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.

WordPress Query’s in de Query Monitor Plugin

WordPress Query’s in de Query Monitor Plugin

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 plug-in 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.

WordPress staging-omgeving

WordPress staging-omgeving

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.

Schakel alle WordPress plugins uit

Schakel alle WordPress plugins uit

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.

Normale reactietijden

Normale reactietijden

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.

Weer Trage reactietijden

Weer Trage reactietijden

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.

Voor en na WP Bullet

Voor en na WP Bullet

Controleer jouw 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 foutenlogboeken, cache-logboeken en toegangslogboeken bekijken via het MyKinsta-dashboard.

Foutlogboek in MyKinsta

Foutlogboek in MyKinsta

Je kunt ook foutlogboeken 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!

Download het wp-config.php bestand

Download het wp-config.php 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 );
WP_DEBUG

WP_DEBUG

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 );
WP_DEBUG_LOG

WP_DEBUG_LOG

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.

Prestatie — Gemiddelde PHP + MySQL reactietijd

Prestatie — Gemiddelde PHP + MySQL reactietijd

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.

Prestatie — PHP doorvoer

Prestatie — PHP doorvoer

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.

Admin-AJAX gebruik

Admin-AJAX gebruik

Zorg ervoor dat u 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.

AJAX gebruik

AJAX gebruik

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 Gemiddelde PHP + MySQL Reactietijd

Top Gemiddelde PHP + MySQL Reactietijd

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.

Top Maximale Upstream Tijd

Top Maximale Upstream Tijd

Je website is Misschien Gehacked

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.

Probleemoplossen 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, hieronder staan 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.

 429 teveel verzoeken

429 teveel verzoeken

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.

 Fout bij het tot stand brengen van een database verbinding

Fout bij het tot stand brengen van een database verbinding

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.

 502 Bad gateway foutmelding in de browser

502 Bad gateway foutmelding in de browser

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.

504 Gateway Timeout foutmelding in de browser

504 Gateway Timeout foutmelding in de browser

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.

Response code overzicht

Response code overzicht

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.

Response statistieken

Response statistieken

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

500 Error overzicht

500 Error overzicht

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).

404 Foutmeldingen

404 Foutmeldingen

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.

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, elke uncached 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 gebeurt 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, kan je altijd chatten met ons verkoop- of ondersteuningsteam.

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.

Content encoding: Gzip

content-encoding: gzip

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. Dit is nu vrij standaard bij de meeste hosting providers, maar op dit moment verbaasd niets ons 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 overgeheveld.

Hotlinking is hetzelfde als wegrijden op benzine die je overgeheveld hebt uit de buurman’s auto. 🚗 Click to Tweet

Hotlinking kan een enorme impact hebben op de originele server. Stel je voor dat je op een shared WordPress host zit en dat de Huffington Post 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 redirections 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) zijn 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.

Minimaliseer redirects — 301

Minimaliseer redirects — 301

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.

Snelheidstest zonder omleiding

Snelheidstest zonder omleiding

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%. Yikes!

Snelheidstest met meerdere omleidingen

Snelheidstest met meerdere omleidingen

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 Redirection hulpmiddel.

Voeg een 301 Redirect Toe

Voeg een 301 Redirect Toe

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.

Redirection overzicht

Redirection overzicht

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);
Schakel WP-Cron uit

Schakel WP-Cron uit

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.

Leverage Browser Caching — Caching Headers

Leverage Browser Caching — Caching Headers

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. Er is niets dat je kunt 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 plug-in 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.) The last-modified and etag headers both validate and set the length of the cache and should be included on every origin server response. Als deze niet correct zijn ingesteld krijg je mogelijk een waarschuwing dat je een “Cache validatie moet specificeren.”

De headers cache-control en expires helpen de browser te bepalen of het bestand is gewijzigd sinds de laatste keer dat deze werd aangevraagd (of beter gezegd: ze valideren de cache). De headers last-modified en etag valideren en bepalen de lengte van de cache, ook deze moeten worden opgenomen in elke respons van de originele server. Als deze niet correct zijn ingesteld, zie je mogelijk de waarschuwing dat je een cache-validator moet opgeven.

Last-modified en ETag HTTP headers

Last-modified en ETag HTTP headers

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.

vary: Accept-Encoding HTTP header

vary: Accept-Encoding HTTP header

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.

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

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 Geheugen Limiet in wp-config.php

Zoals vermeld in de WordPress Codex, vanaf WordPress versie 2.5, kan je 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 Services

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 qua Snelheid voor Jouw WordPress

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.

Pingdom Website snelheidstest

Pingdom Website snelheidstest

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 raad aan er een te kiezen.

Welke snelheidstest je kiest maakt niet zoveel uit als je daar maar bij blijft voor de rest van alle andere testen 🚀 Click to Tweet

2. Wordt niet Obsessief voor een Perfecte Score

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 ten opzichte van de datacenter locative je kielt is. 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 in via de cache wordt geserveerd.

MISS HTTP header

MISS HTTP header

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.

HIT HTTP header

HIT HTTP header

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

Verwijder Query Strings

Een veelvoorkomende waarschuwing of aanbeveling die mensen in snelheidstest tools zien, is dat query reeksen moeten worden verwijderd. Waar gaat dit over? Vaak hebben jouw CSS- en JavaScript-bestanden de bestandsversie aan het einde van hun URL’s, zoals https://domain.com/file.min.css?ver=4.5.3. Sommige servers en proxyservers kunnen query reeksen niet cachen. Dus door ze te verwijderen, kan je misschien de caching verbeteren.

Je kunt een premium plugin zoals Perfmatters gebruiken, die een eenvoudige optie heeft om query reeksen te verwijderen. Of je kunt de volgende code handmatig toevoegen aan het functions.php bestand van jouw thema. Een beter alternatief zou zijn om een gratis plugin, zoals Code Snippets, te gebruiken om de code toe te voegen. Op deze manier hoef je niet direct je thema te bewerken.

function remove_query_strings() {
   if(!is_admin()) {
       add_filter('script_loader_src', 'remove_query_strings_split', 15);
       add_filter('style_loader_src', 'remove_query_strings_split', 15);
   }
}

function remove_query_strings_split($src){
   $output = preg_split("/(&ver|\?ver)/", $src);
   return $output[0];
}
add_action('init', 'remove_query_strings')

Met Query Strings

Hier is een voorbeeld van scripts die geladen worden met query strings.

Met Query Strings

Met Query Strings

Zonder Query Strings

Hier is een voorbeeld van het laden van scripts nadat de query strings zijn verwijderd.

Zonder Query Strings

Zonder Query Strings

Voordat je de query reeksen op de site verwijdert, is het belangrijk om te weten waarom query reeksen worden gebruikt. Versies van bestanden worden meestal gebruikt door WordPress ontwikkelaars om cache-problemen te omzeilen.

Als een ontwikkelaar van plugins bijvoorbeeld een update pusht en style.css verandert van ?ver=4.6 near ?ver=4.7, wordt deze gezien als een geheel nieuwe URL en wordt deze niet in de cache opgeslagen. Als je de query reeksen verwijdert en een plugin bijwerkt, kan dit ertoe leiden dat de cache-versie wordt vastgehouden. In sommige gevallen kan dit het uiterlijk van je site schaden totdat de cache voor dat bestand verloopt of de cache volledig is leeggemaakt.

Ook kunnen sommige CDN’s query reeksen cachen. De Kinsta CDN kan en doet dit standaard. Dus als je klant bij Kinsta bent, zijn query reeksen al in cache opgeslagen.

Bekijk ons uitgebreid artikel over  het verwijderen van query reeksen uit statische bronnen.

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.

Elimineer render-blocking resources

Elimineer render-blocking resources

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 de aflevering 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:

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. En meer dan 86% van de browsers ondersteunt 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.

Gecombineerde CSS en Javascript bestanden

Gecombineerde CSS en Javascript bestanden

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.

Niet Geminificeerde HTML Code

Niet Geminificeerde HTML Code

Geminificeerde HTML

Hieronder staat een voorbeeld van geminificeerde HTML code.

Geminificeerde HTML code

Geminificeerde HTML code

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

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.

CDN Strip Cookie

CDN Strip Cookie

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 de impact op prestaties zijn 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 de kern. 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 grotere deal dan de download grootte van de inhoud.

wp-embed.min.js bestand

wp-embed.min.js bestand

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

Schakel Emojis 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.

wp-emoji-release.min.js

wp-emoji-release.min.js

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

Hoe 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 doen 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:

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.
Split de reacties op in pagina’s

Split de reacties op in pagina’s

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

Standaard zijn 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 we de externe DNS-lookup van gravatar.com soms traag zijn en 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.

Host Gravatar Lokaal of op een CDN

Host Gravatar Lokaal of op een 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 wel vertragen.

Disqus Externe verzoeken

Disqus Externe verzoeken

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 opmerkingen te lazy loaden, zodat ze de initiële paginaweergave niet vertragen. Hier zijn een aantal plugins die je kunt wilt bekijken:

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:

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)

Prefetch

Prefetch

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 en 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 worst 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).

Preconnect

Preconnect

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 ten premium plugin goals Perfmatters gebruiken die een ingebouwde “Script Manager” – functie heeft. Hiermee kan je scripts (CSS en JavaScript) op een per 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 plug-in 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 Table of Content 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 betekend 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 post- 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)
Perfmatters script manager

Perfmatters script manager

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 veel voorkomende 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.

Laadtijd met trackers ingeschakeld

Laadtijd met trackers ingeschakeld (Bron afbeelding: Ghostery)

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 dan we kunnen tellen.

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.

Reactietijden van externe Social Media services

Reactietijden van externe Social Media services

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 facto 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 Mobiel 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!

Mobiel verkeer in Google Analytics

Mobiel verkeer in Google Analytics

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.

Mobiel versus Desktop — MyKinsta Analytics

Mobiel versus Desktop — MyKinsta Analytics

Zorg Ervoor dat Jouw Site Responsief Is

In 2019 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.

Mobile-friendly test

Mobile-friendly test

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.

WordPress srcset

WordPress srcset

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, het biedt 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:

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. Het hebben van een snelle site helpt je rankings te verbeteren, verbetert de doorzoekbaarheid van zoekmachines, verbetert de conversieratio, verhoogt de tijd die bezoekers op de site spenderen en verlaagt de 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.