Mi van a motorháztető alatt? #2 - A képfeldolgozástól a RUM-ig: performance a Weboldal Bérlésben
A gyors weboldal nem egy PageSpeed-pontszámmal kezdődik, és nem egy cache plugin bekapcsolásával ér véget. A Weboldal Bérlésben a teljesítmény a renderelési, kép-, videó-, asset- és mérési pipeline része: responsive képek, LCP-prioritás, célzott JavaScript, stabil layout és saját RUM együtt adja a rendszert.
Egy weboldal attól még nem gyors, hogy egyszer 100 pontot kapott a PageSpeed Insightsban. A valódi kérdés az, hogy milyen erőforrást, mikor, milyen méretben és milyen prioritással küldünk a böngészőnek – és hogy ez a tényleges látogatóknál milyen LCP, INP és CLS értékeket eredményez.
A sorozat első részében a Weboldal Bérlés MVC-alapú, multi-tenant architektúráját és moduláris renderelését néztük meg. Most egy réteggel kijjebb megyünk: azt vizsgáljuk, hogyan jut el a tartalom a lehető legésszerűbb hálózati és renderelési költséggel a böngészőig.
A performance nálunk nem utólagos optimalizálás
A klasszikus folyamat sokszor úgy néz ki, hogy elkészül a weboldal, majd a végén lefut egy Lighthouse, és elkezdődik a piros figyelmeztetések kergetése. Ezzel az a probléma, hogy a legtöbb komoly teljesítménygond már jóval korábban, az architektúrában eldőlt.
Ha minden oldalon betöltünk minden JavaScriptet, az eredeti 3000 pixeles képet küldjük mobilra, a hero kép csak a parser végén kap prioritást, a videó mindkét responsive ága hidratálódik, vagy a consent banner csak JavaScript után kapja meg a végleges geometriáját, azt a végén már nehéz egy minifierrel megjavítani.
A cél: a böngésző már az első requesteknél lehetőleg azt kapja, amire az adott viewportnak és komponensnek ténylegesen szüksége van – nem azt, amit majd később JavaScriptből megpróbálunk visszacsinálni.
Responsive képek: nem elég WebP-re konvertálni
A modern képkezelés három külön problémát old meg: formátumot, felbontást és kiválasztást. Önmagában attól, hogy egy JPEG-ből WebP vagy AVIF készül, még simán letölthetünk mobilon egy indokolatlanul nagy képet.
A Weboldal Bérlés responsive képkezelése több derivatívából dolgozik, a renderelt /srcset pedig use case szerint adja át a böngészőnek a választható candidate-eket. Különösen érzékeny terület a hero, mert nagyon gyakran maga a hero kép lesz az LCP elem.
A split hero szűk mobil profilján például a kép és a preload ugyanabból a candidate-logikából dolgozik: 575 px alatt 360 / 480 / 640 szélességű jelöltekre korlátozzuk a kritikus ágat. A 576–767 px közötti és a desktop tartomány már a teljes responsive készletből választhat. A fontos rész nem önmagában ez a három szám, hanem az, hogy a preload és a később renderelt picture ugyanazt a szabályt kövesse.
| Terület | Performance-döntés | Miért számít? |
|---|---|---|
| Responsive kép | Use case szerinti srcset és sizes | A böngésző nem szükségtelenül nagy fájlt választ. |
| Hero / LCP | loading="eager" + fetchpriority="high" | A kritikus vizuális elem nem áll be a normál lazy queue végére. |
| Preload | A tényleges picture candidate-profil tükrözése | Nem preloadolunk egy képet, majd rendereléskor töltünk le helyette egy másikat. |
| Másodlagos képek | Lazy loading | Nem versenyeznek az első viewport kritikus erőforrásaival. |
| Méretfoglalás | Width/height vagy stabil aspect ratio | A kép megérkezése nem tolja szét a layoutot, így csökken a CLS-kockázat. |
LCP: a preload csak akkor jó, ha ugyanazt tölti le a böngésző
A könnyen kontraproduktív lehet. Ha a preload egy 960-as képet kér, de a tényleges picture alapján a böngésző 480-as képet választ, két requestet is előidézhetünk ahelyett, hogy gyorsítottunk volna.
Ezért a hero LCP-nél a preload nem külön, kézzel karbantartott „második algoritmus”. A cél az, hogy ugyanaz a responsive profil adja a picture és a preload candidate-jeit és sizes értékét. Így a prioritás valóban ugyanarra az erőforrásra mutat, amelyet a böngésző később használni fog.
JavaScript: nem minden oldalnak kell minden bundle
A kliensoldali JavaScriptnél a legolcsóbb végrehajtási idő az a kód, amit le sem töltünk. A rendszer ezért funkció- és komponensfüggő frontend bundle-okkal dolgozik. Egy olyan oldalnak, amelyen nincs adott interaktív modul, nincs szüksége annak teljes runtime-jára sem.
A buildelt fájlok tartalomhash alapján változhatnak, ezért egy módosított forrás új assetnevet kaphat, miközben a változatlan fájlok hosszú cache-élettartammal kiszolgálhatók. Ez egyszerre segíti a cache-elhetőséget és azt, hogy release után ne egy régi böngészőcache miatt kelljen hibát keresni.
A videó külön kategória: poster előbb, stream később
Egy hero videó könnyen több megabájtos erőforrás, ezért nem szerencsés úgy kezelni, mint egy normál képet. A Weboldal Bérlés jelenlegi videófolyamatában az inaktív responsive ág nem kap automatikusan forrást. Mobilon kisebb rendition, normál DPR-es split desktopon közepes, nagyobb felbontású vagy high-DPR környezetben nagyobb változat választható.
A jelenlegi profil mobilon 480p, normál DPR-es split desktopon 720p, high-DPR split/full desktop esetén 1080p változatot használ; WebM az elsődleges, MP4 a fallback. Az eredeti nagy videó csak akkor kerül elő, ha nincs megfelelő generált rendition.
Ez nem csupán bandwidth-optimalizálás. Az első paint környékén az a fontos, hogy a poster/LCP frame megkapja az elsőbbséget, a videó pedig ne kezdjen el a consenttel, hero képpel és kritikus CSS-sel versenyezni.
CLS: sokszor nem egy „ugráló div” a valódi probléma
A Cumulative Layout Shift tipikusan időzítési probléma. Egy banner, font, sticky header, kép, carousel vagy dinamikusan megjelenő komponens önmagában lehet teljesen helyes – csak ha a végleges geometriája későn derül ki, már elmozdítja a felhasználó előtt megjelent tartalmat.
Erre jó példa a consent. Ha a böngésző először banner nélküli állapotot rajzol, majd a deferelt JavaScript később megjeleníti a consent UI-t és új helyet foglal, a CLS már megtörtént. Ezért a jelenlegi megoldásban a korai head bootstrap és a critical consent CSS már az első paint előtt ismeri az alapállapotot; a későbbi JavaScript elsősorban az interakciót köti rá.
Lab vagy field? Mindkettő kell, de nem ugyanarra
A Lighthouse és a PageSpeed kiváló diagnosztikai eszköz. Megmutatja a request waterfallt, a blocking erőforrásokat, a main-thread költséget, az LCP breakdownot és rengeteg olyan részletet, amely nélkül nehéz lenne fejleszteni. De ez laboratóriumi mérés.
A Weboldal Bérlés ezért saját RUM - Real User Monitoring réteget is használ. Itt a tényleges látogatók LCP, INP és CLS adatai kerülnek p75 alapú kiértékelésbe, többek között eszköz, URL/oldaltípus, release és blokkattribúció szerint.
A rendszer alatt futó weboldalak nyilvános, saját RUM-alapú Web Vitals adatai a Weboldal vitalitás oldalon is megtekinthetők. Így nemcsak egy-egy laboratóriumi mérés, hanem a valós látogatói adatokból számolt aktuális állapot és trend is követhető.
| Mérés | Mire jó? | Mire nem elég önmagában? |
|---|---|---|
| Lighthouse / PSI | Trace, waterfall, diagnosztika, reprodukálható tesztkörnyezet | Nem bizonyítja önmagában, hogy a valódi látogatóknál is regresszió történt. |
| Saját RUM | Valós látogatók p75 LCP/INP/CLS állapota és trendje | Nem mondja meg automatikusan a hibás kódsort; ehhez trace és célzott diagnosztika kell. |
| Release összevetés | Megmutatja, hogy egy verzióváltással együtt romlott-e a field teljesítmény | Kis mintánál óvatosan kell következtetni. |
| Blokk-attribution | Segít a problémát hero, űrlap, carousel vagy más komponens köré szűkíteni | Korreláció; a javítás előtt a konkrét render/network folyamatot is ellenőrizni kell. |
Miért p75 és miért nem egyszerű átlag?
A Core Web Vitals szemléletében nem az a kérdés, hogy az „átlagos” látogatónál jó volt-e az oldal, hanem hogy a felhasználók nagy többsége elfogadható élményt kap-e. Ezért a saját RUM-értékelésben is a p75 a fontos döntési pont: a mérések 75 százaléka ennél az értéknél jobb vagy azzal azonos.
A primary RUM populációban a normál navigate és reload betöltéseket kezeljük fő mérési alapként. BFCache, prerender és egyéb speciális navigációk diagnosztikai adatként hasznosak, de nem érdemes velük mesterségesen szebbre vagy rosszabbra húzni a normál oldalbetöltés p75 értékét.
Nem optimalizálunk egyetlen PageSpeed-futásra
A performance-fejlesztés egyik legkönnyebb csapdája a mérési zaj optimalizálása. Ugyanaz az oldal egymást követő Lighthouse-futásokban is adhat eltérő TBT-t, LCP-t vagy összpontszámot.
Ezért a release-gate szemléletünk egyszerű: ugyanazon verzión több mobil és desktop futást nézünk, mediánnal dolgozunk, és csak azt tekintjük valódi problémának, ami ismétlődik és trace-, network- vagy RUM-adattal is alátámasztható.
Nem a PageSpeed warninglistát optimalizáljuk. A felhasználói teljesítményt optimalizáljuk.
A performance valójában visszacsatolási kör
A jó performance-rendszer nem ér véget a deploynál:
- komponens és asset szabályok meghatározzák, mi kerül a böngészőbe;
- a labor mérés segít megtalálni a technikai okot;
- a saját RUM megmutatja, mi történik a tényleges látogatóknál;
- a release- és blokk-attribution segít szűkíteni a regresszió forrását;
- a javítás után pedig ugyanazokkal a metrikákkal ellenőrizhető, hogy valóban jobb lett-e.
Ezért a Weboldal Bérlésben a teljesítmény nem külön „SEO plugin”, nem egyszeri PageSpeed-projekt és nem egyetlen cache-beállítás. Ugyanannak a platformnak a része, mint a renderer, a responsive média, a JavaScript-bundle, a consent és a monitoring.
A következő rész: canonicaltól a foglalási engine-ig
A harmadik részben a háttérszolgáltatások kerülnek sorra: technikai SEO, canonical és sitemap, strukturált adatok, szerzői és tartalmi entitások, űrlapok és consent, valamint az olyan összetettebb modulok, mint a Blog és az Időpontfoglaló. Ott már azt nézzük meg, hogyan lesz a közös platformból nemcsak gyors frontend, hanem üzletileg használható alkalmazás.
GYIK
Gyakran ismételt kérdések a weboldal teljesítményéről és a RUM mérésről
Technikai válaszok az LCP-ről, responsive képekről, PageSpeedről, RUM-ról és a stabil első renderelésről.
A RUM, vagyis Real User Monitoring a tényleges látogatók böngészőjében méri többek között az LCP, INP és CLS értékeket. A PageSpeed/Lighthouse ezzel szemben kontrollált laboratóriumi futás. A lab jó diagnosztikára, a RUM pedig arra, hogy lássuk, mit tapasztalnak valóban a felhasználók.
Mert egyetlen laborfutás pillanatfelvétel, amelyet hálózati és futtatási zaj is befolyásolhat. A Weboldal Bérlésnél több futás mediánját, trace- és network-adatokat, valamint saját RUM trendet együtt érdemes értékelni.
A responsive kép HTML több candidate-et ad át srcset és sizes segítségével, a böngésző pedig a viewport és a megjelenítési méret alapján választ. Kritikus hero use case-eknél a candidate-készlet külön szűkíthető; a split hero szűk mobil ágán például 360, 480 és 640 pixeles változatokból választ.
Ha a preload más candidate-profilt használ, mint a tényleges picture elem, a böngésző előre letölthet egy olyan képet, amelyet végül nem használ. Ez felesleges hálózati versenyt okozhat. Ezért a preload és a renderelt kép responsive logikáját össze kell hangolni.
A videó inaktív responsive ágát nem kell azonnal hidratálni, és az első paintnél a poster vagy LCP kép kap prioritást. A Weboldal Bérlés több videó-renditionből választ viewport és DPR szerint, WebM elsődleges és MP4 fallback formátummal.
Igen. Ha a consent felület geometriája csak késői JavaScript után jelenik meg, layout shiftet okozhat. Ezért fontos, hogy az első painthez szükséges consent állapot és kritikus CSS korán rendelkezésre álljon, miközben a statisztikai mérés csak megfelelő hozzájárulás után indul.