Module 6 · 6.1

Nederlands

Nederlands English Deutsch Français

Wat maakt een site traag, en hoe meet je het?

Module 6: Snelheid · Leestijd: 9 minuten

Leerdoel: Na deze les kun je meten waar de tijd zit en het verschil herkennen tussen traagheid op de server en traagheid in de browser.

Kernbegrippen: TTFB, Core Web Vitals (LCP, INP, CLS), labdata, velddata, PageSpeed Insights, netwerktabblad, compressie, externe scripts, limieten van het hostingpakket, 503

Eerst meten, dan pas sleutelen

"De site is traag" kan tien verschillende oorzaken hebben. Wie zonder meten een cacheplugin, een beeldoptimalisatieplugin en een groter pakket tegelijk neemt, weet daarna niet wat hielp, en heeft er drie dingen bij om bij te houden. Begin daarom altijd met drie vragen (dezelfde als in de handleiding van je hoster):

Alles traag, of alleen het beheer? Een traag beheer met een snelle voorkant wijst op plugins die in het beheer veel doen, of op bots die de inlogpagina bestoken.
Altijd, of op bepaalde momenten? Alleen op drukke tijden of als een geplande taak draait: dan raakt je pakket zijn grenzen.
Bij iedereen, of alleen bij jou? Probeer het op je telefoon via 4G of 5G, of vraag iemand anders. Is het alleen bij jou traag, dan ligt het aan je verbinding of VPN.

Twee helften: server en browser

De tijd die een bezoeker wacht, bestaat uit twee delen (les 1.2):

De server maakt de HTML: webserver, PHP, plugins, database. Dat zie je als TTFB (time to first byte), de tijd tot de eerste byte van het antwoord. web.dev noemt als vuistregel dat de meeste sites moeten streven naar een TTFB van 0,8 seconde of minder.
De browser leest die HTML en haalt daarna alles op wat erin staat: stylesheets, scripts, lettertypen, afbeeldingen, video, meetcodes, chatwidgets. Pas als genoeg daarvan binnen is, ziet de bezoeker iets.

Een hoge TTFB los je op aan de serverkant: caching (les 6.2), minder of lichtere plugins, een nieuwere PHP-versie, een opgeruimde database (les 6.3) of meer rekenkracht. Een lage TTFB met toch een trage pagina wijst naar de browserkant: te grote afbeeldingen, te veel scripts, externe onderdelen.

Core Web Vitals

Google meet de ervaring van bezoekers met drie cijfers, de Core Web Vitals:

Meting	Wat het meet	Goed als
LCP (Largest Contentful Paint)	Hoe snel het grootste stuk inhoud (vaak de grote foto of de kop) zichtbaar is	2,5 seconde of minder
INP (Interaction to Next Paint)	Hoe snel de pagina reageert als je klikt, tikt of typt	200 milliseconden of minder
CLS (Cumulative Layout Shift)	Hoeveel de pagina verspringt tijdens het laden	0,1 of minder

INP verving in maart 2024 de oudere meting FID. Google gebruikt deze cijfers onder andere bij het rangschikken van zoekresultaten, maar de belangrijkste reden om ze te verbeteren is simpel: bezoekers haken af bij een trage of verspringende pagina.

Labdata en velddata

Er zijn twee soorten metingen, en ze geven verschillende getallen:

Labdata: een test op één moment, vanaf één plek, met een nagebootste telefoon en verbinding. Handig om te vergelijken (voor en na een wijziging), maar het is geen echte bezoeker.
Velddata: metingen bij echte bezoekers met Chrome, over de afgelopen 28 dagen. Dat is wat bezoekers echt ervaren. Kleine sites hebben vaak te weinig bezoekers voor velddata.

PageSpeed Insights (pagespeed.web.dev) toont beide: bovenaan de velddata (als die er zijn), daaronder een labtest met een score en concrete adviezen. Kijk niet blind naar de score van 0 tot 100. Kijk naar de onderdelen: is LCP slecht omdat de server traag is (TTFB) of omdat de grote foto 3 MB is?

Test altijd een paar keer (de getallen wisselen) en test ook een gewone pagina, niet alleen de homepage.

Zelf kijken met de browser

De ontwikkelhulpmiddelen van je browser (F12) laten zien wat er echt gebeurt:

Tabblad Netwerk: ververs de pagina met de cache uit (vinkje "Cache uitschakelen"). Je ziet elk bestand dat wordt geladen, hoe groot het is en hoe lang het duurde. Sorteer op grootte: de grootste bestanden zijn vaak afbeeldingen. Sorteer op domein: hoeveel komt er van andere partijen (lettertypen, meetcodes, video's)?
Het eerste verzoek (de HTML zelf): klik erop, tabblad Timing. "Waiting for server response" is de TTFB.
Kopregels van dat eerste verzoek: is er compressie (content-encoding: br of gzip), en kwam de pagina uit een cache (les 6.2)?

De gebruikelijke boosdoeners

In de praktijk komt traagheid bij WordPress meestal door een van deze:

Geen paginacache: elke pagina wordt bij elk bezoek opnieuw gemaakt (les 6.2).
Te veel of zware plugins, vooral plugins die bij elk verzoek externe diensten aanroepen of zware query's doen (les 5.3).
Grote afbeeldingen: een foto van 5 MB van een telefoon op de homepage (les 4.4 en 6.3).
Een zwaar thema of een paginabouwer die op elke pagina veel scripts en stylesheets laadt (les 5.1).
Externe onderdelen: lettertypen, video's, chatwidgets, meetcodes, sociale-media-knoppen van andere partijen. Elk is een verbinding naar een andere server die traag kan zijn.
Een oude PHP-versie (les 8.4).
Een rommelige database: duizenden revisies, spam, logtabellen van plugins (les 6.3).
Bots: crawlers, AI-crawlers en inlogpogingen houden je pakket bezig (les 7.3).
Het pakket loopt tegen zijn grenzen: te weinig rekenkracht (CPU), processen of geheugen voor het verkeer.

De grenzen van je pakket

Bij gedeelde hosting krijgt elk pakket een vast deel van de server: rekenkracht, geheugen, schijfsnelheid en een aantal processen tegelijk. Gebruikt je site meer, dan wordt hij afgeremd, of krijgen bezoekers een foutmelding 503 (Service Unavailable, bij sommige hosters "Resource Limit Is Reached"). Bij DirectAdmin met CloudLinux zie je dat bij Resource Usage (met "faults" als je site werd afgeremd) en met X-Ray zie je per pagina welke plugin of query de tijd kost. Andere hosters hebben vergelijkbare overzichten, soms alleen op aanvraag.

Een groter pakket helpt als je site echt meer nodig heeft (een drukke webshop). Het lost een slecht ingerichte site niet op: het probleem komt dan later terug. Zoek eerst de oorzaak.

Samenvatting

Meet eerst: alles of alleen beheer, altijd of soms, iedereen of alleen jij.
TTFB is de serverkant (streef naar 0,8 seconde of minder); de rest is wat de browser laadt.
Core Web Vitals: LCP (2,5 s), INP (200 ms) en CLS (0,1); INP verving FID in 2024.
PageSpeed Insights toont velddata en labdata; het netwerktabblad laat zien wat er echt laadt.
De meeste traagheid komt door geen cache, zware plugins, grote afbeeldingen en externe onderdelen; een groter pakket is pas de laatste stap.

Quiz

Opdracht

Opdracht A6.1: Meet je TTFB en compressie. Vul het adres van je site in en, als je wilt, één gewone pagina (bijvoorbeeld je contactpagina). Het programma vraagt elke pagina drie keer op zonder cookies en geeft de middelste TTFB, de grootte van de HTML, en of de server de HTML gecomprimeerd stuurt (content-encoding gzip of br). Vergelijk de uitkomst met een test in PageSpeed Insights en noteer wat je opvalt.

Verder lezen

Deze artikelen beschrijven de stappen in de panelen van WebOké; in andere panelen werken ze vergelijkbaar.

Cookies op WebOké

Cookie-instellingen

Noodzakelijk

Marketing