Hvordan gjøre nettsiden din raskere: en praktisk sjekkliste

For å gjøre en nettside raskere, mål den først med PageSpeed Insights, og fiks deretter den største årsaken den peker på. Det er vanligvis for store bilder, for mye JavaScript, tunge skrifter eller tredjepartsskript. Sikt mot Googles Core Web Vitals-mål for «god»: hovedinnholdet synlig innen 2,5 sekunder, svar på trykk innen 200 millisekunder, og nesten ingen layouthopping. De fleste nettsider når dit med en håndfull endringer, ikke en omskriving.

Mål før du endrer noe

Gjetting kaster bort tid. To gratisverktøy dekker nesten alle:

• PageSpeed Insights (pagespeed.web.dev): lim inn en levende URL. Den viser feltdata fra ekte Chrome-brukere (hvis siden din har nok trafikk) og labdata fra en simulert innlasting, pluss en liste over konkrete problemer.
• Lighthouse i Chrome DevTools: den samme labtesten, kjørt på en hvilken som helst side du kan åpne, inkludert en forhåndsvisning. Test i mobilmodus; telefoner på tregere nettverk er der problemene viser seg.

Tallene som betyr noe, er Googles Core Web Vitals. Fra september 2026 gir Googles dokumentasjon på web.dev disse «gode» terskelverdiene, målt ved 75. persentil av sideinnlastinger:

INP erstattet den eldre First Input Delay-målingen i 2024. Hvis et verktøy fortsatt rapporterer FID, er det utdatert.

Skriv ned utgangstallene dine. Etter hver rettelse tester du på nytt, så du vet hva som hjalp.

Der tiden går: alternativer og avveininger

Hver vanlig årsak har en løsning, og hver løsning har en kostnad. Start med de øverste; de er billigst og vanligst.

Bilder

Bilder er det vanligste problemet og det enkleste å fikse. Et 4000-piksler bilde vist i 800 piksler bredt tvinger hver besøkende til å laste ned fem ganger mer enn de ser.

• Server bilder i størrelsen de vises i, med responsive srcset-størrelser for telefoner og datamaskiner.
• Bruk moderne formater (WebP eller AVIF) og fornuftig komprimering.
• Sett width og height på hvert bilde slik at nettleseren reserverer plass. Dette alene fikser det meste av layouthopping.
• Lazy-load bilder under brettet med loading="lazy".
• Lazy-load aldri hovedbildet øverst på siden. Googles LCP-veiledning er tydelig på dette: lazy-lasting av LCP-bildet forsinker det alltid. Gi det fetchpriority="high" i stedet.

JavaScript

Mange AI-bygde nettsider er single-page-apper (SPA-er): nettleseren laster ned en JavaScript-pakke og tegner siden etterpå. Jo større pakken er, desto lengre tid med tom skjerm. Løsninger, i rekkefølge etter innsats:

1. Fjern det du ikke bruker. Be om en liste over avhengigheter og kutt biblioteker som ble lagt til én gang og glemt: et datobibliotek for én dato, en hel ikonpakke for fem ikoner.
2. Del per rute. Last koden for administrasjonspanelet først når noen åpner det, ikke på forsiden.
3. Pre-render offentlige sider. En markedsføringsside som sendes som ekte HTML, vises før noe JavaScript kjører. Dette hjelper også søkemotorer; se SEO for AI-bygde nettsider.

Treg INP betyr vanligvis at én lang oppgave blokkerer siden, for eksempel å filtrere en stor liste ved hvert tastetrykk, eller å tegne en hel tabell på nytt når én celle endres. Ytelsespanelet i Chrome DevTools viser hvilken.

Skrifter

Hver skriftfamilie og -vekt er en fil til. To familier og tre eller fire vekter er vanligvis nok. Forhåndslast skriften som brukes over brettet, bruk font-display: swap slik at tekst vises med en gang, og vær vert for skriftene selv hvis den eksterne skrifttjenesten er treg for besøkende.

Tredjepartsskript

Chatwidgeter, analyse, varmekart, annonsepiksler, innebygde videoer og sosiale feeder laster kode fra andre servere. Hver enkelt virker liten; sammen er de ofte den tregeste delen av siden. Behold dem du faktisk ser på. Last resten etter at siden er interaktiv, og erstatt tunge innbygginger (en YouTube-spiller, et kart) med en lett forhåndsvisning som laster den ekte varen ved klikk.

Serverrespons

Time to first byte (TTFB), altså hvor lang tid serveren bruker på å begynne å svare, ligger under alle andre målinger. Statiske sider servert fra et CDN (et nettverk av servere nær besøkende dine; se hva er et CDN) er raske nesten overalt. Sider bygget av en server ved hver forespørsel avhenger av den serveren og databasen. Caching av gjentatt arbeid og databaseindekser for trege spørringer er de vanlige løsningene.

Ledetekster som fungerer

Vær konkret: nevn siden, målingen og begrensningen. Lim inn PageSpeed Insights-funnene hvis du har dem.

PageSpeed Insights rapporterer LCP på 4,8 s på mobil for forsiden, og LCP-elementet er heltebildet. Konverter og endre størrelse på heltebildet til WebP, server responsive størrelser, sett width og height, gi det fetchpriority="high", og sørg for at det ikke er lazy-lastet. Lazy-load alle bilder under brettet. Ikke endre designet.

Revider denne appens avhengigheter. List opp hver pakke, hva som bruker den og omtrent hvor mye den legger til i pakken. Fjern ubrukte, og del rutene /admin og /settings i separate biter som bare lastes når de besøkes.

Søkeboksen på /products føles treg. Debounce filteret, unngå å tegne hele listen på nytt ved hvert tastetrykk, og paginer eller virtualiser listen hvis den har mer enn 200 elementer.

Steg for steg

1. Test den levende siden i PageSpeed Insights på mobil. Noter LCP, INP og CLS, og de tre største problemene som listes.
2. Fiks bilder først: størrelser, formater, dimensjoner, lazy-lasting under brettet og prioritet for heltebildet.
3. Kutt tredjepartsskript du ikke bruker, og utsett resten.
4. Trim skrifter til det designet trenger.
5. Krymp JavaScript: fjern ubrukte pakker, del per rute.
6. Pre-render offentlige sider hvis de fortsatt rendres på klienten og LCP fortsatt er treg.
7. Sjekk serveren: caching, databaseindekser og statisk hosting for innhold som sjelden endres.
8. Publiser på nytt og test igjen. Feltdata i PageSpeed Insights oppdateres de neste ukene etter hvert som ekte besøk kommer inn, så bedøm tidlige resultater etter labdata.

Vanlige feil

• Å teste bare på en rask laptop. Besøkende dine er på middels gode telefoner og ustabil mobildata. Test i mobilmodus.
• Å jage en perfekt 100. Labpoengsummen er en veiledning. Når Core Web Vitals er i det gode området, betyr innhold og brukbarhet mer enn de siste poengene.
• Å lazy-laste alt, inkludert heltebildet. Det gjør LCP verre.
• Å legge til et hastighetsplugin eller bibliotek oppå. Å fjerne vekt slår nesten alltid å legge til kode for å administrere den.
• Å optimalisere forhåndsvisningen, ikke den levende siden. Utviklingsforhåndsvisninger kjører uoptimaliserte bygg. Mål den publiserte URL-en.
• Å fikse hastighet én gang. Hver ny widget, hvert bilde og hver funksjon legger til vekt. Test igjen etter store endringer.

Sjekkliste for hastighet

• LCP ≤ 2,5 s, INP ≤ 200 ms, CLS ≤ 0,1 på mobil
• Bilder endret størrelse, komprimert, moderne format, med width og height
• Heltebildet ikke lazy-lastet; bilder under brettet lazy-lastet
• Ingen ubrukte JavaScript-biblioteker; tunge ruter delt ut
• To skriftfamilier eller færre, hovedskriften forhåndslastet
• Bare de tredjepartsskriptene du faktisk bruker, lastet sent
• Offentlige sider pre-rendret eller statiske der det går
• Testet på nytt på den levende URL-en etter publisering

Hastighet og mobillayout henger sammen; se hvordan gjøre en nettside mobilresponsiv. For en full gjennomgang før lansering dekker hvordan ta en AI-prototype til produksjon resten.

Hastighet på Mythex

På Mythex gjør du disse endringene ved å be i chatten, eller i kodeeditoren på Pro. Sjekk den publiserte URL-en, ikke forhåndsvisningen, siden Preview kjører en utviklingsserver. Statiske frontender rulles ut som statiske sider når du publiserer (statiske nettsider), noe som passer for innholdssider. Apper med en server skalerer til null: de sover når de er inaktive og våkner ved neste besøk, så første forespørsel etter en rolig periode er tregere, og en tilkoblet database sover etter 5 minutter uten aktivitet (vertsgrenser). Hvis en offentlig side bare er treg ved første besøk, er det sannsynligvis årsaken. Å holde markedsføringssider statiske hjelper. Etter endringer, publiser på nytt og hard-oppdater.

Spørsmål