Sådan gør du din hjemmeside hurtigere: en praktisk tjekliste

For at gøre en hjemmeside hurtigere måler du først med PageSpeed Insights og retter derefter den største årsag, det peger på — typisk overdimensionerede billeder, for meget JavaScript, tunge skrifttyper eller tredjepartsscripts. Sigt efter Googles Core Web Vitals „gode“ mål: hovedindholdet synligt inden for 2,5 sekunder, svar på tryk inden for 200 millisekunder og næsten ingen layoutbevægelse. De fleste sider når dertil med en håndfuld ændringer, ikke en omskrivning.

Mål, før du ændrer noget

At gætte spilder tid. To gratis værktøjer dækker næsten alle:

• PageSpeed Insights (pagespeed.web.dev) — indsæt en live-URL. Den viser feltdata fra reelle Chrome-brugere (hvis din side har nok trafik) og lab-data fra en simuleret indlæsning, plus en liste over specifikke problemer.
• Lighthouse i Chrome DevTools — den samme lab-test, kørt på enhver side du kan åbne, inklusive en forhåndsvisning. Test i mobiltilstand; telefoner på langsommere net er der, problemerne viser sig.

De tal, der betyder noget, er Googles Core Web Vitals. Pr. september 2026 angiver Googles dokumentation på web.dev disse „gode“ grænseværdier, målt ved den 75. percentil af sideindlæsninger:

INP erstattede den ældre First Input Delay-metrik i 2024. Hvis et værktøj stadig rapporterer FID, er det forældet.

Skriv dine startværdier ned. Efter hver rettelse tester du igen, så du ved, hvad der hjalp.

Hvor tiden går hen: muligheder og afvejninger

Hver almindelig årsag har en rettelse, og hver rettelse har en pris. Start med dem øverst — de er billigst og mest almindelige.

Billeder

Billeder er det mest almindelige problem og det nemmeste at rette. Et 4.000 pixels fotografi vist i 800 pixels bredde tvinger hver besøgende til at hente fem gange mere, end de ser.

• Server billeder i den størrelse, de vises i, med responsive srcset-størrelser til telefoner og desktops.
• Brug moderne formater (WebP eller AVIF) og fornuftig komprimering.
• Sæt width og height på hvert billede, så browseren reserverer plads. Det alene retter de fleste layoutforskydninger.
• Lazy-load billeder under folden med loading="lazy".
• Lazy-load aldrig hovedbilledet øverst på siden. Googles LCP-vejledning er ligefrem om dette: lazy-loading af LCP-billedet forsinker det altid. Giv det fetchpriority="high" i stedet.

JavaScript

Mange AI-byggede sider er single-page apps (SPA'er): browseren henter en JavaScript-bundle og tegner så siden. Jo større bundlen er, jo længere et tomt skærmbillede. Rettelser, i rækkefølge efter indsats:

1. Fjern det, du ikke bruger. Bed om en liste over afhængigheder, og skær de biblioteker væk, der blev tilføjet én gang og glemt — et datobibliotek til én dato, en fuld ikonpakke til fem ikoner.
2. Del pr. route. Indlæs koden til admin-dashboardet først, når nogen åbner det, ikke på forsiden.
3. Prerender offentlige sider. En markedsføringsside, der leveres som rigtig HTML, vises, før noget JavaScript kører. Det hjælper også søgemaskiner; se SEO til AI-byggede hjemmesider.

Lav INP betyder typisk, at én lang opgave blokerer siden — filtrering af en enorm liste ved hvert tastetryk, eller gen-rendering af en hel tabel, når én celle ændres. Chrome DevTools' Performance-panel viser, hvilken.

Skrifttyper

Hver skrifttypefamilie og -vægt er endnu en fil. To familier og tre eller fire vægte er som regel nok. Preload skrifttypen, der bruges over folden, brug font-display: swap, så teksten vises med det samme, og hostér selv skrifttyper, hvis den eksterne skrifttypetjeneste er langsom for dine besøgende.

Tredjepartsscripts

Chat-widgets, analyse, varmekort, annoncepixels, indlejrede videoer og sociale feeds henter alle kode fra andre servere. Hver enkelt ser lille ud; tilsammen er de ofte den langsomste del af siden. Behold dem, du faktisk kigger på. Indlæs resten, når siden er interaktiv, og erstat tunge embeds (en YouTube-afspiller, et kort) med en let forhåndsvisning, der først indlæser det rigtige ved klik.

Serversvar

Time to first byte (TTFB) — hvor lang tid serveren tager om at begynde at svare — ligger under alle andre metrikker. Statiske sider leveret fra et CDN (et netværk af servere tæt på dine besøgende; se hvad er et CDN) er hurtige næsten overalt. Sider, som en server bygger ved hver forespørgsel, afhænger af den server og dens database. Caching af gentaget arbejde og databaseindekser til langsomme forespørgsler er de typiske rettelser.

Prompts der virker

Vær specifik: navngiv siden, metrikken og begrænsningen. Indsæt PageSpeed Insights-fundene, hvis du har dem.

PageSpeed Insights rapporterer en LCP på 4,8 s på mobil for forsiden, og LCP-elementet er heltebilledet. Skaler og konverter heltebilledet til WebP, server responsive størrelser, sæt width og height, giv det fetchpriority="high" og sørg for, at det ikke lazy-loades. Lazy-load alle billeder under folden. Ændr ikke designet.

Revider denne apps afhængigheder. List hver pakke, hvad der bruger den, og nogenlunde hvor meget den lægger til bundlen. Fjern de ubrugte, og del ruterne /admin og /settings op i separate chunks, der kun indlæses, når de besøges.

Søgefeltet på /products føles træls. Debounce filteret, undgå at gen-rendere hele listen ved hvert tastetryk, og paginér eller virtualisér listen, hvis den har mere end 200 elementer.

Trin for trin

1. Test den live side i PageSpeed Insights på mobil. Noter LCP, INP og CLS og de tre største problemer, der listes.
2. Ret billeder først: størrelser, formater, dimensioner, lazy-loading under folden, prioritet til heltebilledet.
3. Skær tredjepartsscripts du ikke bruger, og udsæt resten.
4. Trim skrifttyper til det, designet har brug for.
5. Mindsk JavaScript: fjern ubrugte pakker, del pr. route.
6. Prerender offentlige sider, hvis de stadig renderes på klienten, og LCP stadig er langsom.
7. Tjek serveren: caching, databaseindekser, statisk hosting til indhold, der sjældent ændres.
8. Publicer igen, og test igen. Feltdata i PageSpeed Insights opdateres i ugerne efter, efterhånden som reelle besøg kommer ind, så bedøm tidlige resultater ud fra lab-data.

Almindelige fejl

• At teste kun på en hurtig laptop. Dine besøgende er på mellemklasse-telefoner og ustabilt mobildata. Test i mobiltilstand.
• At jage en perfekt 100. Lab-scoren er en vejledning. Når Core Web Vitals er i det gode område, betyder indhold og brugbarhed mere end de sidste få point.
• At lazy-loade alt, inklusive heltebilledet. Det gør LCP værre.
• At tilføje en hastighedsplugin eller et bibliotek oven på. At fjerne vægt slår næsten altid at tilføje kode for at håndtere den.
• At optimere forhåndsvisningen, ikke den live side. Udviklingsforhåndsvisninger kører ikke-optimerede builds. Mål den udgivne URL.
• At rette hastighed én gang. Hver ny widget, hvert billede og hver funktion tilføjer vægt. Test igen efter store ændringer.

Hastighedstjekliste

• LCP ≤ 2,5 s, INP ≤ 200 ms, CLS ≤ 0,1 på mobil
• Billeder skaleret, komprimeret, moderne format, med width og height
• Heltebilledet ikke lazy-loaded; billeder under folden lazy-loaded
• Ingen ubrugte JavaScript-biblioteker; tunge ruter udskilt
• To skrifttypefamilier eller færre, hovedskrifttypen preloaded
• Kun de tredjepartsscripts du faktisk bruger, indlæst sent
• Offentlige sider prerendered eller statiske, hvor det er muligt
• Testet igen på den live URL efter publicering

Hastighed og mobillayout hænger sammen; se sådan gør du en hjemmeside mobilvenlig. Til en fuld gennemgang før lancering dækker sådan tager du en AI-prototype til produktion resten.

Hastighed på Mythex

På Mythex laver du disse ændringer ved at bede om dem i chatten, eller i kodeeditoren på Pro. Tjek den udgivne URL, ikke forhåndsvisningen, da forhåndsvisningen kører en udviklingsserver. Statiske frontends udrulles som statiske sider, når du publicerer (statiske hjemmesider), hvilket passer til indholdssider. Apps med en server skalerer til nul: de sover, når de er inaktive, og vågner ved næste besøg, så den første forespørgsel efter en stille periode er langsommere, og en tilknyttet database sover efter 5 minutters inaktivitet (hostingbegrænsninger). Hvis en offentlig side kun er langsom ved første besøg, er det sandsynligvis årsagen. At holde markedsføringssider statiske hjælper. Efter ændringer publicerer du igen og laver en hård opdatering.

Spørgsmål