Reaktiivinen verkkosuunnittelu: Mahtavien tuntevien verkkosovellusten rakentamisen salaisuus

Viime vuonna olen huomannut, että jotkut kehittäjät käyttävät kahta hienovaraista tekniikkaa, jotka vievät verkkosovelluksen hitaudesta ja jankysta erittäin reaktiiviseen ja kiillotettuun.

Uskon, että nämä tekniikat ovat tarpeeksi tärkeitä, jotta he tarvitsevat nimen: Reaktiivinen web-suunnittelu.

Yhteenvetona voidaan todeta, että reaktiivinen web-suunnittelu on joukko tekniikoita, joita voidaan käyttää sellaisten sivustojen rakentamiseen, jotka aina tuntevat olevansa nopea ja reagoivat käyttäjän syötteisiin riippumatta verkon nopeudesta tai viiveestä.

Verkkosuunnittelijoina ja kehysten kirjoittajina uskon, että on löydettävä tapoja tehdä nämä kuviot oletusarvoisiksi kaikessa, mitä rakennamme, ja se on ensisijainen tavoite UX: n ja havaitun suorituskyvyn parantamiseksi verkossa.

Tekniikka 1: Pikakuormat luuranäytöillä

Hyvin käytettynä tätä tekniikkaa ei melkein koskaan huomaa, mutta sillä on valtava vaikutus sivuston havaittuun suorituskykyyn.

Mielenkiintoista on, että tekniikkaa käyttävät melkein kaikki natiivisovellukset, ja se saa heidät tuntemaan olonsa erittäin reaktiivisiksi jopa kauheissa verkoissa, mutta sitä ei käytännössä koskaan käytetä verkossa!

Mahdollisuus tällä tavalla on!

Lyhyesti sanottuna, luuranganäytöt varmistavat, että aina kun käyttäjä napauttaa mitä tahansa painiketta tai linkkiä, sivu reagoi välittömästi siirtämällä käyttäjän kyseiselle uudelle sivulle ja lataamalla sitten sisältöä tälle sivulle, kun sisältö tulee saataville.

Facebook käyttää luuranganäyttöä parantamaan havaittua suorituskykyä, kun avaat sen ensimmäisen kerran

Luurankoikkunat ovat tärkeä havaittu suorituskykytekniikka, koska ne saavat sovellukset tuntemaan paljon nopeammin, vähentäen dramaattisesti niiden hetkien lukumäärää, joissa käyttäjän jää miettimään:

Mitä tapahtuu? Onko se jopa lastausta? Napautinko sitä oikein?

Flipkart.com on harvinainen esimerkki verkkosivustosta, joka käyttää tätä lähestymistapaa. Sen vuoksi luokkien selaaminen tai tuotteiden napauttaminen tuntuu salamannopealta, vaikka todellisten tulosten lataaminen kestää muutaman sekunnin:

Flipkart.com-sivuston näyttökuva käynnistettiin aloitusnäytöstä erillisessä tilassa Androidissa

Kun tätä tekniikkaa käytetään parhaiten, jo saatavilla olevaa sisältöä, kuten pikkukuvia tai artikkeleita, voidaan käyttää uudelleen parantamaan havaittua suorituskykyä entisestään, jolloin kuormat tuntuvat todella hetkellisiltä.

app.jalantikus.com käyttää Skeleton Screens -kuviota ja käyttää nimikkeitä ja pikkukuvia uudelleen siirtymiä pitkin

Testaa sivustoja luurankoilla

Testaa, kuinka hyvin sivustot käyttävät tätä tekniikkaa, on helppoa: Käytä Chrome-verkon emulointia tehdäksesi verkosta mahdollisimman hidas ja napsauta sitten sivustoa. Jos sivusto toimii hyvin, sivusto tuntuu silti kiihkeältä ja reagoivalta antamasi tiedonantoon.

Hitain tuettu nopeus Chrome-verkon emuloinnissa

Tekniikka 2: ”Vakaa kuorma” elementtien ennalta määritettyjen kokojen kautta

Tiedätkö sen tunteen, jossa verkkosivusto hyppää ympäri, kun yrität käyttää sitä? Yrität vain lukea artikkelin, ja teksti liikkuu jatkuvasti? Sitä kutsumme "epävakaana kuormana", ja meidän on poltettava se tulella .

slate.com -sisältö hyppää hyvin aggressiivisesti sivun latautuessa. Mitä hitaampi verkko olet, sitä pidemmälle se hyppää.

Epävakaa kuormitus vaikeuttaa verkkosivustojen vuorovaikutusta ja saa heidät tuntemaan… hyvin… epävakaa!

Epävakaan sivuston selaaminen muistuttaa minua aina siitä, kuinka kuvittelen sen tuntuvan kävelevän maanjäristyksen aikana

Epävakaa kuormitus johtuu sivulle upotettuista kuvista ja mainoksista, joissa ei ole kokotietoja. Oletuksena selain tietää niiden koon vasta, kun ne on ladattu, joten heti kun kuva latautuu, THUNK!, Koko sivu liukuu alas .

Tämän estämiseksi kaikkien sivun -tunnisteiden on sisällettävä aktiivisesti kuvan sisältämän kuvan mitat.

Monissa tapauksissa tietyillä sivuilla käytetyt kuvat ovat aina samankokoisia, joten niiden koko voidaan yksinkertaisesti sisällyttää HTML-malliin, mutta joissain tapauksissa kuvien koko on dynaaminen, joten niiden koko tulisi laskea, kun kuva ladataan, sitten malli HTML-koodiin, kun se luodaan.


Sama pätee mainoksiin, jotka usein ovat syyllisiä epävakaiden kuormien suhteen. Aina kun mahdollista, luo jako, joka sisältää mainoksen, ja aseta mallineesi koon mukaan parhaan arvauksen perusteella, kuinka suuri tämä mainos tulee olemaan.

Huomaa, että epävakaa kuormitus on pahimmillaan hitaissa verkoissa, koska olet juuri asettunut lukemaan sisältöä, kun se yhtäkkiä hyppää. Et voi koskaan olla varma, että olet turvassa.

Kokoamalla se kaikki

Olen rakentanut pienen esittelysivuston osoitteessa reactive.surge.sh osoittaakseen eroa perinteisen ja reaktiivisen web-suunnittelun välillä.

Tavanomainen tuotteiden lastaus

Huomaa, kuinka hidas se tuntuu ja kuinka turhauttavaa sisällön hyppääminen on. Mielenkiintoista pidän tätä suuruusluokkaa enemmän ärsyttävänä mobiililaitteissa, kun napautetaan näyttöä ja en näe sen reagoivan.

Ladataan artikkeli, jolla on reaktiivinen web-suunnittelu

Reaktiivisella suunnittelulla kuorma tuntuu välittömältä ja sivusto pysyy reaktiivisena napauttamalla takakuvaketta ja artikkelin otsikkoa useita kertoja

Käärimistä

Mitä hitaampi verkko on, sitä huonompi käyttäjäkokemus on, kun sivusiirtymät estävät verkon ja sivut siirtyvät pitkään.

Reaktiivisella verkkosuunnittelulla voimme saada kokemuksemme tuntemaan olonsa kiilaksi ja reagoivaksi (”Responsive Design”, kuten nimi jo otettiin, d’oh!) Edes hitaissa ja tuskallisissa verkoissa.

Haluaisin kuulla yhteisön tiedoista, jotka koskevat havaitun suorituskyvyn vaikutusta KPI-arvoihin, kuten sitoutuminen ja tulot!

Kannustan lisäksi kehysten ja kirjastojen kirjoittajia pohtimaan, miten luuranganäytöt ja vakaat lataukset saadaan oletusasetuksi, joka tunnetaan myös menestyskuoppana.

Jos sinulla on ajatuksia tästä, tweet me @owencm, ja jos pidit tästä, anna sille ♥!

Loppusanat muista tarkistaa mobiililaitteen demonstraatiosivusto reactive.surge.sh, jotta se olisi täynnä!