100 pont a PageSpeed-tesztben: mit változtattunk érte
A betöltési idő rangsorolási tényező, de a szokásos tanácsok ritkán segítenek. Ez a cikk leírja, mit változtattunk ténylegesen a saját oldalunkon, melyik intézkedés mennyit hozott, és hol tértünk rossz irányba.
A lényeg röviden
- A legnagyobb egyedi nyereség nem a fájlok kicsinyítéséből jött, hanem abból, hogy egy 458 KB-os programkönyvtárat 6 KB saját kóddal váltottunk ki.
- A második legnagyobb ok egy félig beállított tömörítés volt: a szerver csak a HTML-t tömörítette, a CSS-t és a JavaScriptet nem.
- Egy 1-es értékű elrendezésugrás 24 pontba került – utólag betöltött CSS okozta, amely csak az első képfelépítés után lépett életbe.
- Ami a legkevesebbet hozta: a képformátumok. Ami a legtöbbet: a dolgok elhagyása.
A kiindulási érték 58 volt a 100-ból mobilon. Ez nem rossz érték egy olyan weboldalhoz, amelynek a fejlécében 3D-hatás van, de olyan érték, amelyet a Google a mobil keresésben érezhetően büntet. A végén 100 pont állt asztali gépen és 98 mobilon, ugyancsak 100-zal az akadálymentességre.
Ami következik, az nem általános ellenőrzőlista, hanem a tényleges menet – beleértve azokat a helyeket, ahol tévedtünk.
A kiindulási helyzet
| Mérési érték (mobil) | előtte | utána |
|---|---|---|
| Teljesítmény | 58 | 98 |
| Akadálymentesség | 95 | 100 |
| Első képfelépítés | 6,1 s | 1,4 s |
| Legnagyobb elem látható | 11,1 s | 2,1 s |
| Átvitel összesen | 298 KB | 184 KB |
| ebből JavaScript | 121 KB | 5 KB |
Az öt beavatkozás, amely valóban számított
1. A programkönyvtárat kiváltani, nem optimalizálni
A fejléc egy részecskefelhőt mutat 3D-ben. Ehhez egy ismert grafikus programkönyvtár futott – 458 KB a kicsinyítés után. A mérés kimutatta, hogy ebből 51 KB egyáltalán soha nem futott le.
A döntő pillantás az a kérdés volt, mennyire van ténylegesen szükségünk belőle. Tizenegy építőelemre: renderelő, jelenet, kamera, geometria, anyag és néhány segédosztály. Mindez közvetlenül a böngésző grafikus felületére programozható.
Eredmény: a 458 KB-ból 6 KB lett. A megjelenítés azonos – ugyanazokat az árnyalókat vettük át.
2. A tömörítés csak félig volt bekapcsolva
A szerverbeállításban a tömörítés „be” értéken állt – de az a sor, amely megmondja, mely fájltípusokat kell tömöríteni, ki volt kommentelve. Ez sok disztribúció alapbeállítása. Eredmény: kizárólag a HTML tömörödött.
A grafikus programkönyvtár tehát tömörítetlenül ment át a vonalon. A bekapcsolás után: az 1243 KB-ból 251 KB lett. Ezenfelül a tömörített változatokat most előre kiszámítva tesszük mellé, hogy a szervernek ne kelljen minden lekérésnél újraszámolnia.
Ráfordítás: két sor beállítás. Hatás: csaknem egy megabájt első lekérésenként.
3. Az animációs programkönyvtárat teljesen eltávolítani
A görgetéskori felúsztatásokhoz egy további programkönyvtár futott, 114 KB. A mérés ráadásul kikényszerített elrendezés-újraszámítások okozójaként mutatta ki – görgetés közben geometriát kérdezett le, és arra kényszerítette a böngészőt, hogy a mozgás közepén újraszámolja az elrendezést.
Kiváltottuk egy IntersectionObserverrel, amely csupán beállít egy osztályt. A tényleges mozgást a CSS végzi. 114 KB-tal kevesebb, nincs több újraszámítás, mintegy 40 sor saját kód.
4. A favikon 205 KB nagyságú volt
Apróság meglepő hatással, mert nagyon korán töltődik be. Kiváltottuk egy 6 KB-os SVG-fájllal, amelyet a meglévő logóból készítettünk.
Tudtad?
A Google-találatokban való megjelenéshez az SVG-favikon nem használ – a Google ott csak raszterformátumokat fogad el, és a képnek négyzetesnek kell lennie olyan élhosszal, amely 48 képpont többszöröse.
Aki tehát csak SVG-t helyez el, a találatban a szürke helykitöltőt kapja a saját logója helyett. A helyes út mindkettőt egymás mellett megadni.
5. A geometriát az animációs képkockában lekérdezni
Egy szkript minden görgetési eseménynél kiolvasta a dokumentum teljes magasságát. Ezt a tulajdonságot a böngésző nem tudja emlékezetből megválaszolni – ehhez újra végig kell számolnia az egész oldal elrendezését, görgetés közben.
Az ebből következő szabály, amely mindenütt érvényes: az eseményben olvasni, a rákövetkező képkockában írni. Soha fordítva. Azóta az oldalmagasságot egyszer mérjük meg és jegyezzük meg, ahelyett hogy másodpercenként hatvanszor újra lekérdeznénk.
A hiba, amely 24 pontba került
Hogy megszabaduljunk az utolsó blokkoló lekéréstől, kettéosztottuk a stíluslapot: a látható területhez szükséges rész közvetlenül a dokumentumba került, a többi utólag töltődött be. Bevett eljárás.
A vágás a forrásfájl egy jelölésénél volt, amely mögött a látható területet sejtettük. Valójában mögötte álltak a fejléc logójának szabályai, az alatta lévő térközöké és a felúsztatásoké. Az oldal tehát nélkülük épült fel, és egy másodperccel később helyre tolódott.
Az eredmény: 1,0 értékű Cumulative Layout Shift – és ezzel 76 pont a 100 helyett asztali gépen. Különösen kellemetlen: helyben, fékezett vonalon az érték 0 volt, mert a stíluslap ott elég korán megérkezett. A hiba csak gyors kapcsolaton volt látható.
A tanulság: vagy az egész stíluslap a dokumentumba, vagy egy sem. A részleges beépítés feltételezi, hogy pontosan tudjuk, melyik szabály kell a látható területen – és ezt egy növekvő oldalnál sosem tudjuk tartósan.
Ami keveset hozott
A teljesség kedvéért azok az intézkedések, amelyek minden útmutatóban szerepelnek, nálunk viszont alig voltak mérhetők:
Képformátumok. A kezdőlapunkon alig van kép – a logó SVG-fájl. Ahol képek előfordulnak, az átalakítás természetesen megéri; fő emelőnek azonban csak képnehéz oldalaknál alkalmas.
A betűtípusok további kicsinyítése. Két betűcsaládot magunk szolgálunk ki, és a látható területen szükségeseket előre betöltjük. További optimalizálás lehetséges lenne, de nem mozdítja az értéket.
A szerver helye. Sokszor ajánlják, a mi esetünkben lényegtelen: az első bájtig eltelt idő már 20 ezredmásodpercnél volt. Aki ott már jól áll, semmit sem nyer egy elosztóhálózattal.
Az utánacsinálható eljárás
- Mérjetek, mielőtt bármit is változtatnátok. Mobilt és asztalit külön, az értékeket feljegyezve.
- Keressétek meg a legnagyobb átvitt fájlt. Szinte mindig JavaScript. A kérdés nem az, hogyan lehet kicsinyíteni, hanem hogy kell-e egyáltalán.
- Ellenőrizzétek a tömörítést. Ne azt, be van-e kapcsolva, hanem azt, mely fájltípusokra.
- Számoljátok meg a blokkoló lekéréseket. Minden stíluslapfájl a fejlécben feltartja az első képfelépítést.
- Fékezés nélkül vizsgáljátok az elrendezésugrásokat. Ez az az egy teszt, amely nálunk hiányzott.
- Minden változtatás után mérjetek újra. Különben a végén nem tudjátok, mi hatott.
Segíts sorrendbe fordítani az oldalam PageSpeed-jelentését. Légy szigorú; ne dicsérj semmit. A mérési értékeim: - Mobil: [pontszám], asztali: [pontszám] - LCP, TBT, CLS eszközönként: [értékek] - A legnagyobb átvitt fájlok mérettel: [lista] - Renderelést blokkoló lekérések: [lista] - A jelentés üzenetei: [szöveg beillesztése] Az oldalról: - Hogyan épült: [CMS / statikus / oldalépítő] - Kell-e JavaScript a látható tartalomhoz? [igen/nem] - Hogyan szolgálódik ki a CSS? [külső / előre / részben előre] Feladatok: 1. Rendeld hozzá minden üzenetet egy okhoz, és mondd meg, melyik mutatót befolyásolja – LCP, TBT vagy CLS. 2. Rendezd az intézkedéseket hatás/ráfordítás szerint. Mindegyiknél nevezd meg, hány pontot mozdít reálisan, és miért. 3. Nevezd meg a jelentésből azokat az intézkedéseket, amelyek az én felépítésemnél gyakorlatilag semmit sem hoznak – és indokold, ahelyett hogy egyszerűen elhagynád őket. 4. Minden nagy JavaScript-fájlnál először azt kérdezd, kell-e egyáltalán, mielőtt a kicsinyítést javasolnád. 5. Jelezd, ha a CSS csak részben szolgálódik ki előre, és magyarázd el, miért lehet ez a CLS szempontjából rosszabb, mint egyáltalán nem. 6. Nevezd meg, mit kell minden változtatás után újramérnem. Ne találj ki mérési értékeket.
Összegzés
Maga a pontszám nem cél – mérési érték, nem üzleti eredmény. Ami számít, az a mögötte álló élmény: egy oldalt, amely 1,4 másodperc után olvasható, több ember olvas el, mint egyet, amelynek hat másodperc kell. A mobilhálózaton érkező látogatóknál a különbség nagyobb, mint bármely szövegoptimalizálás.
Az odavezető út a mi esetünkben egyetlen visszatérő kérdésen át vezetett: kell ez nekünk? Hat beavatkozásból öt abból állt, hogy elvettünk valamit, nem abból, hogy hozzátettünk.
Gyakori kérdések
Hogyan érhető el 100 pont a PageSpeed Insightsban?
A legtöbb weboldalnál három lépésen keresztül: a legnagyobb JavaScript-fájl eltávolítása vagy kiváltása, a tömörítés tényleges bekapcsolása a CSS-re és a JavaScriptre, valamint az elrendezésugrások megszüntetése. A képformátumok és a szerver helye ritkán a szűk keresztmetszet.
Mennyire fontos a betöltési idő a Google-rangsoroláshoz?
Megerősített tényező, de nem erős – a tartalom és a relevancia többet nyom a latban. A nagyobb hatás közvetett: a lassú oldalakat gyakrabban hagyják ott, és ez a viselkedés beépül az értékelésbe.
Mi az a Cumulative Layout Shift, és hogyan szüntethető meg?
Azoknak az elemeknek a mérőszáma, amelyek az első képfelépítés után megváltoztatják a helyüket. A leggyakoribb okok: rögzített méret nélküli képek, utólag betöltött stíluslapok és erősen eltérő metrikájú betűtípusok. Úgy szüntethető meg, ha a hely előre rögzített – szélesség- és magasságmegadással vagy rögzített oldalaránnyal.
Be kell építeni a CSS-t a HTML-be?
Kis stíluslapoknál igen, de akkor teljesen. A részleges beépítés a többi utólagos betöltésével megspórol egy lekérést, cserébe elrendezésugrásokat szerez, amint egy szabály hiányzik a látható területen. Nálunk 7 KB volt tömörítve – ehhez megéri a teljes beépítés.
Mennyit hoz a programkönyvtárakról való lemondás?
A mi esetünkben a legnagyobb egyedi tételt: a 458 KB grafikus programkönyvtárból 6 KB saját kód lett, ehhez jött a 114 KB animációs programkönyvtár nullára csökkentése. Hogy megéri-e, attól függ, mennyit használunk ténylegesen a programkönyvtárból – a mérés kimutatja a nem használt JavaScriptet.
Marketing, amely magát állítja be
A Studio Engine bétája nyitva áll. Foglalj helyet, és alakítsd az elejétől fogva.
Csatlakozom a bétához →