# 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.

- **Eredeti HTML oldal:** [https://weboldal-berles.hu/blog/mi-van-a-motorhazteto-alatt-weboldal-teljesitmeny-core-web-vitals-rum](https://weboldal-berles.hu/blog/mi-van-a-motorhazteto-alatt-weboldal-teljesitmeny-core-web-vitals-rum)
- **AI tartalmi térkép:** [llms.txt](https://weboldal-berles.hu/llms.txt)

- **Megjelenés:** 2026-08-28
- **Kategória:** Weboldal bérlés
- **Szerző:** Szabó Balázs
- **Címkék:** Core Web Vitals, LCP, responsive képek, RUM, webfejlesztés, weboldal bérlés, weboldal teljesítmény

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](https://weboldal-berles.hu/blog/mi-van-a-motorhazteto-alatt-weboldal-berles-rendszerarchitektura) 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](https://weboldal-berles.hu) 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](https://weboldal-berles.hu) 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](https://weboldal-berles.hu/weboldal-vitalitas) 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.

| [#3 - Így épül fel a Weboldal Bérlés rendszerarchitektúrája](https://weboldal-berles.hu/blog/mi-van-a-motorhazteto-alatt-weboldal-teljesitmeny-core-web-vitals-rum) | [#1 - Így épül fel a Weboldal Bérlés rendszerarchitektúrája](https://weboldal-berles.hu/blog/mi-van-a-motorhazteto-alatt-weboldal-berles-rendszerarchitektura) |
| --- | --- |