Hvorfor vi ikke gir deg en ytelsesgaranti

Du har sannsynligvis sett en ytelsesgaranti i et tilbud: «Vi garanterer PageSpeed 90+.» Det høres trygt ut. Et tall er lettere å forholde seg til enn en samtale om avveininger.

Problemet er at leverandøren ikke kan holde det. Ikke fordi vedkommende er uærlig, men fordi tallet ikke er leverandørens eiendom etter at nettsiden er levert. Det er ditt — og det beveger seg hver gang du gjør noe helt normalt med nettstedet.

---

Vil du vite hvor nettsiden din står i dag? Vi måler den som den er nå og forteller deg hva som drar den ned — be om en gjennomgang.

Slik vurderer vi — og hvorfor dette er en posisjon

Dette er ikke en måling. Det er en posisjon.

Alt annet vi publiserer i bloggen vår bygger på tall vi har hentet fra en kilde og kontrollert. Denne artikkelen gjør noe annet: den argumenterer for en praksis. Vi mener ytelsesgarantier er et løfte ingen leverandør kan innfri. Det er en holdning, ikke et forskningsresultat — du kan være uenig. Grunnlaget vårt er:

• Hvordan Core Web Vitals er definert og målt av Google, som er offentlig dokumentert
• Hva som skjer med et nettsted etter overlevering, i prosjektene vi selv har driftet
• At det som endrer scoren mest, nesten alltid ble lagt til etter at vi var ferdige

Endrer måleverktøyene seg, eller endrer Google hvilke måltall som inngår, blir artikkelen utdatert. Den gjennomgås derfor på nytt når det skjer. Sist gjennomgått 14. august 2026.

Skrevet av Svein Tore Olsen, daglig leder i Ebizapple.

---

Hva Core Web Vitals faktisk måler

Begrepene først, nøkternt. Core Web Vitals er Googles samlebetegnelse på tre måltall som beskriver hvordan en side oppleves av den som besøker den:

LCP — Largest Contentful Paint. Måler når hovedinnholdet er synlig. Altså hvor lenge brukeren ser på noe som ennå ikke er artikkelen eller produktbildet hun kom for.

INP — Interaction to Next Paint. Måler responstiden når noen klikker på en knapp, åpner en meny eller huker av i et skjema.

CLS — Cumulative Layout Shift. Måler hvor mye layouten hopper mens siden laster: du sikter på en lenke, et bilde laster ferdig over den, og du treffer noe annet.

Google publiserer terskelverdier for hva de regner som god, middels og dårlig. De er nyttige å kjenne til — men de er Googles målestokk for eget bruk, ikke en kontrakt et byrå kan skrive under på dine vegne. Å bygge mot en målestokk er fornuftig. Å garantere en plassering på den, er noe annet.

Og her er det som gjør garantien vanskeligere enn den ser ut: de tre måltallene stammer egentlig fra to helt ulike datakilder. En laboratoriemåling er verktøyet som laster siden én gang, på en simulert enhet, med en simulert forbindelse — det Lighthouse og laboratoriedelen av PageSpeed Insights gjør. Felt- og brukerdata er det motsatte: anonyme målinger fra ekte besøkende, på det utstyret og nettet de faktisk har. Googles innsamling av dette heter CrUX (Chrome User Experience Report), og det er den kilden som brukes når Core Web Vitals omtales i forbindelse med søk.

Forskjellen er ikke akademisk. En laboratoriemåling kan gjøres på minuttet og gjentas i det uendelige. Felt- og brukerdata bygger seg opp over et rullerende vindu av de siste ukenes besøk, og de speiler publikummet ditt — bor kundene dine i et område med svakt mobilnett, ser du det i CrUX og ikke i laboratoriet. Et byrå som garanterer «en score» sier sjelden hvilken av de to som skal gjelde. Det alene gjør løftet umulig å etterprøve.

---

Hvor mye betyr Core Web Vitals for rangering i Google?

Dette er spørsmålet bak garantien. Nesten ingen ber om et tall fordi de er glad i måltall. De ber om det fordi de har hørt at Google straffer trege sider, og at scoren avgjør om de blir funnet. Det fortjener et ærlig svar, og det ærlige svaret er verken ja eller nei.

Ja, det brukes. Googles egen dokumentasjon sier det rett ut i FAQ-en: «Core Web Vitals are used by our ranking systems.» Samme sted avviser Google at det finnes ett samlet mål for brukeropplevelse — «There is no single signal» — og at gode tall i rapportene betyr noe i seg selv: å få gode resultater i Search Console eller i tredjepartsverktøy «doesn’t guarantee that your pages will rank at the top of Google Search results» (Understanding page experience in Google Search results).

Men relevans går foran. På spørsmålet om hvor mye dette betyr, svarer Google samme sted: «Google Search always seeks to show the most relevant content, even if the page experience is sub-par.» En rask side som ikke svarer på det folk søkte etter, blir altså ikke løftet forbi en tregere side som gjør det. Rekkefølgen er innhold først.

Rollen er å skille mellom sider som ellers ligner. Ordet «tiebreaker» kommer ikke fra Google — det er bransjens omskriving. Men substansen står i annonseringen fra mai 2020: «A good page experience doesn’t override having great, relevant content. However, in cases where there are multiple pages that have similar content, page experience becomes much more important for visibility in Search» (Evaluating page experience for a better web). Dagens formulering er mykere, men peker samme vei: for mange søk finnes det mye nyttig innhold, og i de tilfellene kan brukeropplevelsen bidra.

Signalet er blitt vanskeligere å peke på, ikke borte.

Retningen er verdt å merke seg: fra en oppdatering med navn og dato til noe som er løst opp i de ordinære systemene. Det gjør det ikke uvesentlig. Det gjør det umulig å isolere — og dermed umulig å selge som et tall.

Og det er felt-dataene som gjelder. Om Core Web Vitals-rapporten i Search Console skriver Google at den viser hvordan sidene presterer «based on real world usage data (sometimes called field data)», hentet fra CrUX. Les det sammen med forrige seksjon: tallet som eventuelt kan bety noe for søk, er ikke det du får ut av en laboratoriemåling en tirsdag ettermiddag. Det er hva de faktiske besøkende dine opplevde over de siste ukene. En garanti skrevet på et laboratorietall garanterer feil tall. Og har siden få nok besøkende, har Google ikke nok data om den til å vise den i rapporten i det hele tatt.

Hjelper en perfekt score hvis innholdet ikke svarer på søket? Nei, og det er ikke vår vurdering — det er Googles. I samme FAQ står det at «trying to get a perfect score just for SEO reasons may not be the best use of your time».

Så hvorfor bygge riktig likevel? Fordi begrunnelsene som holder, er de som ikke avhenger av hva Google gjør neste år. En lett DOM og få lag mellom innholdet og nettleseren — komponenter før sider — gjør siden raskere for mennesket som venter, uansett hvordan signalet vektes. Det er den samme grunnen til at vi ikke lover et tall: tallet er en konsekvens av byggemåten, ikke omvendt. Du bygger for brukeren, ikke for måleren.

---

De fire tingene leverandøren slipper taket i

Når vi leverer et nettsted, går kontrollen over til deg. Slik skal det være. Men da flytter fire av de viktigste variablene seg over på din side av bordet.

1. Innholdet du legger inn senere

En nettside som måles ved lansering, måles på sidene vi bygde. Et halvt år senere finnes det landingssider og produktsider ingen hos oss har sett — lengre sider, flere elementer, tyngre seksjoner. Det er ikke feil, det er at nettstedet lever. Men det er ikke det samme nettstedet vi målte.

Det gjelder dobbelt for sider som ikke er skrevet for hånd i det hele tatt. På dynamiske nettsider bestemmes sidelengden av dataene bak: en oversikt med tolv oppføringer og en med tolv hundre er samme mal, men to helt ulike sider å laste.

2. Bildene du laster opp

Den vanligste enkeltårsaken vi ser. Et bilde rett fra mobilkameraet, i full oppløsning, vist i en brøkdel av størrelsen. Nettleseren laster likevel ned hele filen. Ett slikt bilde over brettet kan alene flytte LCP-tallet merkbart — og det tar tre sekunder å gjøre i administrasjonspanelet.

To grep gjør det meste av jobben, og begge er tekniske i navnet og banale i praksis. Det ene er bildeformat: det samme motivet lagret som WebP blir som regel vesentlig mindre enn den samme JPEG-en, uten synlig forskjell for øyet. Det andre er lat lasting — at bilder som ligger langt nede på siden først hentes når brukeren nærmer seg dem. Lat lasting hjelper på alt som ligger under brettet, men skal aldri settes på hovedbildet øverst: da utsetter du nettopp det elementet LCP måler.

3. Tredjepartsskriptene du kobler på

Chat-widget. Analyseverktøy. Annonsepiksel. Bookingmodul. Informasjonskapsel-banneret som må laste før alt annet, fordi det avgjør om resten får lov til å laste.

Hver av disse er kode fra noen andre, hentet fra noen andres server, som kjører i din brukers nettleser. Vi kontrollerer verken hvor rask den serveren er, hvor stor filen blir neste uke, eller hva skriptet gjør. En garanti som omfatter dette, ville vært en garanti på vegne av tredjeparter vi ikke har avtale med.

To varianter er verdt å skille mellom. En sporingspiksel — det lille kallet et annonsenettverk ber deg legge inn for å telle konverteringer — er som regel liten og billig i seg selv, men den kommer nesten alltid med et skriptbibliotek på slep. Verre er gjengivelsesblokkerende ressurser: skript eller stilark som nettleseren må laste ned og kjøre før den får lov til å tegne noe som helst på skjermen. Ett slikt skript, plassert øverst i sidehodet, holder hele siden tom mens det laster. Det er derfor et informasjonskapsel-banner rammer hardere enn størrelsen skulle tilsi: det er ikke stort, det er først i køen.

Denne avveiningen er beslektet med den vi beskriver for betalingsløsninger i nettbutikk — hvert ekstra tredjepartsledd i kassen koster noe, og tre er som regel nok.

4. Målemetoden du bruker

Selv uten at noe endres på nettstedet, kan tallet flytte seg mellom to tester. Det finnes nemlig flere måter å måle på:

Kjør samme test tre ganger på rad, og du får ofte tre ulike resultater. Verktøyet måler en enkelthendelse, ikke en egenskap ved siden. Å garantere et tall som varierer mellom to kjøringer av samme test, er å garantere noe man ikke har definert.

---

Fundamentet: det vi faktisk kan love

Det vi styrer, og som ikke forsvinner den dagen du overtar, er selve byggemåten.

Vi bygger på et fundament som ikke jobber mot deg. En lett DOM — færre unødvendige lag med kode rundt hvert element — og ingen plugin stablet oppå plugin for å løse noe som kan bygges direkte. Samme tankegang som i komponenter før sider: færre og bedre byggeklosser, gjenbrukt bevisst.

DOM-størrelsen er den mest oversette delen av dette. DOM-en er trestrukturen av elementer nettleseren bygger opp av HTML-en, og hvert eneste element koster noe å lage, style og tegne på nytt når noe endrer seg. En sidebygger som pakker hver knapp inn i fire lag containere gir deg et tre som er flere ganger større enn det trenger å være — på en side som ser helt lik ut. Det er en kostnad som følger nettstedet hver eneste sidevisning, i årevis, og den er nesten umulig å rette i etterkant uten å bygge om.

Bilder i riktig format og størrelse. I dimensjonene de faktisk vises i, konvertert til et moderne bildeformat som WebP, med lat lasting på det som ligger under brettet og plass reservert i layouten så siden ikke hopper.

Caching og levering. At en side som ikke har endret seg, ikke bygges opp på nytt for hver besøkende, er caching — det billigste ytelsestiltaket som finnes. Har du besøkende langt unna serveren, gjør et CDN den neste jobben: kopier av filene ligger på maskiner nær brukeren, slik at avstanden ikke er hver enkelt besøkendes problem. Begge deler hører hjemme i fundamentet på en WordPress-nettside, ikke i en plugin man legger på når det først har blitt tregt.

Vi måler før og etter, og viser deg tallene. Ikke som bevis, men som et utgangspunkt du kan sammenligne mot senere.

Vi sier fra når noe du ber om koster deg fart. Vil du ha chat-widget, tre analyseverktøy og videobakgrunn på forsiden, kan du få det — men du hører hva det koster før du bestemmer deg.

Vi lover ikke et tall. Fordi et tall du kan miste ved å installere én widget, ikke er et løfte verdt å gi.

Samme prinsipp som i betalingsløsninger for nettbutikk: vis hvor kostnaden ligger, framfor å oppgi ett tall som ser betryggende ut.

Garanterer ett av tilbudene dine en score? Spør hva som skjer med garantien den dagen du legger inn en chat-widget — eller ta kontakt med oss for en gjennomgang av ditt eget nettsted.

---

Den ubehagelige delen: hvem optimaliserer man for?

Så langt har argumentet vært at garantien er umulig å holde. Det finnes et argument til, og det er verre.

Et byrå som har lovet deg en bestemt score, har fått et insentiv til å optimalisere for testen. Ikke for brukeren din. Testen kjøres på én side, på ett tidspunkt, av en simulert enhet. Brukeren din kommer inn hvor som helst. Det finnes teknikker som pynter på det første uten å hjelpe det andre: utsette innlasting til etter at måleren har sluttet å telle, eller flytte tunge deler av siden ut av det måleren ser på.

Ingenting av dette gjør nettstedet raskere for et menneske. Det gjør tallet penere. Og når tallet er det leverandøren måles på, er det tallet som prioriteres når tiden er knapp. Det er ikke det samme.

Vi bruker samme resonnement på tvers av fagene våre. Når vi graderer en produktkatalog fra N1 til N5 før vi priser jobben, er poenget det samme: lever en måling mottakeren kan etterprøve, framfor et tall som ser betryggende ut i et tilbud.

---

Når er ytelse faktisk problemet?

Det motsatte av å garantere et tall er ikke å blåse i fart. Det er å vite når fart er problemet, og når det er noe annet som ser ut som fart. Tabellen under er vurderingen vår, ikke en fasit — og flere av radene ender i «ikke gjør noe».

Legg merke til at byggemåten står nederst, ikke øverst. Den er den viktigste over tid og den dyreste å endre — og derfor den siste du bør gå løs på hvis bildene og skriptene ikke er ryddet først.

---

Spør om dette i stedet

Bytt ut «kan dere garantere 90+» med:

1. Hvor mange lag med kode ligger mellom innholdet mitt og nettleseren?
2. Skaleres og konverteres bilder jeg laster opp automatisk?
3. Måler dere før og etter, og får jeg se tallene?
4. Sier dere fra hvis noe jeg ber om koster fart?

Spørsmål to er viktigere enn det ser ut. Skjer skaleringen og konverteringen til WebP automatisk ved opplasting, slipper den som skriver innhold å tenke på det — og da skjer det faktisk. Skal det gjøres for hånd, skjer det i tre måneder. Det er det samme argumentet vi bruker for automatisering ellers: det som må huskes, blir glemt.

Svarene sier mer om nettstedet om ett år enn et tall i et tilbud gjør — ikke minst for dynamiske nettsider, der antallet elementer varierer med dataene bak, og der DOM-størrelsen derfor er noe du arver fra malen, ikke fra siden.

---

Spørsmål om ytelsesgaranti og Core Web Vitals

Kan et byrå garantere PageSpeed 90 eller høyere?

Ikke på en meningsfull måte. De kan garantere et tall på én side, med ett verktøy, på ett tidspunkt — før du har lagt inn eget innhold og egne skript. Garantien gjelder til første gang du bruker nettstedet som normalt.

Betyr dette at dere ikke bryr dere om hastighet?

Tvert imot. Vi bryr oss om den delen vi kan påvirke: byggemåten, koden, bildehåndteringen og hva vi advarer deg mot. Vi lover bare ikke et resultattall andre kan endre etter oss.

Hvorfor får jeg forskjellig score hver gang jeg tester?

Fordi laboratorieverktøy måler én enkelt innlasting under simulerte forhold, og nettverk, serverbelastning og simulert enhet varierer. Faktiske brukermålinger er mer stabile — men speiler hva brukerne dine har av utstyr og nett, ikke et ideelt laboratorium.

Hva er LCP, INP og CLS, kort fortalt?

LCP måler når hovedinnholdet er synlig. INP måler hvor raskt siden svarer når noen klikker eller trykker. CLS måler hvor mye layouten hopper mens siden laster.

Ødelegger chat-widgeten og analyseverktøyene farten min?

De koster noe, alltid. Ett verktøy som lastes riktig er sjelden et problem. Fem skript som alle vil kjøre først, er det. Du skal vite prisen før du sier ja, ikke oppdage den et halvt år senere.

Hva gjør jeg hvis nettsiden min allerede er treg?

Mål den først. Rekkefølgen er nesten alltid den samme: bildene, tredjepartsskriptene, og til slutt byggemåten. De to første er ofte raske å rette. Den tredje er en større samtale.

---

Videre lesing om nettsider og ytelse

• Oxygen 6: komponenter før sider — slik slipper vi unødvendige lag i DOM-en
• WordPress-nettsider — hva som ligger i fundamentet, inkludert caching
• Dynamiske nettsider — når byggemåten betyr mest
• Betalingsløsning for nettbutikk — samme prinsipp, andre tall
• PayPal, Stripe og kort i WooCommerce — kassen er også tredjepartsskript
• N1 til N5: hvor vanskelig er katalogen din? — en måling framfor en gjetning
• Automatisering — det som må huskes, blir glemt
• Når to modeller er uenige — om kontroller du ikke kan kontrollere
• Alle artikler i bloggen

Vil du vite hva som drar ned farten på nettstedet ditt? Vi måler det som det er i dag og går gjennom funnene med deg — ta kontakt.