Kjøre JavaScript fra en egen .js-fil: komplett guide

Å kjøre JavaScript fra en egen .js-fil betyr at du legger koden i en separat tekstfil og laster den inn på nettsiden med én liten linje: <script src="filnavn.js"></script>. Dette er den vanlige og anbefalte måten å bruke JavaScript på moderne nettsider. I stedet for å blande store mengder kode direkte inn i HTML-en, holder du HTML, CSS og JavaScript hver for seg. Resultatet er ryddigere sider, kode som kan gjenbrukes på flere sider, og filer nettleseren kan mellomlagre slik at siden laster raskere. Denne guiden viser deg steg for steg hvordan du gjør det, hvor script-taggen bør ligge, og hvordan du unngår de vanligste feilene.

Hva betyr det å kjøre JavaScript fra en egen fil?

En .js-fil er rett og slett en vanlig tekstfil som inneholder JavaScript-kode og har filendelsen .js. Når nettleseren møter en <script>-tagg med et src-attributt (source = kilde), henter den innholdet i den filen og kjører koden som om den stod rett i HTML-dokumentet. Du skriver altså koden ett sted, og peker til den fra så mange sider du vil.

Det motsatte kalles inline-script, der du skriver JavaScript direkte mellom <script> og </script> i HTML-filen. Inline fungerer fint for et par linjer, men for alt annet enn de minste snuttene lønner det seg å flytte koden ut i en egen fil. Prinsippet er det samme som når du skiller ut utseendet i et eget CSS-stilark – vil du vite mer om den delen, forklarer vi det i artikkelen Hva er CSS.

Hvorfor legge JavaScript i en ekstern fil?

Å skille ut JavaScript i en egen fil gir flere konkrete fordeler, ikke bare penere kode:

  • Ryddig og lesbar kode. HTML-en beskriver innholdet, og JavaScript-en ligger for seg selv. Det blir mye enklere å finne og rette feil.
  • Gjenbruk på mange sider. Har du ti sider som skal bruke samme meny- eller skjema-script, legger du koden i én fil og lenker til den fra alle ti. Endrer du filen, oppdateres alle sidene samtidig.
  • Raskere lasting via mellomlagring. Nettleseren lagrer eksterne filer i cache (mellomlager). Når besøkende går videre til neste side, lastes ikke .js-filen på nytt – den hentes fra maskinen deres.
  • Samarbeid. Flere personer kan jobbe med henholdsvis HTML og JavaScript uten å tråkke i hverandres filer.
  • Bedre ytelse med defer og async. Eksterne script kan markeres slik at de ikke stopper opp tegningen av siden – noe du ikke kan gjøre like elegant med inline-kode.

Viktige punkter

  • Slik lastes filen: <script src="filnavn.js"></script> – taggen må alltid lukkes.
  • Ingen tagger i selve filen: .js-filen inneholder bare JavaScript, ingen <script>-tagger.
  • Plassering: rett før </body>, eller i <head> med defer.
  • defer kjører scriptet i rekkefølge etter at siden er lest; async kjører det så snart det er lastet.
  • Unngå document.write() – bruk querySelector og textContent i stedet.
  • Fordeler: ryddig kode, gjenbruk på mange sider og raskere lasting via mellomlagring.

Slik lager du en ekstern JavaScript-fil steg for steg

Prosessen har tre enkle steg: lag filen, koble den til HTML-siden, og test at den fungerer. Alt du trenger er et tekstredigeringsprogram – Notisblokk duger, men et skikkelig kodeverktøy er bedre. Vi har samlet noen gratis valg i oversikten over gratis HTML- og CSS-editorer.

Steg 1: Lag .js-filen

Opprett en ny tekstfil og lagre den med endelsen .js, for eksempel skript.js. Legg den gjerne i en undermappe som js/ for å holde orden. Skriv JavaScript-koden din i filen – helt uten <script>-tagger, for innholdet er allerede JavaScript. Her er et enkelt eksempel som skriver en tekst inn i siden på en moderne måte:

// skript.js
function visHilsen() {
  const element = document.querySelector("#hilsen");
  element.textContent = "Denne teksten kommer fra en ekstern fil!";
}

document.addEventListener("DOMContentLoaded", visHilsen);

Koden venter til siden er ferdig lest inn (DOMContentLoaded), finner elementet med id-en hilsen, og legger teksten inn i det. Vi bruker textContent i stedet for den gamle metoden document.write() – mer om hvorfor lenger ned.

Steg 2: Koble filen til HTML-siden

I HTML-filen legger du inn et tomt element der teksten skal vises, og en script-tagg som peker på filen din:

<div id="hilsen"></div>

<script src="js/skript.js"></script>

Legg merke til to ting. For det første må script-taggen alltid lukkes med </script>, selv når du bruker src – en selvlukkende <script src="..." /> fungerer ikke i HTML. For det andre skal det ikke stå kode mellom åpne- og lukketaggen når du bruker src; eventuell kode der blir ignorert.

Steg 3: Test at det fungerer

Åpne HTML-siden i nettleseren. Ser du teksten fra .js-filen, er alt riktig koblet. Gjør det ikke det, åpne utviklerverktøyene (F12 i de fleste nettlesere) og se i fanene Console og Network. En rød 404-feil i Network betyr at nettleseren ikke fant filen – da er det nesten alltid filbanen i src som er feil. Hvordan du graver i kildekoden, viser vi i guiden Hvordan ser du HTML-kilden til en side.

Hvor i HTML-koden bør script-taggen ligge?

Plasseringen avgjør når scriptet kjører, og det påvirker både om koden virker og hvor raskt siden oppleves. Det finnes to gode strategier.

  • Rett før </body>: Den klassiske og trygge plasseringen. Når nettleseren når script-taggen, er resten av siden allerede lest inn, så koden finner elementene den skal jobbe med. Dette er det enkleste for nybegynnere.
  • I <head> med defer: Den moderne, ofte raskere løsningen. Filen lastes ned tidlig og parallelt, men kjøres først etter at siden er ferdig lest inn.

Det du bør unngå, er en vanlig script-tagg uten defer eller async øverst i <head>. Da stopper nettleseren opp tegningen av siden mens den laster ned og kjører scriptet, og besøkende ser en blank side lenger enn nødvendig.

async og defer: slik styrer du når scriptet kjører

En vanlig ekstern script-tagg er blokkerende: nettleseren pauser lesingen av HTML-en mens den laster ned og kjører filen. Attributtene async og defer endrer dette, og de gjelder kun for eksterne script (altså når src er med).

  • defer: Filen lastes ned parallelt med at siden leses, men kjøres først når hele dokumentet er ferdig lest – og flere defer-script kjøres i den rekkefølgen de står. Perfekt for kode som skal jobbe med innholdet på siden. Eksempel: <script src="js/skript.js" defer></script>
  • async: Filen lastes ned parallelt og kjøres så snart den er ferdig nedlastet, uten garantert rekkefølge. Passer for uavhengige script som statistikk/analyse som ikke trenger resten av siden.
  • Ingen attributt: Blokkerende. Brukes helst bare når script-taggen står helt nederst, rett før </body>.

Er både async og defer satt på et vanlig script, vinner async. Tabellen under oppsummerer forskjellene.

Sammenligning

LastemåteBlokkerer siden?RekkefølgeNår kjører den?Passer best for
Vanlig (ingen attributt)JaGarantertMed én gang taggen nåsScript nederst, rett før </body>
deferNeiGarantertEtter at siden er ferdig lestKode som jobber med innholdet på siden
asyncNeiIkke garantertSå snart filen er lastet nedUavhengige script som statistikk/analyse
type="module"NeiGarantertUtsatt automatisk (som defer)Moderne kode delt i flere moduler

Moderne JavaScript: moduler og type=»module»

På nyere nettsider deler man gjerne koden i flere små filer – moduler – som importerer funksjoner fra hverandre. Da bruker du attributtet type="module":

<script type="module" src="js/hoved.js"></script>

En modul kan hente inn kode fra andre filer med import, og den kjøres utsatt automatisk – akkurat som defer – så du trenger ikke legge til defer i tillegg. Moduler kjører også i «strict mode» og har sitt eget navnerom, slik at variabler ikke lekker ut og kolliderer med annen kode. For eldre nettlesere som ikke støtter moduler, kan du servere en reservefil med attributtet nomodule. Dette er mer avansert, men greit å kjenne til når du møter det.

Unngå document.write – bruk moderne metoder

Mange gamle eksempler, inkludert den opprinnelige versjonen av denne artikkelen, bruker document.write() for å skrive tekst inn i siden. Den metoden fraråder nå MDN og nettleserleverandørene, og du bør styre unna den av flere grunner:

  • Kjøres document.write() etter at siden er ferdig lastet, sletter den hele sideinnholdet og erstatter det med teksten.
  • Google Chrome kan blokkere eksterne, blokkerende script som bruker document.write(), dersom de hentes over en treg forbindelse og ikke er mellomlagret.
  • Metoden kan forstyrre nettleserens tolking av HTML mens siden fortsatt leses, noe som gir uforutsigbar oppførsel.

Bruk heller moderne metoder for å endre innhold: document.querySelector() for å finne et element, og textContent eller innerHTML for å sette innholdet – slik eksempelet i steg 1 gjør. Det er tryggere, raskere og enklere å feilsøke.

Filbaner: slik peker du riktig på .js-filen

Den desidert vanligste feilen er en src-bane som ikke stemmer. Banen forteller nettleseren hvor filen ligger i forhold til HTML-siden.

  • Relativ bane: src="js/skript.js" peker på mappen js ved siden av HTML-filen. src="../js/skript.js" går ett nivå opp først.
  • Rot-relativ bane: src="/js/skript.js" starter alltid fra rota av nettstedet, uansett hvilken side du er på.
  • Absolutt URL: src="https://eksempel.no/js/skript.js" peker på en fullstendig adresse, gjerne til et script på en annen server.

Et godt tips: når du henter script fra andre tjenester, kalles adressen ofte et CDN (innholdsleveringsnettverk). Da bruker du den fulle URL-en de oppgir. Samme logikk gjelder forresten når du lager vanlige lenker – se hvordan du lager en HTML-lenke for en grundig gjennomgang av relative og absolutte adresser.

Flere filer og riktig rekkefølge

Du kan laste inn så mange .js-filer du vil på én side. Rekkefølgen kan være viktig: avhenger én fil av en annen (for eksempel et bibliotek og din egen kode som bruker det), må biblioteket lastes først.

<script src="js/bibliotek.js" defer></script>
<script src="js/min-kode.js" defer></script>

Med defer kjøres filene i rekkefølgen de står, så dette er trygt. Med async har du ingen garanti for rekkefølge, så ikke bruk async på filer som er avhengige av hverandre.

Vanlige feil og hvordan du løser dem

De fleste problemer med eksterne script skyldes noen få gjengangere:

  • Feil filbane (404). Scriptet laster ikke fordi src peker feil. Sjekk Network-fanen i utviklerverktøyene og kontroller store/små bokstaver i filnavnet – mange servere skiller på dette.
  • Scriptet kjører før siden finnes. Koden leter etter et element som ennå ikke er lest inn. Løsning: bruk defer, legg taggen nederst, eller pakk koden inn i DOMContentLoaded.
  • Manglende lukketagg. Glemmer du </script>, kan resten av siden «forsvinne» inn i script-taggen.
  • Kode mellom taggene sammen med src. Har du både src og kode mellom taggene, ignoreres koden. Velg én av delene.
  • Nettleseren viser en gammel versjon. Cachen holder på den gamle filen. Tøm hurtigbufferen, eller legg på et versjonsnummer som skript.js?v=2 under utvikling.
  • Syntaksfeil i filen. Én skrivefeil kan stoppe hele filen. Console-fanen viser feilmeldingen med linjenummer.

Når du har fått alt til å virke, er det lurt å sjekke at selve HTML-en er feilfri også – vi forklarer hvordan i slik validerer du koden på din hjemmeside.

Sikkerhet og ytelse

Når du laster script, særlig fra andre servere, er det noen hensyn verdt å kjenne til:

  • Integritetssjekk (SRI). Attributtet integrity lar nettleseren kontrollere at en ekstern fil ikke er endret, ved å sammenligne den mot en hash du oppgir. Det beskytter mot at et kompromittert tredjeparts-script sniker inn skadelig kode. Bruk det sammen med crossorigin når du laster fra et CDN.
  • Innholdssikkerhetspolicy (CSP). En CSP-regel i servernes HTTP-hoder kan styre nøyaktig hvilke domener det er lov å laste script fra – et effektivt vern mot kryssing av skadelig kode.
  • Last bare fra kilder du stoler på. Et eksternt script får full tilgang til siden din. Bruk kjente, offisielle kilder.
  • Minifisering. For raskere lasting kan du «minifisere» filene – fjerne mellomrom og forkorte navn – før de legges ut. Det gir mindre filer uten å endre funksjonen.

Vil du prøve deg videre med konkret JavaScript, er en fin start vår lille oppskrift på hvordan du lager en JavaScript-tilbakeknapp, som du nå enkelt kan legge i en egen .js-fil.

Vanlige spørsmål (FAQ)

Må jeg bruke .js som filendelse?

Ja, i praksis bør filen hete noe som slutter på .js, og serveren bør sende den med riktig innholdstype (text/javascript eller application/javascript). Det er standarden både nettlesere, verktøy og utviklere forventer, og det gjør filen lett å kjenne igjen.

Hvorfor vises ikke scriptet mitt når jeg åpner siden?

Som regel skyldes det én av to ting: enten finner ikke nettleseren filen (sjekk src-banen og se etter en 404-feil i Network-fanen), eller så kjører koden før elementene finnes. Legg script-taggen nederst eller bruk defer, og se i Console-fanen etter feilmeldinger.

Hva er forskjellen på async og defer?

Begge laster filen parallelt uten å blokkere siden. defer kjører scriptene i rekkefølge etter at siden er ferdig lest – best for kode som jobber med innholdet. async kjører hvert script så snart det er lastet, uten garantert rekkefølge – best for uavhengige script som statistikk.

Kan jeg laste inn flere .js-filer på samme side?

Ja, du kan ha så mange script-tagger du vil. Pass bare på rekkefølgen hvis én fil er avhengig av en annen. Med defer kjøres filene i den rekkefølgen de står, mens async ikke garanterer noen bestemt rekkefølge.

Er inline-script dårligere enn en ekstern fil?

Ikke dårligere, men mindre praktisk for alt annet enn korte snutter. En ekstern fil kan gjenbrukes på flere sider, mellomlagres av nettleseren for raskere lasting, og holder HTML-en ryddig. For noen få linjer engangs-kode er inline helt greit.