Mer enn 90 % av sidene laster inn minst én tredjepartstjeneste, og de 1,000 mest brukte nettstedene har nå i median 106 tredjepartsforespørsler på mobil – 15 flere enn året før – ifølge HTTP-arkivets Nettalmanakk 2025Skript utgjør den største enkeltdelen av disse forespørslene med 24.8 %.
Nesten ingenting av det kom ved en avgjørelse. Det kom én tagg om gangen, og ingen eier totalsummen. Kostnaden er målbar: Googles casestudiebibliotek viser at Vodafone Italia forbedret LCP med 31 % og tok 8 % mer salg.
Denne veiledningen er for personen som blir bedt om å fikse Core Web Vitals og som ikke kan slette en markedsføringstag ensidig. Til slutt vil du ha en poengsum med fem kriterier for hver tredjepart på nettstedet ditt, en rutingsregel som gjør hver poengsum om til én spesifikk handling, og et forsvarlig tall for møtet der noen forsvarer taggen, noe som koster 380 ms.
Bygg opp inventaret før du scorer noe
Du trenger to lister; ingen av dem er komplette alene.
Containerlisten. Eksporter Google Tag Manager-beholderen din: tagger, utløsere og variabler med eierne og utløsningsbetingelsene deres. Dette er hensikten.
Nettverkslisten. Last inn siden i Chrome DevTools med hurtigbuffer deaktivert, kjør deretter Lighthouse og les revisjonen «Reduser virkningen av tredjepartskode». Dette er hva som faktisk kjøres, inkludert tagger injisert av andre tagger, som aldri vises i en containereksport.
For hver tredjepart på en av listene, registrer sju felt:
- Leverandøren og hva den påstår å gjøre
- Navngitt bedriftseier (en person, ikke en avdeling)
- Størrelse på skriptoverføring
- Blokkeringstid for hovedtråd som kan tilskrives den
- Om den ligger på den kritiske banen til LCP-elementet
- Hvilke sidemaler den utløses på
- Sist gang noen tok en avgjørelse ved hjelp av dataene deres
Det siste feltet er det folk hopper over, og det som lukker flest argumenter. Poengsum mot feltdata: Kjerneverdier for nett-viktigheter vurderes på 75. persentil av reelle sideinnlastinger, og en labkjøring på en rask tilkobling smigrer stacken din.
De fem poengkriteriene
Gi hver tredjepart 0–3 poeng på alle fem. Høyere totalpoeng betyr sterkere grunnlag for fjerning.
| Criterion | 0 poeng | 1 punkt | 2 poeng | 3 poeng |
|---|---|---|---|---|
| Kostnad for hovedtråd | Under 50 ms | 50–150 ms | 150–350 ms | Over 350 ms |
| Kritisk baneposisjon | Avfyres etter last, utenfor stien | Asynkron, ingen effekt på LCP | Forsinker LCP-elementet | Gjengivelsesblokkering i <head> |
| Demonstrert bruk | Tar en beslutning ukentlig | Kun månedlig rapportering | Noen åpner den hvert kvartal | Ingen navngitt bruk på 90 dager |
| Utskiftbarhet | Ingen erstatning finnes | Leverandør-SDK er det eneste alternativet | Fasade- eller latbelastning er mulig | Ekvivalenter på native, server-side eller førstepartsløsninger finnes |
| Samtykkeavhengighet | Strengt nødvendig, intet samtykke | Samtykke kreves, laster inn etter innvilgelse | Samtykke kreves, laster standardavslått | Samtykke kreves og porter andre tagger |
To overstyringer kommer i tillegg til totalen:
- En 3 på Demonstrert bruk av ruter for å drepe uavhengig av total. Ingen kostnad er verdt å betale for en tagg ingen bruker.
- En 3 på kritiske baneposisjonsruter til minst bånd 3. Et renderblokkerende skript i hodet er strukturelt, uansett hvor verdifull leverandøren er.
Rutebord
| Totalt | Handling | Avmelding nødvendig |
|---|---|---|
| 0-3 | Behold. Score på nytt om seks måneder. | none |
| 4-6 | Utsett eller lazy-load | Ingeniørarbeid |
| 7-9 | Erstatt med en fasade, eller last betinget etter rute, geografi eller samtykkestatus | Engineering plus-tag-eier |
| 10-12 | Flytt til serversiden, eller erstatt med en tilsvarende førstepart | Analytics-eier |
| 13-15 | Drep. Presenter poengsummen, ikke en mening. | Tag-eierens administrator |
Innenfor et bånd velger erstatningspoengsummen taktikken: en 3 der betyr at det finnes en tilsvarende løsning fra førstepart eller serverside, så velg den veien i stedet for båndets standard.
Signeringskolonnen er viktig fordi hvert band navngir én person. «Nettstedet er tregt på grunn av tagger» er en klage. «Denne taggen fikk 11 poeng, her er hvem som signerer den» er en bot.
Et praktisert eksempel
En sammensatt netthandelsbetaling i mellomklassen. Ikke kundedata; tallene er illustrerende.
| tag | Kostnad | Stilling | Bruk | Erstatt | Samtykke | Totalt | Rute |
|---|---|---|---|---|---|---|---|
| Live-chat-widget | 3 | 2 | 0 | 2 | 1 | 8 | Fasade: last inn ved klikk |
| Eldre varmekartverktøy | 2 | 1 | 3 | 3 | 2 | 11 | Drep (Bruk overstyring) |
| Konverteringstag for annonse | 1 | 1 | 0 | 3 | 2 | 7 | Flytt serverside (utskiftbarhet 3) |
| Plattform for samtykkehåndtering | 1 | 3 | 0 | 1 | 0 | 5 | Bånd 3 (Posisjonsoverstyring): overvåk blokkeringsatferden |
| Skriftleverandør | 1 | 2 | 0 | 3 | 0 | 6 | Selvvert og delsett (utskiftbarhet 3) |
Chat-widgeten er den instruksjonsrike raden. Den brukes virkelig og kan ikke erstattes, og den leder fortsatt til en fasade, fordi rubrikken skiller «trenger vi dette» fra «trenger vi det i løpet av de første 2.5 sekundene».
[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øsningene, rangert etter hvor ofte de faktisk fungerer
Fasader. Erstatt en innebygd funksjon med en statisk plassholder som laster den virkelige widgeten ved interaksjon. Chat-, video-, kart- og gjennomgangswidgeter er de vanlige gevinstene. Det er den mest effektive løsningen i de fleste revisjoner fordi den fjerner kostnadene uten å fjerne funksjonen, og det er derfor den overlever møtet.
Utsettelse. Nyttig, med forbehold. Chrome senker nettverksprioriteten of async og defer ressurser, slik at de lastes inn senere enn du forventer – greit for en piksel, ikke for noe som gjengis. web.dev bemerker også at innebygde elementer "kan blokkere window.onload hvis serverne deres reagerer sakte, selv om innebyggingen bruker asynkron eller utsettelse.» Utsettelse flytter kostnaden; den fjerner den ikke alltid.
Tagging på serversiden. Dette trenger en rettelse, fordi det selges som et sidehastighetsprodukt og ikke er et. Googles eget introduksjon til tagging på serversiden beskriver dataeierskap, forming og ruting – «bare du har tilgang til dataene på serveren inntil du velger å sende dem et annet sted» – og fremsetter ingen ytelseskrav. Nettleseren kjører fortsatt målekode og overfører fortsatt hendelser via bildepiksler, fetch, XHR eller en servicearbeider som betjenes av deg servercontainerdomene.
Det den kjøper er førstepartskontekst og kontroll over hva som forlater infrastrukturen din. Enhver hastighetsøkning er en bivirkning av leverandørskriptene du fjerner under migreringen. Hvis en leverandør lover en INP-forbedring kun fra serversidetagging, spør hvilket skript som slutter å lastes inn i nettleseren. Hvis svaret er ingen, er det ingen forbedring. INP består av inngangsforsinkelse, behandlingsvarighet og presentasjonsforsinkelse, og skript blåser opp de to første ved å okkupere hovedtråden. Endre hvor en forespørsel er sendt påvirker ingen av delene.
Der samtykkelaget endrer aritmetikken
Samtykkehåndteringsplattformen din er vanligvis det elementet med høyest poengsum i inventaret: det sitter i hodet, det er renderblokkerende i sin design, og alle andre tagger venter på det. Poengsett det som alt annet.
Bestem deg deretter for hvilken samtykkemodus du kjører, fordi de to har forskjellige ytelsesprofiler. I Googles ordelag, grunnleggende samtykkemodus betyr at tagger er «blokkert inntil brukerinteraksjon med et samtykkebanner», mens avansert modus «lastes inn med standardinnstillinger satt til denied" og sender informasjonskapselfrie målinger før samtykke. Basic er raskere ved første innlasting. Det koster deg også data: Googles EØS-veiledning advarer om at hvis du forhindrer at tagger lastes inn før bannerinteraksjon, «vil ikke Google kunne bekrefte brukerens samtykkevalg, og dette kan føre til tap av data».
Her fortjener en regional detalj sin plass. Tyrkia er ikke i EØS, så Googles krav om samtykkesignal i EØS når ikke tyrkisk trafikk – men tyrkisk lov gjør det. KVKKs veiledning om informasjonskapsler behandler analyseinformasjonskapsler som å kreve eksplisitt samtykke snarere enn strengt nødvendige, krever at samtykkekategorier ikke er avkrysset som standard og at «Avvis alle» er like fremtredende som «Godta alle», og forbyr informasjonskapselvegger.
Den praktiske konsekvensen for en tyrkisk eller multimarkedsforhandler: kjør grunnleggende samtykkemodus på tyrkisk trafikk og avansert på EØS-trafikk, og du mister ingenting du hadde krav på i noen av markedene. De fleste CMP-er vil ikke gjøre dette med det samme. Det er en geografisk begrenset konfigurasjonsbeslutning, ikke en plugin.
Hva denne rubrikken ikke dekker
- Den scorer tagger, ikke sider. En tagg som er harmløs på hjemmesiden kan være ødeleggende på en oppføringsside som laster inn førti av dem.
- Hovedtrådkostnaden er ikke additiv. Å fjerne fem 100ms-tagger returnerer sjelden 500ms. Mål etter hver endring.
- Den ignorerer din egen kode. Lange oppgaver fra rammeverkhydrering er ofte den største andelen av en dårlig INP, og ingen tredjepartsrevisjon vil finne dem.
- Det gir deg bare kostnadssiden. En 380ms-tagg som genererer reell tilskrivbar inntekt kan være verdt å beholde.
- Den har ingen mening om sikkerhet eller datalagring, noen ganger den faktiske grunnen til at en leverandør bør gå.
- Piggyback-tagger skjules fra containereksport. Der de to listene er uenige, stol på nettverkslisten.
FAQ
Hvordan måler jeg hovedtrådkostnaden for én spesifikk tredjepart? Bruk ytelsespanelet i Chrome DevTools til å tilskrive lange oppgaver til skriptopprinnelse, og kryssjekk med Lighthouse-revisjonen «Reduser virkningen av tredjepartskode». Bekreft mot feltdata, fordi en laboratoriekjøring undervurderer den reelle kostnaden.
Forbedrer serversidetagging Core Web Vitals? Ikke alene. Googles dokumentasjon for tagging på serversiden beskriver datakontroll og ruting, ikke sidehastighet, og nettleseren laster fortsatt inn målekode og overfører hendelser. Enhver forbedring kommer fra leverandørskript du fjerner fra siden som en del av migreringen.
Hvilken Core Web Vital skader tredjeparter mest? Vanligvis INP, fordi skript opptar hovedtråden og øker inputforsinkelsen og behandlingsvarigheten. Renderblokkerende tagger i head-vinduet treffer LCP i stedet, og sent injiserte bannere eller widgeter treffer CLS.
Bør jeg hoste tredjepartsskript selv? Noen ganger, men det er en byttehandel. Selvhostede kopier slutter å motta endringer i leverandør-API-et og sikkerhetsrettelser før du oppdaterer dem manuelt, noe web.dev flagger som en inntekts- og sikkerhetsrisiko.
Hva bør jeg sikte mot? Ved den 75. persentilen av reelle sideinnlastinger: LCP på eller under 2.5 sekunder, INP på eller under 200 millisekunder, CLS på eller under 0.1.
Trenger jeg Googles samtykkemodus hvis trafikken min hovedsakelig er tyrkisk? Googles krav om samtykkesignal i EØS-området gjelder ikke for tyrkisk trafikk, men KVKKs regler for informasjonskapsler gjør det, så du trenger fortsatt en fungerende samtykkemekanisme. Det som endres er at du står fritt til å velge den raskere basisimplementeringen for det segmentet.
Hvor ofte bør dette scores på nytt? Kvartalsvis for hele beholdningen, og ved enhver utgivelse som legger til en leverandør. Tagstabler vokser på nytt: Web Almanacs tall fra år til år viser at antall tredjepartsforespørsler øker.
Hva gjør jeg når tag-eieren nekter? Send partituret og bandet, ikke argumentet. Rubrikken eksisterer, slik at samtalen handler om et tall og en navngitt handling, snarere enn hvis prioritet vinner.
Hvis betalingssidene eller oppføringssidene dine ikke viser Core Web Vitals, og du ikke kan si hvilken leverandør som er ansvarlig, kan du kjøre denne rubrikken på din egen stakk – eller få oss til å kjøre den, med feltdata og en prioritert ordrebeholdning, gjennom Switas webytelsestjenester.
Kilder
- Tredjeparter — 2025 Web Almanac, HTTP-arkiv
- Nett-vitaliteter — web.dev
- Interaksjon med neste maling (INP) — web.dev
- Laster inn tredjeparts JavaScript — web.dev
- Den forretningsmessige effekten av Core Web Vitals – casestudier fra web.dev
- Introduksjon til tagging på serversiden – Google Tag-plattformen
- Send data til en serverbeholder – Google Tag Platform
- Konsepter for samtykkemodus – Google Tag-plattformen
- Oppdateringer av samtykkemodus for EØS-trafikk – Google Ads Hjelp
- KVKK Çerez Rehberi samsvarsplan – Mondaq (analyse av myndighetens 61-siders veiledning; kvkk.gov.tr var ikke tilgjengelig i skrivende stund)
