Syv av ti nettsteder som stryker på PageSpeed Insights, bremses av tredjeparts JavaScript. Eksterne skript, analyseverktøy, annonsenettverk, chat, fonter, cookie-bannere blokkerer renderingen og skyver First Contentful Paint bakover med sekunder. Og du kan ikke skru dem av: analyseverktøy gir data til markedsføring, chat gir leads, uten cookie-banner består ikke nettstedet en revisjon.

Det finnes en løsning: lazy loading. Skriptet lastes først når hovedinnholdet allerede er vist for brukeren. Nettleseren venter ikke, Core Web Vitals-målingene går i grønn sone, og funksjonaliteten på nettstedet lider ikke.

Vi har samlet alle fungerende metoder, fra innebygde HTML-attributter til programmatiske teknikker og WordPress-plugins. Med kodeeksempler du kan kopiere og bruke i dag.

💡 Rask oversikt:

• Forstå defer og async: tabellen viser tydelig forskjellen mellom attributtene
• Mestre programmatisk lasting ved load-hendelsen: en moderne versjon av Patrick Sextons metode
• Sett opp Intersection Observer for skript under folden: chat, kart, kommentarer
• Optimaliser WordPress uten å redigere kode: pluginene Flying Scripts og Asset CleanUp

Hvordan tredjepartsskript bremser innlastingen

Nettleseren analyserer HTML fra topp til bunn. Når den møter <script src="..."> uten attributter, stopper analysen: nettleseren laster skriptet, kjører det, og først deretter fortsetter den å analysere siden. Dette er render-blokkerende.

For brukeren er resultatet en hvit skjerm. Målingen First Contentful Paint (FCP), tiden frem til det første innholdet vises, avhenger direkte av hvor raskt nettleseren kom seg gjennom alle blokkerende skript. FCP er en del av Core Web Vitals og påvirker søkerangeringen direkte.

Tredjepartsskript rammer hardere enn dine egne: de ligger på eksterne servere, og du kontrollerer ikke leveringshastigheten eller tilgjengeligheten deres. DNS-oppslag, TCP-håndtrykk, TLS-håndtrykk, nedlasting, hvert trinn legger til titalls eller hundrevis av millisekunder. Ifølge data fra HTTP Archive for 2024 laster median-nettstedet på mobile enheter 21 eksterne skript, og tre av dem er blokkerende.

Løsningen er å gi nettleseren en tydelig beskjed: «last skriptet i bakgrunnen og kjør det senere.» Det er nettopp det attributtene defer og async er laget for.

Defer og async: to innebygde mekanismer

Begge attributtene skrives i <script>-taggen og endrer lasteatferden. På fundamentalt forskjellige måter.

Defer: utsatt kjøring med rekkefølgegaranti

Attributtet defer forteller nettleseren: «last skriptet i bakgrunnen, kjør etter full HTML-analyse.» Kjørekkefølgen bevares, skriptene kjøres i nøyaktig den rekkefølgen som er angitt i markupen.

1
<script src="https://example.com/analytics.js" defer></script>
2
<script src="https://example.com/chat-widget.js" defer></script>

Det ideelle valget for skript som må kjøres i en bestemt rekkefølge: bibliotek, så dets plugin, så initialisering. defer garanterer at DOM-en er klar når kjøringen skjer. Hendelsen DOMContentLoaded utløses etter alle defer-skript.

Async: fullstendig uavhengighet

async laster skriptet parallelt med analysen og kjører det umiddelbart etter lasting, uten å vente på andre. Rekkefølgen er ikke garantert: det skriptet som lastes først fra serveren, kjøres først.

1
<script src="https://example.com/independent-widget.js" async></script>

Egnet for helt uavhengige skript: besøkstellere, sosiale medier-knapper, annonsebannere. Hvis skriptet ikke er avhengig av DOM-en og ikke avhenger av andre skript, bruk async.

Viktig nyanse: et async-skript kan kjøres før DOM-en er bygget. Hvis det refererer til sideelementer som ikke finnes ennå, får du null og en feil i konsollet. Sjekk alltid.

Programmatisk lasting ved load-hendelsen: Patrick Sextons metode

Hva om skriptet ikke støtter defer/async, eller du ikke kontrollerer markupen? For eksempel at skriptet settes inn via Google Tag Manager eller er hardkodet i en tredjeparts plugin. Da kommer den programmatiske metoden til unnsetning.

Ideen er enkel: opprett et <script>-element via JavaScript og legg det til i DOM-en først etter at siden er ferdig lastet. Forfatteren av tilnærmingen, Patrick Sexton, beskrev teknikken først på varvy.com.

Den moderne versjonen av denne koden:

1
function loadScriptOnPageLoad(src) {
2
  const script = document.createElement('script');
3
  script.src = src;
4
  script.async = false;
5
  document.body.appendChild(script);
6
}
7
 
8
window.addEventListener('load', () => {
9
  loadScriptOnPageLoad('/wp-content/plugins/chat/chat.js');
10
  loadScriptOnPageLoad('/wp-content/plugins/analytics/tracker.js');
11
});

To viktige forskjeller fra tiår gammel kode. For det første: vi lytter til load, ikke DOMContentLoaded. Hendelsen load inntreffer senere, når alle bilder, stiler og fonter er lastet. Et utsatt skript er garantert å ikke påvirke FCP eller LCP. For det andre: ingen window.attachEvent. Denne metoden var bare nødvendig for Internet Explorer 8 og eldre, som ikke lenger eksisterer. Moderne addEventListener fungerer i alle aktuelle nettlesere.

Tre situasjoner der den programmatiske tilnærmingen er uerstattelig

defer og async fungerer bare for <script>-tagger som er skrevet direkte i HTML. Den programmatiske metoden redder deg når:

• Skriptet settes inn via Google Tag Manager eller en annen tag manager, du ser ikke oppmerkingen.
• Du kan ikke redigere malen: en plugin eller et tema fra noen andre med en rigid struktur.
• Du trenger betinget innlasting: for eksempel et kontaktskjemaskript bare på sider med et skjema.

Intersection Observer: lasting ved behov

For enkelte skript er til og med defer for tidlig. En chat-widget trengs ikke før brukeren ruller til bunnteksten. Et kart, ikke før de når adresseblokken. Kommentarer, ikke før de leser seg ned til diskusjonsdelen.

Intersection Observer API løser akkurat denne oppgaven: skriptet lastes bare når målelementet dukker opp i visningsområdet.

1
const chatTarget = document.getElementById('chat-container');
2
 
3
if (chatTarget) {
4
  const observer = new IntersectionObserver((entries) => {
5
    entries.forEach((entry) => {
6
      if (entry.isIntersecting) {
7
        const script = document.createElement('script');
8
        script.src = '/wp-content/plugins/chat/chat.js';
9
        document.body.appendChild(script);
10
        observer.unobserve(entry.target);
11
      }
12
    });
13
  }, { rootMargin: '200px' });
14
 
15
  observer.observe(chatTarget);
16
}

Parameteren rootMargin: '200px' laster skriptet 200 piksler før elementet vises på skjermen, slik at brukeren ikke merker noen forsinkelse. Tidligere brukte utviklere scroll-lyttere med getBoundingClientRect() i årevis, men disse fyrte av på hver eneste piksel av rullingen og overbelastet hovedtråden.

Intersection Observer jobber asynkront og legger nesten ingen belastning på nettleseren. Støtte finnes i alle moderne nettlesere, inkludert Safari fra versjon 12.1. IE11 støttes ikke, men andelen per juni 2026 nærmer seg statistisk feilmargin.

WordPress: lat lasting uten å redigere kode

Hvis nettstedet er på WordPress, kan du implementere lat lasting på tre måter, fra enklest til mest fleksibel.

Utvidelser for lat lasting av skript

To fungerende alternativer, testet på tusenvis av nettsteder.

Flying Scripts, en gratis utvidelse fra Gijo Varghese, 30 000+ aktive installasjoner, versjon 1.2.4 (oppdatert i mai 2026). Kan utsette JavaScript til første brukerinteraksjon: musebevegelse, klikk, rulling, berøring på mobil. Du angir nøkkelord fra skript-URL-en, og utvidelsen utsetter kjøringen. Det finnes en tidsavbrudd, hvis brukeren ikke interagerer med siden, kjøres skriptene etter en angitt tid. Maksimal metrisk gevinst, men chat eller tilbakeringingsskjema bør utelates fra utsettelse, de trengs umiddelbart.

WP Rocket, en premium caching-utvidelse med innebygd funksjonalitet for utsettelse av JavaScript-innlasting. Legger til defer eller async på utvalgte skript via administrasjonsgrensesnittet. Du angir URL-en, utvidelsen endrer attributtet når siden rendres. Passer for dem som allerede bruker WP Rocket til caching og ikke ønsker å multiplisere utvidelser.

Script_loader_tag-hook i functions.php

Hvis du ikke vil installere en egen utvidelse, tillater WordPress filtrering av <script>-tag-utdata gjennom script_loader_tag-hooken. Koden nedenfor legger til defer på alle skript unntatt jQuery og adminpanelet:

1
add_filter('script_loader_tag', function($tag, $handle) {
2
    if (is_admin()) {
3
        return $tag;
4
    }
5
    $skip = ['jquery', 'jquery-core', 'jquery-migrate'];
6
    if (in_array($handle, $skip, true)) {
7
        return $tag;
8
    }
9
    return str_replace(' src', ' defer src', $tag);
10
}, 10, 2);

Plasser koden i barnetemaets functions.php eller via Code Snippets-utvidelsen. Før du anvender, ta en sikkerhetskopi. defer på jQuery vil ødelegge enhver kode som kaller $() eller jQuery() før DOMContentLoaded. Start med enkeltskript, sjekk konsollen for feil etter hver endring.

Full kontroll: Asset CleanUp

Asset CleanUp, en gratis utvidelse (versjon 1.4.0.4, oppdatert i mai 2026) som viser ALLE skript og stiler som lastes på en side. Med størrelse og kilde angitt. Du kan deaktivere et spesifikt skript på en spesifikk side, endre innlastingsattributtet til defer/async, eller fullstendig avlaste en unødvendig ressurs.

Hovedfordelen sammenlignet med Flying Scripts: Asset CleanUp gir et komplett bilde for hver side. Du ser nøyaktig hva som lastes og tar beslutninger presist. Pro-versjonen legger til betinget innlasting etter skjermtype og flytting av skript mellom HEAD og BODY. Fungerer sammen med enhver caching-utvidelse, WP Rocket, W3 Total Cache, WP Fastest Cache.

Et dypdykk i WordPress-akselerasjon finnes i en egen artikkel: 21 tips for å forbedre PageSpeed Insights-poengsummen. Hvis problemet ikke bare er skript, men generell hosting-hastighet, sjekk ut måter å redusere WordPress-sideinnlastingstid. Og verktøy for å sjekke WordPress-ytelse vil hjelpe med å måle den reelle effekten av optimalisering.

Video: async og defer i praksis

En fem minutters gjennomgang fra xplodivity-kanalen, med visuelle lastediagrammer og levende kodeeksempler:

⁉️🤔 Ofte stilte spørsmål

defer** eller async, hva bør man velge for Google Analytics?**

async. Analytics.js og gtag.js er helt uavhengige av DOM-en, de trenger ikke en bestemt kjøringsrekkefølge. GA4 anbefaler offisielt async, biblioteket håndterer forsinket initialisering selv.

Hvordan skiller load-hendelsen seg fra DOMContentLoaded?

DOMContentLoaded utløses når HTML-en er fullstendig tolket og DOM-treet er bygget, stiler og bilder kan fortsatt være under innlasting. load inntreffer senere: når absolutt alt er lastet, inkludert bilder, fonter og stilark. For lat innlasting av skript er load tryggere: siden har definitivt blitt vist for brukeren på dette tidspunktet.

Kan man legge til defer på et inline-skript?

Nei. defer-attributtet fungerer bare for eksterne skript med src-attributtet. Et inline-skript (<script>code</script>) med defer vil bli ignorert, nettleseren vil kjøre det som et normalt blokkerende skript. For å utsette inline-kode, pakk den inn i en DOMContentLoaded- eller load-lytter.

Er det trygt å sette defer på alle skript på et WordPress-nettsted?

jQuery med defer vil ødelegge all kode som kaller $() eller jQuery() før DOMContentLoaded. Det er nettopp derfor jQuery er ekskludert fra behandlingen i kodeeksempelet over. Start med ikke-kritiske skript: chat, sosiale medier, annonser. Utvid listen gradvis, og sjekk konsollen for feil etter hver endring.

Intersection Observer eller defer, hva er best?

De løser forskjellige oppgaver. defer er for skript som alltid trengs på siden, men som ikke er kritiske for første rendering: analyseverktøy, A/B-tester. Intersection Observer er for skript knyttet til en spesifikk blokk: kart, chat i bunnteksten, kommentar-widget. Enkel regel: skript i øvre del av siden, defer; skript under folden, Intersection Observer.

Hva gjør man hvis Flying Scripts ødela funksjonaliteten?

Ekskluder det problematiske skriptet fra utsettelseslisten i plugin-innstillingene. Flying Scripts lar deg spesifisere nøkkelord for inkludering, fjern nøkkelordet for det problematiske skriptet, så vil det lastes normalt. For kritiske elementer som skjemaer og chatter er dette et obligatorisk steg før man aktiverer utsettelse.

Hva du bør bruke på nettstedet ditt: beslutningsmatrise

Valget koker ned til en enkel beslutningstabell:

• Skriptet er skrevet i HTML, du kontrollerer taggene, defer hvis det avhenger av rekkefølge, async hvis det er helt uavhengig.
• Skriptet settes inn via GTM eller en tredjeparts plugin, tagger er utilgjengelige, programmatisk lasting ved load-hendelsen.
• Skriptet er knyttet til en blokk under folden, Intersection Observer med rootMargin: '200px'.
• WordPress, trenger det uten kode, Flying Scripts (gratis, 30 000+ nettsteder) eller Asset CleanUp for full kontroll over ressurser.

Start med det enkleste: åpne PageSpeed Insights, finn blokkerende eksterne skript, og legg til defer på dem. Ett attributt, og FCP kan gå fra rødt til grønt. Og når du har mestret attributter, sjekk ut vår gjennomgang av verktøy for å sjekke WordPress-ytelse, det vil hjelpe deg med å måle den reelle effekten.