Oldalméret (HTML-méret)

SEO

A nagy HTML lassabban érkezik meg és lassabban elemződik. Ez közvetlenül tolja a LCP értékét, mert a fő tartalom megjelenítése a HTML feldolgozása után kezdődik. Lassú mobilhálózaton a különbség másodpercekben mérhető.

AI-értelmezhetőség

A beágyazott CSS és a duplikált markup nem hordoz jelentést. Minél nagyobb az arányuk, annál kevesebb tény jut egy modell kinyerő rétegéig. A kontextus-ablak véges, a zaj pedig helyet foglal.

Üzlet

A feltérképezési költség is valós. Egy 300 kilobájtos sablon 5000 terméken 1,5 gigabájt felesleges forgalom crawlonként. Webshopnál ez a feltérképezés tempóján is meglátszik.

• Minden nyilvános HTML-oldalon számít, mert minden kérés a dokumentummal kezdődik.
• Webshopokban a legérzékenyebb, főleg a kategórialistákon és a szűrős oldalakon.
• Page builderrel épített KKV-oldalakon szinte garantált a felpuffadt HTML.
• Kevésbé kritikus belső admin-felületen, bejelentkezés mögötti nézetben, staging-környezetben.
• Nem releváns JSON-t vagy képet visszaadó végpontokon, ott más mérőszámok számítanak.

Egyoldalas bemutatkozó weboldalnál a nagy HTML önmagában nem drága. Ott inkább jelzés: valószínűleg beépített sablonszemét van a forrásban.

1. Nyisd meg a böngésző devtools Network fülét, frissíts, és kattints az első, dokumentum típusú kérésre.
2. Nézd meg a Size oszlop két sorát: a felső az átvitt, az alsó a kicsomagolt méret.
3. Ellenőrizd a Response Headers blokkban a content-encoding értékét, itt br vagy gzip a jó.
4. Parancssorból kérd le a nyers forrást curl-lel, és számold meg a bájtokat.
5. Futtass egy PageSpeed Insights vagy Lighthouse mérést, és keresd a total byte weight bontásában a document sort.
6. Ha nagy a szám, nyisd meg a View Source nézetet, és nézd meg, mi tölti ki. Általában egyetlen <style> blokk a bűnös.

Jó jel

• Nyers HTML 100 kilobájt alatt.
• Átvitt méret 25 kilobájt alatt tömörítéssel.
• A forrásban látszik a szöveg, nem kell görgetni a tartalomig.

Rossz jel

• 300 kilobájt fölötti nyers HTML tartalmi oldalon.
• Több ezer soros <style> blokk a <head>-ben.
• data:image/png;base64, kezdetű, több tízezer karakteres sorok.
• Hiányzó content-encoding fejléc.

WordPress

1. Nézd meg, melyik page builder ír inline stílust. Elementornál kapcsold be a külső CSS-fájlba mentést a teljesítmény-beállításoknál.
2. Kapcsold ki a nem használt bővítményeket, mert sok közülük minden oldalra injektál markupot.
3. Csökkentsd az archívumokon megjelenő bejegyzések számát 12-24 darabra.
4. Tiltsd le a felesleges beágyazott szkripteket, például az emoji-loadert.

Shopify

1. Keresd meg a sablonban a teljes objektumot kiíró | json hívásokat, és szűkítsd a mezőket.
2. Termékoldalon ne dumpold ki az összes variáns minden metamezőjét.
3. Nézd át a telepített appokat, sok közülük inline szkriptblokkot tesz minden oldalra.

Unas

1. A szövegszerkesztőbe Wordből bemásolt tartalom tele van inline formázással. Illeszd be sima szövegként, és formázz újra.
2. A saját HTML-blokkokban ne tarts stíluslapot, tedd a sablon CSS-ébe.
3. Csökkentsd a kategóriaoldalon egyszerre listázott termékek számát.

Shoprenter

1. A sablonszerkesztőben mozgasd a beágyazott stílust külön CSS-fájlba.
2. Ellenőrizd a fejlécbe illesztett egyedi kódokat, ott gyűlnek a mérőkódok.
3. Állítsd 24-48 termékre az oldalankénti listát.

Egyedi fejlesztés

1. Kapcsold be a brotli tömörítést a webszerveren vagy a CDN szintjén.
2. SSR-keretrendszernél nézd meg a hidratációs payloadot, és csak a megjelenítéshez kellő adatot szerializáld.
3. A base64-be ágyazott képeket tedd külön fájlba, lehetőleg WebP vagy AVIF formátumban.
4. Az inline CSS helyett csak a critical CSS maradjon a <head>-ben, a többi külső fájlban.

• Az egész stíluslap beágyazása a HTML-be: minden oldalletöltésnél újra átmegy a vonalon, cache nélkül.
• Base64-be kódolt képek a forrásban: egy 40 kilobájtos kép így 54 kilobájtot hizlal a HTML-en.
• 500 termék egy kategórián: a sablon markupja annyiszor ismétlődik, ahány elem van.
• Tömörítés hiánya: a content-encoding fejléc nélkül a nyers méret megy át a hálózaton.
• Minify mint egyetlen megoldás: a whitespace levágása 5-10 százalékot hoz, a beágyazott kilobájtokat nem tünteti el.
• Rejtett mobil- és asztali változat egyszerre: mindkét markup letöltődik, csak az egyik látszik.
• Több tíz kilobájtos kommentblokk a sablonból: a szerkesztőnek szól, a felhasználó fizeti a forgalmat.

Nyers és tömörített méret mérése parancssorból:

# nyers HTML-méret bájtban
curl -sL https://pelda.hu | wc -c

# amit a böngésző tényleg letölt (brotli vagy gzip)
curl -sL -H 'Accept-Encoding: br, gzip' https://pelda.hu | wc -c

# tömörítés ellenőrzése a válaszfejlécben
curl -sIL https://pelda.hu | grep -i 'content-encoding\|content-length'

A két szám aránya a tömörítési nyereség. Ha alig térnek el, nincs bekapcsolva a tömörítés.

Tipikus felpuffadás és a karcsú változat:

<!-- rossz: beágyazott stílus és base64-kép a dokumentumban -->
<style>
  .hero { padding: 40px; background: #fff; }
  /* ... további 3200 sor a page buildertől ... */
</style>
<img src="data:image/png;base64,iVBORw0KGgoAAAANSUhEUg..." alt="Csapatunk">

<!-- jó: külső, cache-elhető fájlok -->
<link rel="stylesheet" href="/assets/app.css">
<img src="/img/csapat.avif" width="800" height="600" alt="Csapatunk" loading="lazy">

A külső CSS egyszer töltődik le, utána a böngésző cache-éből jön minden további oldalon.