Slik bruker du Network tab i nettleseren til å finne trege kall og tunge filer

Nettsider føles ofte trege uten at det er åpenbart hvorfor. Er det serveren, databasen, for mye JavaScript, bilder som er for store eller tredjeparts skript som sinker alt?

Network-fanen i nettleserens utviklerverktøy gir deg fasiten. Med noen få grep kan du se nøyaktig hvilke kall som tar tid, hvor mye som lastes ned, og hva du bør prioritere å rydde opp i.

Kom i gang med Network-fanen uten å kaste bort tid

Network-fanen finnes i alle moderne nettlesere. I Chrome og Edge åpner du DevTools med F12 eller Ctrl+Shift+I (Cmd+Option+I på macOS), og klikker på «Network». I Firefox ligger den under «Nettverk».

Det viktigste først: sørg for at «Preserve log» er slått av mens du lærer. Da ser du bare kall for den siden du har åpen. Klikk på «Disable cache» når DevTools er åpen, så får du et mer realistisk bilde av hva førstegangsbesøkende opplever.

Forstå de viktigste kolonnene før du går i detalj

Du trenger ikke kunne alt for å få nytte. Fokuser på noen få kolonner som gir mest informasjon om hvor tiden forsvinner:

• Name: filnavn eller ressursbane for kallet.
• Type: hva slags ressurs det er (document, script, stylesheet, image, fetch, xhr osv.).
• Status: HTTP-statuskode, for eksempel 200, 301, 404 eller 500.
• Size: hvor mye data som faktisk ble lastet ned.
• Time: hvor lang tid hele kallet tok.
• Waterfall: visuell oversikt over når kallet startet og hvor lenge hver fase tok.

Start med å sortere på «Time» eller «Waterfall». Da får du raskt øye på de verste syndene i stedet for å drukne i detaljer.

Finn flaskehalser: hva er det egentlig som er tregt?

En enkel arbeidsflyt for å finne flaskehalser ser slik ut:

1. Åpne siden med Network-fanen synlig.
2. Vent til siden er ferdig lastet, gjerne til du ikke ser flere nye rader dukke opp.
3. Sorter på «Time» synkende, så det tregeste er øverst.
4. Se først på kallet av type «document», dette er hoved-HTML-en.
5. Se deretter på skript, bilder og API-kall med høy tid eller stor størrelse.

Hvis hoveddokumentet bruker mye tid, peker det ofte mot serverlogikk eller databasen. Hvis det er mange etterfølgende kall som tar tid, kan det være API-endepunkter, eksterne tjenester eller tunge filer som er problemet.

Les waterfall-diagrammet uten å misforstå det

Waterfall-kolonnen er overraskende nyttig når du vet hva du ser på. Hver rad har flere fargede segmenter som representerer DNS-oppslag, tilkobling, «waiting» og nedlasting.

For å få mer detaljer: klikk på et kall og gå til «Timing»-fanen. Der ser du blant annet «Waiting (TTFB)». Hvis «Waiting»-delen er høy, betyr det ofte at serveren bruker tid før den sender svar. Hvis «Content Download» er høy, er det gjerne selve filstørrelsen eller treg nettlinje som bremser.

Oppdag tunge bilder og unødvendige filer

Bilder er ofte blant de største bidragene til trege sider. Bruk filteret i Network-fanen til å vise bare «Img» eller «Images». Sorter deretter på «Size» for å se de tyngste filene.

Spør deg selv for hvert stort bilde: må det være så stort i piksler, bør det komprimeres hardere, og kan det lastes inn senere med lazy loading? Det samme kan du gjøre med «JS» og «CSS» for å få oversikt over filer som kunne vært delt opp eller lastet inn bare der de trengs.

Se hvilke API-kall som gjør siden treg etter innlasting

Mange moderne nettsider henter data via fetch/XHR etter at HTML-en er lastet. Dette kan være lister, dashboards eller søkeforslag. I Network-fanen kan du filtrere på «Fetch/XHR» for å se akkurat disse kallene.

Når en bruker opplever at «siden er åpen, men data lar vente på seg», er det ofte disse kallene som er flaskehalsen. Sorter på «Time» og sjekk statuskoder og responsstørrelse. Se i «Preview» eller «Response»-fanen for å avdekke om API-et sender unødvendig mye data som kunne vært filtrert server-side.

Oppdag problemer med caching, 304 og unødvendige kall

Riktig caching kan gjøre stor forskjell. I Network-fanen ser du fort om nettleseren henter de samme filene om igjen ved hver oppdatering, eller om den bruker cache.

Statuskoder som 304 «Not Modified» viser at nettleseren slipper å laste ned hele filen på nytt. Hvis du ser mange 200-kall på statiske filer hver gang du laster inn siden, kan det være tegn på manglende eller feilkonfigurert caching på serveren.

Typiske feil og hvordan du unngår dem i hverdagen

Noen vanlige ting som dukker opp når man først begynner å se i Network-fanen:

• Mange små filer som kunne vært slått sammen eller lastet inn dynamisk.
• Tredjeparts skript for analyse, chat eller annonser som blokkerer innlastingen.
• Store JSON-responser med data som ikke vises noe sted.
• Bilder i full skjermbredde som lastes der de bare vises som små ikoner.
• Ressurser som gir 404 eller 500 ved hver sidelastning, uten at noen har lagt merke til det.

Lag en enkel vane: hver gang du opplever at en side er merkbart treg, bruk to minutter i Network-fanen før du begynner å gjette. Det gir ofte et konkret forbedringspunkt du kan notere direkte som oppgave.

En liten sjekkliste du kan bruke jevnlig

For å holde ytelsen under kontroll over tid kan det være nyttig med en kort rutine, for eksempel ved hver større release:

• Åpne siden i inkognitovindu med Network-fanen oppe og «Disable cache» på.
• Noter total nedlastet mengde (nederst i Network-fanen).
• Sorter på «Time» og identifiser de tre tregeste kallene.
• Sjekk de tre største filene i «Size» og vurder om de kan krympes.
• Kikk raskt på antall 4xx/5xx-koder og rydde opp i åpenbare feil.

Hvis du repeterer denne øvelsen jevnlig, blir det enklere å oppdage ytelsesregresjoner før sluttbrukerne gjør det, og du får et mer bevisst forhold til hva applikasjonen din faktisk laster over nettet.