Så gör du din webbplats snabbare: en praktisk checklista

För att göra en webbplats snabbare mäter du den först med PageSpeed Insights och åtgärdar sedan den största orsaken som den pekar på, oftast överdimensionerade bilder, för mycket JavaScript, tunga typsnitt eller skript från tredje part. Sikta mot Googles "bra"-mål för Core Web Vitals: huvudinnehållet synligt inom 2,5 sekunder, svar på tryck inom 200 millisekunder och nästan ingen layoutförflyttning. De flesta sajter når dit med en handfull ändringar, inte en omskrivning.

Mät innan du ändrar något

Att gissa slösar tid. Två gratisverktyg täcker nästan alla:

• PageSpeed Insights (pagespeed.web.dev): klistra in en publik URL. Den visar fältdata från riktiga Chrome-användare (om din sajt har tillräckligt med trafik) och labbdata från en simulerad inläsning, plus en lista över specifika problem.
• Lighthouse i Chrome DevTools: samma labbtest, körs på vilken sida du kan öppna, inklusive en förhandsvisning. Testa i mobilläge; det är på telefoner med långsammare nätverk som problemen syns.

Siffrorna som betyder något är Googles Core Web Vitals. Från och med september 2026 anger Googles dokumentation på web.dev dessa "bra"-gränser, mätt vid 75:e percentilen av sidinläsningar:

INP ersatte det äldre måttet First Input Delay 2024. Om ett verktyg fortfarande rapporterar FID är det föråldrat.

Skriv ner dina startvärden. Efter varje åtgärd testar du igen så att du vet vad som hjälpte.

Var tiden går: alternativ och avvägningar

Varje vanlig orsak har en åtgärd, och varje åtgärd har en kostnad. Börja med de överst på listan; de är billigast och vanligast.

Bilder

Bilder är det vanligaste problemet och det enklaste att åtgärda. Ett 4 000 pixlar stort foto som visas 800 pixlar brett tvingar varje besökare att ladda ner fem gånger mer än de ser.

• Servera bilder i den storlek de visas, med responsiva srcset-storlekar för telefoner och datorer.
• Använd moderna format (WebP eller AVIF) och rimlig komprimering.
• Sätt width och height på varje bild så att webbläsaren reserverar utrymme. Detta ensamt åtgärdar det mesta av layoutförskjutningen.
• Lazy-ladda bilder under vecket med loading="lazy".
• Lazy-ladda aldrig huvudbilden högst upp på sidan. Googles LCP-riktlinjer är tydliga: lazy-laddning av LCP-bilden försenar den alltid. Ge den fetchpriority="high" i stället.

JavaScript

Många AI-byggda sajter är single-page-appar (SPA): webbläsaren laddar ner ett JavaScript-paket och ritar sedan sidan. Ju större paketet är, desto längre blir den tomma skärmen. Åtgärder, i ordning efter insats:

1. Ta bort det du inte använder. Be om en lista över beroenden och skär bort bibliotek som lades till en gång och glömdes: ett datumbibliotek för ett enda datum, ett helt ikonpaket för fem ikoner.
2. Dela upp per rutt. Ladda koden för adminpanelen först när någon öppnar den, inte på startsidan.
3. Förrendera publika sidor. En marknadsföringssida som levereras som riktig HTML visas innan något JavaScript körs. Detta hjälper även sökmotorer; se SEO för AI-byggda webbplatser.

Låg INP betyder oftast en lång uppgift som blockerar sidan: filtrering av en stor lista vid varje tangenttryck, eller omrendering av en hel tabell när en cell ändras. Chrome DevTools panel för prestanda visar vilken.

Typsnitt

Varje typsnittsfamilj och vikt är en fil till. Två familjer och tre eller fyra vikter brukar räcka. Förladda typsnittet som används ovanför vecket, använd font-display: swap så att texten visas direkt, och self-hosta typsnitt om den externa typsnittstjänsten är långsam för dina besökare.

Skript från tredje part

Chattwidgetar, analys, värmekartor, annonspixlar, inbäddade videor och sociala flöden laddar alla kod från andra servrar. Var och en verkar liten; tillsammans är de ofta sidans långsammaste del. Behåll de du faktiskt tittar på. Ladda resten när sidan är interaktiv, och ersätt tunga inbäddningar (en YouTube-spelare, en karta) med en lätt förhandsvisning som laddar det riktiga vid klick.

Serversvar

Time to first byte (TTFB), alltså hur lång tid servern tar på sig att börja svara, ligger under alla andra mått. Statiska sidor som serveras från ett CDN (ett nätverk av servrar nära dina besökare; se vad är ett CDN) är snabba nästan överallt. Sidor som byggs av en server vid varje förfrågan beror på den servern och dess databas. Cachning av upprepat arbete och databasindex för långsamma frågor är de vanliga åtgärderna.

Prompter som fungerar

Var specifik: namnge sidan, måttet och begränsningen. Klistra in PageSpeed Insights-resultaten om du har dem.

PageSpeed Insights rapporterar en LCP på 4,8 s på mobil för startsidan, och LCP-elementet är hjältebilden. Ändra storlek på hjältebilden och konvertera den till WebP, servera responsiva storlekar, sätt width och height, ge den fetchpriority="high" och se till att den inte lazy-laddas. Lazy-ladda varje bild under vecket. Ändra inte designen.

Granska den här appens beroenden. Lista varje paket, vad som använder det och ungefär hur mycket det lägger till i paketet. Ta bort oanvända och dela upp rutterna /admin och /settings i separata delar som bara laddas när de besöks.

Sökrutan på /products känns trög. Fördröj filtreringen, undvik att rendera om hela listan vid varje tangenttryck och paginera eller virtualisera listan om den har fler än 200 objekt.

Steg för steg

1. Testa den publicerade sidan i PageSpeed Insights på mobil. Notera LCP, INP och CLS, samt de tre största problemen som listas.
2. Åtgärda bilder först: storlekar, format, dimensioner, lazy-laddning under vecket, prioritet för hjältebilden.
3. Skär bort skript från tredje part som du inte använder, och skjut upp resten.
4. Trimma typsnitten till vad designen behöver.
5. Krymp JavaScript: ta bort oanvända paket, dela upp per rutt.
6. Förrendera publika sidor om de fortfarande renderas på klienten och LCP fortfarande är långsam.
7. Kontrollera servern: cachning, databasindex, statisk hosting för innehåll som sällan ändras.
8. Publicera igen och testa om. Fältdata i PageSpeed Insights uppdateras under de följande veckorna när riktiga besök kommer in, så bedöm tidiga resultat utifrån labbdata.

Vanliga misstag

• Att bara testa på en snabb laptop. Dina besökare använder mellanklassmobiler och ojämn mobildata. Testa i mobilläge.
• Att jaga ett perfekt 100. Labbresultatet är en vägledning. När Core Web Vitals ligger i det bra området är innehåll och användbarhet viktigare än de sista poängen.
• Att lazy-ladda allt, även hjältebilden. Det försämrar LCP.
• Att lägga till ett hastighetstillägg eller bibliotek ovanpå. Att ta bort vikt slår nästan alltid att lägga till kod för att hantera den.
• Att optimera förhandsvisningen, inte den publicerade sajten. Utvecklingsförhandsvisningar kör ooptimerade byggen. Mät den publicerade URL:en.
• Att åtgärda hastigheten en gång. Varje ny widget, bild och funktion lägger till vikt. Testa om efter stora ändringar.

Checklista för hastighet

• LCP ≤ 2,5 s, INP ≤ 200 ms, CLS ≤ 0,1 på mobil
• Bilder anpassade i storlek, komprimerade, modernt format, med width och height
• Hjältebilden lazy-laddas inte; bilder under vecket lazy-laddas
• Inga oanvända JavaScript-bibliotek; tunga rutter delade
• Två typsnittsfamiljer eller färre, huvudtypsnittet förladdat
• Endast de skript från tredje part du faktiskt använder, laddade sent
• Publika sidor förrenderade eller statiska där det går
• Testad om på den publicerade URL:en efter publicering

Hastighet och mobillayout hör ihop; se hur du gör en webbplats mobilresponsiv. För en fullständig genomgång före lansering täcker hur du tar en AI-prototyp till produktion resten.

Hastighet på Mythex

På Mythex gör du dessa ändringar genom att be i chatten, eller i kodredigeraren på Pro. Kontrollera den publicerade URL:en, inte förhandsvisningen, eftersom förhandsvisningen kör en utvecklingsserver. Statiska frontend-delar driftsätts som statiska sajter när du publicerar (statiska webbplatser), vilket passar innehållssidor. Appar med en server skalas ner till noll: de somnar när de är overksamma och vaknar vid nästa besök, så den första förfrågan efter en tyst period är långsammare, och en kopplad databas somnar efter 5 minuter utan aktivitet (gränser för hosting). Om en publik sida bara är långsam vid första besöket är det troligen orsaken. Att hålla marknadsföringssidor statiska hjälper. Efter ändringar publicerar du igen och gör en hård uppdatering.

Frågor