Harmadik fél szkriptek gyorsítása (2026)

Miért a harmadik fél szkriptjei a webes teljesítmény legnagyobb rejtett ellensége?

Ha valaha is futtattál Lighthouse auditot — és őszintén, ki ne tette volna mostanában? — szinte biztos láttad már azt a fenyegető figyelmeztetést: „Reduce the impact of third-party code". Nem véletlen, hogy ez az egyik leggyakoribb audit finding. A harmadik féltől származó szkriptek — analitika, hirdetési hálózatok, chat widgetek, közösségi média beágyazások, hozzájárulás-kezelő sávok — szinte garantáltan belassítják az egyébként jól optimalizált weboldaladat is.

A számok magukért beszélnek.

A HTTP Archive 2025-ös Web Almanac adatai szerint a vizsgált weboldalak legalább 90%-a tartalmaz harmadik féltől származó erőforrást. A medián weboldal mobilon 79 harmadik fél kérést indít, asztali gépen pedig 83-at — és ez az előző évhez képest +5 kéréssel több mindkét platformon. A top 1000 webhely esetében a számok még riasztóbbak: medián 106 kérés mobilon és 129 asztali gépen, ami +15 kéréses növekedés 2024-hez képest.

De a kérések száma csak a jéghegy csúcsa. A harmadik féltől származó szkriptek láncreakciót indítanak: a medián láncolási mélység 3, vagyis egyetlen beágyazott szkript átlagosan még két további szkriptet húz maga után. A megfigyelt maximális mélység? 2285 láncolási szint. Igen, jól olvastad.

Hogyan rombolják szét a Core Web Vitals mutatóidat?

LCP (Largest Contentful Paint) hatás

A harmadik fél szkriptjei kétféleképpen rontják az LCP-t. Egyrészt sávszélességet és fő szálat foglalnak el, ami miatt a kritikus erőforrásaid (hero kép, fő szövegblokk) lassabban töltődnek be. Másrészt — és ez a rosszabb eset — ha az elsődleges tartalmad maga is harmadik fél szkripttel kerül a DOM-ba (gondolj az A/B tesztelőkre vagy personalizációs eszközökre), akkor a szkript késése közvetlenül az LCP késése lesz.

Valós tesztek kimutatták, hogy harmadik fél szkriptekkel egy oldal LCP-je 26 másodperc feletti volt. Ugyanez szkriptek nélkül? 1 másodperc alatt. Ez nem elírás.

INP (Interaction to Next Paint) hatás

2026-ban a weboldalak 43%-a még mindig nem felel meg a 200 ms-os INP küszöbértéknek. Az egyik vezető ok: harmadik fél szkriptek által okozott fő szál blokkolás.

Tag managerek, analitika szkriptek, chat widgetek, hozzájárulás-kezelő sávok — mind JavaScript-et futtatnak a fő szálon. Ha egy felhasználó éppen kattintani próbál, de a fő szál egy GTM eseményfeldolgozóval van elfoglalva, az interakció kénytelen várakozni. Az INP pedig az egekbe szökik.

CLS (Cumulative Layout Shift) hatás

Harmadik fél szkriptek gyakran dinamikusan illesztenek be tartalmakat a DOM-ba: hirdetési bannereket, hozzájárulási sávokat, értesítéseket. Ha ezeknek nincs előre lefoglalt helye a layoutban, a meglévő tartalom lejjebb tolódik — ez az az idegesítő layout shift, ami a CLS mutatódat rontja. (Ugye mindenki ismeri azt az érzést, amikor épp rá akarsz kattintani valamire, és az utolsó pillanatban elugrik alólad?)

Alapszintű optimalizálás: async és defer

Na, akkor kezdjük a legegyszerűbb lépéssel. Az alapszabály: egyetlen harmadik fél szkript se töltődjön szinkron módon. Alapértelmezés szerint a böngésző leállítja a HTML feldolgozást, amíg egy <script> elemet le nem tölt és le nem futtat. Az async és defer attribútumok ezt a viselkedést változtatják meg.

defer — az alapértelmezett választásod

A defer attribútummal jelölt szkriptek párhuzamosan töltődnek le a HTML feldolgozás közben, de csak a teljes HTML feldolgozás után, a DOMContentLoaded esemény előtt futnak le. Lényeges részlet: a defer szkriptek megtartják a sorrendjüket — ha két szkriptet defer-elsz, mindig az elsőként deklarált fut le először.

<!-- Jó: nem blokkolja a renderelést, sorrend garantált -->
<script src="https://example.com/analytics.js" defer></script>
<script src="https://example.com/chat-widget.js" defer></script>

async — korai futtatáshoz

Az async szintén párhuzamos letöltést tesz lehetővé, de a szkript azonnal lefut, amint letöltődött — akár a HTML feldolgozás közben is. A sorrend nem garantált: amelyik hamarabb töltődik le, az fut le először.

Ez ideális olyan független szkriptekhez, amelyek nem függenek a DOM-tól és egymástól sem.

<!-- Analitika: nem függ a DOM-tól, korai futtatás előnyös -->
<script src="https://example.com/analytics.js" async></script>

<!-- Widget: DOM-hozzáférés szükséges, defer jobb választás -->
<script src="https://example.com/widget.js" defer></script>

Döntési mátrix

Kritikus renderelési úton van? → Ne használj sem async-ot, sem defer-t (ez harmadik fél szkripteknél nagyon ritkán fordul elő).
Független, DOM nem kell? → async
DOM-hozzáférés szükséges, sorrend fontos? → defer
Nem kritikus a betöltés elején? → Késleltetett betöltés (erről mindjárt lesz szó)

Késleltetett betöltés: Intersection Observer és idle callback

Sok harmadik fél szkriptre egyáltalán nincs szükség az oldal betöltésekor. Gondolj bele: tényleg kell a chat widget azonnal? Vagy a közösségi média gombok a hajtás felett? Ezek mind várhatnak.

Két bevált megközelítés:

requestIdleCallback — amikor a böngésző ráér

// Szkript betöltése csak amikor a fő szál szabad
if ('requestIdleCallback' in window) {
  requestIdleCallback(() => {
    const script = document.createElement('script');
    script.src = 'https://example.com/chat-widget.js';
    document.body.appendChild(script);
  });
} else {
  // Fallback régebbi böngészőkhöz
  setTimeout(() => {
    const script = document.createElement('script');
    script.src = 'https://example.com/chat-widget.js';
    document.body.appendChild(script);
  }, 3000);
}

Intersection Observer — amikor a felhasználó odagörget

// YouTube videó betöltése csak amikor a konténer láthatóvá válik
const videoContainer = document.querySelector('#video-section');
const observer = new IntersectionObserver((entries) => {
  entries.forEach(entry => {
    if (entry.isIntersecting) {
      const iframe = document.createElement('iframe');
      iframe.src = 'https://www.youtube.com/embed/VIDEO_ID';
      iframe.loading = 'lazy';
      iframe.allow = 'accelerometer; autoplay; encrypted-media; gyroscope';
      videoContainer.appendChild(iframe);
      observer.unobserve(entry.target);
    }
  });
}, { rootMargin: '200px' });

observer.observe(videoContainer);

Facade pattern: a teljesítmény és a funkció legjobb kompromisszuma

Ez az egyik kedvenc technikám, őszintén szólva. A facade pattern lényege egyszerű: a nehéz harmadik fél beágyazás helyett egy könnyű, statikus előnézetet jelenítünk meg, és csak akkor töltjük be a tényleges erőforrást, amikor a felhasználó interakcióba lép vele. Ez az úgynevezett „import on interaction" minta.

YouTube facade implementáció

Egy átlagos YouTube iframe beágyazás 500+ KB JavaScript-et tölt be. Még akkor is, ha a felhasználó soha nem nyomja meg a lejátszás gombot. A facade megoldással ez nullára csökken az interakcióig:

<!-- Könnyű facade: csak egy kép és egy lejátszás gomb -->
<div class="youtube-facade" data-video-id="dQw4w9WgXcQ">
  <img src="https://i.ytimg.com/vi/dQw4w9WgXcQ/hqdefault.jpg"
       alt="Videó előnézet" loading="lazy" width="480" height="360">
  <button class="play-btn" aria-label="Videó lejátszása">▶</button>
</div>

<script>
document.querySelectorAll('.youtube-facade').forEach(facade => {
  // Preconnect egérmozgatáskor (felkészülés)
  facade.addEventListener('pointerover', () => {
    const link = document.createElement('link');
    link.rel = 'preconnect';
    link.href = 'https://www.youtube.com';
    document.head.appendChild(link);
  }, { once: true });

  // Kattintáskor betöltjük a valódi lejátszót
  facade.addEventListener('click', () => {
    const videoId = facade.dataset.videoId;
    const iframe = document.createElement('iframe');
    iframe.src = `https://www.youtube.com/embed/${videoId}?autoplay=1`;
    iframe.allow = 'accelerometer; autoplay; encrypted-media; gyroscope';
    iframe.allowFullscreen = true;
    iframe.style.cssText = 'width:100%;aspect-ratio:16/9;border:none;';
    facade.replaceWith(iframe);
  });
});
</script>

Nyílt forráskódú megoldások is vannak: a lite-youtube-embed (YouTube-hoz), a react-live-chat-loader (chat widgetekhez) és a Google Maps Static API (térképekhez) mind kiváló, kész facade implementációk. Nem kell újra feltalálnod a kereket.

Resource Hints: preconnect és dns-prefetch a harmadik fél domainekhez

Ha egy harmadik fél szkriptet nem tudsz teljesen késleltetni (mondjuk kritikus analitikáról van szó), legalább segítheted a böngészőt, hogy a kapcsolat felépítése gyorsabban menjen. A preconnect hint a DNS feloldást, TCP handshake-et és TLS tárgyalást is elvégzi előre — ez 100–500 ms megtakarítást jelenthet.

<!-- Preconnect a legfontosabb harmadik fél originekhez -->
<link rel="preconnect" href="https://www.googletagmanager.com" crossorigin>
<link rel="preconnect" href="https://www.google-analytics.com" crossorigin>

<!-- DNS-prefetch fallback régebbi böngészőkhöz -->
<link rel="dns-prefetch" href="https://www.googletagmanager.com">
<link rel="dns-prefetch" href="https://www.google-analytics.com">

Fontos szabály: maximum 2-3 origint preconnect-elj. Minden egyes preconnect CPU-t és sávszélességet használ (a TLS tanúsítványok ~3 KB-osak). Ha egy preconnect-elt kapcsolat 10 másodpercen belül nem kerül felhasználásra, a Chrome automatikusan bontja. Szóval ne vidd túlzásba.

Partytown: harmadik fél szkriptek a Web Workerben

A Partytown (a Builder.io, jelenleg QwikDev gondozásában) egy nyílt forráskódú könyvtár, ami az erőforrás-igényes harmadik fél szkripteket a fő szálról egy Web Workerbe helyezi át. Az eredmény: a böngésző fő szála felszabadul a renderelésre és az interakciókra, míg az analitika és tracking szkriptek csendben dolgoznak egy külön szálon.

Hogyan működik?

A type="text/partytown" attribútummal jelölt szkripteket a fő szál nem hajtja végre.
A Partytown letölti és egy Web Worker Blob-on belül futtatja ezeket.
Proxy objektumokat hoz létre a DOM eléréshez, szinkron kommunikációt biztosítva Service Worker + Atomics API segítségével.

<!-- Partytown használata GTM-hez -->
<script>
  // Partytown konfiguráció
  partytown = {
    forward: ['dataLayer.push'],
  };
</script>
<script src="/~partytown/partytown.js"></script>

<!-- GTM szkript átirányítva a Web Workerbe -->
<script type="text/partytown"
  src="https://www.googletagmanager.com/gtm.js?id=GTM-XXXXX">
</script>

Mikor érdemes használni? Először mindig alkalmazd az alap optimalizálásokat (async/defer, késleltetett betöltés, facade). Ha a Lighthouse audit továbbra is jelentős harmadik fél hatást mutat a „Minimize main-thread work" és „Reduce the impact of third-party code" kategóriákban, akkor jöhet a Partytown. De fontos tudni: a könyvtár még béta állapotban van, és egyes DOM-függő szkriptek problémákat okozhatnak benne. Ne ez legyen az első, amire nyúlsz.

Szerver oldali tagging: a 2026-os csúcstechnológia

A Google Tag Manager szerver oldali tagging funkciója egy paradigmaváltás. A koncepció: ahelyett, hogy a felhasználó böngészője töltene be és futtatna tucatnyi marketing és analitika szkriptet, egyetlen könnyű kliens oldali kérés megy a saját szerveredre, és a szerver továbbítja az adatokat a harmadik fél szolgáltatóknak.

Vagyis a felhasználó böngészője szinte semmi extrát nem csinál. Elég jól hangzik, nem?

Teljesítménybeli előnyök

Drasztikusan csökkentett kliens oldali JavaScript — csak egyetlen Google Tag vagy minimális konténer kell a böngészőben
Felszabadított fő szál — a tag végrehajtás a szerveren történik, nem a felhasználó eszközén
CDN-ként is működhet — egyéni cache fejlécek, tömörítés és ideiglenes tárolás a szerveren
Jobb adatminőség — az adatok gazdagíthatók szerver oldali információkkal (pl. ügyfél szegmens, élettartam-érték)

Kompromisszumok

Legyünk őszinték: a szerver oldali tagging nem ingyenes. A Google Cloud Platform (vagy alternatív hosting, pl. Stape) szerverköltséget jelent. A beállítás technikai tudást igényel — cloud platform konfiguráció, szerver kezelés, adatfolyamok tervezése.

Kis forgalmú oldalaknak ez minimális költség, de nagy forgalmú oldalaknál gyorsan nőhet. Ennek ellenére a teljesítménybeli és adatvédelmi előnyök 2026-ban már egyértelműen megérik a befektetést az üzleti szempontból kritikus webhelyeknél.

Gyakorlati audit útmutató: lépésről lépésre

Jöjjön a gyakorlat. Az alábbi folyamat segít szisztematikusan feltérképezni és optimalizálni a harmadik fél szkriptjeidet.

1. lépés: Azonosítás Lighthouse-szal

Futtass egy Lighthouse Performance auditot a Chrome DevTools-ban (F12 → Lighthouse fül). Keresd meg a „Reduce the impact of third-party code" szekciót — ez kilistázza az összes harmadik fél szkriptet a fő szál blokkolási idejükkel együtt. A figyelmeztetés akkor jelenik meg, ha a harmadik fél által okozott teljes blokkolási idő meghaladja a 250 ms-ot.

2. lépés: Blokkolás és tesztelés

A Chrome DevTools Network paneljén jobb kattintással blokkolhatsz egyes szkript URL-eket (Block request URL). Futtasd újra a Lighthouse-t a blokkolt szkriptekkel, és mérd a különbséget. Meg fogsz lepődni — néha egy apró chat widget okozza a legnagyobb gondot.

3. lépés: Prioritizálás és cselekvés

Eltávolítható? → Töröld. Ez mindig a legnagyobb hatású optimalizálás.
Késleltethető? → Használj defer-t, requestIdleCallback-ot vagy Intersection Observer-t.
Facade alkalmazható? → Implementálj könnyű előnézetet (videók, térképek, chat).
Fő szálról leemelhető? → Vizsgáld meg a Partytown lehetőségét.
Szerver oldalra helyezhető? → Értékeld a szerver oldali tagging bevezetését.

4. lépés: Teljesítmény budget felállítása

# lighthouse-ci.yaml — automatizált teljesítmény budget
ci:
  assert:
    assertions:
      third-party-summary:total-blocking-time:
        maxNumericValue: 250
      total-blocking-time:
        maxNumericValue: 300
      largest-contentful-paint:
        maxNumericValue: 2500
      interactive:
        maxNumericValue: 3800

Integráld a Lighthouse CI-t a CI/CD pipeline-odba, hogy minden deploy előtt automatikusan ellenőrizd: nem lépte-e túl az oldal a meghatározott korlátokat. Ez megakadályozza, hogy egy új harmadik fél szkript hozzáadása csendben elrontsa a teljesítményt.

5. lépés: Negyedéves felülvizsgálat

A harmadik fél szolgáltatók rendszeresen frissítik szkriptjeiket — és néha (meglepetés!) teljesítményromlást okoznak vele. Állíts be negyedéves auditokat: nézd át a Google Tag Manager konténered tartalmát, távolítsd el az elavult tageket, és mérd újra a teljesítményt.

Vezess be governance folyamatot: minden új harmadik fél szkript hozzáadásához legyen szükség fejlesztői jóváhagyásra, ami magában foglalja a teljesítményhatás értékelését is. Ez az egyetlen módja annak, hogy hosszú távon kézben tartsd a dolgokat.

Valós eredmények: mit érhetsz el?

A harmadik fél szkriptek szisztematikus optimalizálása mérhető üzleti eredményeket hoz:

A Core Web Vitals küszöbértékeket teljesítő oldalak 24%-kal alacsonyabb visszafordulási arányt mutatnak
E-commerce oldalak átlagosan 20%-os konverziós arány növekedést mértek, amikor a betöltési idő 3 másodpercről 1 másodpercre csökkent
A legtöbb weboldal már csak a harmadik fél szkriptek auditálásával és a chat widgetek lazy loadingjával el tudja érni a megfelelő INP értékeket

Nem kell egyszerre mindent megcsinálnod. Kezdd az async/defer beállításával, aztán jöhetnek a facade-ok, és ha szükséges, fokozatosan léphetsz a Partytown vagy szerver oldali tagging felé.

Gyakran ismételt kérdések (GYIK)

Mi a különbség az async és a defer attribútum között szkripteknél?

Az async attribútummal jelölt szkript párhuzamosan töltődik le és azonnal lefut, amint a letöltés kész — akár a HTML feldolgozás közben is. A defer szintén párhuzamosan tölt, de a szkript futtatását elhalasztja a HTML teljes feldolgozásáig, és megőrzi a szkriptek deklarációs sorrendjét. Harmadik fél szkripteknél a defer a biztonságosabb alapértelmezett választás, mivel nem szakítja meg a DOM felépítését.

Hogyan találom meg, mely harmadik fél szkriptek lassítják az oldalamat?

Futtass egy Lighthouse Performance auditot a Chrome DevTools-ban, és keresd meg a „Reduce the impact of third-party code" figyelmeztetést. A DevTools Network fülén szűrhetsz „third-party" kérésekre, a Performance fülön pedig a „Third Party" badge-ek megmutatják, mely szkriptek blokkolják a fő szálat. A Chrome lehetővé teszi szkriptek blokkolását is (jobb klikk → Block request URL), így tesztelheted az egyes szkriptek eltávolításának hatását.

Biztonságos a Partytown használata éles környezetben?

A Partytown jelenleg béta állapotban van, de már számos produkciós oldalon használják. A legfontosabb korlátja, hogy a Web Workerben futó szkriptek nem férnek hozzá közvetlenül a DOM-hoz — a Partytown Proxy-n keresztül kommunikálnak, ami egyes komplex szkripteknél (pl. DOM-manipulációt végző widgetek) problémákat okozhat. Érdemes a hivatalos kompatibilitási listát ellenőrizni, és fokozatosan bevezetni, szkriptenként tesztelve.

Megéri a szerver oldali tagging bevezetése kis forgalmú oldalakon?

Őszintén? Kis forgalmú oldalaknál (havi néhány ezer látogató) a költség-haszon arány kevésbé kedvező, mivel a szerver hosting havi díjat jelent (Stape esetében ~$20/hó-tól, GCP-n pay-as-you-go). Ilyen esetben az async/defer, facade pattern és késleltetett betöltés kombinációja általában elegendő. Nagy forgalmú oldalaknál és e-commerce webhelyeknél viszont a szerver oldali tagging 2026-ban már szinte kötelező — a teljesítmény, adatvédelem és mérési pontosság szempontjából egyaránt.

A Google Tag Manager önmagában lassítja az oldalt?

Maga a GTM konténer mérete viszonylag kicsi (~33 KB tömörítve), de a probléma nem a GTM, hanem az, amit rajta keresztül betöltesz. Minden tag, trigger és változó további JavaScript végrehajtást jelent. Ha a GTM konténered 20+ taget tartalmaz, amelyek közül sok az oldal betöltésekor azonnal lefut, az drámai hatással lehet az INP-re és az LCP-re. A megoldás: rendszeres audit, trigger feltételek finomítása (ne minden oldalon töltődjön be minden tag), és lehetőség szerint szerver oldali tagging alkalmazása.