A Google nemrégiben megjelent podcastja arra hívta fel a figyelmet, hogy a webhelyek egyre nagyobbak, mint valaha. Gary Illyes és Martin Splitt, a Google munkatársai elmagyarázták, hogy az az elképzelés, hogy a webhelyek egyre „nagyobbak”, nem feltétlenül igaz. A kiadók és a keresőoptimalizálók számára az a következtetés vonható le, hogy az oldalsúly nem megbízható mérőszám, mert a „túlsúly” oka nagyon is hasznos lehet.
Az oldal mérete attól függ, hogy mit mérünk
Martin Splitt, a Google munkatársa elmagyarázta, hogy az, hogy sokan mit gondolnak oldalméretnek, attól függ, hogy mit mérnek.
- Csak a HTML méri?
- Vagy a teljes oldalméretről beszél, beleértve a képeket, a CSS-t és a JavaScriptet?
Ez egy fontos megkülönböztetés. Sok keresőoptimalizáló például kiakadt, amikor meghallotta, hogy a Googlebot oldalanként mindössze 2 megabájt HTML-re korlátozza az oldal feltérképezését. A perspektíva szempontjából két megabájt HTML körülbelül kétmillió karakternek (betűknek, számoknak és szimbólumoknak) felel meg. Ez egy HTML-oldalnak felel meg, ugyanannyi betűvel, mint két Harry Potter-könyvben.
De ha a HTML-mel együtt CSS-t, képeket és JavaScriptet is megad, akkor most egy másik beszélgetést folytatunk, amely a felhasználók oldalsebességére vonatkozik, nem pedig a Googlebot feltérképező robotjára.
Martin tárgyalt egy cikket a HTTPArchive webes almanachjáról, amely a webhelytrendek összefoglalása. Úgy tűnt, hogy a cikk különböző típusú oldalsúlyokat kever össze, és ez zavaróvá teszi, mert az oldalsúlynak legalább két változata létezik.
Megjegyezte:
„Látod, ez az a pont, ahol nem vagyok olyan egyértelmű az oldalsúly meghatározását illetően.
…van egy bekezdésük, ahol megpróbálják elmagyarázni, mit értenek oldalsúly alatt. …nem értem a különbségeket, hogy mik ezek a dolgok. Tehát azt mondják, hogy az oldalsúly (más néven oldalméret) az a kilobyte-ban vagy megabájtban mért teljes adatmennyiség, amelyet a felhasználónak le kell töltenie egy adott oldal megtekintéséhez. A könyvemben, amely képeket és miegymást tartalmaz, mert le kell töltenem, hogy lássam.
És ezért meglepődtem, amikor 2015-ben 845 kilobájt volt. Ez számomra meglepő volt. …Mert azt feltételeztem volna, hogy képekkel ez több mint 800 kilobájt.
… 2025 júliusában ugyanez a medián oldal most 2,3 megabájt.”
Az adatok tömörítve lesznek
De ez csak az egyik módja az oldalméret megértésének. Az oldalméret mérlegelésének másik módja az, ha a hálózaton keresztül továbbított tartalmakra összpontosít, ami a tömörítés miatt kisebb lehet. A tömörítés egy szerveroldali algoritmus, amely minimalizálja a szerverről küldött és a böngésző által letöltött fájl méretét. A legtöbb szerver a Brotli nevű tömörítési algoritmust használja.
Martin Splitt elmagyarázza:
„Nyilvánosan teszem fel ezt a kérdést, hogy a különböző embereknek nagyon eltérő elképzeléseik voltak arról, hogyan értelmezték az oldalméretet. Attól függően, hogy melyik réteget nézi, ez is zavaró lesz.
mert van kompresszió is.…Szóval néhányan azt mondják, hogy á, de ez a webhely 10 megabájtot tölt le a lemezemre.
És én úgy vagyok, hogy igen. …de talán ha megnézi, hogy valójában mi megy át a vezetéken, akkor azt találhatja, hogy ez öt vagy hat megabájt, nem pedig az egész 10 megabájt. Mert hálózati szinten tömörítheti a dolgokat, majd kliensoldali szinten kibonthatja…”
Technikailag az oldalméret Martin példájában valójában öt-hat megabájt a tömörítés miatt, és gyorsabban tud letölteni. De a felhasználó oldalán ezt az öt-hat megabájtot kitömörítik, és tíz megabájttá alakul vissza, ami annyi helyet foglal el a felhasználó telefonján, asztalán vagy bárhol.
És ez kétértelműséget vezet be. Az Ön weboldala tíz megabájtos vagy öt megabájtos?
Ez egy tágabb problémát szemléltet: különböző emberek különböző dolgokról beszélnek, amikor az oldalméretről beszélnek.
Még a széles körben használt definíciók sem oldják meg teljesen a kétértelműséget. Az oldalsúlyt úgy írják le, mint „az adatmennyiség kilobyte-ban vagy megabájtban mérve, amelyet a felhasználónak le kell töltenie”, de amint a vita egyértelművé teszi, nincs egyértelmű meghatározás.
Martin azt állítja:
„Ha megkérdezed az embereket, mit gondolnak, hogy ez nagy-e vagy sem, nagyon eltérő válaszokat kapsz attól függően, hogy hogyan vélekednek az oldalméretről. És ennek nincs egy igazi meghatározása.”
Mi a helyzet a jelölés és a tartalom arányával?
A podcastban az egyik legérdekesebb megkülönböztetés az, hogy egy nagy oldal nem feltétlenül hatástalan. Például egy 15 MB-os HTML-dokumentumot elfogadhatónak tartanak, mert „e 15 megabájt nagy része valóban hasznos tartalom”. A méret a szállított értéket tükrözi.
Ezzel szemben mi lenne, ha a tartalom és a jelölés aránya fordítva lenne, ahol volt egy kis tartalom, de az oldal súlyának túlnyomó része jelölés volt.
Martin az aránypéldát tárgyalta:
„…mi van, ha a jelölés az egyetlen többletköltség? És úgy értem, hogy mit értesz? Ez olyan, nos, tudod, ha öt megabájt, de csak nagyon kevés a tartalom, akkor az rossz? Rosszabb, mint ebben az esetben, a 15 megabájt.
És azt hiszem, ez trükkös, mert akkor a tartalom és a jelölés közötti arány furcsa területére jutunk. Igen.
És azt mondtam, nos, de mi van akkor, ha nagy része olyan jelölés, amely valamilyen harmadik fél eszközének vagy valamilyen szolgáltatásnak metaadata, vagy szabályozási okokból, licencelési okokból vagy bármi másból. Akkor ez hasznos tartalom, de nem feltétlenül a végfelhasználó számára, de akkor is rendelkeznie kell vele.
Furcsa lenne azt állítani, hogy ez rosszabb, mint az az oldal, ahol a súlyok többnyire tartalmat tartalmaznak.”
Martin azzal foglalkozik, hogy az oldal súlyának fogalmát a nyers méretről a tényleges adatokra tolja el.
Miért tartalmaznak adatokat az oldalak, amelyeket a felhasználók soha nem látnak?
Az oldal súlyához nagyban hozzájárul az olyan tartalom, amelyet a felhasználók soha nem látnak.
Gary Illyes a strukturált adatokra mutat rá példaként olyan tartalmakra, amelyeket kifejezetten gépek és nem felhasználók számára szánnak. Bár hasznos lehet a keresőmotorok számára, az oldal teljes méretét is növeli. Ha egy megjelenítő sok strukturált adatot ad hozzá az oldalához, hogy kihasználhassa az összes rendelkezésre álló lehetőséget, az növeli az oldal méretét, még akkor is, ha a felhasználó soha nem fogja látni.
Ez a web szerkezeti valóságára hívja fel a figyelmet: az oldalak nem csak emberi olvasók számára készültek. Keresőmotorokhoz, eszközökhöz, mesterséges intelligencia-ügynökökhöz és más rendszerekhez is készültek, amelyek mindegyike hozzáadja a saját követelményeit egy weboldal súlyához.
Amikor a rezsi indokolt
Nem minden nem felhasználónak szánt tartalom szükségtelen.
Martin arról beszélt, hogy a jelölés „metaadatokat” vagy eszközt, szabályozási vagy engedélyezési célt tartalmazhat, egyfajta szürke területet létrehozva. Még ha a további adatok nem is javítják közvetlenül a felhasználói élményt, célt szolgálnak, többek között segítik a felhasználót az oldal keresésén keresztül.
Martin arra törekedett, hogy ezek az oldalsúllyal kapcsolatos megfontolások megnehezítsék azt a kísérletet, hogy az oldal súlyát jónak, ha a küszöbérték alatt van, vagy rossznak, ha az oldal súlya meghaladja azt.
Miért nem működik a tartalom és a metaadatok szétválasztása?
Az egyik lehetséges megoldás, amelyről Gary Illyes beszélt, az, hogy elválasztják az emberre néző tartalmakat a gépekre néző adatoktól. Míg Gary nem említette konkrétan az LLMs.txt javaslatot, az általa tárgyalt valamiben hasonlít rá, mivel tartalmat szolgál ki a gép számára, mínusz az összes többi, a felhasználóknak szánt tartalommal járó többletköltség.
Valójában arról beszélt, hogyan lehet elválasztani az összes géppel kapcsolatos adatot a felhasználó által letöltött adatoktól, így elméletileg kisebb lesz a weboldal felhasználói verziója.
Gary gyorsan elveti ezt az ötletet, mint „utópiát”, mert mindig lesznek spammerek hordái, akik megtalálják a módját, hogy kihasználják ezt.
Elmagyarázta:
„De sajnos ez egy utópikus dolog, mert nem mindenki játszik jól az interneten.
Tudjuk, mennyi spammel kell megküzdenünk. A blogunkon azt írjuk valahol, hogy naponta 40 milliárd URL-t kapunk, ami spam vagy valami őrült szám, nem emlékszem pontosan, de ez valami őrült szám, és határozottan milliárdok. Ez csak megnöveli a keresőmotorok és más gépek által kapott kéretlen levelek mennyiségét, talán úgy, mintha 1 dollár és 5 centre tippelnék, ami ténylegesen növeli a keresőmotorok, az LLM-ek és mások által elnyelt kéretlen levelek mennyiségét.”
Gary azt is elmondta, hogy a Google tapasztalata szerint a történelem során, ha különböző típusú tartalmak vannak, mindig lesznek különbségek a két fajta között. Azt a példát használta fel, amikor a webhelyeken voltak mobil és asztali oldalak, ahol a tartalom két verziója általában eltérő volt, ami viszont problémákat okozott a keresésben és a használhatóságban is, amikor egy webhely az oldal egyik verziójában rangsorol egy weboldalt, majd az oldal másik verziójára küldi a felhasználót, ahol ez a tartalom nem létezik.
Bár nem említette kifejezetten, a Google tapasztalatainak ez a magyarázata jobban megvilágíthatja, hogy a Google miért nem veszi át az LLMS.txt fájlt.
Ennek eredményeként a keresőmotorok nagyrészt az egydokumentumú modell mellett döntöttek, még akkor is, ha az nem hatékony.
A webhely mérete és az oldal mérete a való világ
A vita végül megkérdőjelezi a probléma eredeti koncepcióját, miszerint a nehéz weboldalak rosszak.
Gary észreveszi:
„Az első kérdés az, hogy a webhelyek elhíznak? Szerintem ennek a kérdésnek nincs is értelme.
Mert nem számít, ha egy weboldal kövér. Egyetlen oldal összefüggésében igen.
De egy weboldal kontextusában ez igazán nem számít.”
Így most Gary és Martin az egyre nehezebb weboldalakra helyezi a hangsúlyt, ami értelmesebb módja annak, hogy megvizsgáljuk a weboldalak és webhelyek fejlődésének kérdését.
Ez egy absztrakt ötletről valami mérhetőbb és végrehajthatóbb dolog felé mozgatja a vitát.
A nehezebb oldalak továbbra is valós költségekkel járnak
A nagyobb oldalaknak még gyorsabb kapcsolat és jobb infrastruktúra mellett is vannak következményei, a kisebb súlyozott oldalaknak pedig pozitív előnyei.
Martin elmagyarázza:
„Úgy gondolom, hogy rengeteg erőforrást pazarolunk. És úgy értem, mi is ezt tapasztaltuk egy másik epizódban, ahol azt mondtuk, hogy vannak olyan tanulmányok, amelyek azt mutatják, hogy a gyorsabb webhelyek jobb tartást és jobb konverziós arányt mutatnak. Igen. És a sebesség részben a mérettől is függ. Mert minél több adatot szállítok, annál tovább tart a hálózatnak az adatok tényleges átvitele, és annál tovább tart, amíg a processzor ténylegesen feldolgozza a processzort.”
Tágabb perspektívából nézve nem csak a teljesítmény, hanem a hatékonyság a kérdés. Ahogy Illyés fogalmaz, „sok erőforrást pazarolunk el”.
Lehet, hogy az internet egyre nehezebb, de a legfontosabb az, hogy miért. Az oldalak nem csupán a felhasználóknak szánt tartalommal rendelkeznek, és ez a tervezési választás mind méretüket, mind hatásukat befolyásolja.
