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.
Videre lesing vil gå mer i dybden på vanlige problemer og løsninger på disse.
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.
Tips: 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.
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?
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.
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.
Html-dokumentet forteller hva nettleseren skal laste inn videre.
100 requests og mer regnes det som «Mye». Færre er bedre.
Google.no har 22 requests; Det regnes som bra:
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)
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.
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:
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:
Sircon har konstant overvåking av alle servere og tjenester. Ved eventuelle feil startes feilretting umiddelbart.
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..
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:
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.
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.