A JavaScript költsége 2018-ban

Addy Osmani

2018. augusztus 1. · 20 perc olvasás

Interaktív épület oldalak magában foglalhatja a JavaScript küldését a felhasználóknak. Gyakran túl sok annak. Volt már olyan mobil oldalon, amely úgy nézett ki, mintha csak egy link megérintésével töltött volna be, vagy próbált görgetni, és semmi sem történik?

Bájtról bájtra a JavaScript továbbra is a legdrágább erőforrás, amelyet mobiltelefonokra küldünk, mert nagyban késleltetheti az interaktivitást.

4s. Hasonlítsa össze a

13s egy átlagos telefon (Moto G4) vesz vagy a

36-osok egy alacsony kategóriájú 2018-as telefonon (Alcatel 1X).

Ma bemutatunk néhány stratégiát, amelyekkel hatékonyan tudja megvalósítani a JavaScript-et, ugyanakkor értékes élményt nyújt a felhasználóknak.

Gyorsan maradni, csak az aktuális oldalhoz szükséges JavaScriptet töltse be. Fontosabbá kell tennie, hogy mire lesz szüksége a felhasználónak, a többit pedig lustán töltse be kódfelosztással. Ez adja a legjobb esélyt a betöltésre és az interaktív gyors elérésre. Az alapértelmezett útvonal-alapú kódfelosztással rendelkező halmok játékváltók.
Fogadja el a teljesítmény-költségvetéseket, és tanuljon meg azokon élni. Mobilra törekedjen a JS költségkeretének megismerésérekönyvvizsgálat és vágja le a JavaScript csomagokat. Nagy az esély arra, hogy teljes könyvtárakat szállítson, amikor csak egy töredékre, többszörös kitöltésre van szüksége olyan böngészők számára, amelyekre nincs szükségük, vagy duplikált kódra.
Minden interakció egy új „Time-to-Interactive” kezdete; fontolja meg az optimalizációkat ebben az összefüggésben. Az átviteli méret kritikus az alacsony kategóriájú mobilhálózatoknál, a CPU-hoz kötött eszközöknél pedig a JavaScript elemzési ideje.
Ha az ügyféloldali JavaScript nem kedvez a felhasználói élménynek, akkor tegye fel a kérdést, hogy valóban szükséges-e. Talán a kiszolgálóoldali renderelt HTML valóban gyorsabb lenne. Fontolja meg az ügyféloldali keretek használatának korlátozását olyan oldalakra, amelyek feltétlenül megkövetelik őket. A kiszolgáló-megjelenítés és az ügyfél-renderelés katasztrófa, ha rosszul végzik.

Amikor hozzáférünk az Ön webhelyéhez, valószínűleg sok fájlt küld el, amelyek közül sok szkript. A webböngészők szempontjából ez egy kicsit így néz ki:

Bármennyire is szeretem a JavaScriptet, ez mindig a webhely legdrágább része. Szeretném elmagyarázni, hogy ez miért lehet nagy kérdés.

A medián weboldal ma körülbelül 350 KB tömörített és tömörített JavaScript-et szállít. Tömörítetlen, amely több mint 1 MB szkriptet ad fel, amelyet egy böngészőnek feldolgoznia kell.

Megjegyzés: Nem biztos abban, hogy a JavaScript-csomagjai késleltetik-e, hogy a felhasználók milyen gyorsan lépnek kapcsolatba az Ön webhelyével? Nézd meg Világítótorony .

350 KB tömörített és tömörített szkript. Ezek az oldalak akár 15 másodpercet is igénybe vehetnek, hogy interaktívak legyenek.

Azok a tapasztalatok, amelyek ennyi JavaScript-et szállítanak, többre tartanak Több mint 14 másodperc az interaktív betöltéshez mobil eszközökön.

Ennek nagy tényezője, hogy mennyi időbe telik letölteni a kódot egy mobilhálózaton, majd feldolgozni egy mobil CPU-n.

Nézzük a mobilhálózatokat.

Ez az OpenSignal diagram bemutatja, hogy a 4G hálózatok mennyire következetesen állnak rendelkezésre világszerte, valamint az egyes országok átlagos felhasználói sebességét. Mint láthatjuk, sok országban még mindig alacsonyabb a kapcsolat sebessége, mint gondolnánk.

Nem csak egy korábbi medián weboldal 350 KB-os szkriptjének letöltése tölthet el egy ideig, a valóság az, hogy ha népszerű webhelyeket nézünk meg, valójában sokkal több szkriptet szállítanak ennél:

Mind az asztali, mind a mobil weben elértük ezt a felső határt, ahol a webhelyek néha több megabájt értékű kódot szállítanak, amelyet a böngészőnek aztán feldolgoznia kell. A kérdés az, hogy megengedheti magának ennyi JavaScript-et ?

A mai webhelyek gyakran a következőket küldik JS-csomagjaikban:

Kliensoldali keretrendszer vagy felhasználói felület könyvtár
Állapotkezelő megoldás (pl. Redux)
Polyfills (gyakran olyan modern böngészők számára, amelyekre nincs szükségük)
Teljes könyvtárak, és csak az általuk használtak (pl. Az összes lodash, Moment + locales)
UI-alkatrészek (gombok, fejlécek, oldalsávok stb.)

Ez a kód összeadódik. Minél több van, annál hosszabb ideig tart egy oldal betöltése.

A weboldal betöltése olyan, mint egy filmcsík, amelynek három kulcsfontosságú pillanata van.

Van: Történik? Hasznos? És használható-e?

Történik-e az a pillanat, amikor valamilyen tartalmat megjeleníthet a képernyőn. (elindult a navigáció? a szerver elkezdett válaszolni?)

Hasznos? az a pillanat, amikor olyan szöveget vagy tartalmat festett, amely lehetővé teszi a felhasználó számára, hogy értéket merítsen az élményből és vegyen részt benne.

És akkor használható-e az a pillanat, amikor a felhasználó elkezd értelmesen interakcióba lépni az élménnyel, és történhet valami.

Korábban említettem ezt az „interaktív” kifejezést, de mit jelent ez?

Ahhoz, hogy egy oldal interaktív legyen, képesnek kell lennie arra, hogy gyorsan reagáljon a felhasználói bevitelre. Egy kis JavaScript hasznos teher biztosíthatja, hogy ez gyorsan megtörténjen.

Akár a felhasználó rákattint egy linkre, akár végiggörget egy oldalt, látnia kell, hogy a cselekedeteire reagálva valóban történik valami. Az a tapasztalat, amely ezt nem tudja elérni, frusztrálja a felhasználókat.

Az egyik hely, ahol ez általában előfordul, amikor az emberek a szerveroldalon nyújtanak élményt, majd egy csomó JavaScript-et szállítanak le utána az interfész hidratálásához (eseménykezelők és extra viselkedések csatolása).

Amikor egy böngésző sok olyan eseményt futtat, amelyekre valószínűleg szüksége lesz, akkor valószínűleg ugyanazon a szálon fogja végrehajtani, amely kezeli a felhasználói bevitelt. Ezt a szálat fő szálnak nevezzük.

Túl sok JavaScript betöltése a fő szálba (via