Egy külső szkript beillesztése tíz másodperc munka: bemásolsz egy sort a fejlécbe, és kész. A számlát viszont nem te fizeted ki egyszer, hanem minden egyes látogatód, minden egyes oldalbetöltésnél. Ez a cikk arról szól, hogyan méred meg pontosan ezt a számlát, és hogyan döntöd el szkriptenként, hogy marad, költözik vagy megy.
Mennyit tesz hozzá egy külső szkript a betöltési időhöz?
Rövid válasz: nem a fájlméret számít, hanem a fő szálon eltöltött idő és az idegen szerverrel való kapcsolatfelvétel. Egy 30 kilobájtos szkript, ami sok JavaScriptet futtat, többet árt, mint egy 100 kilobájtos kép.
Hivatalosan igazolt: a Google a Core Web Vitals mérőszámai közül az INP (Interaction to Next Paint) esetében 200 ezredmásodperc alatti értéket tekint jónak, az LCP-nél 2,5 másodperc alattit. A hosszú, 50 ezredmásodpercnél tovább futó feladatok blokkolják a fő szálat, és a böngésző ilyenkor nem tud reagálni a kattintásra. A harmadik feles szkriptek jellemzően pont ilyen hosszú feladatokat gyártanak.
Az egyes típusok tipikus viselkedése, saját tapasztalat alapján, sorrendbe rakva a legdrágábbtól:
- Élő chat-widget: a legdrágább. Saját keretrendszert, ikonkészletet, betűtípust és gyakran WebSocket-kapcsolatot húz be. Sokszor önmagában több adatot tölt, mint a teljes oldal tartalma.
- Sütibanner: csalóka. Kis fájl, de a kritikus úton van, mert az összes többi szkript indítását ő vezérli. Ha lassan válaszol, minden más is csúszik utána.
- Hirdetési pixelek (Meta, Google Ads, TikTok): egyenként mérsékeltek, együtt viszont összeadódnak, és mindegyik külön kapcsolatot nyit.
- Vélemény-widget és közösségi beágyazás: gyakran teljes iframe-et hoz, saját szkriptkészlettel.
- Betűtípus-szolgáltató: extra DNS-feloldás, TLS-kézfogás, és amíg nem érkezik meg, a szöveg vagy láthatatlan, vagy ugrik.
- Térkép: ha a lábléc alján ül és mégis azonnal betölt, tiszta pazarlás.
- Analitika: a jól megírt mérőkód a legolcsóbb tétel a listán.
Hogyan mérd meg szkriptenként, mennyibe kerül?
Rövid válasz: három rétegben, összesítő nézettől a szkriptenkénti kikapcsolásig. Egyetlen mérésre soha ne alapozz döntést, mert a külső szolgáltatók válaszideje ingadozik.
1. Alapállapot rögzítése
Válassz ki két oldalt: a nyitóoldalt és egy tipikus aloldalt (szolgáltatás vagy termék). Futtass mindkettőn PageSpeed Insights mérést mobilra, és jegyezd fel az LCP, INP, CLS és TBT értékeket. Ismételd meg ötször, és a mediánt írd fel, ne az átlagot, mert egy kiugró mérés elviszi az átlagot.
2. Harmadik feles összesítő nézet
Hivatalosan igazolt: a Lighthouse tartalmaz egy külön beszámolót a harmadik feles kód hatásáról, és a Chrome fejlesztői eszközök hálózati fülén a kéréseket domain szerint is tudod csoportosítani. Nyisd meg a Network fület, kapcsold be a harmadik feles szűrőt, és nézd meg, hány különböző domainhez kapcsolódik az oldalad. Ha ez a szám tíz fölött van, ott már biztosan van felesleges tétel.
A Performance fülön vedd fel a betöltést, majd a Bottom-Up nézetben rendezd a feladatokat forrás szerint. Itt látod meg feketén-fehéren, hogy melyik idegen fájl mennyi ezredmásodpercet foglalt a fő szálból.
3. Kérésblokkolás a fejlesztői eszközben
Ez a leggyorsabb módszer, és nem kell hozzá a weboldalhoz nyúlni. A Chrome Network fülén jobb gombbal kattints a kérdéses kérésre, és válaszd a Block request domain lehetőséget. Ezután frissítsd az oldalt, és mérj újra. A különbség a blokkolt és a nem blokkolt állapot között az adott szolgáltató valós ára.
Fontos figyelmeztetés: a domain blokkolása azt is megmutatja, mi törik el nélküle. Ha a sütibannert blokkolod és utána minden más szkript is eltűnik, akkor megtaláltad a függőségi láncot.
4. Szkriptenkénti letiltás és újramérés
A blokkolás után jöjjön az éles teszt. A címkekezelőben (vagy a bővítményben) kapcsolj ki egyetlen szkriptet, ürítsd a gyorsítótárat, és mérj újra ötször. Utána kapcsold vissza, és jöjjön a következő. Készíts egy egyszerű táblázatot négy oszloppal: szkript neve, mediánban mért LCP-változás, mediánban mért TBT-változás, és hogy mennyi extra kérést hozott. Ez a táblázat lesz a döntésed alapja, nem a megérzés.
Szakmai feltételezés: a legtöbb KKV-oldalon a lista első két tétele adja a teljes harmadik feles terhelés több mint felét. Érdemes ezzel a kettővel kezdeni, mert a maradék apró tételekkel bíbelődni időpazarlás.
Melyik szkriptet lehet nyugodtan késleltetni interakcióig?
Rövid válasz: mindent, ami nem befolyásolja az első képernyő megjelenését, és nem kell hozzá adat a betöltés első másodpercéből.
Biztonságosan késleltethető: az élő chat, a vélemény-widget, a közösségi beágyazások, a térkép, a hírlevél-felugró és a legtöbb remarketing-pixel. A késleltetés lényege, hogy a szkript csak akkor kerül be az oldalba, amikor a látogató először görget, mozgatja az egeret vagy megérinti a képernyőt.
Egy egyszerű, keretrendszertől független minta:
let betoltve = false; function chatBetolt() { if (betoltve) return; betoltve = true; const s = document.createElement('script'); s.src = 'https://pelda-chat.hu/widget.js'; s.async = true; document.body.appendChild(s); } ['scroll','pointerdown','keydown','touchstart'].forEach(function(ev) { window.addEventListener(ev, chatBetolt, { once: true, passive: true }); }); setTimeout(chatBetolt, 12000);
A záró setTimeout azért kell, hogy az olyan látogatónál is elinduljon a chat, aki mozdulatlanul olvas. A térkép esetében ennél is egyszerűbb a megoldás: a beágyazott iframe-re tedd rá a loading="lazy" attribútumot, és a böngésző magától megvárja vele, amíg a látogató odagörget.
Amit nem lehet késleltetni: a sütibannert (jogilag a hozzájárulás előtt nem futhat a többi szkript, tehát ő a lánc eleje), és azt az analitikát, amelyik az oldalletöltést magát méri. Ha a mérőkódot interakcióhoz kötöd, a visszafordulási arány torzul, és onnantól rossz adatból döntesz.
Melyik szkriptet kell szerveroldalra vinni?
Rövid válasz: azt, ami hirdetési konverziót mér, mert ezeket a böngészőben egyre több minden akadályozza.
Hivatalosan igazolt: a Meta Conversions API és a Google Analytics 4 Measurement Protocol dokumentált szerveroldali eseményküldést tesz lehetővé, a Google Tag Manager pedig kínál szerveroldali konténert. Ilyenkor a látogató böngészője csak a saját szervereddel beszél, a hirdetési rendszerekkel a szervered kommunikál.
Ennek két haszna van. Egyrészt a látogató gépéről eltűnik több külső kapcsolat, ami mérhető gyorsulás. Másrészt a hirdetési adat pontosabb lesz, mert a reklámblokkolók és a böngészők nyomkövetés-védelme a kliensoldali pixelek egy részét eleve eldobja.
Saját tapasztalat: a szerveroldali mérés üzemeltetést és karbantartást igényel, ezért csak akkor éri meg, ha az oldal ténylegesen és folyamatosan költ hirdetésre. Ha csak alkalmi kampányok futnak, a bonyolultság többe kerül, mint amennyi hasznot hoz. Ez az a pont, ahol sok KKV túllő a célon.
Figyelj arra is, hogy a szerveroldali mérés nem old fel adatvédelmi kötelezettséget. Attól, hogy a szervered küldi az adatot, a hozzájárulást ugyanúgy be kell szerezni, és az adattovábbítást ugyanúgy dokumentálni kell.
Melyik szkriptet érdemes önhosztolni?
Rövid válasz: a betűtípust szinte mindig, az ikonkészletet és a kisebb segédkönyvtárakat pedig többnyire.
A betűtípus a legegyszerűbb nyeremény. Ha külső szolgáltatótól töltöd, minden látogatónál lezajlik egy DNS-feloldás, egy TLS-kézfogás és egy külön letöltés, ráadásul az első betöltésnél a szöveg vagy nem látszik, vagy megjelenés után elugrik. Ha a betűtípus fájlját a saját szervereden tárolod, ez a kör kiesik.
A gyakorlati lépések:
- Töltsd le a szükséges vágásokat, és csak azokat. Két vágás (normál és félkövér) a legtöbb oldalon elég.
- Konvertáld WOFF2 formátumba, mert ez a legjobban tömörített és minden mai böngésző érti.
- Szűkítsd a karakterkészletet latin és latin-ext tartományra, hogy a magyar ékezetek biztosan benne legyenek.
- A CSS-ben állítsd be a
font-display: swapértéket, hogy a szöveg azonnal olvasható legyen. - A legfontosabb betűfájlra tegyél
preloadjelzést.
Adatvédelmi szempontból is van súlya a döntésnek: hivatalosan dokumentált, hogy német bíróság 2022-ben elmarasztalt egy weboldal-üzemeltetőt azért, mert a külső betűtípus-szolgáltató felé hozzájárulás nélkül továbbította a látogatók IP-címét. Ez nem magyar jogeset, tehát önmagában nem magyar precedens, de a mögötte lévő logika a GDPR-ból ered, ezért érdemes komolyan venni.
Amit viszont ne önhosztolj: a hirdetési pixeleket és az analitikát. Ezek a szolgáltatók rendszeresen frissítik a kódjukat, és egy elavult másolat csendben rossz adatot fog gyűjteni.
Melyik szkripttől érdemes egyszerűen megválni?
Rövid válasz: attól, amiről senki nem tudja megmondani, ki nézi az adatát és mikor hozott utoljára döntést.
Tipikus törlésre érett tételek egy KKV-oldalon:
- Két párhuzamos analitikai rendszer, mert évekkel ezelőtt valaki kipróbálta a másodikat, és bent maradt.
- Hőtérkép- vagy munkamenet-rögzítő szkript, amit egy egyszeri elemzés miatt tettek fel, és azóta senki nem nyitotta meg.
- Régi kampányok pixelei olyan hirdetési fiókokból, ahol már nem fut hirdetés.
- Közösségi megosztás-gomb csomag, amit a saját mérésed szerint havonta néhányan használnak.
- Csevegő-widget olyan oldalon, ahol nincs, aki válaszoljon rá munkaidőn kívül.
A gyakorlati módszer egyszerű: kapcsold ki a szkriptet, tedd fel a naptáradba két hét múlvára, és nézd meg, hiányzott-e valakinek. Saját tapasztalat: a legtöbb esetben senki nem veszi észre, és ez önmagában is válasz arra, hogy volt-e üzleti értéke.
Milyen szempontsor alapján dönts szkriptenként?
Rövid válasz: három tengelyen pontozz, és ahol a teljesítményköltség vagy az adatvédelmi kockázat nagyobb, mint az üzleti érték, ott lépj.
Vedd végig minden szkriptre ezt az öt kérdést:
- Üzleti érték: hozott-e ez a szkript az elmúlt fél évben olyan adatot vagy megkeresést, ami alapján ténylegesen döntöttél? Ha nem tudsz konkrét példát mondani, nulla pont.
- Ki nézi: van-e megnevezett ember, akinek a munkájához kell? Ha a válasz "majd egyszer jó lesz", akkor nincs.
- Adatvédelmi kockázat: továbbít-e személyes adatot vagy IP-címet harmadik félnek, és szerepel-e ez az adatkezelési tájékoztatódban? Ha a szkript ott van az oldalon, de a tájékoztatóban nincs, az önmagában hiba.
- Teljesítményköltség: mennyit mértél rá a szkriptenkénti letiltásos tesztben? Ha 100 ezredmásodpercnél többet vesz el a fő szálból, indoklás kell hozzá.
- Van-e olcsóbb alternatíva: késleltethető, szerveroldalra vihető vagy önhosztolható-e?
A pontozás után a döntés általában magától adódik. Magas érték és magas költség esetén jön a késleltetés vagy a szerveroldal. Alacsony érték és bármilyen költség esetén jön a törlés. Magas érték és alacsony költség esetén marad, ahol van.
Hány külső szkript indokolt egy KKV-oldalon?
Rövid válasz, és ez a saját szakmai álláspontom: három-négy fölött ritkán van valódi üzleti indok. Egy sütibanner, egy analitika, egy hirdetési mérés arról a platformról, ahol tényleg költesz, és legfeljebb egy kapcsolatfelvételi eszköz. Ez a négy lefedi a legtöbb hazai kis- és középvállalkozás valós igényét.
Ez nem dogma, hanem alapértelmezés. Egy webáruháznál könnyen indokolt lehet több mérés, egy foglalási rendszert használó szolgáltatónál pedig egy külön beágyazott eszköz. A különbség az, hogy ilyenkor van válasz arra, hogy kinek a munkájához kell.
Záró ellenőrzőlista negyedéves átnézéshez:
- Listázd ki a fejlevesztői eszközben az összes külső domaint, amihez az oldalad kapcsolódik.
- Párosítsd mindegyikhez a felelős személyt és az üzleti indokot, egy mondatban.
- Amelyikhez nem tudsz indokot írni, azt kapcsold ki két hétre.
- Mérj újra ötször, mediánnal, ugyanazon a két oldalon, mint az elején.
- Frissítsd az adatkezelési tájékoztatót ahhoz, ami ténylegesen fut az oldalon.
A gyorsabb oldal önmagában nem garantál jobb helyezést és nem hoz automatikusan több érdeklődőt, de a mérési adatok alapján jó eséllyel csökkenti azt a súrlódást, ami a látogatót az első pár másodpercben elveszi tőled. A válaszmotorok és a keresőrobotok szempontjából pedig az a különbség számít, hogy a tartalmad megjelenik-e szkriptfuttatás nélkül is, vagy csak akkor, ha minden külső fél időben válaszol.
Források és további olvasnivalók
- Google Search Central: Core Web Vitals és oldalélmény dokumentáció
- web.dev: Optimize Long Tasks, Third-party JavaScript, Interaction to Next Paint
- Chrome DevTools hivatalos dokumentáció: Network és Performance panel, Request blocking
- Lighthouse dokumentáció: Reduce the impact of third-party code audit
- Google Tag Manager súgó: szerveroldali címkézés
- Meta for Developers: Conversions API dokumentáció
- Google Analytics 4 súgó: Measurement Protocol
- W3C: Resource Hints és Web Performance specifikációk
- Nemzeti Adatvédelmi és Információszabadság Hatóság (NAIH) tájékoztatói a sütikről
- A harmadik feles szkript költsége nem a fájlmérete, hanem a fő szálon eltöltött ideje és a külső kapcsolatfelvétel késleltetése.
- A hiteles mérés módszere: egy szkript kikapcsolása, öt mérés, medián összevetése az alapállapottal.
- A sütibanner és az analitika a kritikus úton marad, a chat és a vélemény-widget szinte mindig késleltethető interakcióig.
- A hirdetési pixelek jó része szerveroldalra vihető, a betűtípus pedig önhosztolható, ezzel egy külső kapcsolat teljesen kiesik.
- Saját tapasztalat: egy KKV-oldalon három-négy külső szkriptnél többre ritkán van valódi üzleti indok.
Gyakori kérdések
Miért nem elég egyszer lefuttatni egy PageSpeed mérést?
Mert a külső szolgáltatók válaszideje ingadozik, és egyetlen mérés akár másfél másodperccel is eltérhet a valóságtól. Mérj ötször ugyanazon az oldalon, és a mediánt használd. A szkriptenkénti letiltásnál is így járj el, különben a mérési zajt fogod fejlesztésnek nevezni.
A sütibannert is lehet gyorsítani?
Késleltetni nem lehet, mert a hozzájárulás nélkül a többi szkript nem futhat, tehát ő a lánc első eleme. Gyorsítani viszont igen: válassz olyan megoldást, ami kis fájlból dolgozik, ne húzzon be külön betűtípust és ikonkészletet, és lehetőleg a saját szerveredről töltődjön. Mivel a kritikus úton ül, minden nála megspórolt ezredmásodperc az összes utána következő szkriptnél megtérül.
Ha szerveroldalra viszem a mérést, megszűnik a sütibanner-kötelezettség?
Nem. A hozzájárulási kötelezettség attól függ, milyen adatot kezelsz és milyen célra, nem attól, hogy melyik gépről indul a kérés. A szerveroldali mérés teljesítmény- és adatpontossági előny, nem jogi mentesség. Az adatkezelési tájékoztatót ugyanúgy naprakészen kell tartani.
Elronthatom az oldalt, ha önhosztolom a betűtípust?
A tipikus hiba az, hogy nem minden vágást töltesz le, vagy kimarad a latin-ext karakterkészlet, és emiatt az ékezetes betűk más betűtípussal jelennek meg. Ellenőrizd magyar szöveggel, több böngészőben, és nézd meg a fejlesztői eszköz Network fülén, hogy nem marad-e ott a régi külső kérés valamelyik CSS-fájlban.
Honnan tudom, hogy a chat-widget megéri-e a lassulást?
Nézd meg, hány beszélgetés indult az elmúlt három hónapban, és ezekből hány lett érdeklődés vagy megrendelés. Ezt vesd össze azzal, amit a szkriptenkénti letiltás mért. Ha kevés beszélgetés mellett jelentős a teljesítményköltség, az interakcióig késleltetett betöltés jó középút: a widget megmarad, de nem terheli az első képernyőt.
A keresőrobotok és az AI-válaszmotorok mennyire érzékenyek a külső szkriptekre?
Hivatalos állásfoglalás szerint a Google a lassú oldalt nem bünteti közvetlenül, de az oldalélmény jelzésként szerepet kap. Szakmai feltételezés, hogy az AI-válaszmotorok gyűjtői ennél kevesebb türelemmel dolgoznak, mert sokuk nem futtat teljes JavaScriptet. Ezért a legfontosabb szabály, hogy az érdemi tartalom szkriptfuttatás nélkül is olvasható legyen a forráskódban.
Források és további olvasnivalók
Ezen az oldalon a hivatalosan igazolt információt elsődleges forrásokból építjük fel; a saját tapasztalatot és a szakmai becslést mindig külön jelöljük a szövegben.