Det finnes en tommelfingerregel i webbransjen som sier at du må velge: enten en side som ser levende ut, eller en side som scorer godt på ytelse. Vi trodde på den regelen selv. Så målte vi den, og den holdt ikke.
Denne artikkelen er ikke en liste over hva vi mener. Det er en liste over hva vi målte, hvilke antakelser som falt, og hva som faktisk skal til for å komme dit. Kort oppsummert: vi tok feil fem ganger i løpet av ett døgn før vi skaffet oss et instrument som fortalte sannheten. Det er den delen som er verdt å lese.
Utgangspunktet
Forsiden på dops.no ligger i dag på 97 i ytelse på PageSpeed Insights for mobil, med 100 på tilgjengelighet, SEO og beste praksis. Over tolv cache-bustede kjøringer er medianen 97–98: FCP 1,07 s, LCP 2,34 s, TBT 26 ms, CLS 0,032. Ingen feilede revisjoner i de tre siste kategoriene. Selve Docly-plattformens egen side ligger på median 100.
En viktig presisering med én gang: scoren svinger. Klikker du deg inn på PageSpeed Insights for dops.no en dårlig dag, kan du se 84. Det er ikke en feil i tallene over – det er en egenskap ved måleverktøyet, og vi kommer tilbake til hvorfor.
Effektene koster ingenting. Det målte vi.
Forsiden har dekorative canvas-effekter. Effektbunten bruker rundt 1000 ms CPU-tid, og etter enhver vanlig intuisjon skulle det være dyrt. Det er det ikke, fordi den er utsatt til requestIdleCallback etter load. Da kjører den utenfor målevinduet.
Vi testet det ordentlig: vi fjernet samtlige effekter fra en testside og målte mot en uendret kontroll i samme batch. Andelen raske kjøringer gikk fra 83 % til 83 %. Altså ingen forskjell overhodet. Bransjens vante antakelse – «effekter eller god score, velg én» – er målt og motbevist. Det er ikke effektene som koster. Det er når de kjører.
245 KB tredjeparts-JavaScript var verdt ett poeng
Neste antakelse: tredjepartsskriptene må være hovedproblemet. Vi strippet en testside for chat-widget, Cloudflare Turnstile, Google Analytics, alle effekter, jarallax og hele samtykke-stacken. Til sammen 245 KB JavaScript ut.
Medianen gikk fra 98 til 99. Ett poeng.
Underveis lærte vi noe om verktøyet også. Lighthouse anslo at det var 990 ms å spare på render-blokkerende ressurser. Å faktisk fjerne alt sammen ga 0,08 s. «Estimated savings» er nettopp det – modellerte anslag, ikke målinger. De er nyttige som pekepinn på hvor du skal se, men de er ikke et løfte du kan bokføre.
Unntaket som virkelig kostet
Ett funn gikk motsatt vei, og det er det mest lærerike. Parallaks-JavaScript på selve LCP-elementet er dyrt. Jarallax river bakgrunnsbildet ut av CSS-en og bygger sitt eget DOM, slik at preloaden ikke lenger peker på det som faktisk males på skjermen. Median falt fra 97 til 84. LCP gikk fra 2,41 s til 4,46 s.
Det samme biblioteket koster omtrent ingenting andre steder på siden. Konklusjonen er ikke «ikke bruk jarallax». Den er at presisjon i hvor du bruker et verktøy betyr mer enn om du bruker det. Generelle råd av typen «fjern tredjepartsskript» ville aldri funnet dette. Måling fant det på første forsøk.
Måledisiplinen er det egentlige poenget
Grunnen til at vi tok feil fem ganger, var ikke at vi manglet kompetanse. Det var at vi målte med noe som ikke målte.
Lokal Lighthouse ga oss 47 til 98 på byte-identisk kode. Samme filer, samme maskin, helt ubrukelig som beslutningsgrunnlag. Deretter gikk vi til PSI-API-et og trodde vi var i mål – men API-et cacher per URL. Tolv kall til samme URL kan gi deg én kjøring replayet tolv ganger. Da måler du ingenting, samtidig som du er overbevist om at du måler mye.
I tillegg er scoren bimodal. Den lander enten på rundt 71 eller rundt 98, sjelden noe imellom. En median av fem kjøringer lyver systematisk på en slik fordeling.
Oppskriften som til slutt fungerte: bruk PSI-API-et, legg på en unik query-parameter per kjøring, verifiser at fetchTime faktisk er unik, kjør minst tolv ganger, og sammenlign alltid mot en uendret kontroll i samme batch. Da – og først da – kan man si noe om en endring var en forbedring.
Og et tall det er verdt å ta innover seg: rundt 17 % av kjøringene lander på en treg sti uansett hva siden inneholder. Det er Googles måleinfrastruktur, ikke koden din. Derfor snakker vi om median og metode, ikke om at «vi har alltid 97».
Sikkerhet: A+ og en CSP uten unsafe-inline
På securityheaders.com får dops.no karakteren A+. Alle seks headere er på plass: X-Frame-Options, X-Content-Type-Options, Strict-Transport-Security, Referrer-Policy, Permissions-Policy og Content-Security-Policy.
Det mest interessante ligger i detaljene. CSP-en vår har ikke 'unsafe-inline' i script-src. Det er et bevisst og strengt valg, og det blokkerer hele klassen av inline-script-angrep. Prisen er disiplin: all JavaScript må ligge i eksterne filer. Ingen snarveier, ingen «bare denne ene lille snutten i malen». Det er en begrensning vi har valgt fordi den tvinger fram struktur som holder over tid.
Dette lar seg ikke gjøre på hvilken som helst plattform
Tallene over er ikke resultat av triksing i etterkant. De er en konsekvens av hvordan plattformen er bygget. Docly gir oss fire ting som er direkte avgjørende:
Server-rendrede maler. Innholdet ligger i rå HTML. Søkemotorer og AI-agenter kan lese siden uten at JavaScript må kjøre først. Det er derfor SEO-scoren er 100 uten at vi gjør noe spesielt for å oppnå det – det følger av arkitekturen.
Streng CSP som standard. En CSP uten 'unsafe-inline' er vanskelig å innføre i etterkant på en plattform som strør inline-skript utover malene. Når det er utgangspunktet, koster det ingenting.
Master-maler med xdt:Transform. Én endring treffer hele siten kontrollert. Det betyr at et funn fra én måling kan rulles ut overalt uten at man må vedlikeholde den samme rettelsen tolv steder.
Ingen byggesteg. En endring er live umiddelbart. Det høres ut som en bekvemmelighet, men det er faktisk forutsetningen for den arbeidsmåten under: når hver hypotese må gjennom en byggekø, blir tolv kjøringer per variant uoverkommelig, og da måler man fem ganger i stedet – og tar feil.
Hvordan vi jobber
Arbeidet er AI-drevet, men det er ikke det som gjør det til metodikk. Claude Code driver analysen og gjør endringene. Claude sin Chrome-plugin verifiserer i en ekte nettleser, ikke i kildekoden – for HTML-skanning fanger ikke brukket layout eller bilder som ikke lastes. PSI-API-et måler.
Det som skiller dette fra en gimmick, er måledisiplinen rundt. AI gjør det billig å prøve mange hypoteser raskt. Nettopp derfor blir det farlig uten et instrument som kan si «nei, det der var støy». Hastigheten er verdiløs uten en sannhetskilde. Vi tok feil fem ganger på ett døgn, og det eneste som fikset det, var å slutte å diskutere og begynne å måle skikkelig.
Hva vi tar med oss
Tre ting sitter igjen. Antakelser om ytelse er ofte feil, også blant folk som kan faget. Verktøyenes egne anslag er modeller, ikke fasit. Og forskjellen mellom en side som scorer godt og en som ikke gjør det, ligger sjelden i hva den inneholder – langt oftere i når og hvor ting kjører.
Vil du se hvordan vi bygger nettsider på dette grunnlaget, les mer om neste generasjon nettsider eller om hvordan vi jobber med webdesign. Er du nysgjerrig på tallene for din egen side, er både PageSpeed Insights og securityheaders.com gratis – og det tar fem minutter å finne ut hvor du står.