Artikel

Scripts og SEO — Render-blocking JavaScript og performance

Scripts i HTML head blokerer rendering — async og defer attributes løser problemet og forbedrer Core Web Vitals.

Sidst opdateret:

Hvad er render-blocking scripts?

Når browseren parser HTML og støder på et <script>-tag, stopper den parsing og rendering af siden mens scriptet downloades og eksekveres. Dette kaldes render-blocking — siden er fuldstændig sat på pause.

For besøgende og Googlebot betyder render-blocking scripts at intet synligt indhold vises, mens scriptet behandles. Et 300 KB JavaScript-script der loader fra en langsom server kan forsinke First Contentful Paint med adskillige sekunder.

Standard script-tag — det problematiske

<head>
  <script src="/analytics.js"></script>
  <!-- Siden stopper her indtil analytics.js er downloadet og kørt -->
</head>

Browseren downloader og eksekverer analytics.js synkront. Alt andet venter.

async — asynkron downloading og eksekvering

<script src="/analytics.js" async></script>

Med async downloades scriptet parallelt med HTML-parsing. Men så snart download er færdigt, stopper parsing og scriptet eksekveres straks.

Egnet til: scripts der ikke afhænger af DOM eller andre scripts — f.eks. analytics, annonce-scripts, A/B-test-tools.

Ikke egnet til: scripts der afhænger af hinanden (rækkefølge ikke garanteret) eller scripts der manipulerer DOM under indlæsning.

defer — udskudt eksekvering

<script src="/main.js" defer></script>

Med defer downloades scriptet parallelt med HTML-parsing ligesom async, men eksekvering udskydes til HTML er færdigparsed og DOM er klar. Scripts med defer eksekveres i den rækkefølge de er defineret i HTML.

Egnet til: de fleste scripts der manipulerer DOM, scripts der afhænger af hinanden, scripts der ikke behøver køre under sideindlæsning.

Tommelfingerregel: Brug defer som standard for dine egne scripts, async til tredjeparts analytics.

Placering i HTML — head vs body-bund

Den traditionelle løsning inden async og defer eksisterede var at placere scripts i bunden af <body>:

<body>
  <!-- alt sideindhold -->
  <script src="/main.js"></script>
</body>

Dette virker fortsat og forhindrer render-blocking, men defer i <head> er nu den foretrukne løsning — det starter download-processen tidligere.

Third-party scripts og performance

Third-party scripts er den største enkelt-kilde til render-blocking problemer:

  • Analytics (Google Analytics, Matomo)
  • Tag managers (Google Tag Manager)
  • Chat-widgets
  • Sociale medie-widgets
  • A/B-testing-platforme
  • Reklame-scripts

Hvert third-party script er et ekstra DNS-opslag, TCP-forbindelse og download fra en ekstern server. En side med 15-20 third-party scripts i head kan have op til 2-3 sekunders ekstra indlæsningstid.

Strategi for third-party scripts:

  1. Brug async eller defer på alle third-party scripts
  2. Fjern scripts du ikke bruger aktivt
  3. Overvej Google Tag Manager som central indlæser
  4. Brug <link rel="preconnect"> til at fremskynde DNS og forbindelser til tredjeparter

Google Tag Manager og SEO

GTM er et tag management system der loader scripts via sit eget script. Det giver central kontrol over scripts uden deployments, men GTM-scriptet selv bør loades asynkront:

<!-- GTM bør loades i head med async -->
<script async src="https://www.googletagmanager.com/gtm.js?id=GTM-XXXX"></script>

Scripts injiceret via GTM eksekveres efter GTM er loadet. Kritiske scripts (f.eks. consent management) bør ikke afhænge af GTM.

Kritiske scripts vs nice-to-have

Ikke alle scripts er skabt ens. Prioritér:

Kritiske scripts (skal loade hurtigt): core applikationslogik, polyfills der kræves for funktionalitet.

Vigtige scripts (kan defer): scripts der forbedrer oplevelse men ikke blokerer indhold.

Nice-to-have scripts (kan loades endnu senere): chat-widgets, sociale deling-knapper, ekstra analytics.

En nyttig strategi er lazy loading af scripts — loader dem kun når brugeren interagerer med siden eller scroller til det relevante element.

Hvad er forskellen på async og defer? Begge downloader parallelt. async eksekverer scriptet straks når download er færdigt (kan blokere parsing et øjeblik). defer eksekverer scriptet efter HTML er færdigparsed og i kildekodernes rækkefølge.

Skal jeg fjerne Google Analytics fra head? Google Analytics-scriptet bør loades med async — det er standard i GA4-installationsguiden. Det forhindrer at analytics-scriptet blokerer rendering.

Hvad påvirker scripts af Core Web Vitals? Render-blocking scripts forsinker LCP direkte. Tunge scripts der kører under brugerinteraktion kan øge INP. Scripts der ændrer layout kan forårsage CLS.

Sidst opdateret: marts 2026. Denne artikel er en del af Stegger.dk’s SEO-ordbog.

Del af: JavaScript og rendering — Scripts, DOM og CSR vs SSR →

Andre artikler i samme emne

Relaterede begreber

Emne JavaScript og rendering — Scripts, DOM og CSR vs SSR JavaScript er SEOs største rendering-udfordring — forstå CSR vs SSR, DOM, lazy loading og hvad Googlebot faktisk ser. Artikel JavaScript — Hvad er JavaScript og hvad betyder det for SEO? JavaScript tilføjer interaktivitet — men JS-tunge sider kræver rendering, og det er SEOs største tekniske udfordring. Artikel DOM — Document Object Model og JavaScript-rendering DOM er browserens live-version af siden — JavaScript ændrer DOM dynamisk, og det er Googlebots endelige analyse-objekt efter rendering. Emne Web Performance — Core Web Vitals og teknisk hastighed Web performance er en direkte SEO-rankingfaktor — Core Web Vitals, hastighed og responsivt design påvirker din placering. Artikel Core Web Vitals — LCP, INP og CLS forklaret Core Web Vitals er Googles tre performance-signaler: LCP (hastighed), INP (interaktivitet) og CLS (layout-stabilitet) — alle er rankingfaktorer. Hovedguide Kode — Webkode og teknisk SEO Komplet guide til webkode og teknisk SEO — fra HTML-struktur og metadata til crawling, structured data og Core Web Vitals.

Placering i ordbogen

Kode — Webkode og teknisk SEO
JavaScript og rendering — Scripts, DOM og CSR vs SSR
Scripts og SEO — Render-blocking JavaScript og performance