Den trege siden som betyr noe, er ikke hjemmesiden

Sammendrag

Når sjefen din sier at nettstedet er tregt, er instinktet å begynne å komprimere bilder og beklage deg overfor hjemmesiden. Det mer nyttige trekket er å bestemme hvilken side som faktisk er verdt å gjøre raskere først. Denne artikkelen går gjennom ett scenario: et lite markedsteam som blir bedt om å "fikse hastigheten" for et mellomstort B2B-nettsted. Den dekker måling av Core Web Vitals med feltdata, valg av sider basert på forretningsmessig påvirkning, og inkludering av strukturert data først etter de billige fiksene. Utbyttet er en kort, forsvarlig plan som gir mening for en ikke-teknisk sjef.

Den tregeste siden på nettstedet ditt er ikke den PageSpeed Insights flagger. Det er siden sjefen din aldri har åpnet – den som er knyttet til en betalt kampanje, eller begravd i en glemt produktseksjon – og det er den som faktisk avgjør om denne månedens budsjett produserer noe. Når noen på ledernivå sier "nettstedet er tregt, fiks det", trenger de ikke et nettsidehastighetsprosjekt. De trenger en prioriteringsøvelse.

Ta et scenario mange av oss har opplevd. Du er hele markedsteamet for et mellomstort B2B-programvareselskap. Nettstedet har en hjemmeside, en blogg, et hjelpesenter og fem landingssider knyttet til spesifikke annonsekampanjer. Sjefen din leste en artikkel om Core Web Vitals eller hørte en kundeklage. Instruksen er klar: gjør det raskere.

Hvordan du svarer i løpet av den neste timen avgjør om du tilbringer den neste måneden med å komprimere bilder eller gjøre arbeid som endrer tallene som betyr noe.

Begynn med siden som tjener, ikke den som er pinlig

Prinsippet: hastighetsarbeid har en avkastning, og den avkastningen avhenger av trafikk og konverteringsverdi. En side med lav trafikk men høy konvertering kan bety mer for virksomheten enn hjemmesiden, selv om den er tregere.

Så det første trekket er å lage en liste over sider fra analyser, ikke fra nettstedskartet. Hvilke sider mottar penger i form av annonseklikk? Hvilke sider har ikke blitt rørt siden lansering? I dette scenarioet ble den viktigste landingssiden – den bak en betalt søkeannonse som har kjørt i to måneder – bygget med store, uoptimaliserte skjermbilder. Hjemmesiden, derimot, ble allerede optimalisert av et byrå for et år siden.

Du fikser ikke hjemmesiden først. Du fikser siden som tjener penger. Det er ikke et teknisk valg, det er et forretningsvalg. Hvis en full teknisk revisjon høres ut som den rette responsen, motstå det et øyeblikk. Revisjoner produserer en liste; de forteller deg ikke hvilket element du skal begynne med. En veldefinert teknisk SEO-revisjon er et beslutningsverktøy, ikke en panikkrespons.

Du vil ofte finne at et lite antall sider genererer mesteparten av trafikken og konverteringene; resten er informative eller vestigiale. Det er ikke en grunn til å ignorere de trege informative sidene for alltid. Det er en grunn til å sekvensere dem etter sidene som har en direkte linje til inntekter. Hjemmesiden kan være den tregeste av alle, men hvis forretningsmålet er leads, er et besøk på hjemmesiden bare et startpunkt – landingssiden er der noen faktisk konverterer.

Del "rask" inn i "målt" og "følt"

Det andre steget er å skille hva ytelsestester sier om siden din fra hva faktiske brukere opplever. Googles dokumentasjon for Core Web Vitals navngir tre beregninger som teller mot søkerangeringer: Largest Contentful Paint (lasting), Interaction to Next Paint (responsivitet) og Cumulative Layout Shift (visuell stabilitet). De betyr noe fordi de sporer øyeblikk som påvirker om noen faktisk kan bruke siden.

I scenarioet åpner du landingssiden i en ytelsestester og får en rimelig poengsum. Men når du sammenligner det med feltdata i Google Search Console – som gjenspeiler virkelige opplevelser fra besøkende – viser det seg at siden ofte er treg. Det er signalet som betyr noe. Labtester er fortsatt nyttige etter en endring, for å sammenligne før og etter. Men feltdata er grunnsannheten for personer som klikket på annonsen din fra en rekke enheter og tilkoblinger.

I stedet for dette	Begynn med dette	Hvorfor
PageSpeed-poengsum som ett tall	Core Web Vitals feltdata	Feltdata kommer fra faktiske brukere, ikke en testserver
"Nettstedet er tregt"	Hvilke sider støtter forretningsmål	Raske ubrukelige sider genererer ikke leads
Bygg om CMS-et	Komprimer bilder og rydd opp i skript	Lavrisikofikser gir mesteparten av fordelen

Hvis du vil ha en dypere referanse senere, kan en Core Web Vitals-guide gå gjennom hver beregning. Men foreløpig trenger du bare nok til å bygge planen. Nøkkelen er å navngi hvilken av de tre beregningene som faktisk forårsaker problemet på den spesifikke siden. Hvis teksten vises sent, se på bilder og serverrespons. Hvis knapper føles hakkete, se på lange JavaScript-oppgaver. Hvis oppsettet hopper, se på plasser forbeholdt annonser og innebygd innhold. Den nyansen er det som skiller en målrettet fiks fra en tilfeldig optimalisering.

Fiks de billige tingene før de dyre tingene

Det tredje prinsippet: ikke la et ytelsesprosjekt blåse opp til en redesign. De fleste forbedringene som faktisk flytter brukeropplevelsen er uglamorøse og billige.

Se på landingssiden og navngi de åpenbare synderne. Bildene er fulloppløselige skjermbilder. Det er et tredjepartsskript på siden som ingen lenger kan identifisere. En nettskrift blokkerer tekst fra å vises. Dette er kjente problemer.

I en perfekt verden ville du brukt en uke på å skrive siden på nytt med et moderne rammeverk. I praksis starter du med halvdagsoppgaver: komprimer bilder, utsett det ubrukte skriptet, forhåndslast hero-bildet. Du kan teste disse endringene på en ettermiddag, og de krever ikke en godkjenningskomité.

Advarsel: hastighet er ikke alltid så enkelt. Noen sider er trege på grunn av en server, en database eller en tredjepartsavhengighet du ikke kontrollerer. Men hvis du ikke har sjekket de billige fiksene, kan du ennå ikke rettferdiggjøre den dyre. Mange team kaster bort et budsjett på en ombygging fordi de aldri komprimerte skjermbildene. Det er en ydmykhet her som er verdt å beholde: en ytelsespoengsum er et symptom, ikke en diagnose. De billige fiksene er diagnostiske i seg selv. Etter at du har komprimert bildene, lærer du om flaskehalsen var innholdet ditt eller infrastrukturen din.

Legg til strukturert data mens du uansett er i koden

Dette er laget som overrasker sjefen. Etter at du har gjort de billige fiksene, er du allerede inne på siden. Det er det rette øyeblikket å legge til noe som ikke handler om hastighet i det hele tatt: strukturert data.

Strukturert data er markering som hjelper søkemotorer med å forstå hva en side inneholder. Det er den samme HTML-en som kan føre til rikere søkeresultater og bedre synlighet – og den blir mer relevant etter hvert som søk beveger seg mot AI-genererte svar. For et lite team er dette en underutnyttet spak fordi det ikke krever å skrive nytt innhold. Du merker det som allerede finnes.

I scenarioet legger du til et tjenesteorientert skjema på landingssiden. Den nøyaktige typen avhenger av hva siden handler om: en tjenesteside, en artikkel, et produkt. Du trenger ikke å legge til alle typer på en gang. Å legge til én nøye er bedre enn å legge til ti slurvete. Ingen resultat er garantert; Google bestemmer hva som vises. Men risikoen er lav og den potensielle fordelen er reell. Hvis du bestemmer deg for å gå dypere, dekker en implementeringsguide for strukturert data de praktiske trinnene.

Oversett fiksene til "tjente det penger?"

Den vanskelige delen er ikke det tekniske arbeidet. Det er måten du presenterer det for en ikke-teknisk sjef.

Sjefen din ba om én ting: gjør nettstedet raskere. Hvis du sier "vi forbedret LCP på landingssiden", kan du få et tomt blikk. I stedet oversetter du arbeidet til forretningsmessige konsekvenser.

I dette scenarioet er landingssiden destinasjonen for en betalt kampanje. Hvert sekund den venter er et sekund der en besøkende kan forlate før handlingsoppfordringen vises. Så du forklarer: vi fjernet åpenbare friksjoner på siden der penger skifter hender. Du kan ikke love et spesifikt rangeringsopprykk – den som gjør det, gjetter – men du kan komme med et rimelig, ærlig argument. Du kan også knytte dette til budsjettet sjefen din allerede forstår. Den samme annonsekostnaden kjøper et besøk; forskjellen er om det besøket har en sjanse til å bli en lead.

En enkel månedlig rapport fungerer bedre enn et dashbord fullt av sjargong. Vis tre ting: hvilken side du valgte, hvilken beregning du målte, og hva du endret. Hvis beregningen forbedres, er det validering. Hvis den ikke gjør det, har du fortsatt et tydelig eksperiment å vurdere på nytt. Ikke jag en enkelt poengsum måned etter måned; Core Web Vitals svinger med trafikksammensetning, enhetstyper og til og med geografisk region. Rapporter trenden, ikke tallet.

Hva du skal gjøre neste mandag

Lærdommen fra scenarioet: du fikser ikke "nettstedet." Du fikser en spesifikk side, basert på data, og du ender opp med en repeterbar prosess i stedet for et engangsprosjekt. Når noen med makt sier "gjør det raskere", er det mest nyttige svaret ett enkelt avklarende spørsmål: hvilken side, og for hvem?

Deretter måler du feltdata, fikser de billige tingene, legger til strukturert data hvis du allerede er i koden, og rapporterer på et enkelt språk. Resultatene er kanskje ikke dramatiske. Men du vil vite nøyaktig hvilken side som ble raskere, hvorfor du valgte den, og hva du skal gjøre videre. Det er et bedre resultat enn et vagt prosjekt som startet med en hastighetspoengsum og endte i en redesign som ingen forsto.