Ytelse, tilgjengelighet og SEO
henger sammen
De behandles ofte som tre separate sjekklister med tre separate eksperter. Men de springer alle ut av det samme: en nettside som er bygget godt.
Sammenhengen
Tre begreper — ett underliggende prinsipp
Ytelse, tilgjengelighet og SEO behandles i mange organisasjoner som separate disipliner. Ytelsesoptimalisering er «noe utviklerne gjør». Tilgjengelighet er «juridisk compliance». SEO er «noe markedsavdelingen håndterer med plugins».
Den inndelingen er feil, og den er kostbar. De tre fagområdene overlapper massivt — og de sterkeste forbedringene man kan gjøre for ett av dem, gir som regel gevinst i de to andre.
Årsaken er enkel: alle tre handler om å lage en nettside som er lett å forstå, rask å bruke og strukturert på en logisk måte — for mennesker og for maskiner. Det er det samme problemet. Det er den samme løsningen.
Koblingene i praksis
Slik påvirker de hverandre
Google bruker Core Web Vitals som direkte rankingfaktor. LCP, CLS og INP måler brukeropplevelse — og dårlig ytelse straffer plasseringen din i søkeresultater.
Google-crawleren leser nettsider omtrent som en skjermleser: semantisk HTML, logisk innholdsstruktur, meningsbærende lenketekster. En tilgjengelig nettside er som regel en godt indeksert nettside.
En rask nettside er også mer tilgjengelig. Brukere med eldre enheter, dårlig nettilgang eller kognitive utfordringer er de første som forlater en treg side. God ytelse er inkluderende.
Målbare ytelseskrav
Core Web Vitals — Googles ytelsesstandarder
Siden 2021 er Core Web Vitals en direkte rankingfaktor. Her er de fire nøkkelmålene du bør kjenne til.
Largest Contentful Paint
< 2,5 sek
Hva måles
Hvor lang tid tar det før det største innholdselementet på siden er synlig?
Praktisk betydning
Direkte rankingfaktor. Treg LCP = dårlig brukeropplevelse + lavere SEO-score.
Cumulative Layout Shift
< 0,1
Hva måles
Forskyves elementer på siden mens den lastes? Tekst som hopper, knapper som flytter seg.
Praktisk betydning
Irriterende for brukere. Spesielt kritisk for klikk på mobil — og Google straffer det.
Interaction to Next Paint
< 200 ms
Hva måles
Hvor responsiv er siden til brukerinteraksjon? Klikk, tastetrykk, scrolling.
Praktisk betydning
Erstattet FID fra 2024. Mål på om JavaScript-koden blokkerer interaksjoner.
Time to First Byte
< 800 ms
Hva måles
Hvor lang tid tar det fra nettleseren sender en forespørsel til den mottar det første byteet fra serveren?
Praktisk betydning
Ikke en offisiell Core Web Vital, men en viktig indikator på server- og infrastrukturytelse.
I praksis
Sjekklisten som dekker alle tre
Det meste på denne listen forbedrer ytelse, tilgjengelighet og SEO samtidig. Det er ikke tilfeldig.
HTML og struktur
- Én <h1> per side som beskriver innholdet presist
- Logisk overskriftshierarki (h1 → h2 → h3, ingen hopp)
- Semantiske elementer: <nav>, <main>, <article>, <section>, <footer>
- Meningsbærende lenketekster — ikke «klikk her» eller «les mer»
Bilder og media
- Alt-tekst på alle innholdsbærende bilder
- Eksplisitt width og height-attributt for å unngå CLS
- Lazy loading på bilder under folden
- WebP-format med fallback
Ytelse
- Minifisert CSS og JavaScript
- Ingen blokkerende ressurser i <head>
- Fonter forhåndslastet med <link rel="preload">
- Statisk generering eller server-side rendering — ikke client-only rendering for innholdsider
Tilgjengelighet
- Tilstrekkelig fargekontrast (4,5:1 for normal tekst, 3:1 for stor tekst)
- Alle interaktive elementer tilgjengelige med tastatur
- Synlig fokusindikator på alle fokusbare elementer
- ARIA-attributter kun der de faktisk trengs — ikke som erstatning for semantisk HTML
Vanlige misforståelser
Fire myter vi hører for ofte
«SEO handler om nøkkelord og metadata»
Metadata er viktig, men Google vurderer i dag primært brukeropplevelse: lastetid, struktur, relevans og autoritet. Nøkkelord uten god teknisk grunnmur gir lite.
«Tilgjengelighet er bare for blinde»
15–20 % av befolkningen har en eller annen form for funksjonsnedsettelse. Men tilgjengelig design forbedrer opplevelsen for alle: eldre enheter, dårlig lys, stress, svakt nettverk.
«Vi fikser ytelse etter lansering»
Ytelse er arkitektur. Å fikse det i etterkant betyr å rive opp fundamentet. En treg React-app som laster 4 MB JavaScript er ikke noe du optimaliserer — du bygger den om.
«PageSpeed 100 er urealistisk for ekte nettsider»
Det er absolutt mulig med Next.js og riktig arkitektur. Vi dokumenterer det for våre egne prosjekter. Det krever disiplin, men det er ikke magi.
Vil du se det i praksis?
Vi dokumenterer ytelse, tilgjengelighet og SEO
Vi leverer ikke nettsider uten å vise deg Lighthouse-scorer og Core Web Vitals. Det er en del av avtalen.