Loadtid – Sådan måler du loadtiden på din hjemmeside
Langt de fleste ikke professionelle, ved ikke hvordan man skal måle loadtiden på sin hjemmeside. Og derfor går de også galt i byen når de så skal til at måle, eller får andre til at måle det for en.
Fx hvis du skal have en hastighedsekspert på for at optimere hastigheden, er det essentielt at du på forhånd ved hvordan målinger skal foretages og hvordan de skal læses – Så du ikke bliver taget ved næsen.
Loadtid optimering – Værktøjer
Hvilke værktøjer man skal bruge i sit hastighedstjek, kommer jeg ind på her. Men fælles er at de skal vise loadtiden, samt vise hvordan og hvornår de enkelte filer og elementer loader på siden. Du kan ikke bruge en måler som bare giver dig tallet på bundlinjen.
Pingdom Tools
Du kan bruge Pingdom Tools. Det bruges til at måle loadtiden fra forskellige dele fa verdenen. Har du et dansk website, skal du derfor enten vælge Sverige/Stockholm.
Fordelen ved Pingdom Tools er at det er, eller var et værktøj som man kunne teste hurtigt med og hurtigt få spyttet waterfall og onloadtid ud. Ulempen er dog at det til tider går ned og er lidt langsomt. Og selvfølgelig det faktum at Pingdom Tools, kun måler til OnLoad tiden gør at det er et værktøj jeg sjældent bruger. Og når jeg bruger det, er det kun for overblikkets skyld.
GTmetrix
GTmetrix bruges også til at måle på loadtiden, men det tager det bare et skridt videre. Den kan også vise dig renderingstider. Har du et dansk website, vælger du at måle fra london.
Fordelen ved GT metrix er at man får et helhedsbillede af hvordan hastigheden er på hjemmesiden. Den tester i dybden og den gør det godt. GT metrix måler altid minimum 2 sekunder efter OnLoad tiden, for lige at se om der skulle være mere der loader – Jeg personligt bruger altid DG metrix når jeg optimerer hastighed, både før, under og efter. Også fordi den er hurtig at bruge og faktisk kommer med ret præcise tal. Og endnu bedre, GT metrix viser også renderingstiden, som reelt er den tid som brugeren mærker og Google måler på.
WebPageTest
Endnu en du også kan bruge. Den er sværere at tyde og der er flere data visuelt tilgængelig. Og derfor kan den blive uoverskuelig især for en nybegynder. Jeg bruger den ikke selv.
dotcom-monitor Website Speed
ligner lidt pingdom tools, men her kan man teste fra mange flere locations. Den er også god at bruge til det at pushe filer ud på din CDN i hele verdenen efter du har tømt CDN cachen.
Når du vælger et eller flere værktøjer
Det er vigtigt at du vælger at benytte dig af 2 værktøjer. Jeg selv bruger altid Pingdom og GTmetrix, af den grund at jeg altid har brugt det og synes de andre er lidt langsomme og jeg finder mig godt tilpas og tilfreds med det der kommer ud af dem.
Jeg bruger også Google Chrome (Timeline og Network). Samt til performance Apache Benchmark og intern server + xdebug. Men det er lidt mere nørdet og ikke her du skal kigge i langt de fleste tilfælde, medmindre du selvfølgelig gerne vil lærer at optimere hjemmesider.
Når du har valgt testværktøjer
Når du har sat dig på to, handler det reelt om at teste sitet. Her går det ikke med en enkelt eller 5 tests. Jeg plejer at lade GTmetrix teste på et site hver time i minimum 24 timer, for at jeg på den måde kan se hvordan sitets loadtid er, både set over tid, men også i gennemsnit.
Det samme gælder egentlig pingdom tools, der kommer jeg løbende ind og tester det pågældende website, for at jeg på den måde kan se hvordan det går og ikke går. Det vigtige er i begge tilfælde, at man skal teste fra samme sted hver gang. – Og gør dig selv den tjeneste at teste siden både med og uden caching, minificering etc.
Når du har testet
Når du er færdig med at teste, hvilket man jo reelt aldrig bliver, Så er det tid til at se på de resultater der kommer frem. Det man typisk kigger på er det man kalder et waterfall/vandfald.
Alt efter tester, kan denne se lidt anderledes ud, og farverne være lidt forskellige og betyde hvert sit.
Her vil lige komme en forklaring på de to jeg selv bruger:
Pingdom Tools
- DNS – Browseren spørger efter DNS oplysninger
- SSL – Browseren udfører SSL håndtryk
- Connect – Browseren tilslutter sig serveren
- Send – Browseren sender forespørgsel til serveren
- Wait – Browseren venter på data/svar fra serveren
- Receive – Browseren downloader data fra serveren
GTmetrix
- Blocking – Browseren afventer at måtte påbegynde forespørgsel
- DNS Lookup – Browseren spørger efter DNS oplysninger
- Connecting – Browseren tilslutter serveren
- Sending – Browseren sender forespørgsel til serveren
- Waiting – Browseren venter på data/svar fra serveren
- Receiving – Browseren downloader data fra serveren
- DOM Loaded –
- Page Loaded –
Man kan som sagt ikke sige ret meget ud fra den samlede loadtid, men se i stedet på det waterfall der kommer frem. Her vil jeg prøve at forklare nogle forskellige waterfalls, og hvad det kan indikere i forskellige situationer. Men jeg vil også komme ind på det man kan kalde falske positiver, alt efter hvilke øjne der ser.
Lang WAIT
En lang WAIT på første kaldet i vandfaldet, kan indikerer at serveren kommer på overarbejde. Typisk er det grundet Databasekald og serversidekode der lige skal fortolkes og stykkes sammen.
I nedenstående tilfælde, er der målt på en ny kundes hjemmeside uden html cache, som man skal. Og det viser tydeligt at serveren kommer på overarbejde. Det kan enten være en alt for stor løsning til en for lille server. Eller det kan være for dårligt kodet site. Eller en kombi af de to. I alle tilfælde bør der blive gjort noget ved det.
Men pas på – Hvis ikke html cache er slået fra, kan det også betyde at der ved måling bliver genereret ny cache, hvilket skaber en falsk høj WAIT også kaldet First Load. Så før du tester, deaktiver gerne plugins der har med caching at gøre
First load
Det kan være svært at vide hvad First load egentlig betyder. I dette tilfælde er det når man har installeret et caching plugin, så vil first load være noget højere, end second load.
Med det mener jeg selvfølgelig at hver gang cachen er blevet slettet, skal der optræde en First load, før der reelt er genereret en cache igen.
Det kunne se ud sådan:
Hvorfor er det falskt?
Jo det er det fordi First Load kun optræder første gang en side/fil skal genereres. I ovenstående tilfælde er det faktisk kun JS og CSS filer der bliver ramt af First Load, hvilket kunne indikere at der er foretaget nogle ændringer i fx design, som lige skal minificeres på ny. Men ikke desto mindre så generere first load op imod 10 sekunder højere end second load.
