Reaktiv Web Design: Hemmeligheten bak å bygge webapper som føles fantastiske

Det siste året har jeg observert to subtile teknikker som ble brukt av noen utviklere som tar en web-app fra å føle seg treg og uhyggelig til veldig reaktiv og polert.

Jeg tror disse teknikkene er viktige nok til at de trenger et navn: Reactive Web Design.

Oppsummert er reaktiv webdesign et sett med teknikker som kan brukes til å bygge nettsteder som alltid føles raske og responsive til brukerinput uavhengig av nettverkshastighet eller latenstid.

Som webutviklere og rammeforfattere tror jeg å finne måter å gjøre disse mønstrene standard på i alt vi bygger, er en topp prioritet for å forbedre UX og oppfattet ytelse på nettet.

Teknikk 1: Øyeblikkelig belastning med skjelettskjermbilder

Når den brukes godt, blir denne teknikken nesten aldri lagt merke til, men har stor innvirkning på opplevd ytelse på et nettsted.

Interessant er at teknikken brukes av nesten alle innfødte apper og gjør at de føler seg veldig reaktive selv i forferdelige nettverk, men den blir nesten aldri brukt på nettet!

Muligheten på denne måten ligger!

Kort sagt, skjermbildene sikrer at hver gang brukeren banker på en knapp eller en lenke, siden reagerer umiddelbart ved å overføre brukeren til den nye siden og deretter laste inn innholdet til den siden når innholdet blir tilgjengelig.

Facebook bruker en skjelettskjerm for å forbedre opplevelsen når du først åpner den

Skjelettskjermbilder er en viktig opplevd ytelsesteknikk da de får applikasjoner til å føle seg mye raskere, noe som dramatisk reduserer antall øyeblikk hvor brukeren lurer på:

Hva skjer? Er det til og med lasting? Har jeg tappet den riktig?

Flipkart.com er et sjeldent eksempel på et nettsted som benytter seg av denne tilnærmingen. Bla gjennom kategorier eller tappe på produkter føles derfor lynraskt, selv når de faktiske resultatene tar noen sekunder å laste:

En skjermbilde av flipkart.com lansert fra startskjermen i frittstående modus på Android

Når denne teknikken brukes best, kan innhold som allerede er tilgjengelig, for eksempel miniatyrbilder eller artikkeltitler, brukes på nytt for å forbedre den opplevde ytelsen ytterligere, slik at masse føles virkelig øyeblikkelig.

app.jalantikus.com bruker skjelettskjermbildet og gjenbruker titler og miniatyrbilder på tvers av overganger

Teststeder med skjelettskjermbilder

Det er enkelt å teste hvor godt nettsteder bruker denne teknikken: bare bruk Chrome-nettverksemulering for å gjøre nettverket så tregt som mulig, og klikk deretter rundt på et nettsted. Hvis det gjør dette bra, vil nettstedet fortsatt føles kjipt og responsivt på innspillene dine.

Den tregeste hastigheten som støttes i Chrome-nettverksemulering

Teknikk 2: “Stabile belastninger” via forhåndsdefinerte størrelser på elementer

Du kjenner den følelsen der et nettsted hopper rundt mens du prøver å bruke det? Du prøver bare å lese en artikkel, og teksten fortsetter å bevege seg rundt? Det er det vi kaller en "ustabil belastning", og vi trenger å brenne den med ild.

slate.com-innhold hopper veldig aggressivt etter hvert som siden lastes inn. Jo saktere nettverket du er på, jo lenger hopper det etter.

Ustabile belastninger gjør nettsteder vanskelige å samhandle med, og får dem til å føle seg… vel… ustabile!

Å bla gjennom et ustabilt nettsted minner meg alltid om hvordan jeg ser for meg at det ville føles å gå rundt under et jordskjelv

Ustabile belastninger er forårsaket av bilder og annonser som er innebygd på en side, men ikke inkludert størrelsesinformasjon. Som standard vet nettleseren bare størrelsen på disse når de har lastet inn, så så snart et bilde er lastet inn, glir hele siden ned .

For å forhindre dette, må alle -kodene på en side proaktivt inkludere dimensjonene på bildet de vil inneholde.

I mange tilfeller er bilder som brukes på bestemte sider alltid av samme størrelse, og størrelsen kan ganske enkelt inkluderes i HTML-malen, men i noen tilfeller er størrelsen på bilder dynamisk, og dermed bør størrelsen beregnes når bildet lastes opp og deretter males. inn i HTML når den er opprettet.


Det samme gjelder annonser, ofte en skyldige når det gjelder ustabile belastninger. Der det er mulig, opprett en div som vil inneholde en annonse, og angi den i templateringen slik at den blir dimensjonert med beste gjetning på hvor stor denne annonsen blir.

Vær oppmerksom på at ustabile belastninger er som verst på sakte nettverk, ettersom du nettopp har funnet deg til å lese innhold når det plutselig hopper, og du kan aldri helt være sikker på at du er trygg.

Sette alt sammen

Jeg har bygget et lite demoside på reactive.surge.sh for å demonstrere forskjellen mellom konvensjonell og reaktiv webdesign.

Konvensjonell artikkelbelastning

Legg merke til hvor treg det føles og hvor frustrerende innholdshopping er. Interessant synes jeg disse størrelsesordenene er mer irriterende på mobile enheter når jeg trykker på skjermen og ikke ser den reagere.

Laster inn en artikkel med reaktiv webdesign

Med reaktiv design føles belastningen øyeblikkelig, og nettstedet forblir reaktivt når du trykker på bakikonet og artikkeltittelen flere ganger

Innpakking

Jo tregere nettverket er, desto dårligere blir brukeropplevelsen når sideoverganger blokkeres i nettverket og sider hopper rundt i lengre perioder.

Med Reactive Web Design kan vi få opplevelsen vår til å føle seg snus og responsiv (“Responsive Design” som et navn allerede ble tatt, d’oh!), Selv i tregt og smertefullt nettverk.

Jeg vil gjerne høre om data fra samfunnet om effekten av opplevd ytelse på KPI-er som engasjement og inntekter!

I tillegg vil jeg oppfordre ramme- og biblioteksforfattere til å vurdere hvordan man lager skjermbilder og stabile belastninger som standard, også kjent som suksessgropen.

Hvis du har tanker om dette, kan du tweet meg @owencm, og hvis du likte dette, så gi det en ♥!

PS! husk å sjekke ut demosiden reactive.surge.sh på en mobilenhet for det er full glans!