Een WordPress-pagina bestaat niet. Hij wordt bij elk bezoek opnieuw in elkaar gezet. Je tekst staat in een database, je menu ergens anders, je instellingen weer ergens anders. Bij elk bezoek worden al die stukken opgehaald en samengevoegd.
Dat ophalen gebeurt met vragen aan je database. Die vragen heten queries.
Zolang het er tientallen zijn, merkt niemand er iets van. Bij honderden wordt je site merkbaar traag.
Het is de meest onzichtbare oorzaak van traagheid die er is. Je afbeeldingen zie je, je scripts zie je, maar dit gebeurt volledig buiten beeld.
Elke pagina stelt vragen aan je database. Te veel vragen maakt hem traag.
Wat is een query?
Een query is een vraag aan je database. In gewone taal: geef me de tekst van pagina 42. Of: geef me de laatste vijf berichten.
De database zoekt dat op en stuurt het antwoord terug. PHP plakt het resultaat in je sjabloon.
Het verschil met zoeken in Google
Verwarrend genoeg heet een zoekopdracht in Google ook een query. Dat is een ander begrip met dezelfde naam.
Hier gaat het over de technische kant: een opdracht aan je eigen database. Niet over wat iemand intypt in een zoekmachine.
Hoeveel zijn er normaal?
Een schone WordPress-installatie doet er ongeveer twintig tot vijftig per pagina. Dat is prima.
Met een handvol plugins loopt dat op naar honderd. Ook dat is nog werkbaar.
Kom je boven de driehonderd, dan is er iets mis. Dan zit er meestal een plugin tussen die bij elk bezoek iets zwaars doet. Meer daarover lees je bij plugin.
Waarom het traag wordt
Drie oorzaken die ik tegenkom
Te veel vragen, elk klein maar samen zwaar.
Een enkele trage query die seconden kost.
Een database zonder de juiste sorteerindex.
Die tweede is de vervelendste. Een filter over duizenden producten kan een vraag stellen waar de database minuten over doet.
Dat merk je pas als er echt bezoek komt. Op een lege testomgeving lijkt alles snel.
Hoe je het ziet
Met een hulpmiddel dat per pagina toont hoeveel vragen er zijn gesteld en welke het langst duurden.
Dat is werk voor je bouwer, maar de uitkomst is voor jou leesbaar. Je krijgt een lijst met de zwaarste vragen en waar ze vandaan komen.
Meestal wijst dat direct een plugin aan. Meer over die kant lees je bij backend.
Wat caching eraan doet
Veel, en dat is de reden dat het zo effectief is. Een cache bewaart het eindresultaat van een pagina.
De volgende bezoeker krijgt dat opgeslagen resultaat. Er wordt dan geen enkele vraag meer gesteld aan je database.
Dat maakt caching het krachtigste middel tegen dit probleem. Alleen werkt het niet overal: een winkelwagen of een klantomgeving moet per bezoeker worden opgebouwd. Daar helpt alleen het opruimen van de oorzaak. Meer daarover lees je bij pagespeed.
Meet op de juiste pagina
Doe je meting op een pagina die traag aanvoelt en niet op je homepage. Die is vaak juist het beste geoptimaliseerd.
Een overzichtspagina met filters of een categoriepagina met veel producten is meestal de plek waar het knelt.
Het aantal zegt niet alles
Vijftig zware vragen zijn erger dan tweehonderd lichte. Kijk dus niet alleen naar het aantal maar ook naar de duur.
Bij oude sites kom ik soms getallen boven de duizend tegen. Dan is de site niet traag door de afbeeldingen maar door wat er onder de motorkap gebeurt.
Waarom een webshop anders is
Een winkelwagen kan niet uit een cache komen, want die verschilt per bezoeker. Daar helpt alleen het opruimen van de oorzaak.
Een webwinkel stelt daardoor zwaardere eisen aan je server. Zwaarder dan een bedrijfssite van tien pagina’s.
Meer vragen over Query
Dit zijn de vragen die ik hierover het vaakst krijg. Ik werk ze los uit.
Wat is een query?
Hoeveel queries doet een WordPress-pagina?
Waarom maken queries je site traag?
Hoe zie je welke query traag is?
Wat doet caching met queries?
Wat is het verschil tussen een query en een zoekopdracht in Google?
Wat is een query?
Een schone installatie doet er ongeveer twintig tot vijftig per pagina. Dat is prima en dat merkt niemand.
Met een handvol plugins loopt dat op naar honderd. Ook dat is nog werkbaar op een fatsoenlijke server.
Kom je boven de driehonderd, dan is er iets mis. Dan zit er meestal een plugin tussen die bij elk bezoek iets zwaars doet.
Ik kom bij oude sites soms getallen van boven de duizend tegen. Dan is de site niet traag door de afbeeldingen maar door wat er onder de motorkap gebeurt.
Het aantal zegt overigens niet alles. Vijftig zware vragen zijn erger dan tweehonderd lichte. Meer daarover lees je bij plugin.
Laat dit een keer meten als je site traag aanvoelt zonder duidelijke reden. Boven de driehonderd per pagina is er iets mis.
Meestal wijst zo’n meting direct een plugin aan die bij elk bezoek iets zwaars doet. Laat het hulpmiddel daarna weer verwijderen, want het hoort niet op een live site.
Hoeveel queries doet een WordPress-pagina?
Een query is een vraag aan je database. In gewone taal: geef me de tekst van pagina 42, of geef me de laatste vijf berichten in deze categorie.
De database zoekt dat op en stuurt het antwoord terug. Daarna wordt het resultaat in je sjabloon geplakt en naar de browser gestuurd.
Een WordPress-pagina bestaat namelijk niet als bestand. Hij wordt bij elk bezoek opnieuw in elkaar gezet.
Je tekst staat in een database, je menu ergens anders, je instellingen weer ergens anders. Bij elk bezoek worden al die stukken opgehaald en samengevoegd.
Verwarrend genoeg heet een zoekopdracht in Google ook een query. Dat is een ander begrip met dezelfde naam. Hier gaat het over de technische kant.
Je hoeft hier niets mee te doen als beheerder. Het verklaart wel waarom een site traag kan zijn terwijl je afbeeldingen klein zijn.
Dit gebeurt volledig buiten beeld, en het is de meest onzichtbare oorzaak van traagheid die er is.
Waarom maken queries je site traag?
Om drie redenen die ik in de praktijk tegenkom.
Te veel vragen, elk klein maar samen zwaar. Elke vraag kost even tijd, en honderden keren even is bij elkaar een halve seconde.
Een enkele trage vraag die seconden kost. Dat is de vervelendste, want die valt in een gemiddelde niet op.
En een database zonder de juiste sorteerindex, waardoor er telkens door alles heen gezocht moet worden.
Die tweede zie je vaak bij een filter over duizenden producten. Op een lege testomgeving lijkt alles snel, want er staat weinig in. Met echte gegevens erin loopt het vast.
Test je site met echte gegevens erin en niet op een lege testomgeving. Daar lijkt alles snel.
Een filter over duizenden producten gedraagt zich compleet anders dan hetzelfde filter over twintig producten. Vraag daarom altijd om een testomgeving met een kopie van je echte gegevens. Op een lege database presteert alles goed. Zonder die kopie test je een situatie die niet bestaat.
Hoe zie je welke query traag is?
Met een hulpmiddel dat per pagina toont hoeveel vragen er zijn gesteld en welke het langst duurden.
Dat installeer je tijdelijk en haal je daarna weer weg. Het is niet iets wat je permanent op een live site laat staan.
Je krijgt dan een lijst met de zwaarste vragen en waar ze vandaan komen. Meestal wijst dat direct een plugin aan.
Dat is werk voor je bouwer, maar de uitkomst is voor jou leesbaar. Je hoeft geen code te snappen om te zien dat plugin X verantwoordelijk is voor tachtig vragen.
Doe die meting op een pagina die traag aanvoelt, niet op je homepage. Die is vaak juist het beste geoptimaliseerd. Meer daarover lees je bij backend.
Laat je bouwer dit tijdelijk meten en het hulpmiddel daarna weer verwijderen. Het is niets voor permanent gebruik.
De uitkomst is voor jou leesbaar: je hoeft geen code te snappen om te zien welke plugin de meeste vragen stelt.
Wat doet caching met queries?
Heel veel, en dat is de reden dat caching zo effectief is.
Een cache bewaart het eindresultaat van een pagina. De volgende bezoeker krijgt dat opgeslagen resultaat te zien.
Er wordt dan geen enkele vraag meer gesteld aan je database. Het verschil tussen tweehonderd vragen en nul is enorm.
Alleen werkt het niet overal. Een winkelwagen, een klantomgeving of een pagina met een live voorraadstand moet per bezoeker worden opgebouwd.
Daar helpt alleen het opruimen van de oorzaak. Dat is precies waarom een webshop andere eisen stelt aan je hosting dan een bedrijfssite met tien pagina’s. Meer daarover lees je bij cache.
Zet caching aan als je dat nog niet hebt. Het verschil tussen tweehonderd vragen en nul is enorm.
Houd er rekening mee dat het niet overal werkt. Een winkelwagen of klantomgeving moet per bezoeker worden opgebouwd. Vraag je bouwer welke pagina’s wel en niet uit de cache komen.
Is je website traag zonder dat je begrijpt waarom? Stuur me de link via het formulier hieronder. Ik meet hoeveel vragen je pagina’s aan de database stellen en welke plugin de meeste tijd kost. Dat is vaak de verborgen oorzaak. Vermeld je plaats, dan weet ik meteen waar je zit.
Waar kan ik je mee helpen?
Ook bekend als: Database-opdracht, zoekopdracht, databasevraag
