Best practice hastighedsoptimering der tager website performance til næste niveau

Faktisk hastighed vs. Oplevet hastighed

Websitets hastighed er kundens førstehåndsindtryk af din virksomhed, og derfor er websiteperformance unægteligt afgørende for din forretning. Lange loadtider er en converion killer –  men er sandheden i virkeligheden mere nuanceret?

Hastighedsoptimering opdeles i to begreber: “faktisk hastighed” og “oplevet hastighed”.

Faktisk hastighed

Faktisk hastighed er den tid websitet tager fra, at klientens web browser har sendt en forespørgsel til webserveren, til at webserverens svar modtages og renderes af klientens web browser. Alle websider (inkl. billeder, scripts, tekster, video, mv.) sendes fra webserveren tilbage til klienten, og kal downloades af modtageren. 

Ved at sende så få HTTP requests (forespørgsel på filer) som muligt, samt komprimerer filer mest muligt så filstørrelsen reduceres, samt vælge at hente indhold fra webservere som er fysisk tættere på klienten, kan vi optimere den faktiske hastighed – altså den tid det rent faktisk/teknisk tager fra, at klienten forespørger på en URL til, at alt indhold er downloadet og vist. Ved at kontrollere rækkefølgen af hvilke filer der skal hentes først, og hvilke der kan udskydes, kan hastigheden øges kontekstuelt (ikke alle ressourcer er lige kritiske at hente for, at kunne vise den side som brugeren efterspørger).

Faktisk hastighed måles i TTFB (Time to First Byte) og indikerer den tid det tager for brugeren at modtage den første byte data. TTFB optimeres ikke alene ved at minimere antallet eller størrelsen af ressourcer der skal downloades, men også i høj grad ved en optimal konfiguration af webserveren.

Derudover skelnes der i mellem flere faktorer i leveringen og præsentationen af data til brugeren, efter forespørgsel til serveren. Google har defineret seks sub-metrics, som opdeler webperformance mere granuleret. I blandt de vigtigste er:

• FCP (First Contentful Paint): Indikerer tiden det tager for klients browser at rendere det første indhold i DOM’en, efter forespørgsel på en URL.
• FMP (First Meaningful Paint): Indikerer tiden det tager for at websidens primære indhold er synligt for brugeren above the fold.
• TTI (Time to Interactive): Indikerer den tid det tager for at websidens indhold er interaktivt (der kan klikkes på elemeter). At elementer blot er synlige er ikke altid ensbetydende med, at browseren er “klar” til at brugeren kan interagere med indholdet.

Vi optimerer webløsninger mod alle seks begreber, som også anvedes i Googles Pagespeed algoritme, der bl.a. har direkte indflydelse på SEO – og hvor stort potentiale et website har for at opnå toprankings.

Oplevet hastighed

Oplevet hastighed handler derimod om, at skabe de optimale betingelser for at bruger har en oplevelse af at websitet loader hurtigt. Selvom den faktiske hastighed ikke nøndigvis er lav, kan den oplevede hastighed godt være det. Dermed kan oplevet hastighed, modsat den faktiske, ikke kvantificeres i sekunder, men handler i højere grad om subjetiv opfattelse. Ikke desto mindre bør brugerens oplevede hastighed ikke negligeres eller nedprioriteres ift. optimering af den faktiske hastighed. 

Fo rstørre platforme som eksempelvis Amazon og Facebook, der globalt anvendes af millarder af brugere og dagligt leverer uanede mængder af data, er optimering af brugernes oplevede hastighed, lige så vigtigt som den faktiske hastighed. For selvom optimering af den faktiske hastighed og mindskning af ressourcer reducerer ventetiden, så skalerer det dårligt. Flere brugere eller kunder betyder nemlig flere kald til serveren, som belastes i højere grad. 

Facebooks Feed er et klart eksempel på at UX optimerning af brugernes oplevede hastighed kan danne bro til bedre performance (skabe en bedre oplevelse, og dermed fasftholde brugere/sikre brug af platformen). Facebooks Feed dannes i realtid med machine learning, for deres ca. 2,5 mia. månedlige brugere. Det kræver serverkapacitet og i spidsbelastninger er der pres på ressourcer, som skaber ekstra lange loadtider for brugerne. Men ved at implementere UX tiltag kan den oplevede hastighed optimeres.

Eksempel på UX ændringer (animation af indlæg der hentes) i Facebooks Feed.

Lazy Loading

Lazy loading er et metode til at optimere den oplevede hastighed ved brug af asynkron loading af ressourcer. Det fungerer ved at download af billedressourcer på websitet udskydes fra pageload til, at de rent faktisk skal bruges – oftest når brugeren scroller, og billedet er synligt i browserens viewport. Det gør det muligt at belaste serveren mindre når brugere besøger websitet og der sker færre HTTP requests.

Progressive JPG/JPEG

Udover lazy loading, kan progressive JPG-billeder også bidrage til en bedre brugeroplevelse og hurtigere oplevet hastighed. Der skelnes mellem “normal”/baseline JPEG og progressive JPG, hvor den afgørende forskel er i måden billedet komprimeres på. Baseline JPEG loades for brugeren i browseren én linje af gangen fra toppen og ned, hvorimod progressive JPEG viser billedet i sin helhed (dog utydeligt) med det samme, og billedet loades ved at flere og flere pixels downloades, og gør billedet skarpere.

Eksempel på hvordan Baseline JPG loades:

Eksempel på hvordan Progressive JPG loades: