Hoe u de snelheid van een website controleert

De snelle manier: een echte browsertest

Voer de URL in bij een page-speed-test en laat die de pagina in een echte browser laden in plaats van te schatten. Een goed rapport geeft u een screenshot van wat er werd weergegeven, de totale tijden, en een uitsplitsing per verzoek die toont welke afbeelding, welk script of welke aanroep van derden traag was. Die uitsplitsing is wat "de pagina is traag" verandert in "dit ene lettertypebestand blokkeert de weergave 1,8 seconden lang".

Voer die uit vlak na een deployment, na een update van een plugin of thema, en voordat u zich vastlegt op een wijziging van hosting of CDN. Dat zijn de momenten waarop de snelheid verandert en niemand het merkt.

Het zelf meten vanaf de commandoregel

Voor het serverdeel van het verhaal heeft u helemaal geen browser nodig. curl kan zijn eigen tijdsuitsplitsing afdrukken:

curl -o /dev/null -sS -w   "dns:%{time_namelookup}s connect:%{time_connect}s tls:%{time_appconnect}s ttfb:%{time_starttransfer}s total:%{time_total}s\n"   https://example.com/

Dit meet één verzoek voor alleen het HTML-document, dus het zal altijd sneller lijken dan de echte pagina. Precies daarom is het nuttig: het isoleert de server van de browser. Is ttfb hier hoog, dan helpt geen enkele beeldoptimalisatie. Is ttfb laag en voelt de pagina nog steeds traag, dan zit het probleem in wat de browser moet doen nadat de HTML is aangekomen.

Wat TTFB, LCP en volledige laadtijd betekenen

• Time to first byte (TTFB). Hoe lang de server erover deed om te beginnen antwoorden, inclusief DNS, het opzetten van de verbinding, TLS en de eigen verwerking van de server. Een hoge TTFB wijst op hosting, databasequery's of backendcode, niet op de assets van de pagina.
• Largest contentful paint (LCP). Het moment waarop het grootste zichtbare element in het viewport klaar was met weergeven, meestal een grote afbeelding, een videoposter of een groot tekstblok. Dit cijfer komt het dichtst bij wat een bezoeker "toen de pagina verscheen" noemt. Google beschouwt 2,5 seconden of minder als goed.
• Laadtijd / volledige laadtijd. Het moment waarop de browser klaar was met het laden van het document en de blokkerende resources. Alles wat de bezoeker kan zien, is normaal gesproken ruim voor dit moment al klaar.
• Totale tijd tot rust. Laadtijd plus alles wat daarna nog draait, zoals scripts die data ophalen zodra de pagina klaar lijkt. Een pagina kan afgerond lijken en toch nog bezig zijn, en dat werk concurreert met de eerste scroll of klik van de bezoeker.
• Verzoeken en overgedragen bytes. Hoeveel bestanden de pagina ophaalde en hoeveel er werd gedownload. Dit zijn de hendels achter vrijwel elk cijfer hierboven.

Lees ze samen. Een lage TTFB met een hoge LCP betekent dat de browser te veel doet: te veel verzoeken, renderblokkerende scripts, of een enorme grote afbeelding. Een hoge TTFB terwijl al het andere normaal is, betekent dat de server het knelpunt is, nog voordat de browser er überhaupt aan te pas komt.

Waarom één test vanaf één plek misleidt

Het is normaal om dezelfde URL twee keer te testen en twee verschillende resultaten te krijgen, en geen van beide is fout. Drie dingen bepalen het grootste deel van de spreiding:

• Afstand. Een test die dicht bij de server draait, heeft een kortere netwerkroute dan een die op een ander continent draait. Zitten uw bezoekers in Europa en test u vanuit dezelfde stad als uw server, dan meet u het beste geval, niet het typische.
• Apparaatprofiel. Een test kan een mobiel apparaat nabootsen met een kleiner viewport, een andere user agent en een vertraagde verbinding. Een voor desktop afgestelde pagina scoort met opzet heel anders onder mobiele emulatie.
• Caching en opwarming. Het eerste verzoek kan een koude cache raken bij het CDN of de applicatie; het tweede wordt warm bediend. Voer een pagina twee of drie keer uit en gebruik het patroon, niet de ene snelste run.

Eén test blijft de moeite waard. Het betekent alleen dat een cijfer pas betekenis krijgt samen met de omstandigheden waaronder het is gemeten.

Hoe u een watervaldiagram leest

Het watervaldiagram is de tijdlijn per verzoek, één balk per bestand, gesorteerd op wanneer het begon. Vier vormen komen steeds terug:

1. Een lange eerste balk voordat er iets anders begint. Dat is TTFB op de HTML, en alles wacht daarachter in de rij.
2. Een trap waarbij elk verzoek pas begint zodra het vorige eindigt. Dat is een afhankelijkheidsketen, meestal een script dat een ander script laadt dat de echte inhoud laadt. Ketens zijn de duurste vorm op de grafiek.
3. Een brede balk in het midden van een domein van een derde partij. Advertenties, chatwidgets, analytics en lettertypen staan hier, en een trage derde partij vertraagt uw eigen pagina als die synchroon wordt geladen.
4. Een dichte cluster kleine balkjes. Tientallen kleine bestanden, elk met zijn eigen verbindingsoverhead. Minder, grotere, gecachete bestanden verslaan meestal veel kleine.

Balken in rood of met 4xx- en 5xx-codes verdienen aandacht, ook wanneer de pagina er prima uitziet, want een mislukkend verzoek kost nog steeds tijd voordat het mislukt.

Een vertraging opvangen die niemand ging zoeken

Eén test vertelt u hoe de pagina eenmaal presteerde, vanaf één plek, op één apparaatprofiel. Dat is wat u wilt bij het debuggen van iets specifieks. Het is niet wat u wilt wanneer het doel is om een vertraging überhaupt op te merken: pagina's worden stap voor stap zwaarder, en niemand draait een handmatige test op een rustige dinsdag. Geplande page-speed-monitoring voert dezelfde test volgens een interval uit vanaf dezelfde locaties, bewaart de geschiedenis en waarschuwt wanneer de cijfers een drempel overschrijden. Voer er nu een uit met de page-speed-test, en zie responstijd van de server als het trage deel de server blijkt te zijn.