Az oldalak több mint 90%-a legalább egy harmadik féltől származó kérést tölt be, és az első 1,000 webhely jelenleg átlagosan 106 harmadik féltől származó kérést továbbít mobilon – 15-tel többet, mint egy évvel korábban – a HTTP Archívum adatai szerint. 2025-ös webes almanachA szkriptek teszik ki ezen kérések legnagyobb részét, 24.8%-át.
Szinte semmi sem érkezett döntés alapján. Egyenként, címkénként érkeztek, és senki sem birtokolja a teljes összeget. A költség mérhető: a Google esettanulmány-könyvtárában a Vodafone Italy 31%-kal javította az LCP-t, és... 8%-kal több eladás.
Ez az útmutató azoknak a felhasználóknak szól, akiket a Core Web Vitals mutatók javítására kérnek fel, és nem tudnak egyoldalúan törölni egy marketingcímkét. A végére minden harmadik félhez egy öt kritériumból álló pontszámot fog kapni a webhelyén, egy útvonalszabályt, amely minden pontszámot egy adott műveletté alakít, valamint egy védhető számot arra a találkozóra, ahol valaki megvédi a címkét, ami 380 ms-ba kerül.
Építsd fel a leltárt, mielőtt bármit is szereznél
Két listára van szükséged; egyik sem teljes önmagában.
A konténerlista. Exportáld a Google Tag Manager tárolódat: címkék, triggerek és változók a tulajdonosaikkal és az aktiválási feltételekkel együtt. Ez a cél.
A hálózati lista. Töltsd be az oldalt a Chrome DevTools-ban letiltott gyorsítótárral, majd futtasd a Lighthouse-t, és olvasd el a „Harmadik féltől származó kód hatásának csökkentése” auditot. Ez az, ami valójában lefut, beleértve a más címkék által beillesztett címkéket is, amelyek soha nem jelennek meg egy konténer exportálásában.
Mindkét listán szereplő minden harmadik fél esetében hét mezőt kell rögzíteni:
- Az eladó és az, amit ígér
- Megnevezett vállalkozás tulajdonosa (egy személy, nem egy részleg)
- Szkriptátvitel mérete
- A fő szál blokkolási ideje, ami ennek tulajdonítható
- Vajon az LCP elemhez vezető kritikus úton helyezkedik-e el?
- Mely oldalsablonokon aktiválódik
- Legutóbb, amikor valaki az adatai alapján hozott döntést
Az utolsó mezőt hagyják ki az emberek, és ez zárja le a legtöbb argumentumot. Pontozás a mezőadatokhoz képest: A Core Web Vitals mutatókat a következő helyen értékelik: A valódi oldalbetöltések 75. percentilisét, és egy gyors kapcsolaton végzett laborvizsgálat előnyös a számodra.
Az öt pontozási kritérium
Minden harmadik félnek 0–3 pontot kell adni mind az öt pontban. A magasabb pontszám erősebb okot jelent az eltávolításra.
| Kritérium | 0 pontok | 1 pont | 2 pontok | 3 pontok |
|---|---|---|---|---|
| Főszál költsége | 50 ms alatt | 50-150 ms | 150-350 ms | Több mint 350 ms |
| Kritikus út pozíció | Töltés után tüzel, letérve az útról | Aszinkron, nincs hatással az LCP-re | Késlelteti az LCP elemet | Renderelés-blokkolás <head> |
| Bizonyított használat | Hetente döntést hoz | Csak havi jelentés | Valaki negyedévente kinyitja | 90 napig nem volt megnevezett használat |
| Cserélhetőség | Nincs helyettesítő | A Vendor SDK az egyetlen lehetőség | Homlokzati vagy lazyload lehetséges | Létezik natív, szerveroldali vagy saját fejlesztésű megfelelője |
| Hozzájárulástól való függőség | Feltétlenül szükséges, hozzájárulás nem szükséges | Hozzájárulás szükséges, sok a megadás után | Hozzájárulás szükséges, a betöltések alapértelmezés szerint elutasítva | Hozzájárulás szükséges, és más címkéket is kezel |
Két felülírás található az összegen felül:
- 3-as a Bemutathatóan használt Ölési útvonalakra, függetlenül az összegtől. Semmi árat nem ér egy olyan címkéért fizetni, amit senki sem használ.
- A 3-as kritikus útvonalú pozíció legalább a 3-as sávba vezet. Egy renderelést blokkoló szkript a headben strukturális tényező, bármennyire is értékes a szállító.
Útválasztó asztal
| Összeg | Akció | Aláírás szükséges |
|---|---|---|
| 0-3 | Tartsd meg. Hat hónap múlva újra pontozd. | Egyik sem |
| 4-6 | Késleltetés vagy lusta betöltés | Mérnöki |
| 7-9 | Cserélje ki egy homlokzatra, vagy töltse be feltételesen útvonal, földrajzi hely vagy hozzájárulási állapot alapján | Mérnöki és címketulajdonos |
| 10-12 | Szerveroldali áthelyezés, vagy csere egy saját fejlesztésű megfelelőjére | Analytics-tulajdonos |
| 13-15 | Ölj. Mutasd be az eredményt, ne a véleményt. | Címketulajdonos kezelője |
Egy sávon belül a Replaceability pontszám választja ki a taktikát: a 3-as azt jelenti, hogy létezik egy saját fejlesztésű vagy szerveroldali megfelelője, ezért azt az utat válaszd a sáv alapértelmezettje helyett.
Az aláírási oszlop azért fontos, mert minden zenekar megnevez egy személyt. Az „Az oldal lassú a címkék miatt” egy panasz. Az „Ez a címke 11 pontot ért, itt van, aki aláírta” egy cédula.
Egy működő példa
Egy összetett középkategóriás e-kereskedelmi fizetési felület. Nem ügyféladatok; a számok illusztrációk.
| címke | Költség | Pozíció | Felhasználás | Cserélje | Beleegyezés | Összeg | Útvonal |
|---|---|---|---|---|---|---|---|
| Élő chat widget | 3 | 2 | 0 | 2 | 1 | 8 | Homlokzat: kattintásra terhelhető |
| Régi hőtérkép eszköz | 2 | 1 | 3 | 3 | 2 | 11 | Ölj meg (Használj felülírást) |
| Hirdetéskonverziós címke | 1 | 1 | 0 | 3 | 2 | 7 | Szerveroldali áthelyezés (3. helyettesíthetőség) |
| Hozzájárulás-kezelő platform | 1 | 3 | 0 | 1 | 0 | 5 | 3. sáv (Pozíció felülbírálása): a blokkolási viselkedésének auditálása |
| Betűtípus-szolgáltató | 1 | 2 | 0 | 3 | 0 | 6 | Saját host és részhalmaz (3. helyettesíthetőség) |
A chat widget az instrukciós sor. Valóban használják, nem cserélhető, és továbbra is egy homlokzatra irányít, mivel a rubrika elválasztja a „szükségünk van erre” és a „szükségünk van rá az első 2.5 másodpercben” kérdéseket.
[INTERNAL DATA NEEDED: replace this composite table with a real anonymised inventory from a Switas engagement — vendor category, measured blocking time, post-change field metric.]
A három javítás, aszerint rangsorolva, hogy milyen gyakran működnek
Homlokzatok. Cserélj le egy beágyazott elemet egy statikus helyőrzőre, amely interakciókor betölti a valódi widgetet. A csevegés, videó, térképek és értékelő widgetek a szokásos sikert hozzák. A legtöbb auditban ez a legnagyobb hozamú megoldás, mivel a funkció eltávolítása nélkül távolítja el a költségeket, ezért marad meg a megbeszélésen.
Halasztás. Hasznos, fenntartásokkal. Króm csökkenti a hálózati prioritást of async és a defer erőforrásokat, így később töltődnek be a vártnál – pixelek esetén rendben van, renderelt dolgok esetén nem. A web.dev megjegyzi azt is, hogy a beágyazások „blokkolhatják” a window.onload ha a szervereik lassan reagálnak, még akkor is, ha a beágyazás aszinkron vagy halasztást használ." A halasztás áthelyezi a költséget; nem mindig szünteti meg azt.
Szerveroldali címkézés. Ez javításra szorul, mivel oldalbetöltési sebességet növelő termékként árulják, pedig nem az. A Google sajátja. Bevezetés a szerveroldali címkézésbe leírja az adatok tulajdonjogát, formázását és útvonalát – „csak Önnek van hozzáférése a szerveren található adatokhoz, amíg úgy nem dönt, hogy máshová küldi azokat” – és nem tesz teljesítmény-követelményt. A böngésző továbbra is futtat mérési kódot, és továbbra is továbbít eseményeket képpontokon keresztül, fetch, XHR vagy egy szolgáltató munkatársa szerverkonténer domain.
Amit vásárol, az az első féltől származó kontextus és az infrastruktúrából kilépő információk feletti kontroll. Bármilyen sebességnövekedés a migráció során eltávolított gyártói szkriptek mellékhatása. Ha egy gyártó pusztán a szerveroldali címkézésből származó INP-javulást ígér, kérdezze meg, hogy melyik szkript állítja le a böngészőben való betöltést; ha a válasz nem, akkor nincs javulás. Az INP a következőkből áll: bemeneti késleltetés, feldolgozási időtartam és megjelenítési késleltetés, és a szkriptek a fő szál elfoglalásával felfújják az első kettőt. A kérés helyének megváltoztatása küldött egyiket sem érinti.
Ahol a beleegyezési réteg megváltoztatja a számtani műveleteket
A hozzájárulás-kezelő platformod általában a legmagasabb pontszámot elérő elem a leltárban: a headben található, tervezésénél fogva renderelés-blokkoló, és minden más címke erre vár. Pontozd, mint bármi mást.
Ezután döntsd el, hogy melyik hozzájárulási módot használod, mivel a kettő eltérő teljesítményprofillal rendelkezik. A Google szavaival élve, alapvető hozzájárulási mód azt jelenti, hogy a címkék „blokkolva vannak, amíg a felhasználó nem interakcióba lép egy beleegyező bannerrel”, míg a speciális mód „alapértelmezett beállításokkal töltődik be” denied„és a hozzájárulás előtt sütimentes méréseket küld. Az Basic gyorsabb a kezdeti betöltéskor. Ráadásul adatforgalomba is kerül: a Google… EEA útmutató figyelmeztet, hogy ha megakadályozza a címkék betöltését a bannerrel való interakcióig, „a Google nem lesz képes ellenőrizni a felhasználók hozzájárulási döntéseit, és ez adatvesztéshez vezethet”.
Itt egy regionális részlet kiérdemli a helyét. Törökország nem tagja az EGT-nek, így a Google EGT-s hozzájárulási jelre vonatkozó követelménye nem éri el a török forgalmat – a török törvények viszont igen. A KVKK sütihasználatról szóló útmutatója az analitikai sütiket kifejezett hozzájárulást igénylőként kezeli, nem pedig szigorúan szükségesként, előírja, hogy a hozzájárulási kategóriák alapértelmezés szerint ne legyenek ellenőrizve, és az „Összes elutasítása” ugyanolyan hangsúlyos, mint az „Összes elfogadása”. tiltja a sütifalakat.
A gyakorlati következmény egy török vagy többpiaci kiskereskedő számára: futtasson alap hozzájárulási módot a török forgalomra, és haladó módot az EGT-s forgalomra, és így semmit sem veszít, amire bármelyik piacon jogosult lett volna. A legtöbb CMP ezt nem teszi meg alapértelmezés szerint. Ez egy földrajzi hatókörű konfigurációs döntés, nem pedig egy bővítmény.
Amit ez a rubrika nem fed le
- Címkéket pontoz, nem oldalakat. Egy ártalmatlan címke a főoldalon romboló hatású lehet egy olyan listázó oldalon, amely negyvenet tölt be.
- A fő szál költsége nem additív. Öt 100 ms-os címke eltávolítása ritkán ad vissza 500 ms-ot. Minden változtatás után végezzen mérést.
- Figyelmen kívül hagyja a saját kódodat. A keretrendszer hidratációjából adódó hosszú feladatok gyakran a rossz INP nagyobb részét teszik ki, és egyetlen harmadik fél általi audit sem fogja ezeket megtalálni.
- Csak a költségoldalt adja meg. Egy 380 ms-os címkét, amely valódi, tulajdonítható bevételt generál, érdemes lehet megtartani.
- Nincs véleménye a biztonságról vagy az adatok tárolásáról, néha ez az igazi ok, amiért egy árusnak mennie kellene.
- A hátlapon elhelyezett címkék elrejthetők a konténerexportok elől. Ahol a két lista nem ért egyet, bízz a hálózati listában.
FAQ
Hogyan mérhetem meg egy adott harmadik fél fő szálának költségét? A Chrome DevTools Teljesítmény paneljén rendeld hozzá a hosszú feladatokat a szkriptek eredetéhez, és ellenőrizd a Lighthouse „Harmadik féltől származó kód hatásának csökkentése” auditjával. Ellenőrizd a terepi adatokkal, mert a laboratóriumi futtatás alábecsüli a valós költségeket.
Javítja-e a szerveroldali címkézés a Core Web Vitals mutatókat? Nem önmagában. A Google szerveroldali címkézésről szóló dokumentációja az adatvezérlést és az útválasztást írja le, nem az oldal sebességét, és a böngésző továbbra is betölti a mérési kódot és továbbítja az eseményeket. Bármilyen javulás a migráció részeként az oldalról eltávolított gyártói szkriptekből származik.
Melyik Core Web Vital szolgáltatást károsítják a harmadik felek a legnagyobb mértékben? Általában INP, mivel a szkriptek foglalják el a fő szálat, és megnövelik a bemeneti késleltetést és a feldolgozási időt. A headben lévő renderelést blokkoló tagek ehelyett az LCP-t, a később beillesztett bannerek vagy widgetek pedig a CLS-t érik el.
Érdemes külső szkripteket saját tárhelyen tárolnom? Néha előfordul, de ez egy csere. A saját tárhelyen tárolt példányok nem kapják meg a gyártói API-módosításokat és biztonsági javításokat, amíg manuálisan nem frissíted őket, amit a web.dev bevételi és biztonsági kockázatként jelöl meg.
Mire kellene törekednem? A valós oldalbetöltések 75. percentilisénél: LCP legfeljebb 2.5 másodperc, INP legfeljebb 200 milliszekundum, CLS legfeljebb 0.1.
Szükségem van a Google hozzájárulási módjára, ha a forgalmam többnyire török? A Google EGT-beli hozzájárulási jelre vonatkozó követelménye nem vonatkozik a török forgalomra, de a KVKK sütiszabályai igen, így továbbra is szükség van egy működő hozzájárulási mechanizmusra. A változás az, hogy szabadabban választhatja a gyorsabb alapvető implementációt az adott szegmenshez.
Milyen gyakran kell ezt újrapontozni? Negyedévente a teljes készletért, és minden olyan kiadáskor, amelyhez új szállító tartozik. A címkehalmok újra növekednek: a Web Almanach éves adatai azt mutatják, hogy a harmadik féltől származó kérések száma növekszik.
Mit tegyek, ha a címke tulajdonosa elutasítja? A kottát és a zenekart küldd, ne a vitát. A rubrika azért létezik, hogy a beszélgetés egy számról és egy megnevezett cselekvésről szóljon, nem pedig arról, hogy kinek a prioritása nyer.
Ha a fizetési vagy hirdetési oldalai nem felelnek meg a Core Web Vitals mutatóknak, és nem tudja megmondani, melyik szállító felelős, futtassa le ezt a rubrikát a saját tesztverzióján – vagy kérje meg minket, hogy futtassa le terepi adatokkal és egy rangsorolt teendőlistával. Switas webes teljesítményszolgáltatások.
Források
- Harmadik felek — 2025 Webes évkönyv, HTTP-archívum
- Webes vitals mutatók — web.dev
- Interakció a következő festéssel (INP) — web.dev
- Harmadik féltől származó JavaScript betöltése — web.dev
- A Core Web Vitals üzleti hatása — web.dev esettanulmányok
- Szerveroldali címkézés bemutatása — Google Tag Platform
- Adatok küldése szerverkonténerbe — Google Tag Platform
- Hozzájárulási mód fogalmai — Google Tag Platform
- Az EGT-forgalomhoz tartozó hozzájárulási mód frissítései — Google Ads Súgó
- KVKK Çerez Rehberi megfelelési ütemterv — Mondaq (a Hatóság 61 oldalas útmutatójának elemzése; a kvkk.gov.tr a cikk írásakor nem volt elérhető)
