By No Zebra

Små hacks der øger den OPLEVEDE performance på din shop uanset loadspeed

Sådan øger du den oplevede performance og loadtid på dit site (og ikke kun den faktiske load speed)

Læsetid: 8-10 minutter

Den OPLEVEDE hastighed er den, som rent psykologisk betyder noget for de besøgende på dit site, viser studier. Uanset om dit site loader lynhurtigt eller mindre hurtigt, kan du arbejde med den oplevede hastighed for brugeren. Få 5 konkrete råd til intelligente performanceforbedringer, der øger din konverteringsrate.

Lad os hurtigt slå fast: Loadspeed er et dødsens vigtigt parameter for enhver webshop og website med respekt for sig selv og sine konverteringer.

Se bare denne graf med sammenhæng mellem loadtid og konverteringsrate.

 


(Tilvirket efter: https://skilled.co/resources/speed-affects-website-infographic/)

 

Men load-tiden er langt fra det eneste, der tæller…

Én ting er den faktiske hastighed og loadspeed. En anden ting er den oplevede hastighed og performance, som handler om, hvor hurtigt din bruger tror/opfatter, at dit website er.

Hvad gør det af forskel, tænker du?

Jo, uanset hvor hurtig en loadtid, dit site rent faktisk har, kan du øge brugerens oplevelse af, at dit site reagerer hurtigt.

Det lyder måske som snyd, men det er det lang fra. Det er helt konkrete hacks og designjusteringer, du kan lave på dit site.

Som bekendt forlader kunderne ofte websites/shops, fordi de er for "langsomme". Særligt på mobil er vi grov-utålmodige som brugere. 

Emnet kræver en smule baggrund og et par illustrative eksempler. Det får du her.
 

Hvordan opleves hastighed af mennesker?

Hollandsk forskning har vist følgende:

  • Handlinger, som er færdige inden for cirka 100 millisekunder, opleves som øjeblikkelige for brugeren
     
  • Handlinger, som tager mellem 0,5 og 1 sekund, opleves som umiddelbare for brugeren. Dette er den normale responstid i mellemmenneskelig interaktion og samtale.
     
  • Handlinger, som tager mellem 2 og 5 sekunder: I dette tidsinterval, som er den normale loadspeed for mange sites, er brugeren stadig koncentreret om opgaven, men har brug for feedback fra sitet for at acceptere ventetiden og ikke springe fra. 
     
  • Handlinger, som tager mellem 5 og 10 sekunder: Her begynder det at blive svært at fastholde brugeren. Der skal ikke meget til, før de klikker sig tilbage i Googles overblik og finder et andet og hurtigere site at handle på. 
     

 

Tre performance-anbefalinger ud fra dette:

  1. Loading af en side skal være umiddelbar
  2. Enhver handling af brugeren, som f.eks. et klik, skal have øjeblikkelig feedback.
  3. Ved enhver handling af brugeren, som tager længere tid end 2 sekunder, skal brugeren have en form for feedback/indikation på, at handlingen er i gang og snart er færdig.

 

Hvor stor skal performance-forbedringen være, før det giver mening?

Det svarede Ernst Heinrich Weber på allerede i 1834.

Han viste med sin "Just Noticeable Difference"-lov, at der skal en bestemt tidsmæssig forskel til, før vi mennesker lægger mærke til forskellen/forbedringen.

Den lå på mellem 7 og 18 procent, hvilket senere er blevet til 20% reglen.

Så du skal altså skære minimum cirka 20 procent af loadtiden, før brugeren bemærker en positiv forskel.

Loader dit site på 5 sekunder i dag, skal du skære 1 sekund af.


 

En cykelrytter og et baggagebånd i Houston: Hvorfor er det så slemt at være passivt ventende?

De fleste mennesker foretrækker at være aktive i deres ventetid end passive. 

Faktisk viser forskning, at vi overestimerer vores faktiske ventetid med op til 36 procent, hvis vi er passive/laver ingenting, mens vi venter. 

Derfor begynder vi tit at lave alverdens ting, mens vi venter, for at undgå følelsen af passivitet. Fx at trække telefon op af lommen straks, når vi venter på en bus...

Her er to andre eksempler:


1. Da Chris Froome styrtede i Tour de France 2016:

Da Chris Froome styrtede og ødelagde sin cykel i Tour de France i 2016, rejste han sig straks op og begyndte han at løbe op ad bjerget i sin gule førertrøje, som han død og pine ville forsvare.

Det gjorde han i stedet for at blive og vente på bilen med reservecykler til trods for, at det

  1. er hårdt og skidt for ben og knæ at løbe i cykelsko
  2. koster ekstra kræfter i forhold til at cykle og
  3. er i strid med reglerne i Tour de France.

Men den passive venten og følelsen af tidspilde var værre. 
 

2. Da klagerne væltede ind over Houston Airport…

I 2009 oplevede Houston Airport et stort antal klager fra rejsende, som syntes, at de skulle vente længe på deres baggage.

Houston Airport var på det tidspunkt en af de hurtigste lufthavne (de brugte i snit 8 minutter) til at få tasker og kufferter frem til baggagebåndet, så de undrede sig.

Det viste sig lidt overraskende, at det handlede om den oplevede ventetid.

Det tog nemlig kun passagererne cirka ét minut at gå fra flyet og hen til baggagebåndene, hvor de så skulle stå stille i 7 minutter, før deres tasker kom.

Løsningen?

Man gjorde tingene værre...

Lufthavnen ændrede stisystemet fra flyet og hen til baggagebåndet, så det tog passagererne længere tid at gå derhen. Dermed blev den oplevede ventetid på baggagen reduceret markant og klagerne forsvandt.

Den reelle tidsbesparelse for passagererne? Ingen.

Den oplevede tidsbesparelse: Stor.

Hvad kan du lære af Froome og Houston? 

  1. Hold så vidt muligt brugeren i en "aktiv tilstand" på dit site/shop
  2. Få den passive venten til at føles hurtigere

Herunder får du de konkrete performance-råd til at holde brugeren i en aktiv tilstand og på ventetiden til at føles hurtigere:
 

Hold brugeren i aktiv tilstand

Ved en umiddelbar ventetid på mere end 1 sekund kan det være en fin ide at vise brugeren, at handlingen er i gang. Det kan være spinners, progress bars osv. 

Eksempel på spinner til at vise ventetid:

MEN: Undgå at signalere ventetid, når det ikke er nødvendigt.

Vi ser meget ofte spinners brugt på alt, som loades asynkront. Hvis din loadtid er under ét sekund, så har det ofte den modsatte effekt: Du fortæller brugeren, at de venter og river dem ud af deres aktive og ”ufarlige” ventetilstand. Det er unødvendigt.
 

Performance-råd 1: Tilføj en “Active State”-effekt på knapper

Nedenstående er en af de nemmeste ting, der kan gøres, men som vi desværre ser alt for tit, ikke bliver gjort.

Ved at tilføje et ”:active state” til knapper, så giver knappen feedback og kommunikerer til brugeren, at den har forstået den ønskede handling og er ved at udføre den.

Vi er nede at pille ved millisekunder her, men det virker og har en stor effekt for brugerens oplevelse af ventetid.

For endnu større effekt af active state se også ”Performance-råd 3” længere nede på siden.

 

Performance-råd 2: Udfør ”optimistiske handlinger”

En optimistisk handling betyder, at dit site tillader en øjeblikkelig respons på en handling, fordi vi kan forvente, at det går godt, SELVOM handlingen egentlig behandles af systemet behind the scenes.

Dermed holdes brugeren i en aktiv tilstand, fordi feedbacken ikke lader vente på sig.

Herunder er et eksempel med et Instagram-post, som det ville fungere MED og UDEN optimistiske handlinger. Hjertet bliver rødt, hhv. før og efter, at handlingen er behandlet af det bagvedliggende system.


Tryk "like" på de to Instagram-posts og se forskellen på, hvornår hjertet bliver rødt:

rasmuslynggaard

rasmuslynggaard Giv mig et like og se hvordan loadingen sker 🎉

API request som opdaterer databasen

 

Og her ses et tilsvarende Instagram-like MED optimistisk handling:

rasmuslynggaard

rasmuslynggaard Giv mig et like og se hvordan loadingen sker 🎉

API request som opdaterer databasen

 

Dette kan man ligesom Facebook/Instagram gøre ved de handlinger, hvor det er næsten 100 procent sikkert, at det går godt.

Det er naturligvis vigtigt, at du indtænker en eller anden form for handling og giver brugeren besked, hvis handlingen ikke går godt, selvom den optimistiske handling viser, at det er gået godt.

 

Performance-råd 3: Reagér forud på brugerens hensigt/klik

Du kan lave små hacks på dit site, så det reagerer så snart, at brugeren har vist en hensigt.

For eksempel:


> Aktivér handlingen på Mouse down:

Normalt sender sitet først besked om brugerens handling, når musen har været klikket ned OG er sluppet igen.

Men hvis du sætter det op til, at sitet behind the scenes begynder at loade den ønskede handling allerede, når knappen trykkes ned, men først viser/gennemfører handlingen, når knappen slippes, kan du få et forspring på 100-150 millisekunder. Det virker også på touch devices, men der vil fordelen ofte ikke være helt så stor.


> Få brugeren til at klikke på knappen i længere tid:

Hvis vi som supplement tilfører en animation på :active state, dvs. brugerens klik ned på knappen, ser vi ofte, at brugeren klikker længere tid på knappen, inden de slipper igen. Vi får derved et endnu større forspring i forhold til at pre-loade det kommende indhold.

 

Få den passive venten til at føles hurtigere, end den faktisk er

Kan man ikke holde folk i det aktive stadie, så er det vigtigt, at vi trods alt gør noget for at holde på brugeren eller få ham tilbage i aktiv stadie.

Det er der mange forskellige måder til. Herunder kan du se nogle af de muligheder, du har for at minimere ventetiden – eller i hvert fald fornemmelsen af, at vi venter:

 

Performance-råd 4: Skær 12 pct. af den oplevede ventetid med den rette progress bar/statusindikator:

Progress bars kan - hvis de bliver brugt korrekt - være gode, da de indikerer til brugerne, at siden fungerer og deres handling er registreret. Det er dog ikke alle progress bars, der fungerer lige godt.

Nogle studier har vist, at progress bars med en animation af striber, som peger i modsat retning af bevægelsen, får det til at virke som om, at tiden går hurtigere.

Yderligere studier har vist, at hvis striberne accelererer som i den nederste bar herunder, så føles det endnu hurtigere for brugeren. Faktisk helt op til 12,2 procent hurtigere. Effekten kan nemt opnås ved blot at lave en ease-in på animationen.


Alene designet gør, at brugerne oplever ventetiden, som værende 12,2 pct. kortere/hurtigere ved den nederste progress bar end den øverste, selv om de er præcis lige hurtige.

 

Mange progress bars indikerer ligesom disse ikke sandheden, men kun en forventet loadtid. Det gør de fordi, det kan være svært at lave en ”sand” eller helt præcis progress bar.

Det kan være et problem, hvis en brugers hastighed er langsommere eller hurtigere end dét, vores progress bar er bygget til.

Sorry, nu bliver det lidt teknisk:

For at gardere os mod dette, kan vi foretage et API-kald, hvor vi timer den tid, det tager, og dividerer med den tid, vi forventede det ville tage. Den værdi kan vi så senere gange med den tid, vi forventer et kald tager, for at få en indikation af, hvor lang tid det vil tage for brugeren i virkeligheden og tilpasse vores loaders efter det.

På den måde kan vi få nogle progress bars, som i et vist omfang passer på virkeligheden – i hvert fald har vi forsøgt at sikre os mod svingende hastigheder på netforbindelser.
 

Performance-råd 5: Lav flere optimistiske handlinger og hent dit indhold på forhånd

Vi talte tidligere om optimistiske handlinger og om at forudse brugerens hensigt og næste skridt.

Det kan vi bruge til at pre-loade indhold allerede INDEN, brugeren har klikket.

Her er et par eksempler:

  • Hvis brugeren scroller ned, kan du f.eks. loade kommende billeder/videoer lige inden, at brugeren når frem til dem.
  • Hvis brugeren har foretaget en søgning på siden med et succesfuldt resultat, bliver den eftersøgte side med altovervejende sandsynlighed besøgt derefter og kan derfor preloades.
  • Hvis brugeren navigerer til en log-in-side, er startsiden (efter log-in) jo stensikkert den næste side.
  • Hvis brugeren befinder sig på en side med artikler eller billeder, hvor der skal ”bladres”, er det næste/forrige side/billede højst sandsynligt det næste, der skal vises.

 

Ressource hints: De tekniske muligheder for at loade indhold på forhånd

Det er heldigvis relativt nemt at lege med ressource hints. Det kræver blot, at man indsætter et link=“rel” tag i sin kode, hvilket også betyder, at man kan gøre det via JavaScript.

Det er desværre ikke alle de nedenstående, som er lige godt understøttet i de forskellige browsere. Men det gode er, at det ikke skader at bruge uanset hvad. I de browsere, som understøtter det, virker det bare. Og i de andre bliver det ignoreret.

Future Links JavaScript

I nedenstående video er der brugt et JavaScript framework kaldet Futurelink. Futurelink måler, når musen begynder at de-accelerere, hvilket man typisk gør, nå man nærmer sig et link, som man gerne vil klikke på.

Hvis vi bruger det til at forudse, hvilket link der bliver klikket på i vores menu, så kan vi begynde at hente den næste side, allerede inden brugeren har klikket på linket.

Her kan du se forskellen i loadtid og dermed den oplevede ventetid med et eksempel fra SamKnows:

 

Hvis du har læst hertil, er der kun tilbage at sige godt holdt ud og tak for din tid :)

Tag fat i mig, hvis du vil høre mere om ovenstående og de tekniske muligheder for højtydende e-handelsløsninger og webshops.

/Rasmus Lynggaard
Chief Technology Officer
No Zebra
rly@nozebra.dk