Alle nettsider lastes inn med forskjellig hastighet. Noen er lynkjappe, og andre føles som en seig sirupsmasse som bare aldri blir ferdig med å vise musepekeren som et snurrende ventesymbol. Ytelsen på et nettsted varierer veldig, og man kan lære mye ved å analysere ytelsen på sitt eget nettsted.

Et kjapt eksempel: Besøker man google.no får man ganske så lynkjapt opp en enkel ferdig innlastet webside som viser den kjente logoen med et enkelt søkefelt. Man skriver «google.no» i adressefeltet i nettleseren, og fra man trykker enter-tasten, tar det jevnt 100 millisekunder (ms) før google.no begynner å vises. Deretter tar det ytterligere 350 ms å gjøre ferdig visningen.

Et nettsted bør være ferdig innlastet på under ett sekund

En total lastetid på 450 ms er kjapt, og i internettparadis er alle nettsteder minst så kjappe på innlasting. Du kan også måle disse tallene på ditt eget nettsted. Det er enklere enn man tror, bare man blir litt kjent med nettleserenes innebyggede verktøy.

  • Hvordan måler man ytelsen på sitt eget nettsted?
  • Hvorfra får man disse millisekund-tallene?
  • Hvordan hjelper det oss med å identifisere hvorfor nettsiden er så treg?

Mål ytelsen – en kjapp innføring

  1. Besøk nettstedet du vil sjekke
  2. Trykk F12 på tastaturet for å åpne utviklerverktøyet
  3. Trykk på fanen «Network»
  4. Trykk F5 på tastaturet for å laste nettsiden på nytt, slik at utviklerverktøyet du nå har oppe kan gjøre sine målinger.
  5. Sjekk resultatet (se hint under)

inspector

Videre lesing vil gå mer i dybden på vanlige problemer og løsninger på disse.

Innebygget verktøy for å måle ytelse

De fleste nettlesere har et slikt verktøy med lignende funksjoner. Denne artikkelen vil forholde seg til Google Chrome Inspector tool, slik den fremsto i versjon «53.0.2785.89 m» på Windows 10.

Trykk F12 på tastaturet, eller høyreklikk på nettsiden og velg «Inspect element». Da åpnes utviklerverktøyet.

inspector-locationTips: Du kan bytte posisjon på utviklerverktøyet ved å klikke på prikkene helt til høyre og velge en annen type plassering.

Du finner også Googles egen dokumentasjon på inspectoren her.


Et nettsted blir ikke alltid tregt av seg selv

Når man setter opp et nytt nettsted begynner man med blanke ark. En tom nettside lastes inn lynkjapt, det er nesten ingen ventetid, men heller ingenting å vise frem.

Etter en stund får man fylt på med funksjonalitet og innhold (bilder, tekst, menypunkter, widgets etc), og nettsiden bruker litt mer tid på å lastes inn.

Etter et halvår i drift har det nye, kjappe og flotte nettstedet begynt å lastes inn på over to sekunder, og scrolling oppleves hakkete og fælt. Hva skjedde?

Mulig problemkilde #1: Veldig mange spørringer mot serveren

Litt grunnkunnskap: Nettsiden hentes fra serveren i mange deler for å vise en fullverdig nettside. Nettleseren kan be serveren om en og en del av nettsiden, og hver gang gjøres det med en spørring («request») til serveren. Her er en forenklet oversikt over hva en nettleser henter fra serveren.

100 requests og mer regnes det som «Mye». Færre er bedre.

Første spørring mot serveren

Når man besøker et nettsted vil nettleseren din først be om å få «grunnmalen» (html-dokumentet). Dette inneholder en referanse til alle bilder, stilark og fonter, samt javascriptfiler og eksterne kilder som skal lastes inn.

Andre, tredje, fjerde..etc.. spørring mot serveren

Html-dokumentet forteller hva nettleseren skal laste inn videre.

  • Stilarkene som lastes inn forteller hvordan nettsiden skal se ut. Hvert stilark er en egen spørring mot serveren. Fontfiler kan også lastes inn fra stilarkene.
    Det er vanlig å se mellom 1-10 stilark. Jo færre, jo bedre.
  • Javascript som lastes inn utfører diverse tilpassede jobber, f.eks. å gjøre noe klikkbart, eller vise tilpasset informasjon. Hver javascriptfil er en egen spørring mot serveren.
    Det er vanlig å ha flere javascriptfiler. Jo færre, jo bedre.
  • Bildefiler lastes også inn ett og ett. Hvert bilde er en egen request mot serveren.
  • Eksterne kilder er gjerne iframes eller eksterne javascript-spørringer. Typisk eksempel er Facebook Page Plugin, eller fontfiler. Disse lastes gjerne etter alt annet, og gjerne fra en annen server enn hvor nettsiden din ligger lagret.

Hvordan finne antall requests

  1. I inspectoren, åpne fanen for «Network».
  2. Last inn nettsiden på nytt (Refresh)
  3. Se nederst etter et tall som forteller «N requests»

100 requests og mer regnes det som «Mye». Færre er bedre.
Google.no har 22 requests; Det regnes som bra:

google-requests-count

Løsninger

Det å ha mange requests kan stamme fra mange forskjellige problemkilder. De mest typiske:

#Problem:
For mange bilder på nettsiden. F.eks vil 100 bilder betyr 100 requests i tillegg til alle andre requests. Bilder kan også lastes inn fra stilarkene (typisk: ikoner, logo, bakgrunnsbilder etc.).

Løsning:
Reduser antall innlegg som vises samtidig, og reduser gjerne antall bilder per innlegg. Ingen innlegg bør ha mer enn 10-15 bilder. Last inn nettsiden på nytt (refresh) flere ganger for å sjekke om det ble bedre.

#Problem:
For mange utvidelser (plugins). F.eks. er det vanlig at hver plugin i WordPress laster inn sine egne stilark og egne scripts. Det betyr at typisk vil hver plugin i WordPress legge til minst 2 requests.

Løsning:
Skru av plugins en etter en for å finne den verste eller de verste. Oppdager du plutselig mange færre requests på en refresh, bør du se deg om etter alternativ plugin.

OBS: Enkelte CMS plugins laster veldig mange scripts og stilark, f.eks. UberMenu. Slike plugins bør man styre unna.

#Problem:
CMS theme/template er rett og slett for dårlig laget.

Løsning:
Bytt theme/template og se om det blir langt færre requests på neste refresh. Hvis det blir langt færre, bør du vurderer å bytte tema.

OBS: Bytting av tema kan føre til tapte menyoppsett eller widgets, som også kan føre til færre requests (false positive, og ekstra ryddejobb)

Mulig problemkilde #2: Første spørring mot serveren bruker for lang tid

Som nevnt i #1, første spørring mot serveren forteller hva som skal lastes inn videre. Hvis denne første viktige spørringen bruker for lang tid, vil alt annet begynne innlastingen sent.

Første request bør ikke bruke over 350 ms.

Hvordan sjekke ytelsen på en enkelt request

  1. I inspectoren, åpne fanen for «Network».
  2. Last inn nettsiden på nytt (Refresh)
  3. Se på øverste request i listen. Det er den første.

Første request bør ikke bruke over 350 ms. Det er ca der nettstedet slutter å oppleves som kjapt (et noe subjektivt synspunkt). Hvert millisekund over dette gjør treghetsfølelsen verre, og husk at det er først når denne første spørringen er ferdig at alt det andre (bilder, stiler, scripts m.m) kan begynne innlastingen, som jo tar enda lengre tid.

Google.no sin første spørring svarer på mellom 100-140 ms (test gjerne flere ganger), og det regnes som meget bra. Her vises inspector som rapporterer 108ms på første request:

googleno-first-request-speed

Løsninger

Her må man feilsøke systemet som skal vise websiden. Dette er et typisk problem med WordPress når man har lagt til for mange plugins. 

Feilkilder kan inkludere:

  • Midlertidige problemer. Serveren kan være hardt belastet pga mye trafikk. Bare vent en stund og se om det blir bedre.
  • Dårlig CMS som bruker lang tid uansett hva man gjør. Bytt CMS.
  • CMS med alt for tung konfigurasjon (mange plugins, dårlig kodede plugins). Rydd opp ditt CMS.
  • Serverproblem (tom for ram, feilkonfigurert, etc).

Sircon har konstant overvåking av alle servere og tjenester. Ved eventuelle feil startes feilretting umiddelbart.

Mulig problemkilde #3: Det lastes for mange MB.

Et nettsted bør tilstrebe å laste inn færrest mulig antall bytes. Man kan argumentere for at man bør holde seg under 1 MB total lastestørrelse på en full sidevisning. Med større skjermer og flere pixler per skjerm blir vanskeligere å holde filstørrelsene nede uten at man får stygge bilder.

Sorter gjerne på filstørrelse i inspectoren, da finner du de største bildene og får gjort noe med problemet.

Det finnes også tilfeller hvor man ønsker å vise mange store flotte bilder, og da blir det vanskelig å unngå at megabytene flyr avgårde i takretning.

En mobilbruker vil spesielt sette pris på at man unngår å brenne avgårde månedskvotene. Mobilselskapene påstår jo fortsatt at 1 GB trafikk i måneden er mye..

Finn ut hvor mye trafikk dine mobilbrukere belastes:

  1. I inspectoren, åpne fanen for «Network».
  2. Last inn nettsiden på nytt (Refresh)
  3. Se nederst etter et tall som forteller «n KB transferred»

Hvis det står MB istedet for KB, så begynner mobilbrukerene å bli bekymret. Lavere tall er bedre. Sorter gjerne på filstørrelse i inspectoren, da finner du de største bildene og får gjort noe med problemet.

Her er et eksempel fra freeimages.com, som viser en rekke potensielle problemer, videre analysert under bildet:

freeimages-com-example

Det lastes inn nesten 3MB data på forsiden. For en webside som driver med bilder må man kanskje regne med litt mer størrelse, men inspectoren forteller oss at dette kan forbedres.

1: To av bildene alene tar opp over 1 MB størrelse. (fra slideshowet). Å komprimere disse vil spare mest!
2: Nesten 300 requests. Noen er riktignok mot eksterne kilder, men dette er alt for mye.
3: Nesten 4 sekunder før DOMContentLoaded, som enkelt sagt betyr at alle elementer på nettsiden er lagt på plass. Det tar tid før alt ser ferdig eller riktig ut.
4: Flere bilder bruker over 1 sekund på å hentes fra serveren. Færre requests kan gi serveren mer tid til å svare kjappere. Dette kan også skje hvis serveren ligger langt unna.

Mulig problemkilde #4: For mye javascript

Javascript er nettleserens måte å kjøre kode mens nettsiden vises. Dette kan brukes til å gjøre alt man vil, inkludert spørre etter mer innhold fra serveren.

Sorter på «Type» og finn «script». Da kan du se url til scriptfilene du mistenker som problemkilder.

Dette er en stor verden å sette seg inn i, men javascript kan kjøres såpass intenst at nettsiden oppleves som supertreg. Ett tungt script kan være nok til å ødelegge den gode nettopplevelsen. Her er det opp til utvikler av scriptet å unngå å stjele for mange ressurser.

Nettsiden kan oppleves som hakkete, scrolling kan oppleves som «seigt», og musepekeren kan vises som et snurrende loading-ikon uten at det tilsynelatende skjer noe som helst. Laster man innhold med javascript kan nettsiden «hoppe».

For å feilsøke: Inspectoren kan sortere på «Type». Se etter «script», og finn url til scriptfilene du mistenker som problemkilder. Da finner du gjerne fort ut hvilken plugin eller eksternkilde som skaper unødig trøbbel på ditt nettsted.
Man kan også forsøke å skru av plugins for å se om det blir bedre.

Her må man bare bruke erfaring, fornuft og en del prøv-og-feil hvis man ikke finner frem.