A képeket megfelelő méretben, modern formátumban és reszponzív változatokban küldje, a fő LCP-képet pedig prioritással töltse be. Távolítsa el a nem használt CSS-t és JavaScriptet, a kódot ossza fel oldalak és interakciók szerint, és korlátozza a harmadik feleket. A betűtípusokat és a dinamikus elemeket úgy állítsa be, hogy ne tolják el az elrendezést.
A képek, a CSS és a JavaScript optimalizálása csökkenti azt az adatmennyiséget és munkát, amelyre a böngészőnek az oldal megjelenítése és használhatóvá válása előtt szüksége van. A cél nem a lehető legkisebb fájl mindenáron. A képnek kellően jó minőségűnek kell maradnia, a stílusok nem villoghatnak, és az interakciónak a kód felosztása után is működnie kell. A jó optimalizálás az adott sablon kritikus útvonalából és a valós eszközökből indul ki.
Először mérje meg a kérések vízesésdiagramját, a fő szálat, valamint az LCP-t, INP-t és CLS-t meghatározó elemeket. Ezután távolítsa el a nem használt erőforrásokat, és csak ezt követően tömörítse a maradékot. Egyetlen univerzális „speed” bővítmény tesztelés nélküli hozzáadása megkettőzheti a lazy loadingot, megváltoztathatja a szkriptek sorrendjét, vagy elronthatja az űrlapot. Ezért minden szabálynak egyértelmű céllal, kivételekkel és regressziós ellenőrzéssel kell rendelkeznie.
Készítsen elő hatékony képfeldolgozási folyamatot
Az eredeti képet feltöltéskor a valós komponensek alapján dolgozza fel több méretre. Kínáljon a böngészőnek srcset és sizes attribútumot, hogy a mobil ne az asztali fájlt töltse le. A modern formátumot a tartalom és a támogatottság alapján válassza, megfelelő fallbackkel. Egy fénykép, egy logó és egy egyszerű illusztráció eltérő beállítást igényel. A tömörítést vizuálisan, a célméreten értékelje, ne csupán az eszköz által kijelzett százalék alapján.
Adja meg a szélességet és a magasságot, hogy a böngésző lefoglalhassa a helyet. Az első nézet alatti képek használhatnak natív lazy loadingot, az LCP-jelöltet azonban korán kell felfedezni, és általában nem halasztják el a betöltését. Ne töltse be előre a teljes galériát. A dekoratív hátteret fontolja meg CSS-ben, a tartalmi képet pedig HTML-ben, megfelelő alternatív szöveggel. Az automatikus CDN-transzformátort tesztelje vágásoknál, gyorsítótárazásnál és az eredeti kép elérhetetlensége esetén.
Csökkentse a CSS általi blokkolást a megjelenés elrontása nélkül
Derítse ki, mely stílusok szükségesek az első megjelenítéshez, és melyek tartoznak csak lejjebb lévő vagy más oldalon található komponensekhez. Távolítsa el a régi könyvtárakat és a duplikált keretrendszereket, mielőtt mindent minifikálni próbálna. A kritikus CSS megfelelő módon beágyazható vagy priorizálható, a többi blokkolás nélkül tölthető be, de a generálásnak a valós dinamikus tartalmat kell követnie. A nem használt szelektorok túl agresszív eltávolítása törölheti a JavaScript által létrehozott állapotokat.
A globális dizájnrendszer csökkenti a véletlenszerű szabályok és kivételek számát. A komponenseknek saját stílusokkal kell rendelkezniük, és ott kell betölteniük azokat, ahol használják őket, ha az architektúra ezt lehetővé teszi. A minifikálás csökkenti az adatforgalmat, a szerveroldali tömörítés további adatot takarít meg, de mindkettő csak az utolsó réteg. Ellenőrizze a megjelenítést gyorsítótár nélkül, lassabb betöltéssel, hosszú szöveggel, űrlaphibával és különböző szélességeken.
- Duplikált és nem használt alapok eltávolítása
- Megfelelő kritikus CSS
- Valós komponensekhez kötött stílusok
- Dinamikus állapotok vizuális regressziós tesztje
Csökkentse a JavaScriptet és a fő szál terhelését
Ossza fel a bundle-t útvonalak és funkciók szerint, hogy egy cikk ne töltse le a konfigurátor vagy a pénztár kódját. A felesleges könyvtárakat távolítsa el, a kisebb funkciókat pedig a böngésző natív felületével oldja meg, ha a támogatás megfelelő a célközönség számára. A tree shaking csak megfelelő modulstruktúra mellett működik. A tömörítés csökkenti az átvitt adatmennyiséget, de nem csökkenti az elemzési és végrehajtási időt úgy, mint a kód eltávolítása.
A hosszú feladatokat bontsa fel, a nem lényeges munkát pedig helyezze a kritikus interakción kívülre. Az eseménykezelők csak a minimumot végezzék, a költséges számítások áthelyezhetők vagy előre elkészíthetők. A DOM-ot tartsa ésszerű méretűnek, és ne hozzon létre több ezer rejtett elemet. A szkripteket a függőségek szerint jelölje defer vagy async attribútummal, ne tömegesen. A módosítás után tesztelje a menüt, az űrlapokat, a cookie-beállításokat, az analitikát és minden állapotot gyors hálózat nélkül is.
Ellenőrizze a betűtípusokat, a harmadik feleket és a regressziókat
Csak a szükséges betűcsaládokat, vastagságokat és karakterkészleteket használja. A helyi tárolás javíthatja az ellenőrizhetőséget és a magánszféra védelmét, ha a licenc megengedi az ilyen felhasználást. A font preload csak a kritikus fájloknak jár; a túl sok preload versenyez a fő képpel. Állítsa be a font-display értéket és egy hasonló metrikájú tartalék betűtípust, hogy a szöveg elérhető maradjon, és az elrendezés ne mozduljon el jelentősen.
Minden chat, analitikai tag, videóbeágyazás vagy hirdetési szkript hálózati és számítási költséggel jár. Tartsa nyilván a felelőst, a célt, a hozzájárulási feltételt és azt, hogy a betöltés elhalasztható-e az interakcióig. Rendszeresen távolítsa el azokat az eszközöket, amelyeket senki sem értékel ki. A teljesítménykeret és a kiadáskor futó automatikus teszt kiszűri a fájlok gyarapodását; a terepi metrikák igazolják a hatást. Az optimalizálás változáskezelési folyamat, nem egyszeri takarítás.
Vezessen be biztonságos optimalizálási sorrendet
Először készítsen leltárt az erőforrásokról, és jelölje meg a tulajdonosaikat. Távolítsa el a nem használt kódot, a képek régi változatait és a cél nélküli tageket. Ezután állítsa be a megfelelő méreteket, formátumokat és a bundle felosztását. Csak ezt követően finomhangolja a prioritást, a preloadot, a minifikálást és a cache-t. Ez a sorrend csökkenti annak kockázatát, hogy bonyolultan optimalizál egy olyan fájlt, amelyre a weboldalnak egyáltalán nincs szüksége, vagy hogy a preloaddal háttérbe szorít egy valóban kritikus erőforrást.
Minden lépést üres és meleg gyorsítótárral is telepítsen staging környezetbe, és hasonlítsa össze a vízesésdiagramot a változtatás előtt és után. Funkcionálisan járja végig a navigációt, az űrlapokat, a keresést, a nyelvválasztó menüt és a pénztárt, ha van. Vizuálisan ellenőrizze az első renderelést és az elmozdulásokat lassú hálózaton. Az eredményt rögzítse a teljesítménykeretben és az automatikus tesztben. Ha az optimalizálás egy konkrét kivételre támaszkodik, dokumentálja azt a komponensnél, hogy egy későbbi refaktorálás ne távolítsa el.
- Előbb eltávolítani, aztán tömöríteni
- Mérés hideg és meleg cache mellett is
- Funkcionális és vizuális regressziós teszt
- A kivételek a komponensnél dokumentálva
Gyakori kérdések
Melyik képformátum a legjobb a webre?
A tartalomtól, a kívánt minőségtől, az átlátszóságtól és a támogatottságtól függ. A modern formátumok gyakran csökkentik a fényképek méretét, az SVG biztonságos vektoros elemekhez megfelelő. Fontosabb a megfelelő méret kiszolgálása és a vizuálisan ellenőrzött tömörítés.
Bekapcsoljam a lazy loadingot minden képre?
Nem. Az első nézeten kívül eső képek profitálnak belőle, a fő LCP-képet azonban késleltetheti. Az elhelyezés és a sablon alapján döntsön. Mindig adja meg a méreteket, és ellenőrizze az eredményt a betöltési vízesésdiagramon.
Biztonságos a CSS és a JavaScript minifikálása?
Megfelelő build folyamat esetén általában igen, de az összevonás és a sorrend megváltoztatása megsértheti a függőségeket vagy a dinamikus kódot. Először távolítsa el a felesleges erőforrásokat, a változtatást staging környezetben vezesse be, és tesztelje a kritikus interakciókat.
Források és további olvasnivaló
Adam Antoni vyvíja weby, aplikácie a softvér na mieru. Prepája firemné systémy, automatizuje procesy a vytvára AI agentov. Pôsobí v Spišskej Novej Vsi a spolupracuje s firmami na celom Slovensku.
