Kaj se je zgodilo in zakaj je to pomembno

Razvijalec je pri gradnji razširitve za Chrome z imenom Fastary, ki zajema posnetke zaslona, naletel na nenavaden problem. Vsakič je zaznal zamik od 2 do 3 sekund, čeprav je delo premaknil v ozadje, kot to priporoča praktično vsak vodnik za hitrost spletnih strani. Ugotovitev je presenetljiva in za lastnike podjetij zelo pomembna: včasih je premikanje podatkov v ozadje počasnejše, kot če delo preprosto opraviš na glavni niti brskalnika.

To je pomembno, ker se za hitrostjo tvoje spletne strani skrivajo tehnične odločitve, ki jih večina lastnikov nikoli ne vidi, a jih obiskovalci občutijo na svoji koži. Počasna, zatikajoča se stran pomeni manj povpraševanj, več zapuščenih košaric in slabšo uvrstitev na Googlu. Zato se splača razumeti, kaj se dogaja v ozadju, četudi nisi razvijalec.

Sveto pravilo, ki ga vsi ponavljajo

V svetu spletnega razvoja obstaja pravilo, ki naj se ga nikoli ne krši: "Nikoli ne blokiraj glavne niti." Najdeš ga v skoraj vsakem vodniku za hitrost. In ima svoj smisel.

Glavna nit brskalnika je enonitna, kar pomeni, da lahko počne samo eno stvar naenkrat. Poleg tega ni samo naša. Delimo si jo z izrisovalnim pogonom brskalnika, z obravnavo klikov in vnosov ter z drugimi ključnimi opravili. Manj časa kot zasedamo glavno nit, bolj odzivna se zdi stran. Zato smo se navadili premikati zahtevna opravila v ozadje, kot da bi morala med uporabniškim vmesnikom in računanjem obstajati trdna meja, ki je ne smemo prestopiti.

To je videti kot "priporočena" arhitektura. A resnica je bolj niansirana: včasih te sam akt premikanja dela, torej pakiranje, kopiranje in razpakiranje podatkov, zamrzne enako kot delo samo.

Kako brskalnik izolira svoje okolje

Da razumemo, zakaj se to dogaja, si poglejmo, kako brskalnik loči različna okolja. Brskalnik ni eno samo okolje, temveč več okolij, ki tečejo hkrati, vsako s svojim pomnilniškim prostorom in pravili:

  • Glavna nit je tista, ki jo najbolj poznamo. Tu teče logika, tu živi struktura strani, tu se izrisujejo slogi in tu uporabnik klika.
  • Web Workers so ločene niti, ki lahko izvajajo kodo brez dostopa do vsebine strani. Uporabljamo jih za težka podatkovna opravila.
  • Service Workers so mrežni posredniki, ki prestrezajo omrežne zahteve in lahko tečejo celo, ko je stran zaprta.
  • Konteksti razširitev za Chrome, kamor sodijo skripte v ozadju in tako imenovani Offscreen dokumenti.

Vsako od teh okolij je izolirano od ostalih. Delavec v ozadju živi v drugem pomnilniškem prostoru kot glavna nit in ne moreta preprosto brati spremenljivk drug drugega. Temu pravimo arhitektura "deli nič". Da si okolja sploh izmenjajo podatke, si morajo eksplicitno pošiljati sporočila prek vmesnikov, kot je `postMessage()`.

Skriti strošek pošiljanja podatkov

Ko pokličeš `postMessage()`, brskalnik uporabi tako imenovani algoritem strukturiranega kloniranja. Podoben je znanemu pretvarjanju v besedilni zapis, le da je močnejši. Gre za globoko, rekurzivno kopiranje: brskalnik prehodi celotno strukturo podatkov, klonira vsako vrednost, jo pretvori v prenosljivo obliko, pošlje bajte v ciljno okolje in tam vse skupaj znova sestavi.

Za majhen podatek, na primer nastavitev "tema: temna", je to neopazno. Zgodba pa se spremeni pri težkih podatkih, saj gre za sinhrono, blokirno operacijo, katere strošek raste linearno z velikostjo podatkov. Konkretno: če uporabnik klikne gumb in se v ozadje pošlje 8 MB velika slika, mora glavna nit takoj ustaviti vse, kar počne, in izvesti to serializacijo in kopiranje. Če traja pakiranje, pošiljanje in razpakiranje dlje kot samo obdelava podatkov na glavni niti, potem ni smisla premikati dela v ozadje.

Obstajajo sicer tako imenovani prenosljivi objekti, pri katerih se lastništvo podatka preda naprej brez kopiranja, kar je izjemno hitro. Po merjenjih Chromovih razvijalcev traja prenos 32 MB pod 7 milisekund, kloniranje istih podatkov pa okoli 300 milisekund, torej 43-krat počasneje. A ima to svoje slabosti: podatek po pošiljanju izgubiš, ni vse mogoče prenesti, in vmesniki razširitev za Chrome pogosto silijo vse skozi klasično serializacijo. V praksi ta bližnjica marsikdaj sploh ni na voljo.

Ko je pravilna arhitektura napačna arhitektura

Razvijalec Fastaryja je hotel, da bi njegova razširitev delovala kot domača aplikacija, hipno in gladko. Zato je po priporočilih uporabil Offscreen dokument, skrit dokument, ki teče v ozadju in podpira delo s sliko. Tja je pošiljal zajete posnetke zaslona, jih obdeloval, obrezoval in vračal nazaj. Na papirju popolna arhitektura.

V praksi pa se je posnetek zatikal s tistim vztrajnim zamikom 2 do 3 sekund. Krivec ni bila obdelava slike, temveč prav premikanje velikega slikovnega podatka sem in tja med okolji. Ključna misel, ki jo lahko odneseš, je ta:

> Pravilo ni "nikoli ne blokiraj glavne niti", temveč "nikoli ne blokiraj glavne niti predolgo."

Preden delo premakneš v ozadje, se moraš vprašati: je to opravilo drago za obdelavo ali drago za premikanje? Če je premikanje dražje od obdelave, je bolje pustiti delo na glavni niti. Brskalnik mora izrisati novo sličico vsakih 16,6 milisekunde, opravilo, daljše od 50 milisekund, pa velja za "dolgo". Prava umetnost ni slepo sledenje pravilom, temveč znati ločiti, kdaj katero pravilo velja.

Kaj to pomeni za tvoje podjetje in tvojo spletno stran

Morda si misliš, da se te to ne tiče, ker ne gradiš razširitev za Chrome. A načelo je univerzalno in se skriva v vsaki hitri ali počasni spletni strani.

  • Hitrost ni ena sama nastavitev, ki jo vklopiš. Je vrsta odločitev, kje in kako se opravi vsako delo. Ista funkcija je lahko bliskovita ali boleče počasna, odvisno od tega, kako je zgrajena v ozadju.
  • Slepo sledenje "najboljšim praksam" ne zagotavlja hitrosti. Kot kaže ta primer, lahko priporočena arhitektura izdelek celo upočasni. Zato potrebuješ nekoga, ki razume, zakaj pravilo obstaja, in ne le, da obstaja.
  • Obiskovalci občutijo vsak zamik. Tri sekunde zatikanja pri interakciji so razlika med tem, da ti obiskovalec zaupa, in tem, da odide h konkurenci. Google pa hitrost meri in nagrajuje z boljšo uvrstitvijo.

Če imaš spletno trgovino s pregledovalnikom slik izdelkov, konfiguratorjem, filtri ali interaktivnimi elementi, so to prav področja, kjer se pojavljajo taki skriti stroški. Pri Carpolab ne sledimo slepo modnim vzorcem, temveč vsako odločitev tehtamo glede na to, kako se bo tvoja stran dejansko obnašala v rokah pravega obiskovalca na pravem telefonu.

Če te zanima, koliko bi stala hitra, premišljeno zgrajena spletna stran ali trgovina, si lahko okvirno oceno ustvariš v našem kalkulatorju. Če pa se ti stran že zatika in ne veš, zakaj, se oglasi pri nas in skupaj poiščemo vzrok.

Kako Carpolab pristopa k hitrosti

Naša filozofija je preprosta: hitrost ni dodatek, temveč temelj. Namesto da bi vsako opravilo mehanično premaknili v ozadje, se vprašamo, kje je resnično ozko grlo. Včasih je rešitev prav v tem, da delo pustimo tam, kjer je, in se izognemo dragemu premikanju podatkov. Rezultat je stran, ki se odziva takoj in obiskovalcu daje občutek, kot da uporablja domačo aplikacijo, ne pa počasne spletne strani.

Prav ta razlika loči spletišče, ki obiskovalca zadrži, od tistega, ki ga izgubi.

Pogosta vprašanja

Ali je pravilo "nikoli ne blokiraj glavne niti" napačno?

Ne, je dobro vodilo, a ni absolutno. Pravilnejša različica je "nikoli ne blokiraj glavne niti predolgo". Za nekatera opravila je premikanje v ozadje pametna izbira, za druga pa je strošek premikanja podatkov večji od koristi. Odločitev je vedno odvisna od konkretnega primera.

Kako vem, ali je moja spletna stran prizadeta zaradi takih težav?

Znaki so zatikanje ob kliku, počasno odpiranje pregledovalnikov slik ali filtrov ter splošni občutek "lepljivosti". Merjenje hitrosti, na primer prek Google orodij, pokaže tako imenovane dolge naloge. Če jih opaziš, se splača ozadje pregledati s strokovnjakom.

Ali lahko obstoječo počasno stran izboljšate, ali jo je treba narediti na novo?

Odvisno od stanja. Marsikdaj je mogoče z usmerjenimi popravki hitrost bistveno izboljšati brez popolne prenove. Kdaj pa je stran zgrajena tako, da je nova gradnja bolj smiselna in cenejša na dolgi rok. V vsakem primeru najprej ugotovimo vzrok, šele nato predlagamo rešitev.

Vir: Smashing Magazine