Hogyan csökkentettük egy webhely betöltési idejét egy másodperc alá
A sebesség nem hiúsági mutató — javítja a helyezéseket és növeli a bevételt. Íme a pontos teljesítménynövelő munka, amelyet minden fejlesztésnél elvégzünk, a legfontosabb sorrendben.
A legtöbb lassú weboldal nem rejtélyes okok miatt lassú. Néhány megjósolható, egymásra halmozódott probléma miatt lassúak — és ezeket előre látható sorrendben kell javítani. Amikor egy ügyfél három másodperces betöltési idővel fordul hozzánk, ritkán van szükségünk különleges trükkökre. Fegyelemre van szükségünk.
Ez ugyanaz az ellenőrzőlista, amelyet minden teljesítményoptimalizálási projekt során végigveszünk, nagyjából prioritási sorrendben. Mindegyik lépés költséghatékony a hatásához képest, és a legtöbb webhely a legelső három lépés után drámaian gyorsabbnak érződik.
Mérjen, mielőtt bármihez hozzáérne
Nem tudja javítani azt, amit nem mér, és határozottan nem tudja bizonyítani a javulást kiindulási alap nélkül. Minden projektet valós felhasználói adatokkal (field data) kezdünk, nem csak laboratóriumi pontszámokkal (lab scores).
- Labor (Lab) — Lighthouse és WebPageTest egy ellenőrzött, megismételhető pillanatképhez.
- Valós (Field) — valós felhasználói metrikák (CrUX / RUM) arról, amit az emberek valójában tapasztalnak.
- Keret (Budget) — szigorú felső határ útvonalanként, így a visszaeséseket a CI-ban szűrjük ki, nem pedig éles környezetben (production).
A 100-as laborpontszám semmit sem ér, ha a valós felhasználók középkategóriás telefonokat és megbízhatatlan hálózatokat használnak. Optimalizáljon a valós adatokra.
Szüntesse meg a renderelést blokkoló erőforrásokat
A legtöbb weboldalon a legnagyobb nyereséget az jelenti, ha a CSS-t és a JavaScriptet eltávolítjuk a kritikus útvonalról (critical path). A böngésző addig nem tud rajzolni (paint), amíg be nem fejezte a renderelést blokkoló erőforrások feldolgozását — így minél kevesebb van belőlük, annál hamarabb jelenik meg valami.
// defer everything that isn't critical
const load = () => import('./analytics.js');
if ('requestIdleCallback' in window)
requestIdleCallback(load);
else setTimeout(load, 2000);Illessze be közvetlenül (inline) a CSS azon kis részét, amely az első képernyőhöz (first viewport) szükséges, majd a többit töltse be aszinkron módon. Halassza (defer) a nem kritikus szkripteket. A cél egy olyan első megjelenítés (first paint), amely nem vár semmire, amire nincs feltétlenül szüksége.
Tekintsen a képekre keretként (budget)
A képek általában a legnehezebb elemek az oldalon, és ezeknél a legkönnyebb hibázni. Az esetek kilencven százalékát három szabály lefedi:
- Kiszolgálás modern formátumokban — AVIF vagy WebP —, fallback lehetőséggel.
- Méretezze a képeket a megjelenített méreteikre; soha ne küldjön egy 3000px-es főképet (hero) egy 600px-es helyre.
- Alkalmazzon lusta betöltést (lazy-load) mindenre, ami a hajtás alatt (below the fold) van, és foglaljon le helyet a kiterjedésváltozás (layout shift) elkerülése érdekében.
Gyorsítótárazás az edge-en
Miután az oldal letisztult, a következő kérdés az, hogy a bájtok milyen gyorsan érik el a felhasználót. Egy ésszerű gyorsítótár-fejlécekkel (cache headers) ellátott CDN a 600 ms-os lekérést az eredetszervertől (origin trip) 30 ms-os edge-találattá (edge hit) alakítja. Dinamikus tartalom esetén a stale-while-revalidate azonnali válaszokat ad, miközben a háttérben frissít.
A teljesítmény egy funkció. Ugyanúgy tervezünk rá keretet (budget), mint a fejlesztés bármely más részére.
Az eredmény
A cikk alapjául szolgáló projektben a főoldal largest contentful paint értéke 3,1 másodpercről 0,9 másodpercre csökkent, és az organikus konverziók mérhetően növekedtek a hónapon belül. Egyik sem volt varázslat — csak a fenti ellenőrzőlista, sorrendben alkalmazva.
Ha webhelye lassúnak tűnik, és nem tudja, hol kezdje, vegye fel velünk a kapcsolatot — egy rövid audit általában felszínre hozza azt a két vagy három változtatást, amely a legtöbb szempontból számít.