Web Performance Audit: 15 åtgärder som ger 90+ Lighthouse-poäng

Nar nagon sager att deras sajt kanns langsam ar det forsta jag gor att be om siffror. Kanslan ar ofta ratt, men den racker inte for att veta var problemet sitter eller om en atgard faktiskt hjalpte. En web performance audit och matvardena i Core Web Vitals ger oss ett gemensamt sprak for det dar: tre matvarden som beskriver hur en sida upplevs av den som faktiskt sitter och vantar pa den. I den har guiden gar jag igenom vad de mater, hur jag prioriterar och vilka flaskhalsar jag oftast stoter pa.

Vad Core Web Vitals faktiskt mater

Det handlar om tre saker. Largest Contentful Paint, eller LCP, mater hur lang tid det tar innan det storsta synliga elementet pa sidan har ritats upp. Det ar oftast en hjaltebild eller en rubrik och sager nagot om hur snabbt sidan kanns laddad. Interaction to Next Paint, INP, mater hur lang tid det tar innan sidan svarar nar nagon klickar eller skriver. Cumulative Layout Shift, CLS, mater hur mycket innehallet hoppar runt medan sidan laddas.

Det fina med de tre ar att de tacker tre helt olika sorters upplevd langsamhet. En sida kan ladda snabbt men kanna seg vid klick, eller ladda fint men flytta knappen precis nar du ska trycka. Genom att titta pa alla tre slipper man optimera fel sak.

Faltdata och labbdata ar inte samma sak

En vanlig fallgrop ar att man kor ett verktyg som Lighthouse en gang i en snabb webblasare pa en snabb uppkoppling och tror att man har sanningen. Det ar labbdata, en kontrollerad matning under fasta forhallanden. Den ar bra for att jamfora fore och efter, men den sager inte hur dina riktiga besokare har det.

Faltdata, ibland kallat RUM eller real user monitoring, samlas in fran riktiga besok pa riktiga enheter och uppkopplingar. Det ar den datan Google faktiskt anvander och det ar den jag litar pa nar jag ska veta om en andring gjorde skillnad i verkligheten. Min vana ar att anvanda labbdata for att felsoka och faltdata for att bekrafta.

Sa prioriterar jag nar allt kanns langsamt

Allt gar inte att fixa pa en gang, och allt ar inte lika mycket vart att fixa. Jag borjar nastan alltid med LCP, eftersom den paverkar det forsta intrycket mest och ofta har de tydligaste orsakerna. Darefter tittar jag pa CLS, som brukar vara billig att atgarda nar man val hittat boven. INP lamnar jag ofta till sist eftersom den kraver mer arbete med hur JavaScript kor.

• Mat forst, gissa aldrig. Utan en baslinje vet du inte om du forbattrar eller forsamrar.
• Atgarda en sak i taget och mat om, sa du vet vad som faktiskt gjorde skillnad.
• Borja med de sidor som har mest trafik, inte de som ar enklast att fixa.

De flaskhalsar jag oftast hittar

For LCP ar det nastan alltid bilder som ar for stora eller laddas for sent, eller en server som svarar langsamt pa forsta anropet. Att komprimera bilder, skicka dem i moderna format och prioritera den bild som syns forst loser ofta halva problemet. En langsam serverrespons doljer sig ibland bakom en databas som behover ses over.

For CLS ar boven oftast bilder eller annonser utan reserverad plats, eller typsnitt som byts ut mitt i laddningen sa att texten hoppar. For INP handlar det om for mycket JavaScript som blockerar huvudtraden precis nar anvandaren forsoker interagera.

Tredjepartsskript ar ofta den dolda boven

Nar jag granskar en sajt som kanns trog hittar jag nastan alltid ett knippe tredjepartsskript som ingen riktigt minns varfor de finns dar. Analysverktyg, chattwidgetar, A/B-testverktyg och annonser laggs pa over tid och var och en kostar lite. Tillsammans kan de ata upp halva budgeten for INP.

Mitt rad ar att med jamna mellanrum inventera vilka skript som faktiskt anvands och ta bort dem som ingen langre behover. Det som maste vara kvar kan ofta laddas senare eller pa ett satt som inte blockerar resten av sidan. Det ar enkel optimering som inte kraver att man ror sin egen kod.

Gor det till en vana, inte ett engangsprojekt

Det som gor mig mest besviken ar nar ett team lagger ner veckor pa att optimera och sedan later siffrorna glida tillbaka. Prestanda ar inte ett projekt man blir klar med, det ar nagot som forsamras lite for varje ny funktion om ingen haller koll. Jag brukar satta upp matning som loper kontinuerligt och en enkel budget for hur stor en sida far bli, sa att forsamringar syns direkt i stallet for forst nar besokarna borjar klaga.

Om du vill se hur det har ser ut i skarpt lage har jag samlat ett par konkreta exempel pa optimeringar i var casebook, dar bade utgangslaget och resultatet finns med.

Sa hanger matvardena ihop med affaren

Det ar latt att se en web performance audit som en teknisk ovning, men jag brukar paminna om att den mater nagot som faktiskt paverkar verksamheten. En sida som kanns trog gor att besokare hoppar av innan de ens sett vad du erbjuder, och det syns direkt i hur manga som stannar kvar och slutfor det de kom for. Jag har sett hur en tung forsta laddning tappar besokare i exakt det ogonblick da de ar som mest otaliga.

Darfor forsoker jag alltid koppla en matning till nagot konkret i stallet for att stirra pa en isolerad siffra. Fragan ar inte om LCP gick fran ett varde till ett annat, utan om fler besokare stannar och gor det de kom for. Nar man ramar in arbetet sa blir det ocksa mycket lattare att motivera tid for prestanda infor dem som haller i budgeten, eftersom det da handlar om affar och inte om teknik for sin egen skull.

Relaterat

• API-svarstid under 100 ms: Caching-strategier med Redis och CDN
• Teknisk skuld-inventering: Metrik, prioritering och 90-dagarsplan
• Bundle-optimering för Next.js: Tree-shaking, code splitting och lazy loading

Vill du ta det vidare?

Om din sajt kanns langsam och du vill veta var det faktiskt sitter kan vi ta ett forutsattningslost samtal dar jag tittar pa dina matvarden. Du kan ocksa lasa mer om hur jag jobbar med optimering eller titta i var casebook for konkreta exempel.