Kdaj je smiselno »blokirati« glavno nit brskalnika

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 opravite na glavni niti brskalnika.

To je pomembno, ker se za hitrostjo vaše 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 niste razvijalec.

Sveto pravilo, ki ga vsi ponavljajo

V svetu spletnega razvoja obstaja pravilo, ki ga ne smeš nikoli kršiti: »Nikoli ne blokiraj glavne niti.« Najdete ga v skoraj vsakem vodniku za hitrost. In ima svoj smisel.

Glavna nit brskalnika je ena sama, 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. Čim manj časa zasedamo glavno nit, tem 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 vas 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čete `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 sama obdelava podatkov na glavni niti, potem nima 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 manj kot 7 milisekund, kloniranje istih podatkov pa okoli 300 milisekund, torej 43-krat počasneje. A ima to svoje slabosti: podatek po pošiljanju izgubite, 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. Na papirju popolna arhitektura.

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

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

Preden delo premaknete v ozadje, se morate 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 v slepem sledenju pravilom, temveč v tem, da znaš ločiti, kdaj katero pravilo velja.

Kaj to pomeni za vaše podjetje in vašo spletno stran

Morda si mislite, da se vas to ne tiče, ker ne gradite 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 vklopite. 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 potrebujete 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 vam obiskovalec zaupa, in tem, da odide h konkurenci. Google pa hitrost meri in nagrajuje z boljšo uvrstitvijo.

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

Če vas zanima, koliko bi stala hitra, premišljeno zgrajena spletna stran ali trgovina, si lahko okvirno oceno ustvarite v našem kalkulatorju. Če pa se vam stran že zatika in ne veste, zakaj, se oglasite 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 Googlovih orodij, pokaže tako imenovane dolge naloge. Če jih opazite, 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. Včasih 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.