Fjern eller udsæt tunge tredjeparts scripts uden at ødelægge funktionalitet

Tredjeparts scripts er typisk ikke i jeres build-pipeline: de tilføjes i tag manager, CMS-plugins eller af leverandører. Alligevel betaler brugerne prisen i LCP, INP og ofte CLS. Denne guide hjælper dig med at kortlægge, vurdere og reducere belastningen uden at slukke for kritiske funktioner.

Hvornår er den relevant? Når waterfall viser mange ukendte domæner, når INP er dårlig på sider med mange tags, eller når du ved at marketing har tilføjet «bare ét script» hver måned i tre år.

Hvornår denne guide er relevant

Tegn på at tredjepart er et problem

Høj INP efter klik, mange lange tasks i Performance, langsom første visning med tredjeparts kø i toppen af waterfall.

Hvilke sider og typer sites der ofte rammes

Content-sider med mange marketing-tags, webshops med chat og tracking, SaaS med session replay.

Det skal du have klar før du går i gang

Adgang til DevTools eller lignende

Du skal kunne se netværk, kilder og performance-profiler.

Liste over installerede tags, widgets og embeds

Eksporter fra tag manager, eller lav en manuel liste med ejer.

Én side eller template at teste på

Start med en højtrafik-side - fx forsiden eller en kampagne-side.

Den hurtige prioritering (så du ikke drukner i en lang liste)

Når du har en liste over scripts, er næste skridt at score dem ud fra to akser:

• Impact: påvirker det LCP/INP/CLS mærkbart (tidligt netværk, main thread, layout)?
• Timing-krav: skal det køre før første visning, eller kan det vente?

En praktisk klassificering der virker i praksis:

• A: Kritisk tidligt: få scripts (typisk consent + evt. én nødvendig integration). Skal være små og stabile.
• B: Kan udsættes: analytics, heatmaps, A/B, session replay, chat – typisk efter samtykke og/eller efter første interaktion.
• C: Kun på udvalgte sider: pixels der kun giver mening på kampagne, embeds på blog, etc.
• D: Kandidat til fjernelse: ingen ejer, ingen måler, eller duplikat funktionalitet.

Trin 1: Kortlæg alle tredjeparts scripts

Find dem i kildekode og netværk

Filtrér i Network på «third-party» domæner, og brug initiator til at se hvad der trækker hvad ind.

Del dem op efter funktion

Marketing, analytics, support, compliance, sociale embeds - forskellige ejere og forskellige krav til timing.

Tip: “ejer” er et teknisk krav

Hvis ingen kan sige hvorfor scriptet findes, hvilke events det skal sende, og hvem der opdager når det fejler, så er det et stærkt signal om at det bør fjernes eller flyttes ud af critical path.

Trin 2: Find de scripts der loader tidligt

Hvilke scripts starter før første visning

Disse påvirker ofte LCP og FCP - de konkurrerer med jeres eget indhold.

Hvilke scripts blokerer eller konkurrerer med kritiske ressourcer

Se på prioritet og rækkefølge i waterfall. Kombinér med render-blocking guide hvis jeres egne CSS/JS også er problemet.

Konkrete ting du kan kigge efter i Network

• mange requests til tredjepart før document/CSS er “i gang”
• tidlige downloads af store JS bundles fra tracking-domæner
• redirects (301/302) før den endelige script-URL (spildte round-trips)

Trin 3: Find dem der belaster main thread

Lange tasks

Åbn Performance, optag mens du udfører et realistisk klik. Se find lange tasks i DevTools.

Tunge event handlers

Tredjepart kan registrere listeners der kører samtidig med jeres.

Sen interaktion

Nogle scripts vågner først efter idle - de kan stadig give dårlig INP hvis de kolliderer med brugerflow.

Konkrete ting du kan kigge efter i Performance

• lange tasks lige efter klik (banner/checkout/menu)
• mange event listeners fra samme tredjeparts kilde
• parsing/evaluation der fylder mere end jeres egen kode på mobile profiler

Trin 4: Vurder om de er nødvendige

Forretning, funktion og konvertering

Hvis scriptet ikke understøtter et mål nogen måler på, er det et kandidat til at gå.

Ting der kun bruges af vane

«Vi har altid haft det pixel» er ikke en strategi.

Ting der kan erstattes

Lettere SDK, server-side tagging, eller færre duplikerede værktøjer.

Trin 5: Udsæt, begræns eller fjern

Kun på bestemte sider

Tag manager-regler: load kun på blog, ikke på checkout.

Klik før load

Chat og video kan ofte vente til brugerhandling.

Eksempel på “click-to-load” princip:

• vis en let placeholder
• load widget først når brugeren klikker
• og lad resten af siden være fri af widget-JS indtil da

Delay eller lazy loading af scripts

Indlæs efter load eller requestIdleCallback hvor det er sikkert.

Fjern helt

Når ingen ejer det, eller det er duplikat.

Trin 6: Test igen

Før og efter målinger

Samme URL, samme hardware-profil, samme netværksprofil.

Hvad du skal holde øje med

LCP, INP, CLS, og om funktioner stadig virker (tracking, chat, consent).

Sådan kontrollerer du at optimeringen er “rigtig” (ikke kun mindre JS)

1. Før/efter waterfall
   • færre tredjeparts requests før første visning
   • LCP-ressourcen starter ikke senere pga. nye konkurrencer
2. Før/efter Performance trace
   • færre/lavere long tasks omkring kritiske interaktioner
3. Funktionalitet
   • consent gating virker (intet marketing før accept)
   • events sendes stadig (test i staging og produktion)
4. Holdbarhed
   • dokumentér ejere og timing-krav, ellers kommer problemet igen næste måned

Typiske fejl

Alt loader overalt

Scope er gratis performance.

Ingen ejer scripts

Så vokser listen uden kontrol.

Nye tags kommer på uden test

Kræv måling som gate ved nye tredjeparts integrationer.

Checkliste før du lukker opgaven

• Kritiske scripts er bevaret og dokumenteret
• Unødige scripts er væk eller udsat
• Brugerflows og tracking er verificeret på staging og produktion

Afslutning

• Kortlæg, prioriter tidlige og tunge scripts, vurder ejerskab, udsæt eller fjern, mål igen.

Læs baggrunden i tredjeparts scripts og hastighed og fortsæt med INP og JavaScript. Waterfall-forståelse: sådan læser du en waterfall.

Relaterede guides

Sådan finder du lange tasks i DevTools og forbedrer INP

2026-03-25

Lær hvordan du bruger DevTools til at finde lange tasks, tunge event handlers og JavaScript der gør siden træg at bruge.

Optimer cookie banner uden CLS og INP problemer

2026-03-24

Lær hvordan du bygger eller justerer cookie bannere, så de ikke skubber indhold, blokerer interaktion eller gør siden tungere end nødvendigt.

Forbedr INP ved at reducere JavaScript og lange tasks

2026-03-05

Få bedre interaktivitet ved at trimme JavaScript, splitte bundles og fjerne lange tasks, der gør siden langsom at bruge.

Undgå CLS fra fonts: font-display, preload og stabile fallbacks

2026-03-30

Lær at undgå layout-hop (CLS) fra webfonts med font-display, fallback-strategi og korrekt preload. Guiden er til dig der vil have pæn typografi uden at ødelægge stabilitet.

Sådan fejlsøger du LCP fra start til slut

2026-03-27

Følg en praktisk arbejdsgang til at finde årsagen til høj LCP, fra serverrespons og render blocking til billeder, prioritering og netværksrækkefølge.

Fix CLS: sådan gør du layout stabilt uden hop i indholdet

2026-02-20

Lær hvordan du reducerer CLS med faste dimensioner, aspect ratio, stabile embeds og korrekt font loading, så siden ikke hopper under indlæsning.

FAQ

Kan jeg udsætte alle tredjeparts scripts?

Nej. Nogle scripts har lovmæssige eller forretningsmæssige krav om at køre ved bestemte tidspunkter. Udsæt det der kan, og dokumentér undtagelser.

Hvordan ved jeg om et script er vigtigt?

Find ejeren i organisationen, og spørg hvilke rapporter eller flows der afhænger af det. Hvis ingen kan forklare det, er det en stærk kandidat til fjernelse eller test på staging.

Hvor meget kan tredjepart egentlig betyde?

Meget. Et enkelt tungt script kan dominere INP på mobil, eller udskyde LCP hvis det konkurrerer om netværk og CPU tidligt. Effekten skal måles, ikke gættes.

Næste skridt efter guiden

Brug emnesider, ordbog og blog til at validere og uddybe næste ændring.

Se relaterede emnerLæs forklarende blogindlægTjek begreber i ordbogSe hele ordbogen (A–Å)