Mer än 90 % av sidorna laddas av minst en tredjepartswebbplats, och de 1 000 främsta webbplatserna har nu i median 106 tredjepartsförfrågningar på mobilen – 15 fler än året innan – enligt HTTP-arkivets Webbalmanackan 2025Skript utgör den största enskilda andelen av dessa förfrågningar med 24.8 %.
Nästan inget av det kom genom beslut. Det kom tagg för tag, och ingen äger hela kostnaden. Kostnaden är mätbar: Googles fallstudiebibliotek visar att Vodafone Italien förbättrade LCP med 31 % och tog 8% mer försäljning.
Den här guiden är för den person som ombeds att åtgärda Core Web Vitals och som inte ensidigt kan ta bort en marknadsföringstagg. I slutet kommer du att ha en poäng med fem kriterier för varje tredje part på din webbplats, en routingregel som omvandlar varje poäng till en specifik åtgärd och ett försvarbart tal för mötet där någon försvarar taggen vilket kostar 380 ms.
Bygg upp inventariet innan du får något
Du behöver två listor; ingen av dem är komplett på egen hand.
Containerlistan. Exportera din Google Tag Manager-behållare: taggar, utlösare och variabler med deras ägare och aktiveringsvillkor. Det är avsikten.
Nätverkslistan. Ladda sidan i Chrome DevTools med cachen inaktiverad, kör sedan Lighthouse och läs granskningen "Minska påverkan av tredjepartskod". Det är detta som faktiskt körs, inklusive taggar som injiceras av andra taggar, vilka aldrig visas i en containerexport.
För varje tredje part på endera listorna, registrera sju fält:
- Leverantören och vad den påstår sig göra
- Namngiven företagsägare (en person, inte en avdelning)
- Skriptöverföringsstorlek
- Blockeringstid för huvudtråd som kan hänföras till den
- Om den ligger på den kritiska vägen till LCP-elementet
- Vilka sidmallar den aktiveras på
- Senaste gången någon fattade ett beslut med hjälp av dess data
Det sista fältet är det som folk hoppar över, och det som stänger flest argument. Poäng mot fältdata: Core Web Vitals bedöms vid 75:e percentilen av verkliga sidladdningar, och en labbkörning på en snabb anslutning smickrar din stack.
De fem poängkriterierna
Poängsätt varje tredje part 0–3 på alla fem. Högre totalsummor innebär starkare skäl för borttagning.
| Kriterium | 0 poäng | 1 punkt | 2 poäng | 3 poäng |
|---|---|---|---|---|
| Kostnad för huvudtråd | Under 50 ms | 50–150 ms | 150–350 ms | Över 1 000 ms |
| Kritisk vägs position | Avfyras efter last, utanför vägen | Asynkron, ingen effekt på LCP | Fördröjer LCP-elementet | Renderingblockering i <head> |
| Bevisad användning | Drivs fram ett beslut varje vecka | Endast månadsrapportering | Någon öppnar den varje kvartal | Ingen namngiven användning på 90 dagar |
| Utbytbarhet | Ingen ersättning finns | Leverantörs-SDK är det enda alternativet | Fasad- eller lazy-load är möjlig | Motsvarigheter för nativa, server- eller förstapartslösningar finns |
| Samtyckesberoende | Absolut nödvändigt, inget samtycke | Samtycke krävs, laddas efter beviljande | Samtycke krävs, laddas som standard nekad | Samtycke krävs och grindar andra taggar |
Två överskrivningar ligger ovanpå totalen:
- En 3:a på Visad användning av rutter för att Döda oavsett totalsumma. Ingen kostnad är värd att betala för en tagg som ingen använder.
- En 3:a på kritiska vägens positionsrutter till minst band 3. Ett renderingsblockerande skript i huvudet är strukturellt, oavsett hur värdefull leverantören är.
Ruttbord
| Totalt | Handling | Signering krävs |
|---|---|---|
| 0-3 | Behåll. Gör om poängen om sex månader. | Ingen |
| 4-6 | Uppskjuta eller lata in | Teknik |
| 7-9 | Ersätt med en fasad, eller lasta villkorligt efter rutt, geografisk plats eller tillstånd | Engineering plus-taggägare |
| 10-12 | Flytta till serversidan, eller ersätt med en motsvarighet från första part | Analytics-ägare |
| 13-15 | Döda. Presentera poängen, inte en åsikt. | Taggägarens chef |
Inom ett band väljer utbytbarhetspoängen taktiken: en 3:a där betyder att en motsvarighet från första part eller serversidan finns, så ta den vägen snarare än bandets standard.
Kolumnen för godkännande är viktig eftersom varje band namnger en person. "Webbplatsen är långsam på grund av taggar" är ett klagomål. "Denna tagg fick 11 poäng, här är vem som godkänner den" är en biljett.
Ett fungerande exempel
En sammansatt e-handelsutcheckning för medelstora företag. Inte kunddata; siffrorna är illustrativa.
| tagg | Pris | Placera | Använda | ersätta | Samtycke | Totalt | Rutt |
|---|---|---|---|---|---|---|---|
| Livechatt-widget | 3 | 2 | 0 | 2 | 1 | 8 | Fasad: ladda vid klick |
| Äldre värmekartverktyg | 2 | 1 | 3 | 3 | 2 | 11 | Döda (Använd åsidosättning) |
| Annonskonverteringstagg | 1 | 1 | 0 | 3 | 2 | 7 | Flytta serversidan (utbytbarhet 3) |
| Plattform för samtyckeshantering | 1 | 3 | 0 | 1 | 0 | 5 | Band 3 (Positionsåsidosättning): granska dess blockeringsbeteende |
| Typsnittsleverantör | 1 | 2 | 0 | 3 | 0 | 6 | Självvärd och delmängd (utbytbarhet 3) |
Chattwidgeten är den instruktiva raden. Den används verkligen och kan inte ersättas, och den leder fortfarande till en fasad, eftersom rubriken separerar "behöver vi detta" från "behöver vi det inom de första 2.5 sekunderna".
[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.]
De tre lösningarna, rangordnade efter hur ofta de faktiskt fungerar
Fasader. Ersätt en inbäddad widget med en statisk platshållare som laddar den riktiga widgeten vid interaktion. Chatt-, video-, kart- och recensionswidgetar är de vanligaste vinsterna. Det är den mest effektiva lösningen i de flesta granskningar eftersom den tar bort kostnaden utan att ta bort funktionen, vilket är anledningen till att den överlever mötet.
Uppskjutning. Användbart, med vissa förbehåll. Chrome sänker nätverksprioriteten of async och defer resurser, så de laddas senare än du förväntar dig – okej för en pixel, inte för något som renderas. web.dev noterar också att inbäddningar "kan blockera window.onload om deras servrar svarar långsamt, även om inbäddningen använder async eller defer." Uppskjutning flyttar kostnaden; det tar inte alltid bort den.
Taggning på serversidan. Detta behöver korrigeras, eftersom den säljs som en produkt för sidhastighet och inte är en. Googles egen introduktion till serversidestaggning beskriver dataägande, formning och routing — "bara du har tillgång till data på servern tills du väljer att skicka dem någon annanstans" — och gör inga prestandaanspråk. Webbläsaren kör fortfarande mätkod och överför fortfarande händelser, via bildpixlar, fetch, XHR eller en servicearbetare som betjänas från din servercontainerdomän.
Det den köper är kontext från första part och kontroll över vad som lämnar din infrastruktur. Eventuell hastighetsökning är en bieffekt av de leverantörsskript du tar bort under migreringen. Om en leverantör lovar en INP-förbättring enbart från serversidestaggning, fråga vilket skript som slutar laddas i webbläsaren; om svaret är inget, sker ingen förbättring. INP består av inmatningsfördröjning, bearbetningstid och presentationsfördröjning, och skript blåser upp de två första genom att ockupera huvudtråden. Ändrar var en förfrågan är skickas påverkar ingendera.
Där samtyckeslagret ändrar aritmetiken
Din plattform för samtyckeshantering är oftast det objekt som får högst poäng i inventariet: det sitter i huvudet, det är renderingsblockerande av sig självt, och alla andra taggar väntar på det. Poängsätt det som allt annat.
Bestäm sedan vilket samtyckesläge du använder, eftersom de två har olika prestandaprofiler. Enligt Google, grundläggande samtyckesläge innebär att taggar är "blockerade tills användaren interagerar med en samtyckesbanner", medan avancerat läge "läses in med standardinställningarna inställda på denied" och skickar cookiefria mätningar före samtycke. Basic är snabbare vid den första laddningen. Det kostar dig också data: Googles EES-vägledning varnar för att om du förhindrar att taggar laddas förrän bannerinteraktion sker, "kommer Google inte att kunna verifiera användarnas samtyckesval och detta kan leda till dataförlust."
Här förtjänar en regional detalj sin plats. Turkiet är inte inom EES, så Googles krav på samtyckessignal inom EES når inte turkisk trafik – men turkisk lag gör det. KVKK:s guide om cookiepraxis behandlar analyscookies som att de kräver uttryckligt samtycke snarare än strikt nödvändiga, kräver att samtyckeskategorier är avmarkerade som standard och att "Avvisa alla" är lika framträdande som "Acceptera alla", och förbjuder cookieväggar.
Den praktiska konsekvensen för en turkisk återförsäljare eller återförsäljare med flera marknader: kör grundläggande samtyckesläge på turkisk trafik och avancerat på EES-trafik, och du förlorar ingenting som du hade rätt till på någon av marknaderna. De flesta CMP:er gör inte detta direkt. Det är ett geografiskt begränsat konfigurationsbeslut, inte ett plugin.
Vad denna bedömningsmatris inte täcker
- Den poängsätter taggar, inte sidor. En tagg som är ofarlig på startsidan kan vara förödande på en listningssida som laddar fyrtio av dem.
- Kostnaden för huvudtråden är inte additiv. Att ta bort fem 100ms-taggar ger sällan 500ms. Mät efter varje ändring.
- Den ignorerar din egen kod. Långa uppgifter från ramverkshydrering är ofta den större andelen av en dålig INP, och ingen tredjepartsgranskning kommer att hitta dem.
- Det ger dig bara kostnadssidan. En 380ms-tagg som genererar verkliga attributbara intäkter kan vara värd att behålla.
- Den har ingen åsikt om säkerhet eller datalagring, ibland den faktiska anledningen till att en säljare borde gå.
- Piggyback-taggar döljs från containerexporter. Om de två listorna inte överensstämmer, lita på nätverkslistan.
FAQ
Hur mäter jag kostnaden för huvudtråden för en specifik tredje part? Använd prestandapanelen i Chrome DevTools för att tillskriva långa uppgifter till skriptursprung och dubbelkolla med Lighthouse-granskningen "Minska påverkan av tredjepartskod". Kontrollera mot fältdata, eftersom en labbkörning underskattar den verkliga kostnaden.
Förbättrar serversidestaggning Core Web Vitals? Inte på egen hand. Googles dokumentation för serversidestaggning beskriver datakontroll och routing, inte sidhastighet, och webbläsaren laddar fortfarande mätkod och överför händelser. Eventuella förbättringar kommer från leverantörsskript som du tar bort från sidan som en del av migreringen.
Vilken Core Web Vital skadar tredje part mest? Vanligtvis INP, eftersom skript upptar huvudtråden och ökar inmatningsfördröjningen och bearbetningstiden. Renderingblockerande taggar i head-gränssnittet drabbar LCP istället, och sent injicerade banners eller widgets drabbar CLS.
Borde jag själv hosta tredjepartsskript? Ibland, men det är en byteshandel. Självhostade kopior slutar ta emot ändringar i leverantörs-API:et och säkerhetskorrigeringar förrän du uppdaterar dem manuellt, vilket web.dev flaggar som en intäkts- och säkerhetsrisk.
Vad bör jag sikta på? Vid den 75:e percentilen av verkliga sidladdningar: LCP på eller under 2.5 sekunder, INP på eller under 200 millisekunder, CLS på eller under 0.1.
Behöver jag Googles samtyckesläge om min trafik mestadels är turkisk? Googles krav på samtyckessignal inom EES gäller inte turkisk trafik, men KVKK:s cookieregler gör det, så du behöver fortfarande en fungerande samtyckesmekanism. Det som ändras är att du är friare att välja den snabbare grundläggande implementeringen för det segmentet.
Hur ofta ska detta poängsättas igen? Kvartalsvis för hela lagret, och vid varje utgåva som lägger till en leverantör. Taggstackar växer igen: Webbalmanackans siffror jämfört med föregående år visar att antalet tredjepartsförfrågningar ökar.
Vad gör jag när taggägaren vägrar? Skicka partituret och bandet, inte argumentet. Matrisen finns så samtalet handlar om ett nummer och en namngiven handling snarare än vems prioritet som vinner.
Om dina kassa- eller listningssidor misslyckas med Core Web Vitals och du inte kan säga vilken leverantör som är ansvarig, kör den här matrisen på din egen stack – eller låt oss köra den, med fältdata och en prioriterad orderstock, via Switas webbprestandatjänster.
Källor
- Tredje parter — 2025 Webbalmanacka, HTTP-arkiv
- Webbnyheter — web.dev
- Interaktion med nästa färg (INP) — web.dev
- Laddar JavaScript från tredje part — web.dev
- Affärspåverkan av Core Web Vitals — fallstudier från web.dev
- Introduktion till serversidestaggning — Google Tag Platform
- Skicka data till en serverbehållare — Google Tag Platform
- Koncept för samtyckesläge — Google Tag Platform
- Uppdateringar av samtyckesläget för EES-trafik — Google Ads Hjälp
- KVKK Çerez Rehberi efterlevnadsplan — Mondaq (analys av myndighetens 61-sidiga guide; kvkk.gov.tr var inte nåbar i skrivande stund)
