Növelje hatékonyan a (mobil) webhely teljesítményét!

Cégünket a Google meghívta az idei észak-európai Page Speed ​​Race versenyre. A verseny célja az volt, hogy két hónapon belül a legmagasabb abszolút javulást érje el a webhely világítótorony teljesítményének mutatója.

A felhasználói élmény és a vállalkozás szempontjából kritikus fontosságú a gyors és vonzó mobilinternet-élmény. A felhasználók elvárásai a mobilon folyamatosan növekednek, és kritikus fontosságú maradni a sebesség iránti igény előtt.

Azok az oldalak, amelyek a verseny részei voltak és amelyeket fejlesztenünk kellett, a kezdőlap, a kategória áttekintése és a termék részletei voltak. Ahol a mi esetünkben a termékoldalnak kellett a legkíméletesebb szeretet és gondoskodás.

A kérelmek lebontása
Az első lépés az volt, hogy megvizsgáljuk az oldalunk által benyújtott kéréseket, amelyek könnyen elvégezhetők a Chrome DevTools programban (vagy olyan webhelyekkel, mint a WebPageTest). . Meglehetősen könnyen megtudtuk, hogy túl sokat, sőt néha szükségtelen eszközöket terhelünk. Például miért töltené be a képet egy mobil eszközhöz, ha csak az asztalon kellene megjelennie? Gyors ellenőrzés, és sok kilobájtot spórolhat vele.

Egy másik dolog, amit kiderítettünk, hogy az eszközök betöltésének sorrendje nem volt megfelelő, és ez nem részesítette előnyben a kritikus megjelenítési utat. Miután megnéztük egy ingyenes Google tanfolyamot, a következő dolgokat tudtuk meg:

Lusta a képek betöltése
A kérések vizsgálata során azt tapasztaltuk, hogy a képek nagy részét már letöltöttük, így számunkra a leglogikusabb lépés a lusta betöltés volt.

Oldalainkon már használtuk az Intersection Observert címkézések küldésére a GTM-hez, így ezt a funkciót könnyedén kibővíthettük, hogy lustán betöltsük a képeket. Ehhez használtuk a reakció-kereszteződés-megfigyelő csomagot, amely egy kicsit megkönnyíti az életet, de természetesen maga is megvalósíthatja.

Miután engedélyeztük a termékoldalunkon, azonnal jelentősen csökkent a képméret azon az oldalon, ahol 1,21 MB-tal kezdtünk és 122 KB-mal végeztünk!

A javascript-csomag optimalizálása
A Javascript messze a legnehezebb a böngésző számára betöltésre, mivel renderelés-blokkoló, és a fő szál elfoglalt, így minden kilobájt, amelyet leválthat a csomagról, azonnali előnye a teljesítményének.

A webpack-bundle-analizátort használjuk csomagjaink ellenőrzésére. Ez egy nagyon praktikus eszköz, amellyel optimalizálhatja az ügyféloldali csomagot, mivel nagyon könnyen megnézheti, hogy mely csomagok (túl) nagyok, vagy melyek nem tartozhatnak a csomagba.

A megszüntetni szokásos gyanúsítottak többnyire olyan könyvtárak, mint a Lodash vagy a jQuery. Ha szükséged van rá, kihívd magad. A gyakorlat végén majdnem 100 KB-ot takarítottunk meg.

A CSS optimalizálása
Vállalatunkon belül az ITCSS-t használjuk, de a termék oldalát még nem alakítottuk át annak érdekében, hogy ezt kihasználjuk, így ez jó alkalom volt arra, hogy átírjuk, megtisztítsuk a CSS másolatát, és használja a már meglévő CSS osztályokat, amelyek végül további 13 KB-ot spóroltak meg.

Mivel a CSS a megjelenítést blokkolja, úgy döntöttünk, hogy beillesztjük az alap, a fejléc és a lábléc stílusát, ami jelentősen javította az Első tartalmas festéket. A következő lépések a kritikus oldalstílusok többi részének felvázolása és különböző stíluslapok létrehozása eszközönként.

Kiszolgálóoldali szervizhívási válaszok gyorsítótárazása
Oldalaink különböző hívásokat indítanak különböző mikroszolgáltatásokra, némelyik személyre szabott, néhány valós idejű adatot mutat. Ezeket a szolgáltatásokat nem tudjuk gyorsítótárba helyezni, de vannak olyan szolgáltatási válaszaink is, amelyeket gyorsítótárazhatunk, némelyiket egy percig, és hosszabb ideig.

Megvalósítottuk a csomópont-gyorsítótárat, és minden hívásnál ellenőrizzük, hogy van-e gyorsítótárazott válaszunk, különben be fogjuk tölteni a szolgáltatást. Egyes szolgáltatások gyorsítótárazzák a válaszukat is, de az ügyfelek gyorsítótárazásával is megtakarítható a hívás és az esetleges késés.

Természetesen meg kell találnia, hogy mi lenne a legjobb gyorsítótár-időtartam, ha mindkét oldal gyorsítótárazna. Például, ha mindkét fél 30 percig gyorsítótárazza, akár 60 percet is igénybe vehet, mire a webhely tartalma megváltozik.

Frissítsen a 7-es verzióra és távolítsa el a szerveroldali transzlációt
Ez egy kicsit technikai fejlesztés. Volt egy általános Webpack beállításunk, amely a szerveroldali kódunkat ugyanúgy átültette, mint az ügyféloldali kódot, de erre nincs szükség. Miért kell áttelepíteni a szerveroldali kódot, hogy az IE 11-ben is működjön? Nem, nem szabad.

Az egyetlen dolog, amit át akartunk adni, az az import / export funkció, mert esetünkben minden szükséges átírása () sok időt vesz igénybe. Alapszabály, hogy ha nincs szüksége importálásra, mindig kövesse a követelményeket a szerveren. Akkor nincs többé oka a kód átültetésének.

A babel 6-ról 7-re történő frissítéssel együtt sok kilobájtot vágtunk le, amelyet a szervernek már nem kell feldolgoznia! Még egy esetünk is volt, amikor a csomag 400kB-ról 200kB-ra csökkent!

A Fehér Zebra emelkedik
Közel két hónapos verseny után, és minden elvégzett fejlesztésünkkel a második helyen állunk a Világítótorony összesített pontszámának 71-ről 78-ra történő javításával.

Erre a teljesítményre nagyon szép szavakat kaptunk a Google-től:

Nagyszerű munka a Speed ​​Race végéig, lenyűgöző sebességemelkedéssel! Nagyon szoros felhívás volt az 1. helyért, és nagyon élveztük a lelkesedését a verseny során. Tudja, hogy ez még mindig óriási teljesítmény Észak-Európa 85 csapata között – gratulálunk!

Ne dobja el a labdát, hajtsa végre a teljesítmény-költségvetést
A verseny végével ez nem jelenti azt, hogy már nem kellene a sebességre és a teljesítményre koncentrálnunk, éppen ellenkezőleg, mindig legyél felsőbbrendű. Ezért hozzáadtuk a teljesítménykereteket a Lighthouse teljesítményéhez, a sebességindexhez és a tartalomméretekhez.

Ha a legjobb eredményre törekszik, akkor a javascript-csomagnak 150 KB alatt kell lennie, a Világítótorony teljesítményének pontszáma meghaladja a 90-et, a felhasználó-központú mutatók esetében pedig a Google nagyon jó irányelvekkel rendelkezik. Ha a határokig szeretné elérni, itt az ideje elkezdeni a Progresszív Webalkalmazások (PWA) tanulmányozását.

Köszönjük, hogy szánt időt arra, hogy elolvassa ezt a történetet! Ha szívesen olvasta ezt a történetet, tapsoljon nekem az alábbi ?? gombra kattintva, hogy mások is láthassák ezt itt a médiumon.

A Wehkamp.nl-nél dolgozom, az egyik legnagyobb e-kereskedelmi vállalat ??
Van egy Tech blogunk, nézze meg és iratkozzon fel, ha további ehhez hasonló történeteket szeretne olvasni. Vagy nézze meg állásajánlatainkat, ha nagyszerű munkát keres!