Dansk hosting fra Aalborg
Servere i Europa
24/7/365 dansk support
[email protected]
Performance og cache 7 min. læsning Opdateret 3. oktober 2026

Tredjepartsscripts: GTM, chat og tracking, der koster hastighed

Tredjeparts scripts som GTM, chat og pixels koster hastighed og INP. Gør status, mål omkostningen pr. script – og behold marketings tal.

Tredjepartsscripts: GTM, chat og tracking, der koster hastighed

Kort svar: GTM, chat-widgets, tracking-pixels og videoafspillere er ofte sidens tungeste JavaScript – og de bor uden for din kontrol. Opskriften: (1) gør status – mange scripts overlever deres formål, (2) mål hvad hvert script koster i CPU-tid, (3) indlæs det, der skal blive, så sent og så målrettet som muligt, og (4) genmål INP – det er typisk dét tal, tredjepartsscripts ødelægger.

Fagligt gennemgået: 2. oktober 2026

Du kan optimere billeder og cache til perfektion – og stadig have en side, der føles træg, fordi et chat-script og tre tracking-pixels slås om hovedtråden. Tredjepartsscripts er en af de hyppigste forklaringer på „vi har gjort alt, og INP er stadig dårlig“. Det gør dem ikke forbudte – men det gør dem til noget, man budgetterer, ikke bare tilføjer.

Guiden tager dig gennem fire trin: status, måling, klogere indlæsning og oprydning i Google Tag Manager. Til sidst kommer en tjekliste til verifikation, så marketing stadig får deres tal.

Før du ændrer noget: Aftal med den, der ejer marketing og analytics, hvilke målinger der skal blive, før du fjerner eller udskyder noget. Lav ændringerne på staging eller én ad gangen på live-sitet, og notér hvad du har ændret, så du kan rulle tilbage, hvis en konvertering forsvinder.

Hvorfor tredjepartsscripts koster så meget

Et tredjepartsscript koster på tre måder. Først skal browseren slå et nyt domæne op og oprette en forbindelse. Derefter skal filen hentes – ofte efterfulgt af flere filer, som scriptet selv henter. Og til sidst skal JavaScriptet køres på browserens hovedtråd, som også skal reagere på klik, tryk og tastetryk. Det er den sidste del, der gør ondt: Mens et script kører en lang opgave, kan siden ikke reagere, og det måles som dårlig INP.

Du styrer heller ikke, hvad scriptet gør i morgen. Udbyderen kan opdatere koden, tilføje nye funktioner eller hente flere filer, uden at du ændrer noget på dit site. Derfor er tredjepartsscripts noget, du skal se på løbende – ikke kun én gang.

1. Gør status

Åbn Netværk-fanen i browserens udviklerværktøjer, genindlæs siden, og filtrér på domæner, der ikke er dine egne. Skriv listen ned: analytics, pixels, chat, heatmaps, A/B-test, video, fonte og anmeldelses-widgets. Spørg for hvert enkelt: Bruger nogen dataene?

Typiske fund er en heatmap-tracker fra et afsluttet projekt, to konkurrerende analyseværktøjer og en chat, ingen besvarer. Alt, der ikke kan forsvares med et navn og et formål, ryger – det er gratis hastighed:

Genskabt eksempel: statusliste over tredjepartsscripts med vægt og beslutning
Genskabt eksempel med illustrative tal, 30. august 2026: fem scripts, 1,1 MB – og to af dem uden ejer. Eksemplet er ikke data fra hostious.io.

En simpel statustabel gør beslutningerne lettere. Udfyld den for hvert script:

ScriptFormålEjerSiderBeslutning
—————
fx analyticsTrafik og konverteringerMarketingAlleBehold, indlæs efter samtykke
fx chat-widgetKundeserviceSupportKontakt og produktsiderBehold som facade
fx heatmapGammelt projektIngenAlleFjern

Kig også efter scripts, der indlæses af plugins uden for GTM. Mange WordPress-plugins tilføjer deres egne tredjepartsscripts på alle sider, selvom de kun bruges ét sted.

2. Mål omkostningen

Vægt i KB er kun halvdelen – den dyre halvdel er CPU-tid på hovedtråden, som blokerer sidens reaktioner og dermed INP. Mål i udviklerværktøjernes Performance-fane: Optag en indlæsning med CPU-throttling slået til, så den ligner en almindelig mobiltelefon, og se, hvilke scripts der står bag de lange opgaver. Lighthouse og PageSpeed Insights viser også tredjepartskode i et særskilt afsnit; navnet har skiftet mellem versioner.

Den mest direkte test er at blokere scriptet og måle igen. Udviklerværktøjerne har en funktion til at blokere enkelte request-URL’er eller hele domæner. Bloker ét script ad gangen, optag en ny indlæsning, og sammenlign. Nu kan du sætte pris på hvert script og tage beslutninger på data: En chat, der skaber lange opgaver på mobil, skal enten lades være eller først indlæses ved behov.

Husk, at labtests kun viser én indlæsning på én enhed. Den endelige dom over INP kommer fra feltdata – se forskellen på PageSpeed Insights og CrUX.

3. Indlæs klogere

  • Udskyd til efter indlæsning: Tracking og analytics behøver ikke blokere renderingen. Cache-pluginets delay-funktion udskyder dem til første interaktion; fælderne står i delay-guiden.
  • Brug async eller defer: Scripts, der indsættes direkte i temaet, skal have async eller defer, så de ikke stopper HTML-parseren. defer bevarer rækkefølgen og kører efter parsing; async kører, så snart filen er hentet.
  • Indlæs ved behov (facade): Vis en let attrap – et chat-ikon, et video-thumbnail – og hent først det rigtige script ved klik. Det er standardtricket for chat og YouTube-embeds.
  • Afgræns til relevante sider: Konverterings-pixels hører til på købssider – ikke på alle artikler. Både GTM-triggere og plugins kan styre det pr. side.
  • Selvhost det små: Få, små scripts og fonte kan hentes hjem og serveres fra eget domæne – færre forbindelser og bedre cache-kontrol. Det er ikke muligt for de fleste store trackere, som opdaterer sig selv.
  • Forbind tidligt til det nødvendige: Et script, der skal bruges tidligt, kan få en preconnect til sit domæne, så forbindelsen er klar. Brug det sparsomt – se guiden om preload og preconnect.

Værktøjer, der flytter tredjepartsscripts over i en web worker, findes også, men de kræver test af hvert enkelt script og er sjældent første skridt på et almindeligt WordPress-site.

4. Ryd op i Google Tag Manager

Google Tag Manager er ikke selv problemet – det er containeren, der vokser: gamle tags, dublerede triggers og „lige et hurtigt script“ fra tidligere kampagner. Ryd op i containeren med samme spørgsmål som i trin 1, og genovervej, om alle tags skal fyre på alle sider.

En god oprydning i GTM følger typisk denne rækkefølge:

  1. Eksportér containeren som backup, før du ændrer noget.
  2. Sæt tags på pause frem for at slette dem, så du kan genaktivere dem.
  3. Fjern dubletter, fx to tags der sender samme sidevisning.
  4. Skift brede „All Pages“-triggere ud med triggere for de sider, hvor tagget faktisk bruges.
  5. Test i forhåndsvisningstilstand, og udgiv en ny version med en beskrivende note.

På danske sites med samtykkebanner skal scripts, der sætter cookies eller sender persondata til markedsføring, først indlæses efter samtykke. Det er et juridisk krav og samtidig en hastighedsgevinst for de besøgende, der takker nej. Bruger du Googles annonceværktøjer, skal samtykket også sendes videre via Googles Consent Mode. Læs mere i guiden om cookiebannere.

Sådan verificerer du

Oprydningen er målbar, når:

  • listen over tredjepartsdomæner er kort og navngiven, og hvert script har ejer og formål;
  • Lighthouse’ afsnit om tredjepartskode er skåret mærkbart ned;
  • INP i feltdata forbedres over de følgende uger;
  • marketing stadig får deres tal.

Den sidste del er vigtig: Verificér i analytics og annonceplatformene, at målingerne stadig kommer ind efter ændringer i delay og samtykke. Gør listen til et kvartalsritual – scripts formerer sig stille.

Læs også

Ofte stillede spørgsmål om tredjepartsscripts

Hvor mange scripts er „for mange“?

Der findes intet magisk tal – kun budgettet: hvad koster de tilsammen på mobil, og er INP stadig grøn? Fem veldrevne scripts kan være fint; ét dårligt kan vælte målingen alene.

Kan jeg bare delaye alle scripts?

Nej – samtykkebanner, betalingsscripts og funktionel kode skal køre pålideligt fra start. Delay er til måling og pynt; funktion og jura undtages. Og test altid efter: delay-fejl viser sig som døde menuer og manglende målinger.

Flytter server-side tracking problemet?

Delvist – server-side GTM flytter dele af arbejdet væk fra browseren og kan give renere data, men kræver opsætning, en server og løbende drift. For de fleste danske SMV-sites giver oprydning og klog indlæsning det meste af gevinsten med langt mindre arbejde.

Hvordan finder jeg ud af, hvilket script der gør siden langsom?

Bloker scriptene ét ad gangen i browserens udviklerværktøjer, og optag en ny indlæsning i Performance-fanen. Det script, der fjerner flest lange opgaver, når det er blokeret, er det, du skal tage fat på først.

Skrevet af Marc, stifter af Hostious

Jeg hedder Marc og har stiftet Hostious. Vi hoster WordPress-hjemmesider og WooCommerce-webshops for danske virksomheder – drevet fra Aalborg-området med servere i Europa – og jeg skriver guiderne her ud fra det, vi ser i driften hver dag.

Udgivet 30. august 2026Opdateret 3. oktober 2026Fagligt gennemgået 2. oktober 2026

Samme emne

Fortsæt med emnet

Alle guides: Performance og cache