Uw site is traag: de 5 oorzaken, in de volgorde waarin u ze moet zoeken

„Mijn site is traag" beschrijft een ergernis, geen storing. Onder die zin schuilen vijf verschillende problemen, met verschillende symptomen, verschillende oplossingen en verschillende kosten. En de meeste adviezen die u vindt beginnen met de aanname dat u al weet welk probleem u heeft.

Dat is wat de meeste tijd kost. Er wordt een cachemodule geïnstalleerd voor een databaseprobleem, er worden afbeeldingen gecomprimeerd terwijl het wachten vóór hun aankomst plaatsvindt, er wordt van hosting gewisseld terwijl de traagheid komt van een advertentiescript dat maanden geleden voor een afgelopen campagne werd geplaatst.

Dit artikel geeft geen oplossingen. Het sorteert: voor elk van de vijf oorzaken het symptoom dat het aanwijst, de controle die het bevestigt, en waar u daarna heen gaat. De volgorde is niet decoratief — hij wordt aan het eind uitgelegd, en hij heeft een praktisch gevolg: zolang een oorzaak stroomopwaarts aanwezig is, zeggen de metingen daaronder niets.

Inhoud

• De vraag die het probleem in tweeën snijdt
• Oorzaak 1. De server heeft tijd nodig voordat hij antwoordt
• Oorzaak 2. Uw site maakt elke pagina bij elk bezoek opnieuw
• Oorzaak 3. De database werkt terwijl de bezoeker wacht
• Oorzaak 4. De weergave wordt geblokkeerd door wat ervoor laadt
• Oorzaak 5. De code die u niet geschreven heeft
• Waarom deze volgorde en geen andere
• De vier fouten die het meest kosten
• Veelgestelde vragen
• Wat er te doen blijft

De vraag die het probleem in tweeën snijdt

Vóór de vijf oorzaken doet één enkele vraag de helft van het werk:

Vindt het wachten plaats voordat er iets verschijnt, of terwijl de pagina zich voor uw ogen opbouwt?

Bekijk uw eigen site op een gewone verbinding, en beschrijf wat u ziet:

• het scherm blijft wit, daarna komt alles bijna tegelijk → het wachten ligt vóór de eerste byte. Zoek bij oorzaak 1, 2 en 3;
• er verschijnt snel iets, daarna valt de rest langzaam op zijn plaats, in stukken → het wachten ligt erna. Zoek bij oorzaak 4 en 5.

Deze waarneming kost niets en schrapt de helft van de sporen. U bevestigt hem daarna met een cijfer: de serverreactietijd, die elk meetinstrument los van de rest toont. Het is de vertraging tussen het verzoek van de browser en de eerste ontvangen byte — vóór elke weergave, elke afbeelding, elk script.

Nog één reflex voordat u iets aanraakt: de huidige staat veiligstellen. Een diagnose breekt niets, maar de correcties die volgen wel.

Oorzaak 1. De server heeft tijd nodig voordat hij antwoordt

Het symptoom. Alles is traag, ook pagina's die vrijwel niets bevatten — een colofon, een contactformulier, de pagina van een kort artikel. De vertraging hangt niet af van de inhoud van de pagina, niet van het moment, en niet van de bezoeker.

Wat het bevestigt. De serverreactietijd is hoog op een bewust schrale pagina. Dat is het belangrijke punt: de homepage meten bewijst niets, een homepage is bijna altijd de zwaarste pagina van de site. Neem de leegste pagina die u heeft.

Wat het betekent als het dat niet is. Een server die snel antwoordt op een schrale pagina maar traag op een rijke wijst niet naar de hosting: hij wijst naar wat die pagina extra doet — ofwel oorzaak 2, ofwel oorzaak 3.

Waarom dit de eerste is om uit te sluiten. Als het antwoord traag is nog voordat de opbouw begint, zal geen enkele weergaveoptimalisatie zichtbaar zijn. U wint tienden op een post die niet de dure is, en concludeert dat „niets werkt".

De veelvoorkomende oorzaken zijn saai: een verzadigd gedeeld pakket tijdens piekuren, een oude PHP-versie, geen uitvoeringscache aan serverzijde. Dat zijn hostingkwesties, geen WordPress-kwesties — en juist daarom worden ze laat ontdekt, terwijl er in de site wordt gezocht.

Oorzaak 2. Uw site maakt elke pagina bij elk bezoek opnieuw

Het symptoom. De traagheid is constant, gelijk voor alle bezoekers, en wordt duidelijk erger wanneer meerdere mensen tegelijk komen. De site houdt stand als het rustig is en bezwijkt zodra dat niet meer zo is.

Wat het bevestigt. Zonder paginacache doet WordPress hetzelfde werk bij elk bezoek opnieuw: de database bevragen, de inhoud samenstellen, het thema toepassen, de pagina produceren. Twee bezoekers die hetzelfde artikel opvragen, starten dezelfde fabricage twee keer, voor een identiek resultaat.

Wat het betekent als het dat niet is. Een site die al een cache heeft en nog steeds traag is voor een anonieme bezoeker verwijst terug naar oorzaak 1. Als hij alleen traag is voor ingelogde mensen, is het oorzaak 3 — en dat is het slechtst gediagnosticeerde geval van allemaal, omdat de cache de indruk wekt dat het probleem is opgelost.

Waar naartoe. Dit is de goedkoopste oorzaak om aan te pakken en de meest lonende, en hij heeft zijn eigen artikel: de oplossing van de paginacache. Qua gereedschap doet een gratis extensie het werk: onze cachemodule.

Oorzaak 3. De database werkt terwijl de bezoeker wacht

Het symptoom, en het is zeer herkenbaar. De site is snel in een privévenster en traag zodra u bent ingelogd. Of: snel op inhoudspagina's, traag op de winkelwagen, het klantaccount, de interne zoekfunctie, het dashboard. In een webshop zijn dat precies de pagina's die geld opleveren.

Wat het bevestigt. Open dezelfde pagina uitgelogd, daarna ingelogd. Als het verschil duidelijk is, verbergt de paginacache het probleem voor anonieme bezoekers en laat het volledig intact voor alle anderen — want een gepersonaliseerde pagina kan niet vanuit een kopie worden geleverd.

Wat er meestal achter zit. Opties die bij elk verzoek automatisch worden geladen, ook die welke zijn achtergelaten door lang geleden verwijderde extensies. Query's die een hele tabel doorlopen — pijnloos zolang de tabel klein is, vervelend zodra hij is gegroeid. Geplande taken die WordPress bij het laden van een pagina start, wat erop neerkomt dat de bezoeker die toevallig langskwam het onderhoud van de site betaalt.

Het teken van veroudering. Deze oorzaak dient zich niet van de ene op de andere dag aan: hij nestelt zich. Een site die geleidelijk over maanden trager wordt, zonder zichtbare verandering, wijst bijna altijd hierheen. Het wordt aan de hosting toegeschreven, er wordt een ander pakket genomen, en er beweegt niets.

Waar naartoe. De behandeling staat uitgewerkt in de geavanceerde technieken, en het aantal geïnstalleerde extensies speelt een directe rol: uw extensies doorlichten.

Oorzaak 4. De weergave wordt geblokkeerd door wat ervoor laadt

Het symptoom. De server antwoordt snel — u heeft het gecontroleerd — en toch blijft het scherm een tijd wit, waarna de pagina in één blok verschijnt. Het wachten zit niet meer in het antwoord, het zit in wat de browser moet verwerken voordat hij kan tekenen.

Wat het bevestigt. Een correcte serverreactietijd samen met een late eerste weergave. De browser heeft de pagina ontvangen en kan hem nog niet tonen: hij wacht op stijlbladen, scripts, soms een extern lettertype, voordat hij de controle teruggeeft.

De meest voorkomende vormen. Één stijlbestand dat de opmaak van alle pagina's van de site bevat, inclusief die welke de bezoeker nooit zal zien. Een bibliotheek die op de hele site wordt geladen voor een formulier dat op één pagina staat. Een lettertype dat vanaf een extern domein wordt opgehaald, wat een naamopzoeking en een verbinding toevoegt vóór het eerste leesbare woord.

Het geval van de afbeeldingen, dat tot deze familie behoort. Het grootste element van het eerste scherm is vaak een afbeelding; zolang die niet is aangekomen, lijkt de pagina leeg, ook al is al het andere klaar. Een afbeelding die veel groter wordt geleverd dan de afmetingen waarin ze wordt getoond, verstuurt bytes die niemand zal zien. Het onderwerp heeft een eigen artikel: de foto's van uw site lichter maken, en het bijbehorende gratis gereedschap: afbeeldingsoptimalisatie.

Waar naartoe. De indicatoren die precies dit moment beschrijven, en hoe u ze leest zonder uzelf voor de gek te houden, staan in het optimaliseren van de Core Web Vitals. In een webshop: de Core Web Vitals van WooCommerce.

Oorzaak 5. De code die u niet geschreven heeft

Het symptoom, en het is de scherpste test van dit hele artikel. De site is traag in productie en snel op een testkopie — terwijl het dezelfde site is, hetzelfde thema, dezelfde extensies. Het verschil zit niet in de site: het zit in wat er in productie aan is toegevoegd en nergens anders ooit is geïnstalleerd.

Waaruit deze post bestaat. Bezoekersmeting, cookiebanner, livechat, advertentiepixels, externe lettertypen, kaarten, testgereedschap, conversieregistratie. Elk daarvan is ooit door iemand gevraagd, om een reden die op dat moment goed was.

Wat het bijzonder maakt. Het is de enige post waarvan niemand in het bedrijf een regel heeft geschreven, en daarom de enige die niemand zich gerechtigd voelt te verwijderen. Hij groeit door opeenvolgende toevoegingen en krimpt nooit vanzelf — een pixel die voor een afgelopen campagne is geplaatst, blijft bij elk bezoek laden, eindeloos.

Wat het betekent als het dat niet is. Een testkopie die even traag is als de productie pleit de derden vrij en verwijst terug naar oorzaak 1 tot 4.

Het geval van de cookiebanner. Hij is verplicht, hij komt vroeg in het laadproces, en hij verschuift de pagina vaak terwijl hij zich invoegt. Het antwoord is niet hem te verwijderen: het is hem te plaatsen zonder dat hij de inhoud wegduwt. Behandeld in onze aanpak van toestemming en cookies.

Waarom deze volgorde en geen andere

De volgorde rangschikt de oorzaken niet naar frequentie of naar ernst. Hij volgt één enkele regel:

Een oorzaak stroomopwaarts maakt elke meting stroomafwaarts onjuist.

Als de server traag antwoordt (oorzaak 1), wordt alles wat u over de weergave meet vervuild door dat wachten. Als de site elke pagina opnieuw maakt (oorzaak 2), variëren uw metingen met de drukte van het moment en concludeert u van alles uit een voor/na-vergelijking. Als de database bij elk bezoek werkt (oorzaak 3), geeft de cache u goede cijfers op de anonieme pagina's en verbergt u het probleem in plaats van het te zien.

Vandaar het praktische gevolg, dat het hele nut van de lijst is: elke uitgesloten oorzaak maakt de volgende meetbaar. Dit is geen volgorde van prioriteit, het is een volgorde van geldigheid.

Een tweede reden, minder theoretisch: de kosten. De eerste drie oorzaken worden gecontroleerd zonder de site aan te raken, en de eerste twee worden opgelost zonder in de code in te grijpen. De laatste twee vragen om afwegingen — een script weghalen betekent praten met degene die erom vroeg.

De vier fouten die het meest kosten

De homepage meten. Die is bijna altijd het meest bewerkt en het minst representatief. Meet een inhoudspagina, een productpagina en een pagina uit het bestelproces: drie profielen, drie verschillende knelpunten. De volledige redenering voor webshops staat in het optimaliseren van de conversietrechter.

De cijfers van tevoren niet noteren. Zonder een opgeschreven startpunt kan geen enkele correctie worden beoordeeld, en eindigt het gesprek altijd met „ik vind dat het beter voelt". Noteer de cijfers, en houd één pagina onaangeroerd als controlepagina.

Meerdere dingen tegelijk veranderen. Dat is de zekerste manier om nooit te weten wat gewerkt heeft — en om voor altijd drie nutteloze instellingen te houden omdat ze in de partij zaten die werkte.

Optimaliseren wat het gereedschap toont in plaats van wat de bezoeker meemaakt. Een score die stijgt omdat een script drie seconden is uitgesteld heeft niets verbeterd: het wachten heeft de meting verlaten, niet de pagina. Veldgegevens beschrijven uw bezoekers; een synthetische test vanuit een nabijgelegen datacentrum beschrijft niemand.

Veelgestelde vragen

Wordt een trage site echt bestraft in de zoekresultaten? Snelheid is één criterium naast andere, en zelden het criterium dat een positie bepaalt. Het meest meetbare effect zit niet in de rangschikking maar in wat er na de klik gebeurt: een bezoeker die wacht, vertrekt. Het is eerst een conversievraagstuk en pas daarna een vindbaarheidsvraagstuk.

Moet ik van hosting wisselen? Alleen na het uitsluiten van oorzaak 2 tot 5. Van hosting wisselen is duur, riskant, en lost alleen oorzaak 1 op. Veel migraties gebeuren voor een probleem dat met de site zou zijn meegereisd.

Versnelt het verwijderen van extensies een site? Vaak, maar niet om de reden die men denkt. Het is niet hun aantal als zodanig: het is dat elke extensie optielezingen, scripts en aanhaakpunten toevoegt die bij elke pagina worden uitgevoerd. Het onderwerp wordt behandeld in de extensiehel.

Mijn site was een jaar geleden snel. Wat is er gebeurd? Een geleidelijke vertraging zonder zichtbare verandering wijst bijna altijd naar oorzaak 3: de database groeit, query's zonder index kosten steeds meer, opgestapelde opties blijven laden. Er is niets kapot — de opeenstapeling wordt eindelijk zichtbaar.

Wat er te doen blijft

Het sorteren gebeurt op volgorde, en stopt zodra een oorzaak is bevestigd:

• Beschrijven wat u ziet — wit scherm en dan alles tegelijk, of geleidelijke weergave
• De serverreactietijd meten op een schrale pagina, niet op de homepage
• Uitgelogd en ingelogd vergelijken op dezelfde pagina
• Productie en testomgeving vergelijken, als u er een heeft
• Alle gemeten cijfers noteren, met de datum, voordat u iets verandert
• Slechts één oorzaak aanpakken, opnieuw meten, en dan naar de volgende

Om het geheel in de gaten te houden zonder er dagelijks aan te denken, staat de periodieke controle hier beschreven: weten of het goed gaat met uw site.

En de zin om te onthouden, als er maar één overblijft: open de traagste pagina van uw site, niet uw homepage. Dat is de pagina die uw ontevreden klanten hebben gezien.

Qua gereedschap volstaan de gratis versies voor de diagnose en voor de eerste twee oorzaken: paginacache, paginaprestaties en afbeeldingsoptimalisatie. De bijbehorende premiumversies vallen onder een volledige terugbetaling binnen 14 dagen.