JavaScript på din hjemmeside: det du som ejer skal vide

Hvad JavaScript gør på din side

En side består af tre lag. HTML er indholdet og strukturen: overskrifter, tekst, billeder, formularer. CSS bestemmer, hvordan det ser ud. JavaScript er et programmeringssprog, der kører i den besøgendes browser og kan ændre siden, efter den er indlæst: reagere på klik, hente nye data og vise dem, eller tjekke en formular, mens den bliver udfyldt.

I en webshop er det JavaScript, der lægger en vare i kurven uden at skifte side, opdaterer prisen, når du vælger en anden størrelse, viser fragtmulighederne i kassen og taler med betalingsløsningen. Meget af det kunne i princippet klares med almindelige sideskift, men det ville føles langsommere for kunden.

Det gode princip hedder progressive enhancement: det vigtigste skal virke med HTML alene, og JavaScript lægger det bedre lag ovenpå. En kontaktformular, der kun kan sendes, hvis et script har indlæst korrekt, er en formular, der af og til ikke kan sendes.

Hvor JavaScriptet kommer fra

På en WordPress-side har ejeren sjældent skrevet en eneste linje af det JavaScript, siden indlæser. Det kommer fra temaet, fra en page builder, fra hvert plugin, der har en synlig funktion (slidere, formularer, filtre, cookiebanner), fra WooCommerce selv og fra tredjeparter som analyseværktøjer, chat, anmeldelser og annoncepixels.

Problemet er sjældent det enkelte script, men summen. Mange plugins indlæser deres filer på hver eneste side, også dem, hvor funktionen ikke bruges, så et formularplugin kan sende sin JavaScript med til produktsiderne, og en slider til kassen. Hvert nyt plugin er derfor også en beslutning om hastighed.

Hvad det koster i hastighed

JavaScript koster tre gange. Først skal filen hentes. Så skal browseren læse og oversætte den. Til sidst skal den køres, og det sker på browserens hovedtråd, den samme, der tegner siden og reagerer på klik. Mens et tungt script kører, kan siden se færdig ud uden at reagere, når du trykker på den. Det er netop det, Googles måling INP (Interaction to Next Paint) fanger: hvor lang tid der går fra et klik eller tryk, til siden viser et svar.

De to sidste trin rammer telefoner langt hårdere end computere. Den samme fil, der køres på et øjeblik på en ny bærbar, kan tage mærkbart længere på en billig telefon, og det kan være dér, dine kunder er. Derfor kan en side score fint, når du tester den på dit kontor, og stadig føles træg for kunderne.

Et script i sidens <head> uden særlige attributter blokerer: browseren stopper med at bygge siden, til filen er hentet og kørt. Med defer hentes filen, mens siden bygges, og køres først bagefter, i den rækkefølge scripts står. Med async hentes den også parallelt, men køres, så snart den er klar, uanset rækkefølge. Det passer til selvstændige scripts som analyse, men ikke til scripts, der afhænger af hinanden. I WordPress kan et tema eller plugin bede om det direkte og samtidig kun indlæse filen, hvor den bruges:

add_action( 'wp_enqueue_scripts', function () {
    if ( ! is_front_page() ) {
        return; // slideren findes kun på forsiden
    }
    wp_enqueue_script(
        'forside-slider',
        get_theme_file_uri( 'js/slider.js' ),
        [],
        '1.0',
        [ 'strategy' => 'defer', 'in_footer' => true ]
    );
} );

Mere om at få JavaScript, CSS og billeder til at fylde mindre finder du i guiden om indlæsning af JavaScript, CSS og billeder.

Se, hvad din side indlæser

Du kan selv få et overblik på få minutter, uden at installere noget:

1. Åbn en side i Chrome, højreklik og vælg Undersøg. Gå til fanen Network, vælg filteret JS og genindlæs siden. Nu ser du hver JavaScript-fil, hvor den kommer fra, og hvor stor den er.
2. Sortér efter domæne. Filer fra dit eget domæne kommer fra tema og plugins, ofte med pluginets navn i stien. Resten er tredjeparter.
3. Åbn fanen Coverage (via menuen med de tre prikker, More tools) og genindlæs. Den viser, hvor stor en del af hver fil der faktisk blev brugt på siden.
4. Kør siden gennem PageSpeed Insights, og se efter punkterne om ubrugt JavaScript og arbejde på hovedtråden. De peger på de filer, der koster mest.

Gør det på forsiden, en produktside og kassen. Et script, der dukker op på alle tre, men kun bruges på én af dem, er et godt sted at starte.

Tredjepartsscripts

Et script fra en anden virksomhed kører med de samme rettigheder som din egen kode. Det kan læse alt på siden, også det, kunden skriver i en formular, og det kan ændre siden. Du stoler altså på både leverandøren og alle, der kan ændre filen på deres server. Brug kun tjenester, du faktisk bruger, og fjern dem, når I stopper med dem: et gammelt tracking-script fra en kampagne for to år siden bliver ellers stående.

Tredjeparter gør også din side afhængig af deres servere. Er de langsomme, bliver din side det, hvis scriptet blokerer. Og scripts, der sætter cookies til statistik eller markedsføring, må først indlæses, når den besøgende har sagt ja. Det skriver Datatilsynet om cookies. Et cookiebanner, der viser et valg, men indlæser det hele alligevel, løser ikke noget.

Sikkerhed

Den klassiske risiko hedder XSS (cross-site scripting): en angriber får sin egen JavaScript ind på din side, typisk gennem et felt eller en adresse, som siden viser uden at rense den. Så kører angriberens kode i dine besøgendes browsere, med adgang til det samme som din egen. Forsvaret ligger på serveren. Alt input skal tjekkes og renses der, fordi JavaScript-tjek i browseren kan springes over af enhver. Hold tema og plugins opdateret, da XSS er den type sårbarhed, der oftest bliver anmeldt i WordPress-verdenen¹. Og læg aldrig hemmelige nøgler eller passwords i JavaScript: alt, hvad browseren får, kan den besøgende læse.

Når noget holder op med at virke

Hvis en knap ikke reagerer, eller kurven ikke opdateres, så åbn konsollen (Undersøg, fanen Console). Røde fejl dér fortæller, hvilken fil der fejlede. Én fejl i ét script kan stoppe andre scripts på siden, så fejlen viser sig ofte et helt andet sted end der, hvor den opstår. Typiske årsager er et nyligt opdateret plugin, to plugins, der indlæser hver sin version af det samme bibliotek, og optimeringsplugins, der samler eller udskyder filer i en rækkefølge, de ikke tåler. Slå optimeringen fra for en stund: virker siden så, har du fundet stedet.

Ofte stillede spørgsmål

Kan min hjemmeside fungere uden JavaScript?

Indhold, navigation og almindelige formularer kan og bør virke uden. En moderne kasse med betalingsløsning kræver JavaScript i praksis. Målet er ikke nul JavaScript, men at det, der indlæses, bliver brugt.

Er jQuery et problem?

Ikke i sig selv. Mange WordPress-plugins bruger det stadig, og så skal det indlæses. Det bliver et problem, når det indlæses kun for en enkelt lille funktion, eller når flere versioner ender på den samme side.

Hvorfor siger PageSpeed, at jeg har ubrugt JavaScript?

Fordi filer bliver hentet på sider, hvor kun en lille del af koden bruges. Det skyldes typisk plugins, der indlæser alt overalt. Løsningen er at indlæse dem, hvor de bruges, eller at skifte plugins, der ikke kan det.

Vil du have hjælp?

Vi rydder op i JavaScript på WordPress-sider og webshops, og vi bygger de funktioner, der ikke findes som et godt plugin. Læs mere om vores udvikling.

1. Patchstack, State of WordPress Security in 2025 (på engelsk): XSS var den mest anmeldte type sårbarhed i 2024 og udgjorde næsten halvdelen af de nye fund. ↩︎