Långsam hemsida? Så testar du och gör den snabbare
Kort svar: Börja med att testa rätt sida i PageSpeed Insights på mobil, kontrollera stora bilder och se när rubrik och telefonnummer blir användbara på din egen telefon. Ändra en sak i taget och mät igen. En långsam sida kan göra det svårare att kontakta dig, men ett hastighetstest kan inte säga hur många jobb du förlorar.
Lab, fält och vikt är olika saker
- Labbmätning (till exempel PageSpeed Insights / Lighthouse): simulerad miljö, bra för att hitta orsaker, poängen kan variera mellan körningar.
- Fältdata (Chrome UX Report när den finns): hur riktiga användare upplevt sidan. Saknas data för små sajter.
- Filvikt: hur många kilobyte som laddas. Lätt att jämföra, men inte samma sak som “känns snabb”.
- TTFB: tid till första byte från servern. Lång svarstid kan bero på bland annat server, sidans kod och cache. Värdet ensamt visar inte vilken orsak som gäller.
- Upplevd snabbhet: syns rubrik och nummer tidigt, eller blockerar en cookie-ruta allt?
- Konvertering: ringer eller skickar någon? Hastighet hjälper bara om kontaktvägen fungerar. En snabb första överblick får du i Hemsidetest, där kontaktvägar och mobilprestanda ingår i samma stickprov (poängen mäter inte hur många som faktiskt hör av sig).
Googles översikt av Core Web Vitals: web.dev/vitals. De tre vanliga mätvärdena handlar om största innehållet (LCP), respons (INP) och layoutskift (CLS). Trösklar i dokumentationen är riktmärken för “bra” i Googles verktyg, inte ett löfte om fler jobb om du precis klår en siffra.
Vanliga orsaker på hantverkarsajter
- Foton uppladdade i full kamerastorlek till en smal mobilvy.
- Tunga sidbyggare som laddar CSS/JS överallt.
- Plugins som ingen använder längre.
- Tredjepartsskript: karta, video, chatt, typsnitt från andras servrar, spårning.
- Långsam server även när HTML:en är liten.
Kontrollera vilken fil eller funktion som faktiskt håller tillbaka just din sida. En tung bild och en långsam server behöver olika åtgärder; fler tillägg är inte i sig en diagnos.
Så testar du en långsam hemsida
- Öppna PageSpeed Insights och testa startsidan eller den tjänstesida kunderna faktiskt kommer till. Välj mobilresultatet.
- Skilj på verkliga användares data och den simulerade labbkörningen. En liten hemsida kan sakna fältdata utan att något är fel. Google förklarar skillnaden här.
- I labbkörningen: läs LCP, CLS och åtgärdslistan. INP hör till fältdata när den finns. Labbvärdet TBT kan hjälpa dig hitta blockerande arbete, men är inte ett uppmätt INP för dina besökare.
- Öppna samma sida på din telefon med wifi avstängt. Kan du läsa erbjudandet och trycka på telefonnumret innan resten laddat? Notera störande hopp eller överlägg.
- Gör en avgränsad ändring och kör samma test igen. Använd flera jämförbara körningar eftersom ett enskilt resultat kan variera.
Vad betyder LCP, INP och CLS?
I Googles beskrivning av Core Web Vitals är följande gränser riktmärken för en bra upplevelse i fältdata, bedömt vid den 75:e percentilen. De är inte gränser för hur många jobb en hemsida ger.
| Mått | Bra enligt Google | Vad du undersöker |
|---|---|---|
| LCP, när det största innehållet visas | Högst 2,5 sekunder | Vilket element mätningen pekar ut. Är det huvudbilden, texten eller något annat? |
| INP, respons efter en interaktion | Högst 200 millisekunder | Om knappar och menyer svarar snabbt. Kräver användarinteraktioner; ett labbvärde för TBT är inte samma mått. |
| CLS, oväntade layoutskift | Högst 0,1 | Om bilder eller annat innehåll flyttar rubriker och knappar medan sidan laddar. |
Saknas fältdata i PageSpeed Insights kan webbplatsen ha för lite underlag i Chrome UX Report. Det betyder varken godkänt eller underkänt. Använd labbkörningen för felsökning och kontrollera kontaktvägen på din telefon.
Behöver jag 100 av 100 i PageSpeed Insights?
Nej, gör inte testpoängen till ett villkor för att få använda hemsidan. Prioritera sådant som stör en riktig besökare: innehåll som dröjer, knappar som hoppar och kontaktval som inte svarar. Mät före och efter i samma typ av test, i stället för att installera flera optimeringstillägg på chans.
En enkel mätlogg
URL och datum: Vad jag ändrade: Mobil eller dator: LCP i labbkörningar före / efter: CLS före / efter: Fältdata finns: ja / nej Största bildens filstorlek före / efter: Syns rubrik och kontaktväg tidigt på min telefon: Vad blev bättre och vad behöver kontrolleras:
Praktisk kontroll: Om den största bilden pekas ut, exportera en mindre version för platsen där den används. Kontrollera att motivet fortfarande ser bra ut, byt bara bilden och jämför. En mindre fil är ett verifierbart resultat; bättre LCP måste mätas och fler kundförfrågningar följas separat.
Fixa i den här ordningen
- Skala bilder till visningsstorlek, använd moderna format (till exempel WebP/AVIF där det stöds), ange bredd och höjd så sidan inte hoppar. Bedöm både synlig kvalitet och filvikt; det finns ingen procentsats som passar alla bilder.
- Stäng av tillägg du inte kan förklara.
- Byt inbäddad karta mot statisk bild + länk, ladda video först vid klick, hosta typsnitt själv om du kan.
- Om TTFB fortfarande är dålig efter det, överväg bättre hosting.
Cookie-rutor och tredjepartsskript hör ihop: behöver du cookie-banner? Bilder i praktiken: fota egna jobb.
När det är rimligare att bygga om
Be först om en avgränsad felsökning med pris för de konkreta åtgärderna. Jämför reparation och ombyggnad utifrån kostnad, redigerbarhet och vad som fortfarande fungerar. En låg prestandapoäng ensam är inget skäl att beställa en ny hemsida. Läs när det är värt att bygga om. Vad som ingår i bygge och månadsplan står på prissidan.
Vill du ha en konkret lista för din adress, skicka den via formuläret.
En mobilprestandapoäng är en del av bedömningen, inte ett betyg på hela hemsidan. Läs hur poäng och testtäckning fungerar i Hemsidetest.