A felhasználók első benyomása, hogy webhelye vagy alkalmazása milyen gyorsan töltődik be. Ebben az útmutatóban olyan bevált technikákat sorolunk fel, amelyek segítségével az első oldalbetöltés után értékes másodperceket lehet leborotválni.
Tartalomjegyzék
Kezdeti betöltési idő
Az az idő, amely eltelik attól a pillanattól kezdve, amikor a felhasználó vagy az ügyfél beírja a webhely domainnevét a tartalom megtekintéséig, a legfontosabb néhány másodperc ahhoz, hogy jó első benyomást keltsen.
Az Amazon úgy találta, hogy minden 100 ezredmásodperc késleltetés az eladások 1%-ába került.
És mégis, sok webfejlesztő ezt utólagos gondolatként kezeli. Egyre több könyvtárat adnak hozzá az egyre több funkcióhoz, és idővel fokozatosan kevesebb konverziót látnak. Ami még rosszabb, ezeket a konverziós veszteségeket nehéz észlelni, mert elhagyják a lassan betöltő oldalt, mielőtt az bármilyen mutatót elküldene.
Ezek egy része olyan technikák, amelyek az előtérben, mások pedig a háttérben alkalmazhatók. Ettől függetlenül a webalkalmazásokat gyorsan be kell tölteni.
Adja hozzá a megfelelő méreteket
Az első dolog, amit meg kell tennie, a méretek hozzáadása. A betöltési folyamatnak számos szakasza van, és a megfelelő szegmensek mérése nélkül nem fogja tudni, hol van a szűk keresztmetszet.
A betöltési folyamat legfontosabb mérföldkövei a következők:
Mérések | Diagram készült: Terrastruct
Ez azt jelenti, hogy ennek a diagramnak minden szegmensét nyomon kell követnie.
Nézzük végig, hogyan teheted ezt meg.
Böngésző kérése a válaszra:
Mérje meg ezt a szerverén. Azt a pillanatot szeretné elérni, amikor az API megkapja a kérést, amikor választ szolgál. Attól függően, hogy történik-e külső hívás például adatbázisokhoz, ez vagy nagyon rövid, vagy jelentős szűk keresztmetszet lehet.
A kapott válaszra adott válasz:
Ezt nehezebb mérni, de ennek egyik módja az, hogy időbélyeget ad hozzá, amikor a válasz elhagyja a szervert, és méri ezt az aktuális idővel a felhasználó oldalán az első lehetséges pillanatban (szkriptcímke a HTML fejében oldal).
Az első elégedett festékre érkezett válasz:
Az első tartalmas festés arra utal, hogy az első elem mikor jelenik meg a DOM-on. Ez lehet valami olyan egyszerű, mint egy szöveg vagy háttér, vagy egy betöltő pörgető. Ezt a Lighthouse futtatásával mérheti a Chrome fejlesztői eszközeiben.
Az első tartalmas festék a legnagyobb tartalomig:
A legnagyobb tartalommal rendelkező festék arra utal, amikor a legnagyobb elem jelenik meg a felhasználó böngészőjének nézetablakában. Ez általában az oldalbetöltés „megjelenítési” részének végét jelzi, és a felhasználó egy feltöltött képernyőt lát. Ezt a Lighthouse futtatásával is mérik.
A legnagyobb tartalmas festmény időről időre interaktív:
Végül az interaktívvá válás ideje azt jelenti, hogy a felhasználó mikor tud olyan műveleteket végrehajtani, mint a görgetés, kattintás és gépelés. Különösen frusztráló lehet, ha ez az időtartam hosszú, mert egy renderelt képernyőt látnak maguk előtt, de nem tehetnek semmit, amikor elvárják, hogy képesek legyenek rá! Ez egy másik mérőszám, amelyet a Lighthouse segít mérni.
Csökkentse a kódot
Most, hogy megvannak a mérések, elkezdheti az optimalizálást. Az optimalizálásnak vannak kompromisszumai, és a mérések megmondják, melyik éri meg.
A leggyorsabban betölthető oldal egy üres oldal, de sok kódot lehet hozzáadni egy alkalmazáshoz, mielőtt bárki észrevenné a különbséget az üres oldal és a betöltési sebesség között. Gyakran előfordul, hogy a lépések olyan aprók, hogy csak egy nap veszi észre a különbséget az egyes felépítések között, csak lassan kezd érezni. Észreveszi, hogy az alkalmazása felduzzadt, és ezen a ponton a kód csökkentése jelentős változást hoz.
Két sebességjavulás érhető el, ha csökkenti a kódot:
- Az alkalmazás gyorsabban átvitelre kerül a hálózaton.
- A felhasználó böngészője gyorsabban befejezi a kód elemzését.
Az első gyorsulás kicsi; mivel a kéréseket vezetéken keresztül tömörítik, ha 1 MB forráskódot levág, az csak 10 KB sávszélesség-megtakarítást jelenthet. A kisebb elemzésből származó gyorsulás azonban jelentős. Felhasználói valószínűleg számos böngészőn és számítógépen futtatják az alkalmazást, amelyek közül sok nem rendelkezik azzal a számítási teljesítménnyel, hogy olyan gyorsan elemezze a kódot, mint saját maga.
Vagy futhatnak mobileszközökön, még kevesebb számítási teljesítménnyel. A különbség másodpercek nagyságrendje is lehet.
Tehát minél kevesebb kódja van, a böngésző annál gyorsabban tudja befejezni az elemzést és elindítani az alkalmazást. Még akkor is, ha egy betöltési képernyőt szeretne megjeleníteni, amelyet a Javascript vezérel, azt megelőzte a kód elemzése.
De nem akarja levágni a funkciókat vagy ténylegesen törölni a kódot. Szerencsére van néhány szokásos gyakorlat a kód csökkentésére anélkül, hogy ezt meg kellene tenni.
- Futtassa a kódot a minifivereken keresztül. A minifikátorok olyan optimalizálásokat hajtanak végre, mint például a hosszú nevek rövidítése (a signUpDarkModeButton ss lesz), eltávolítják a szóköz karaktereket és másokat, hogy a kód a lehető legkompaktabb legyen anélkül, hogy bármit is elveszítene.
- Részleges importálás. A könyvtárak gyakran tele vannak olyan dolgokkal, amelyekre nincs szükséged, de egy esernyőcsomag alá csomagolják őket. Lehet, hogy egy segédprogramkönyvtárnak csak egy adott funkcióját szeretné, ezért a teljes könyvtár importálása helyett csak a szükséges kódot importálhatja.
- Tree-shake halott kód. Néha hibakeresési célból hagy kódot, vagy nem tisztított meg alaposan egy elavult funkciót, és bár benne van a forráskódban, soha nem fut le. A JavaScript-eszközláncban vannak olyan eszközök, mint például a Webpack, amelyek képesek észlelni a halott kódot vagy a fel nem használt függőségeket, és automatikusan eltávolítják azokat az éles összeállításból.
A kód felosztása darabokra
Miután annyi kódot csökkentett, amennyit csak tud az általános alkalmazásból, elgondolkodhat azon, hogy tovább szorítsa ezt az ötletet, és csökkentse a kezdeti betöltéshez szükséges kódot.
Tegyük fel, hogy a kód 20%-a az alkalmazás olyan funkcióját működteti, amelyet a felhasználók csak néhány kattintás után érhetnek el. Időpazarlás lenne, ha a böngésző elemezné a kódot a betöltési képernyő megjelenítése előtt. A kód darabokra osztása jelentősen csökkentheti az interaktívvá váláshoz szükséges időt.
Ahelyett, hogy összefonódott függőségi grafikont készítene az összes Javascript-fájl importjairól, azonosítsa a könnyen vágható területeket. Például előfordulhat, hogy egy összetevő betölt néhány nehéz könyvtárat. Az összetevőt külön fájlba különítheti el, majd csak akkor importálhatja, ha a felhasználó készen áll az összetevővel való interakcióra.
Számos könyvtár létezik a betöltés elhalasztására, attól függően, hogy melyik keretrendszert használja. Nem kell túlzásba esni ezzel, és minden komponenst szétválasztani, mert akkor a felhasználónak gyors kezdeti terhelése van, és minden további interakcióra várnia kell. Keresse meg a szegmentálható legnagyobb darabokat, és ossza fel ott a forráskódot.
Szerveroldali renderelés
Tekintettel arra, hogy a böngészőknek minden intenzív elemzést és fordítást el kell végezniük, és a felhasználóknak Chromebookokat és mobileszközöket kell használniuk, a betöltési idő csökkentésének egyik gyakori módja az, hogy a szerverek vállalják a terhelés egy részét. Ez azt jelenti, hogy ahelyett, hogy üres oldalt adna meg, majd Javascriptet használna az összes tartalom kitöltéséhez, ahogy manapság a legtöbb egyoldalas alkalmazás teszi, futtathat egy Javascript-motort a szerverén (általában Node.js), és kitöltheti a annyi adatot és tartalmat, amennyit csak tud.
Szerverei sokkal gyorsabbak és kiszámíthatóak lesznek, mint a felhasználók böngészői. Elkerülhetetlenül továbbra is elemezniük kell néhány Javascript-kódot, hogy az alkalmazás interaktív legyen. Ennek ellenére a szerveroldali megjelenítés képes kitölteni a kezdeti tartalom nagy részét, így amikor a felhasználó megkapja az oldalt, az már legalább egy betöltési képernyőt vagy folyamatjelző sávot jelenít meg.
És ha adatokra van szükség a kezdeti nézethez, akkor az ügyfélnek nem kell külön kérést tennie, hogy megkapja; már hidratálva lesz az alkalmazásban, hogy az ügyfél használhatja.
Az eszközök tömörítése
Az elemek életre keltik az oldalt, és az oldal nem érzi magát teljesen betöltöttnek, amíg az elemek megjelenítése be nem fejeződik. Ez lehet a háttér, a felhasználói felület ikonjai, egy felhasználói profilkép, vagy akár a betöltési pörgető is. Az elemek gyakran az elrendezést is eltolhatják, így ha a felhasználó megpróbál kapcsolatba lépni valamivel, az oldal tovább ugrálhat az elemek betöltése közben. Néha ezek az elemek jelentik a legnagyobb tartalmat.
De az eszközök az alkalmazások egyik legnehezebb része is. Egy kép több megabájttal is beérkezhet, és sok ikon betöltése könnyen túllépheti a böngésző maximális egyidejű hálózati kérelmet, ami megdöbbentő betöltési sort okoz.
Szinte soha nem akarsz letölteni egy képet az internetről, majd hivatkozni rá az alkalmazásodban. A képeket a lehető legkisebb méretre kell átméretezni, amelyen megjelennek. Ha felhasználói profilja egy apró, 50 x 50 pixeles elemben jelenik meg, átméretezés nélkül, az alkalmazásnak időbe telik, hogy letöltse a teljes képet, amely asztali háttérképként élesnek tűnik, majd átméretezi az apró méretre.
Másodszor, a képek formátumuktól függően tömöríthetők. Manapság a webm az előnyben részesített formátum, de a webes tömörítési területet folyamatosan fejlesztik, és sok új formátum van a láthatáron. A formátumok változó jellege miatt előfordulhat, hogy egyes böngészők nem támogatják az újabbakat! Szerencsére a böngészőtechnológia lehetővé teszi a felhasználó böngészőjének a támogatott formátumok betöltését.
Tehát tömörítse a legújabb és legjobb formátumra, de tartsa meg a kevésbé modern verziót is, és használjon olyan kép- és videóelemeket, amelyek támogatják a visszaeső formátumokat.
Következtetés
Ez az öt leghatékonyabb technika, amellyel a felhasználók villámgyorsan, első alkalommal tölthetik be az alkalmazást. Ezek javítják a konverziós arányokat, a felhasználók elégedettségét, és még a keresési helyezéseket is, mivel a SEO jutalmazza a gyors betöltési időt. Nál nél Terrastructezeket a technikákat és még sok mást alkalmazunk, hogy a felhasználók a lehető leggyorsabban létrehozhassák és megtekinthessék az ebben a cikkben látható diagramokat.