Responstid og asynkrone JavaScript
De siste årene har bruk av asynkrone JavaScript fått stor utbredelse. I stedet for å laste en hel side på nytt hver gang du klikker på noe, kan et lite skript ta seg av kommunikasjonen med tjeneren og sømløst dytte inn nye data riktig sted på siden.
Dette er vel og bra når det gjør nettstedet raskere og enklere å bruke. Men det er dessverre ikke alltid tilfelle. Blendet av fordelene med dette verktøyet er det mange utviklere som benytter det også i tilfeller der en statisk side hadde fungert like fint. Ofte fører dette til at nettsider og webapplikasjoner blir tregere enn de behøver å være.
Test #1: Uten asynkrone JavaScript
La oss bruke følgende enkle side som et eksempel:
Denne siden består av en statisk HTML-side og to statiske bilder – totalt 1.5kB med data. Å laste denne siden på min datamaskin tar i gjennomsnitt 75 millisekunder, fordelt omtrent som følger:
| HTML | 50ms | |
| Bilde | 25ms | |
| Bilde | 25ms |
Tid 
Nettleseren laster først ned HTML-dokumentet og tolker dette. Underveis oppdager nettleseren at det refereres til to forskjellige bilder, og laster ned disse også. Svoosj. Lynraskt.
Test #2: Med asynkrone JavaScript
La oss prøve én gang til, men la et JavaScript hente inn kommentarene på egenhånd når siden først er lastet. Hvor lang tid vil det ta?
| HTML | 50ms | |||
| JS | 20ms | |||
| Data | 36ms | |||
| Bilde | 25ms | |||
| Bilde | 25ms |
Tid
På min datamaskin tar dette i gjennomsnitt 131 millisekunder. Det er fremdeles ganske raskt, men er allikevel hele 75% lengre tid enn i det første eksempelet!
Hva er det egentlig som foregår?
Men hvordan kan forskjellen bli så stor av et så lite skript? Burde ikke den raske og fine nettlinjen min klare å laste ned denne lille siden like raskt som den andre?
Nei, det er dessverre ikke slik det fungerer. Selv om du kan overføre store mengder data per sekund over en rask nettlinje, behøver signalene fremdeles en gitt mengde tid for å fysisk komme seg fra A til B. Å sende et signal via Internett fra Oslo til Bergen og tilbake tar minst 15 millisekunder, uansett hvor lite data som følger med. Signalet skal jo fysisk forflytte seg gjennom tusen kilometer med kobber- og fiberkabel, og enn så lenge vi er begrenset av lysets hastighet må vi belage oss på litt venting.
Når nettleseren min må gjøre fire slike rundturer (HTML, JS, data, bilder) for å få tak i dataene den behøver for å kunne vise siden over, tar det naturligvis lengre tid enn når den bare må gjøre to (HTML, bilder).
Effekten blir gradvis større jo lenger unna du er fra datamaskinen du vil kommunisere med. Mens det bare tar 15 millisekunder å komme seg fra Oslo til Bergen og tilbake, tar tur-retur Tromsø 30 millisekunder, og skal du kommunisere med noen i California tar det hele 200 millisekunder! Så det som ser fint og raskt ut for deg kan være smertelig tregt for brukerne dine andre steder i verden.
Konklusjon
Hvor mange rundturer gjør brukerens nettleser når din nettside lastes? Om du gjør alt riktig bør det aldri være mer enn tre når siden først lastes, og to når du gjør asynkrone oppdateringer underveis. Om du kan redusere antall rundturer ytterligere vil det glede både brukerne dine og tjenermaskinen din.
Om en side inneholder data som skal oppdateres dynamisk og ofte, sørg for å laste ned en statisk versjon først. Så kan du oppdatere den dynamisk noen sekunder senere.
Kartet over er basert på dette, og kan fritt brukes av andre under en Creative Commons-lisens.
