Mere end 90 % af siderne indlæses af mindst én tredjepart, og de 1,000 største websteder har nu i gennemsnit 106 tredjepartsanmodninger på mobilen – 15 flere end året før – ifølge HTTP-arkivets Webalmanak 2025Scripts udgør den største enkeltstående andel af disse anmodninger med 24.8 %.
Næsten intet af det ankom ved beslutning. Det ankom én tag ad gangen, og ingen ejer det samlede beløb. Omkostningerne er målbare: Googles casestudiebibliotek viser, at Vodafone Italien forbedrede LCP med 31 % og tog 8% mere salg.
Denne vejledning er til den person, der bliver bedt om at rette Core Web Vitals, og som ikke ensidigt kan slette et marketingtag. Til sidst vil du have en score med fem kriterier for hver tredjepart på dit websted, en routingregel, der omdanner hver score til én specifik handling, og et forsvarligt tal for det møde, hvor nogen forsvarer tagget, hvilket koster 380 ms.
Opbyg inventaret, før du scorer noget
Du skal bruge to lister; ingen af dem er komplette alene.
Containerlisten. Eksportér din Google Tag Manager-container: tags, triggers og variabler med deres ejere og aktiveringsbetingelser. Dette er hensigten.
Netværkslisten. Indlæs siden i Chrome DevTools med cache deaktiveret, kør derefter Lighthouse, og læs revisionen "Reducer virkningen af tredjepartskode". Dette er det, der rent faktisk udføres, inklusive tags, der er injiceret af andre tags, som aldrig vises i en containereksport.
For hver tredjepart på en af listerne skal du registrere syv felter:
- Leverandøren og hvad den påstår at gøre
- Navngiven virksomhedsejer (en person, ikke en afdeling)
- Størrelse på scriptoverførsel
- Blokeringstid for hovedtråd, der kan tilskrives det
- Om den ligger på den kritiske vej til LCP-elementet
- Hvilke sideskabeloner den aktiveres på
- Sidste gang nogen traf en beslutning ved hjælp af deres data
Det sidste felt er det, folk springer over, og det, der lukker flest argumenter. Score i forhold til feltdata: Core Web Vitals vurderes ved 75. percentil af reelle sideindlæsninger, og en laboratoriekørsel på en hurtig forbindelse smigrer din stak.
De fem scoringskriterier
Giv hver tredjepart 0-3 point på alle fem områder. Højere totaler betyder stærkere grunde til fjernelse.
| Kriterium | 0 point | 1 point | 2 point | 3 point |
|---|---|---|---|---|
| Hovedtrådsomkostninger | Under 50 ms | 50-150 ms | 150-350 ms | Over 350 ms |
| Kritisk sti-position | Affyres efter læsning, uden for stien | Asynkron, ingen effekt på LCP | Forsinker LCP-elementet | Render-blokering i <head> |
| Dokumenteret brug | Trækker en beslutning ugentligt | Kun månedlig rapportering | Nogen åbner den hvert kvartal | Ingen navngiven brug i 90 dage |
| Udskiftelighed | Der findes ingen erstatning | Leverandør-SDK er den eneste mulighed | Facade- eller dovenbelastning er mulig | Native, server-side eller tilsvarende førstepartsløsninger findes |
| Samtykkeafhængighed | Strengt nødvendigt, intet samtykke | Samtykke påkrævet, indlæses efter tilladelse | Samtykke kræves, indlæses som standard afvist | Samtykke kræves og gater andre tags |
To overskrivninger ligger oven i det samlede beløb:
- En 3 på Demonstreret brug af ruter til at dræbe uanset total. Det er ikke værd at betale for et mærke, som ingen bruger.
- En 3 på kritiske sti-positionsruter til mindst bånd 3. Et render-blokerende script i hovedet er strukturelt, uanset hvor værdifuld leverandøren er.
Routing tabel
| Samlet beløb | Handling | Godkendelse nødvendig |
|---|---|---|
| 0-3 | Behold. Score igen om seks måneder. | Ingen |
| 4-6 | Udskyd eller lazy-load | Engineering |
| 7-9 | Erstat med en facade, eller indlæs betinget efter rute, geografi eller samtykketilstand | Engineering plus-tag-ejer |
| 10-12 | Flyt til serversiden, eller erstat med en tilsvarende version fra førsteparten | Analytics-ejer |
| 13-15 | Dræb. Præsenter partituret, ikke en mening. | Tag-ejerens administrator |
Inden for et bånd vælger udskiftelighedsscoren taktikken: en 3 der betyder, at der findes en tilsvarende løsning fra førstepart eller serverside, så vælg den vej i stedet for båndets standard.
Kolonnen "godkendelse" er vigtig, fordi hvert band navngiver én person. "Siden er langsom på grund af tags" er en klage. "Dette tag scorede 11, her er hvem der godkender det" er en bøde.
Et fungerende eksempel
En sammensat e-handelsbetaling i mellemklassen. Ikke kundedata; tallene er illustrative.
| tag | Pris | Position | Brug | udskifte | Samtykke | Samlet beløb | R |
|---|---|---|---|---|---|---|---|
| Livechat-widget | 3 | 2 | 0 | 2 | 1 | 8 | Facade: indlæs ved klik |
| Ældre varmekortværktøj | 2 | 1 | 3 | 3 | 2 | 11 | Dræb (Brug tilsidesættelse) |
| Annoncekonverteringstag | 1 | 1 | 0 | 3 | 2 | 7 | Flyt serverside (Udskiftelighed 3) |
| Platform til samtykkehåndtering | 1 | 3 | 0 | 1 | 0 | 5 | Bånd 3 (Positionstilsidesættelse): tjek dens blokeringsadfærd |
| Skrifttypeudbyder | 1 | 2 | 0 | 3 | 0 | 6 | Selvvært og delmængde (Udskiftelighed 3) |
Chat-widgetten er den instruktive række. Den bruges reelt og kan ikke erstattes, og den fører stadig til en facade, fordi rubrikken adskiller "har vi brug for dette" fra "har vi brug for det inden for de første 2.5 sekunder".
[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øsninger, rangeret efter hvor ofte de rent faktisk virker
Facader. Erstat en indlejring med en statisk pladsholder, der indlæser den rigtige widget ved interaktion. Chat-, video-, kort- og anmeldelseswidgets er de sædvanlige succeser. Det er den mest effektive løsning i de fleste revisioner, fordi den fjerner omkostningerne uden at fjerne funktionen, hvilket er grunden til, at den overlever mødet.
Udsættelse. Nyttig, med forbehold. Chrome sænker netværksprioriteten of async og defer ressourcer, så de indlæses senere end forventet — fint for en pixel, ikke for noget, der gengives. web.dev bemærker også, at indlejringer "kan blokere window.onload hvis deres servere reagerer langsomt, selvom embedningen bruger async eller defer." Udsættelse flytter omkostningerne; det fjerner dem ikke altid.
Server-side tagging. Dette skal rettes, fordi det sælges som et pagespeed-produkt og ikke er et. Googles eget Introduktion til serverside-tagging beskriver dataejerskab, -formning og -routing — "kun du har adgang til dataene på serveren, indtil du vælger at sende dem et andet sted hen" — og fremsætter ingen krav om ydeevne. Browseren kører stadig målekode og overfører stadig hændelser via billedpixel, fetch, XHR eller en servicemedarbejder, der betjenes fra din servercontainerdomæne.
Det, den køber, er førstepartskontekst og kontrol over, hvad der forlader din infrastruktur. Enhver hastighedsforøgelse er en bivirkning af de leverandørscripts, du fjerner under migreringen. Hvis en leverandør lover en INP-forbedring udelukkende fra serverside-tagging, så spørg, hvilket script der stopper med at indlæses i browseren. Hvis svaret er nej, er der ingen forbedring. INP er sammensat af inputforsinkelse, behandlingsvarighed og præsentationsforsinkelse, og scripts oppuster de to første ved at optage hovedtråden. Ændrer hvor en anmodning er sendt påvirker ingen af delene.
Hvor samtykkelaget ændrer aritmetikken
Din samtykkehåndteringsplatform er normalt det element med den højeste score i inventaret: det sidder i headeren, det er render-blokerende i sin design, og alle andre tags venter på det. Giv det score som alt andet.
Beslut derefter hvilken samtykketilstand du bruger, da de to har forskellige præstationsprofiler. Med Googles ord, grundlæggende samtykketilstand betyder, at tags er "blokeret indtil brugerinteraktion med et samtykkebanner", mens avanceret tilstand "indlæses med standardindstillingerne indstillet til denied" og sender cookiefri målinger før samtykke. Basic er hurtigere ved den første indlæsning. Det koster dig også data: Googles EØS-vejledning advarer om, at hvis du forhindrer tags i at indlæses indtil bannerinteraktion, "vil Google ikke være i stand til at bekræfte brugerens samtykkevalg, og dette kan føre til tab af data."
Her fortjener en regional detalje sin plads. Tyrkiet er ikke i EØS, så Googles krav om samtykkesignal i EØS når ikke tyrkisk trafik – men det gør tyrkisk lov. KVKK's vejledning om cookiepraksis behandler analysecookies som krævende udtrykkeligt samtykke snarere end strengt nødvendige, kræver som standard, at samtykkekategorier ikke er markeret, og at "Afvis alle" er lige så fremtrædende som "Accepter alle", og forbyder cookievægge.
Den praktiske konsekvens for en tyrkisk eller multimarkedsforhandler: Kør grundlæggende samtykketilstand på tyrkisk trafik og avanceret på EØS-trafik, og du mister intet af det, du havde ret til på nogen af markederne. De fleste CMP'er vil ikke gøre dette fra starten. Det er en geografisk begrænset konfigurationsbeslutning, ikke et plugin.
Hvad denne rubrik ikke dækker
- Den scorer tags, ikke sider. Et harmløst tag på forsiden kan være ødelæggende på en annonceside, der indlæser fyrre af dem.
- Hovedtrådsomkostningerne er ikke additive. Fjernelse af fem 100ms-tags returnerer sjældent 500ms. Mål efter hver ændring.
- Den ignorerer din egen kode. Lange opgaver fra frameworkhydrering er ofte den største andel af en dårlig INP, og ingen tredjepartsrevision vil finde dem.
- Det giver dig kun omkostningssiden. Et 380ms-tag, der genererer reel tilskrivelig omsætning, kan være værd at beholde.
- Den har ingen mening om sikkerhed eller dataopbevaring, nogle gange den egentlige grund til, at en sælger bør gå.
- Piggybacked-tags skjules fra containereksport. Hvor de to lister er uenige, så stol på netværkslisten.
Ofte stillede spørgsmål
Hvordan måler jeg hovedtrådsomkostninger for én specifik tredjepart? Brug Chrome DevTools Performance-panelet til at tilskrive lange opgaver til scriptoprindelser, og krydstjek med Lighthouse-revisionen "Reducer virkningen af tredjepartskode". Bekræft med feltdata, da en laboratoriekørsel undervurderer de reelle omkostninger.
Forbedrer server-side tagging Core Web Vitals? Ikke alene. Googles dokumentation til server-side tagging beskriver datakontrol og routing, ikke sidehastighed, og browseren indlæser stadig målekode og overfører hændelser. Enhver forbedring kommer fra leverandørscripts, som du fjerner fra siden som en del af migreringen.
Hvilken Core Web Vital skader tredjeparter mest? Normalt INP, fordi scripts optager hovedtråden og forøger inputforsinkelsen og behandlingsvarigheden. Render-blokerende tags i head-teksten rammer i stedet LCP, og sent injicerede bannere eller widgets rammer CLS.
Skal jeg selv hoste tredjepartsscripts? Nogle gange, men det er en byttehandel. Selvhostede kopier stopper med at modtage ændringer til leverandør-API'en og sikkerhedsrettelser, indtil du opdaterer dem manuelt, hvilket web.dev markerer som en indtægts- og sikkerhedsrisiko.
Hvad skal jeg sigte efter? Ved den 75. percentil af reelle sideindlæsninger: LCP på eller under 2.5 sekunder, INP på eller under 200 millisekunder, CLS på eller under 0.1.
Har jeg brug for Googles samtykketilstand, hvis min trafik primært er tyrkisk? Googles krav om samtykkesignal i EØS gælder ikke for tyrkisk trafik, men det gør KVKK's cookieregler, så du har stadig brug for en fungerende samtykkemekanisme. Det, der ændrer sig, er, at du er friere til at vælge den hurtigere basisimplementering for det pågældende segment.
Hvor ofte skal dette scores igen? Kvartalsvis for den fulde beholdning og ved enhver udgivelse, der tilføjer en leverandør. Tag-stakke vokser igen: Webalmanacens år-til-år-tal viser, at antallet af tredjepartsanmodninger stiger.
Hvad gør jeg, når tag-ejeren nægter? Send partituret og båndet, ikke argumentet. Rubrikken eksisterer, så samtalen handler om et tal og en navngiven handling snarere end hvis prioritet vinder.
Hvis dine betalings- eller listesider ikke viser Core Web Vitals, og du ikke kan sige, hvilken leverandør der er ansvarlig, så kør denne rubrik på din egen stak – eller få os til at køre den med feltdata og en prioriteret backlog. Switas web performance-tjenester.
Kilder
- Tredjeparter — 2025 Webalmanak, HTTP-arkiv
- Web Vitals — web.dev
- Interaktion med Next Paint (INP) — web.dev
- Indlæser tredjeparts JavaScript — web.dev
- Den forretningsmæssige effekt af Core Web Vitals — web.dev casestudier
- Introduktion til serverside-tagging — Google Tag Platform
- Send data til en servercontainer — Google Tag Platform
- Koncepter for samtykketilstand — Google Tag Platform
- Opdateringer til samtykketilstand for EØS-trafik – Hjælp til Google Ads
- KVKK Çerez Rehberi compliance roadmap — Mondaq (analyse af Myndighedens 61-siders vejledning; kvkk.gov.tr var ikke tilgængelig på tidspunktet for skrivningen)
