Csökkentsük a Javascriptet

A „Javascript bloat” ősi narratívája mindig jelen van a technológiai világban. A webfejlesztők szeretik a Javascriptet, a háttérfejlesztők utálják, és a végfelhasználók általában nem törődnek vele, amíg a webhelyek gyorsan megnyílnak, úgy működnek, ahogy kell, és nem kémkednek utánuk. Ennek ellenére a weboldalakon túl sok a Javascript, különösen az SPA-k, amelyeket néhány tipp betartásával elkerülhet. Lássuk hogyan.

Miért érdekel?

Manapság az internetkapcsolatok meglehetősen gyorsak (általában), miért aggódna, ha az alkalmazásban 1 megabájt JS van? A legtöbb natív mobilalkalmazás több száz megabájtot tesz ki!

Tehát a Javascript használatakor egy szkriptnyelvvel van dolgunk (a névben van), tehát a kódot valaminek el kell olvasnia és értelmeznie kell. Ebben az esetben ez a saját böngészője. Ezután a kód betöltődik a memóriába, és a böngésző elkezdi csinálni vele a dolgokat. A probléma itt az, hogy időt és feldolgozási teljesítményt igényel. Tehát ha van egy egyszerű hírwebhelye, és mindenkinek le kell töltenie 4 megabájt szkriptet és nyomkövetőt, hogy meg tudjon nézni egy hírcikket, akkor valószínűleg csak egy olvasót veszített el. Ennek a 4 megabájt Javascriptnek a letöltése, elolvasása és elemzése rendkívül sok időt vesz igénybe, különösen mobileszközökön. Internetkapcsolataink nagyszerűsége ellenére a legtöbben WiFi-n vagy mobilhálózaton (3G, 4G stb.) keresztül érik el. Ezek megbízhatatlanok és lassúak még a jó lefedettségű területeken is. Azt is vegye figyelembe, hogy az átlagos telefon nem olyan gyors.

Minél több Javascriptet használ, annál több időt vesz igénybe egy oldal lekérése a szerverről, annál több időbe telik a tartalom megjelenítése, és végül a felhasználónak annál többet kell megnéznie a weboldalt. Még csúcskategóriás szervertechnológiával és CDN-ekkel is.

Jó kiindulási pont a webhely teljesítményének mérése a Google Lighthouse segítségével (a Chrome webes eszközeinek Audits lapja). Az olyan mérőszámok, mint a Legnagyobb tartalommal rendelkező festék és az Interaktívig tartó idő jó módszerek annak megállapítására, hogy a Javascript lassítja-e a webhely betöltését. A "WebPageTest" egy nagyszerű eszköz, amellyel tesztelheti webhelyét különböző eszközökön, például lassú okostelefonokon, korlátozott kapcsolaton, így jobban tesztelheti a valós helyzeteket.

Ennek ismeretében nézzük meg, hogyan javíthatjuk webhelyünk teljesítménymutatóit néhány tipp segítségével.

Árok fürdők

Rendben, ez egy kicsit szélsőséges, és valószínűleg csak akkor hasznos, mielőtt elkezdené dolgozni a projekten. A leggyorsabb Javascript egyáltalán nem Javascript. Nincs kód a legjobb kód, legalábbis ezt mondják. Alkalmazásainak szerver-renderelésével teljesen lemondhat az ügyféloldali Javascriptről. A Rails, a Phoenix, a Laravel vagy bármely full-stack webes keretrendszer használata lehetővé teszi a webalkalmazások teljes egészében a háttérben megjelenített megvalósítását.

Tudom, megdöbbentő. Régóta készítettünk ilyen alkalmazásokat, és valahogy bevált. Nézze meg a Basecampet, nagyon jól csinálják. Miután több SPA-könyvtárral és szerver által renderelt full-stack keretrendszerrel dolgoztam, tanúsíthatom, hogy a legtöbb esetben egy csomó olyan koncepciót lemásolunk kliens oldalon, amelyek akár full-stack egységként is létezhetnének: útválasztás, adatellenőrzés, alkalmazás. állapot, API-hívások (teljes verem esetén ezek egyszerűen nem léteznek).

Digitális ügynökségnél dolgozva gyakran láttam SPA-kat nagyon egyszerű projektekre alkalmazva, ahol egy klasszikus Rails alkalmazás is kiváló. Mea culpa, én magam is megtettem. Az ügyféloldali megközelítés nagyszerű, ha külön csapatokat szeretne létrehozni a háttérben és a frontendben. Ha mindkettőnek külön csapata van, az segít a csapatoknak megszervezni magukat. Végül is ezeket a SPA-keretrendszereket és könyvtárakat nagyon nagy szervezetek készítették nagyon nagy kódbázisokkal.

De még a kisebb projektek esetében is az SPA-k kiválóak a nagyon reaktív alkalmazásokban, és minden olyan alkalmazás, amely megpróbálja emulálni a natív élményt, például animációk és navigációs vezérlők segítségével, szintén profitál ezekből a modern frontend technológiákból.

De ennek ellenére nagyon jó verem készíthető a CRUD-hoz hasonló alkalmazásokhoz a Rails-szel és egy kis JS-szel, stimulussal és Turbolinkkal. Megszerzi a Rails fantasztikus fejlesztői élményét, elkerüli a Turbolinkkel való teljes oldalas frissítések rettegését, majd a Stimulus segít a Javascript ésszerű megírásában. Nincs hálózati kérés kezelése, nincs API írás, nincs kézi hitelesítési token kezelés. Csak nyers termelékenység.

És ha reaktivitást keres, jelölje be a StimulusReflex (sínekhez) és a LiveView (Phoenix esetén) lehetőséget. Reaktivitás a szerver oldalon.

Végül vessen egy pillantást a Basecamp-ra, amely csak Rails-t és egy nagyon könnyű Javascript-könyvtárat, a Stimulust és a jó öreg Turbolinket használ. Mobilhoz és asztali számítógéphez egyaránt.

Utolsó baráti emlékeztető ezzel kapcsolatban. Válassz valamit, ami jó egyensúlyt teremt a karbantarthatóság és a csapat boldogsága között. Ne váltson át egy adott technológiára vagy cselekvési módra csak azért, mert egy véletlenszerű haver az interneten ezt mondja! Fedezze fel és nézze meg, mi működik az Ön számára.

Használjon natív könyvtárakat

Most térjünk vissza a Javascripthez. A fejlesztők gyakran egy népszerű függőséget keresnek, mielőtt kipróbálnák és használnák a böngészőplatform által kínált natív eszközöket. Rendben van, az internetes előzmények nagy részében a böngésző alapértelmezett könyvtárai meglehetősen instabilok voltak, vagy egyszerűen nem működtek több böngészőverzióban. Például a hálózati kéréseket lebonyolító könyvtárakat szinte minden projektbe importálják, amikor a böngészőben már van erre egy hatékony eszköz: "fetch".

const response = await fetch("/api/validator", {
  method: "POST",
  headers: {
    "Content-Type": "application/json",
    Accept: "application/json",
  },
  body: JSON.stringify(formState),
});

const json = await response.json();

Jelenleg valószínűleg valami olyasmit használ a webalkalmazásában, mint a axios vagy superagent, mindkettő 4,4 kb, illetve 6,4 kb méretű, a blogbejegyzés írásakor. Régi szokások miatt mindig a axios-hoz folyamodom, de lecseréltem a fetch-re, és az élet nagyszerű volt.

A legtöbb probléma az fetch-re mutatott rá az alapértelmezett beállítások hiánya és a furcsa hibakezelés (csak hálózati meghibásodás esetén adnak hibát, nem pedig rossz válaszokat), de ez egy egyszerű egyedi burkolóval javítható. Tekintse meg ezt a fantasztikus blogbejegyzést Kent C. Doddstól, ahol egyéni burkolóanyagot készít, hogy elhárítsa a józan alapértelmezések hiányával kapcsolatos problémákat.

Ha az axios API körül szeretne maradni, mindig használhatja a „redaxios”-t. Egy axios kompatibilis API, amely fetch-t használ a motorháztető alatt, és mindössze 800 bájt!

Ha pedig támogatnia kell a régebbi böngészőket, használja az „unfetch” kifejezést polikitöltésként.

Próbálja ki és használja a böngésző natív funkcióit, mielőtt az npm-en lévő megoldások után nézne, meg fog lepődni. A böngészők manapság fantasztikus dolgokra képesek, és szinte minden egyes funkció újratölthető a régebbi böngészőkbe.

Legyen óvatos a harmadik féltől származó függőségekkel

Annak ellenére, hogy a böngésző nagyszerű platform, meglehetősen ritka a projekt anélkül, hogy harmadik féltől származó függőséget használna. Még ha maximalizálja is a böngésző természetes erejét, vannak olyan alapvető könyvtárak, amelyekre valószínűleg szüksége lesz. Egy dolog azonban megtörténik, hogy az emberek gyakran keresnek egy adott könyvtárat, és nem igazán gondolnak a következményekre. Az Ön által használt könyvtárak növelik a webalkalmazás teljes méretét. Erre figyelnünk kell.

Hogyan? Egy olyan eszközzel, mint a Bundlephobia, ellenőrizze a csomag méretét használat előtt, és ellenőrizze, hogy megrázható-e. És mi az a fán rázható csomag, amit megkérdezhetsz? Ez alapvetően azt jelenti, hogy a legtöbb Javascript-csomagoló, mint például a Rollup, Webpack és mások, eltávolítja a nem használt kódot az említett csomagból.

Például, ha importálja a lodash fájlt, a teljes csomag az utolsó csomagba kerül. Használhatja azonban a lodash-es alternatívát, amely ugyanazt teszi, és fában megrázható, és csak az importált függvényeket használja. Amíg ezt csinálod:

import { uniqueId } from "lodash-es"

Ne feledje, próbálja megtalálni a megfelelő egyensúlyt a „kerék újrafeltalálása” vagy egy újabb függőség hozzáadása között. Ha pedig könyvtárakat keres problémái megoldására, válasszon egy kicsi és fák rázhatót.

Használhatja a kódfelosztást is, és feltételesen töltheti be a többkitöltést. Kicsit megmutatom hogyan.

Kódfelosztás

Ha Javascript kötegelőt használ, valószínűleg képes kódfelosztásra. Ez alapvetően abból áll, hogy a teljes Javascript-kódbázist különböző modulokra bontja. Általában arra használják, hogy ne töltsék be egyszerre a teljes alkalmazást. Ha nagy webalkalmazással rendelkezik, általában célszerű kódfelosztást végrehajtani, így a felhasználóknak nem kell minden egyes Javascript-részletet letölteniük az alkalmazásban.

Például, ha rendelkezik egy React alkalmazással react-router, akkor útvonal alapú kódfelosztást hajthat végre. Az alkalmazás minden egyes oldalának megvan a saját modulja, valamint egy közös köteg, amely tartalmazza a különböző modulokban közös Javascript-kódot. Ez csökkenti a webalkalmazás egyes részeinek kezdeti betöltési méretét, de ennek az az ára, hogy hálózati kérést kell benyújtani minden alkalommal, amikor az útvonal változik.

Nem megyek bele mélyebben a megvalósítás részleteibe, de megnézheti a react-router dokumentumokat, hogy miként teheti ezt meg a legjobban. Fontos megjegyezni, hogy csak olyan kódot töltsünk be, amelyre a felhasználónak szüksége van, vagy szinte biztosan szüksége lesz a jövőben.

A népszerű keretrendszerek az SPA-könyvtáraikon felül, mint például a Next.js (React), a Nuxt (Vue.js) és a Sapper (Svelte) ezt már a dobozból megteszik, az oldalra épülő komponenseken alapuló kódfelosztással. Ez nagyszerű módja ennek, mivel ezt saját kezűleg kell megvalósítania.

Ezt a stratégiát akár a függőségek feltételes betöltésére is használhatja. A következő példában néhány polikitöltést csak akkor importálunk, ha a böngésző natívan nem támogatja az adott funkciót.

if (typeof IntersectionObserver === "undefined") {
  await import("intersection-observer");
}

if (typeof Map === "undefined") {
  await import("core-js/es6/map");
}

if (typeof Set === "undefined") {
  await import("core-js/es6/set");
}

if (typeof window.requestAnimationFrame === "undefined") {
  await import("raf/polyfill");
}

Alkalmazza ezt bármire, amire szüksége van. Ezzel különböző csomagokat tölthet be mobilra vagy asztali számítógépre. Különböző felhasználói szerepkörök esetén például a normál felhasználóknak valószínűleg nem kell az adminisztrátori irányítópult kódját betölteniük a böngészőjükbe.

Ne támogassa a régebbi böngészőket

Drámai kijelentés. Manapság valószínűleg a babel-t használja a JS-kód átültetésére, hogy kompatibilis legyen a régebbi böngészőkkel. Így a nyelv minden egyes új funkciója visszakerül támogatásra. Ha az IE (Internet Explorer) a cél, akkor a babel minden nyílfüggvényt normál függvényré alakít. A transzpilált kód hosszabb, nehezebb, és valószínűleg nem annyira optimalizált, mint a ténylegesen írt kód.

Hogyan lehet ezt megoldani? Kerülje el a régebbi böngészőket. Úgy értem, ez elsőre nevetségesnek és ellentmondónak tűnhet, de a régebbi böngészők, főleg az IE, nyilvánvalóan nem biztonságosak, lassabbak és egyszerűen rosszabbak, mint az alternatíva. Ha a számítógép IE-t futtat, valószínűleg a Chrome vagy a Firefox futtatására is képes. Van néhány olyan eset, amikor ez nem lehetséges. Egyes intézmények és cégek egyszerűen nem engedik meg az embereknek, hogy frissítsenek vagy telepítsenek alkalmazásokat a számítógépükre, ezért leragadtak a Windows XP és IE mellett.

Ha csökkenti a szükséges polikitöltések számát, és a kódnak a böngészőben való futtatásához szükséges átalakításokat, komoly helyet takaríthat meg. Különféle Javascript-csomagokat is létrehozhat, egyet a modern böngészőkhöz, egyet pedig a régebbiekhez. Ellenőrizheti, hogy a felhasználó futtatja-e az IE-t, és elküldheti neki a többszörösen kitöltött kötegeket, de ehhez olyan kiszolgálóra van szüksége, amely elemzi a HTTP kérések felhasználói ügynökét. Ha „JAMstack” alkalmazást készít, valószínűleg nem tudja hatékonyan elemezni a felhasználói ügynök karakterláncot, és úgyis mindenki ugyanazt a csomagot fogja megkapni.

A polyfill.io egy lehetőség, feltételesen tölti be a polyfilleket, a böngésző verziója alapján.

Ne feledje, hogy bármikor áttekintheti webalkalmazásának felhasználói bázisát, és ellenőrizheti a régebbi böngészőkkel rendelkező felhasználók százalékos arányát. Tiszteletben követheti felhasználója böngészőjének verzióit egy adatvédelmi központú nyomkövető (kicsit paradox) használatával, mint például a „Goatcounter”. Csak nagyon alapvető információkat gyűjtenek, amelyek nem tudják egyértelműen azonosítani a felhasználókat, tiszteletben tartva a magánéletüket. Valószínűleg észre fogja venni, hogy egyáltalán nincsenek IE-felhasználói (legalábbis azokra a termékekre, amelyeken dolgoztam, ez a helyzet).

A globális piaci részesedés tekintetében az IE 3%-kal rendelkezik, de jó ötlet átvizsgálni a piacot, és megnézni, van-e értelme IE-barátnak lenni. Képzelje el, hogy az alkalmazás egy speciális eszköz a linuxos felhasználók számára. Egyáltalán nem fognak IE-t használni.

Ez felhasználói kutatás kérdése, mint minden nagyszerű terméknek. Egy vállalati pénzügyi piacra szánt alkalmazásnak valószínűleg IE-re lenne szüksége. Sokan ezen a területen ragadnak a Windows XP-hez a szervezeti korlátozások miatt. Rad startup ötletért? Valószínűleg egyetlen IE felhasználó sem fog felbukkanni.

Legalább győződj meg arról, hogy a céloldalad működik IE-n, majd csak mondd meg az embereknek, hogy frissítsenek :)

Becsomagolás

Az indoklás egyszerű. Ügyeljen a Javascript (valószínűleg a "legnagyobb blogbejegyzés") költségeire, és használjon egyszerű megoldásokat a probléma kezelésére. Ne felejtse el, hogy az idő előtti optimalizálás minden rossz gyökere, de a projekt életének korai szakaszában végrehajtott néhány módosítás a világ változásait hozhatja létre.

Ezenkívül ellenőrizze az internetes élményt lassabb eszközökön. Nem tudom ezt elégszer elmondani. Nem mindenkinek van a zsebében Galaxy S20 vagy a legújabb fényes iPhone.

Mindez a felhasználói élményen múlik. Tegyen hozzáférhetővé, hatékony webalkalmazásokat, amelyek pontosan azt teszik, amit kellene.