Så får du en snabbare hemsida

Börja med det som besökaren faktiskt märker

En snabb hemsida visar användbart innehåll tidigt, reagerar när någon trycker och håller layouten stilla medan resten laddas. Det räcker alltså inte att startsidan ser färdig ut på din egen dator. Besökaren kanske använder en äldre telefon, har sämre uppkoppling eller öppnar en produktsida som aldrig ligger i cache. Arbetet blir mer träffsäkert när du utgår från sådana situationer.

Den här guiden hjälper dig att hitta flaskhalsen, välja en rimlig åtgärd och kontrollera att förändringen verkligen fungerar. Du behöver inte börja med att byta webbhotell eller installera ett nytt tillägg. Börja i stället med en viktig adress: exempelvis den tjänstesida där kunder kontaktar dig eller den artikel som många nya läsare kommer till.

Skriv ned vad som känns långsamt. Är skärmen tom? Väntar huvudbilden på sig? Fryser menyn efter ett tryck? Hoppar knappen undan när en bild dyker upp? Dessa observationer är användbara ledtrådar. De hjälper dig att ställa rätt fråga när du senare granskar en rapport med många tekniska termer.

Gör förändringarna på en kopia om de påverkar kod, cache eller tillägg. Förbered en säkerhetskopia som går att återställa och dokumentera de gamla inställningarna. En förbättrad mätning är inte värd mycket om kontaktformuläret samtidigt slutar fungera.

Mät på ett sätt som går att upprepa

Välj tre representativa sidor: en vanlig ingångssida, en innehållssida med bilder och en sida med en viktig funktion. Har du en butik kan den tredje sidan vara kassan. Testa mobil och dator separat. Spara adress, datum, testläge och om du var inloggad. Annars blir det svårt att veta om du jämför samma sak efter ändringen.

PageSpeed Insights skiljer mellan fältdata från verkliga besök och ett laboratorietest under bestämda förhållanden. Fältdata beskriver en period, inte bara den senaste publiceringen. De kan därför släpa efter en förbättring. Laboratorietestet kan ge snabbare återkoppling på en enskild ändring, men det återskapar inte alla besökares enheter, nätverk och beteenden.

Kontrollera om fältvärdena gäller den enskilda adressen eller hela webbplatsens ursprung. En mindre sida kan sakna tillräckliga data. Det betyder varken att den är snabb eller att den är långsam. Använd då kontrollerade tester och egna besökarflöden som underlag, och var tydlig med vad du faktiskt har mätt.

Kör gärna samma laboratorietest tre gånger och jämför medianen. Det är en praktisk arbetsmetod för att minska betydelsen av ett enstaka avvikande resultat, ingen garanti för statistisk säkerhet. Anteckna också vilket problem rapporten pekar ut. En poäng utan en förklaring säger ganska lite om vad du ska ändra.

Förstå LCP, INP och CLS innan du optimerar

Core Web Vitals beskriver tre olika delar av upplevelsen. LCP handlar om när det största relevanta bild- eller textinnehållet i den synliga ytan visas. INP beskriver hur snabbt sidan ger visuell återkoppling efter interaktioner. CLS mäter oväntade layoutförskjutningar. Du behöver därför inte samma lösning för alla tre värdena.

Gränserna bedöms vid den 75:e percentilen och separat för mobil respektive dator. Förenklat ska minst tre av fyra uppmätta besök klara den aktuella gränsen. Ett bra genomsnitt kan dölja en grupp besökare som har det betydligt sämre. Titta därför inte enbart på det snabbaste resultatet från din arbetsdator.

TTFB är ett kompletterande felsökningsmått för väntan på svarets första byte. Det ingår inte bland dessa tre Core Web Vitals. En lång första väntan kan ändå skjuta hela laddningen framåt. Läs vår fördjupning om TTFB om det är där din mätning börjar avvika.

Följ laddningskedjan till den största fördröjningen

När det största synliga innehållet är en bild kan du tänka på vägen till LCP som fyra delar. Först väntar webbläsaren på den första byten av HTML-svaret. Därefter kan det dröja innan bildhämtningen börjar. Själva överföringen tar också tid. Till sist kan bilden vara nedladdad men fortfarande vänta på att visas.

Bilden visar ordningen, inte faktiska mätvärden. Använd den som en karta över din egen rapport. Om den stora fördröjningen ligger före bildhämtningen hjälper det kanske mer att göra bilden tidigt upptäckbar än att pressa filen några kilobyte till. Om bilden redan är hämtad behöver du undersöka vad som hindrar visningen.

Öppna webbläsarens utvecklarverktyg och nätverkspanelen, ofta kallad Network. Ladda om sidan och leta först upp dokumentet och sedan den aktuella bildfilen. Kolumner för storlek, tid och startordning ger en första överblick. Vattenfallet hjälper dig se vilka hämtningar som överlappar och vilka som börjar sent.

Spara gärna en skärmbild av ditt eget vattenfall före ändringen. Markera den resurs du undersöker och skriv en kort hypotes, exempelvis ”huvudbilden upptäcks först efter ett skript”. Nu har du en konkret sak att bekräfta. Ändra inte fem inställningar samtidigt; då blir det svårt att förstå varför resultatet förbättrades eller försämrades.

Anpassa bilder till platsen där de visas

En bild som visas i en smal artikelkolumn behöver sällan levereras i kamerans ursprungliga storlek. Börja med att undersöka bildens faktiska plats på sidan. Kontrollera både bredden på en telefon och den största bredden på dator. Skapa sedan ett litet antal bildvarianter som täcker dessa användningar utan att varje besökare måste hämta den största filen.

HTML-attributen srcset och sizes hjälper webbläsaren att välja mellan varianterna. Srcset beskriver vilka filer och bredder som finns, medan sizes beskriver den förväntade visningsbredden i olika layouter. Webbläsaren väger även in bland annat skärmens pixeltäthet. Det är därför inte säkert att en ruta som är 360 CSS-pixlar bred använder en fil som är exakt 360 bildpunkter bred.

I räkneexemplet ovan motsvarar en visningsbredd på 360 CSS-pixlar och en pixeltäthet på två ungefär 720 bildpunkter. En variant omkring 800 bildpunkter kan därför vara en rimlig kandidat. Poängen är att erbjuda användbara storlekar, inte att tvinga fram ett exakt val för alla enheter. Kontrollera vilken fil som faktiskt hämtas i nätverkspanelen.

Komprimera därefter bilden och jämför resultatet visuellt. Fotografier, skärmbilder och diagram tål olika behandling. Om liten text blir grötig har du komprimerat fel innehåll för hårt. Beskär onödiga kanter före export och kontrollera den färdiga bilden i den storlek läsaren ska se. Behåll originalet separat så att framtida varianter inte skapas från en redan försämrad kopia.

Låt viktiga bilder komma tidigt och resten vänta

Lazy loading innebär att vissa resurser hämtas först när de närmar sig den del av sidan som besökaren ska se. Det är användbart för bilder långt ned i en lång guide. Det kan minska arbetet vid det första besöket, särskilt när läsaren inte kommer att scrolla genom hela sidan.

Den huvudsakliga bilden i första skärmbilden bör däremot normalt inte ha loading="lazy". Om den är sidans LCP-element kan en uppskjuten hämtning förlänga väntan på det viktigaste innehållet. Låt bilden finnas i den ursprungliga HTML-koden när det är möjligt. För en verifierat viktig bild kan fetchpriority="high" dessutom ge webbläsaren en prioriteringssignal.

Ge inte alla bilder hög prioritet. När allting markeras som brådskande blir det svårare att uttrycka vad som faktiskt är viktigast. Var också försiktig med förladdningar. En förladdad fil som inte används av den aktuella layouten kan konkurrera med resurser som besökaren verkligen behöver. Kontrollera därför mobilvarianten separat efter en sådan ändring.

Skriv alltid bildens korrekta bredd och höjd i HTML, eller reservera motsvarande proportioner i layouten. Det hjälper webbläsaren att hålla platsen öppen innan filen är klar. Här i guiden kommer förklarande bilder inne i respektive avsnitt. Läsaren får sammanhanget först och kan sedan använda bilden utan att leta på en annan del av sidan.

Använd cache där samma svar kan återanvändas

Cache betyder att ett tidigare resultat sparas och används igen. Men flera olika lager kan finnas samtidigt. Webbläsarcache sparar exempelvis bild- och CSS-filer hos besökaren. Helsidescache kan återanvända färdig HTML. Objektcache kan i sin tur minska återkommande arbete i applikationen. Dessa lager löser olika problem och ska inte blandas ihop.

En offentlig artikel är ofta en bra kandidat för helsidescache eftersom samma innehåll visas för många läsare. Ett konto med personliga uppgifter är en annan situation. Där måste cachelösningen hantera användarens sammanhang korrekt, eller låta begäran gå vidare utan delad helsidescache. Att en sida går snabbare gör inte ett felaktigt delat svar acceptabelt.

Bilden visar en förenklad kontrollfråga: får flera besökare se samma HTML-svar? Om svaret är nej måste den personliga vägen vara tydligt avskild. För en butik behöver du särskilt kontrollera kassa, varukorg och kundkonto. Det räcker inte att testa startsidan utloggad och sedan anta att resten av webbplatsen fungerar likadant.

Efter en cacheändring gör du ett första besök och därefter ett nytt besök. Testa även att publicera en liten innehållsändring. Visas den när den ska? Kontrollera hur cachen töms och vem som ansvarar för det. För statiska filer kan versionsnamn eller versionsparametrar hjälpa till när innehållet ändras, så att en lång lagringstid inte låser fast en gammal design hos besökaren.

Undersök servern innan du köper mer kapacitet

Om väntan är lång redan före HTML-svaret ska du undersöka mer än bildstorlekar. Kontrollera onödiga omdirigeringar, långsamma databasfrågor, tunga anrop till andra system och om servern når sina resursgränser. TTFB påverkas också av nätverk och anslutning, så det är inte ett rent mått på PHP:s arbetstid.

Jämför en enkel offentlig sida med en dynamisk sida som inte använder helsidescache. Om bara den dynamiska sidan är långsam kan det peka mot applikationens arbete. Om problemet framför allt uppstår vid bestämda klockslag bör du jämföra med schemalagda importer, säkerhetskopior och besökstoppar. Spara tidpunkterna så att supporten kan leta efter samma händelser i loggarna.

Be webbhotellet beskriva vilka gränser du faktiskt når. Fråga efter belägg för exempelvis CPU-belastning, minnesbrist eller begränsat antal samtidiga PHP-processer. Ett större paket kan vara rätt beslut, men det bör lösa en observerad begränsning. Det hjälper sällan mot ett skript som väntar på en långsam extern tjänst.

Ändra inte slumpmässigt PHP:s minnesgräns i hopp om snabbare sidor. Mer tillåtet minne gör inte automatiskt beräkningen snabbare. Läs skillnaden mellan server-RAM och WordPress minnesgräns och kontrollera kompatibiliteten innan du byter PHP-version. Dokumentera både förbättringen och eventuella nya fel efter ett byte.

Minska JavaScript och testa riktiga interaktioner

En sida kan se färdig ut samtidigt som webbläsaren är upptagen med att köra kod. Det märks när en meny inte öppnas, ett filter känns segt eller textfältet reagerar sent. INP hjälper dig att bedöma denna respons, men du behöver också återskapa själva interaktionen för att förstå vad som händer.

Gå igenom de skript som laddas på sidan. Behövs ett bildspel när bara en bild visas? Måste ett formulärbibliotek köras på alla undersidor? Kan en inbäddad video laddas först när läsaren väljer att spela den? Börja med att ta bort arbete som saknar uppgift, i stället för att försöka göra varje onödig funktion lite effektivare.

I utvecklarverktygens prestandavy kan långa uppgifter på huvudtråden visa var webbläsaren blir upptagen. Uppgifter över 50 millisekunder räknas som långa i detta sammanhang. Att dela upp tungt arbete kan skapa tillfällen för webbläsaren att hantera inmatning och uppdatera skärmen, men rätt ändring beror på hur koden är skriven.

Använd inte fördröjd skriptladdning som en universallösning. Menyer, formulär och betalningsflöden kan vara beroende av en viss ordning. Testa därför tangentbordsnavigering, tryck, inmatning och felmeddelanden efter ändringen. Ett vanligt sidladdningstest med ett bra resultat ersätter inte en genomgång av de handlingar som besökaren behöver kunna utföra.

Håll layouten stilla och förenkla typsnitten

Layoutförskjutningar uppstår när innehåll flyttar sig oväntat. En bild utan reserverat utrymme kan skjuta ned texten när den dyker upp. En sent infogad ruta ovanför artikeln kan flytta hela läspositionen. Leta efter sådana situationer genom att ladda sidan långsamt och fortsätta observera när du scrollar.

Reservera plats för bilder, videor och andra inbäddningar utifrån deras avsedda proportioner. För innehåll som varierar i höjd behöver designen ha en medveten lösning. Att lägga in en tom yta på chans kan skapa stora luckor, medan för lite utrymme fortfarande ger hopp. Utgå från de faktiska format som webbplatsen använder.

Webbtypsnitt kan också påverka hur texten bryts och när den blir synlig. Färre familjer och vikter ger färre resurser att hantera. En systemfont behöver inte hämtas som en separat webbfont. Om ett eget typsnitt behövs ska reservtypsnittet väljas med omsorg, så att bytet inte kraftigt ändrar radlängder och elementhöjder.

Font-display styr hur texten får visas medan en webbfont laddas. Ett snabbt synligt reservtypsnitt är ofta bättre än osynlig text, men ett senare byte kan fortfarande ändra layouten. Testa därför både läsbarheten under laddningen och sidans stabilitet efteråt. Se också över om samma rubrik verkligen behöver flera dekorativa typsnitt för att vara tydlig.

Optimera WordPress med färre gissningar

På en WordPress-sida kommer belastningen ofta från kombinationen av tema, tillägg, innehåll och servermiljö. Antalet tillägg är inte ensamt ett prestandamått. Ett litet tillägg kan göra mycket tungt arbete, medan flera enkla tillägg kan påverka väldigt lite. Undersök funktion och resursanvändning i stället för att jaga ett bestämt antal.

Skapa först en separat stagingmiljö. Välj sedan ett misstänkt tillägg och jämför samma sida med och utan dess funktion. Kontrollera även om funktionen tillför CSS eller JavaScript på sidor där den inte används. Anteckna vad som försvinner ur nätverkslistan och vilka synliga funktioner som påverkas.

Undvik att aktivera flera överlappande optimeringar samtidigt. Två lösningar som båda ändrar skriptordning eller cache kan göra felsökningen svårare. Bestäm vilken komponent som ansvarar för helsidescache, bildhantering och eventuell kodoptimering. Kontrollera dess undantag och återställningsmöjligheter innan du slår på mer avancerade inställningar.

Radera inte databastabeller bara för att namnen verkar obekanta. De kan tillhöra en funktion som fortfarande används. Om en rapport pekar mot databasen behöver du undersöka frågorna och datamängden, inte utföra en allmän rensning utan plan. För webbutiker är kassa, order och schemalagda jobb särskilt viktiga att kontrollera efter förändringar.

Avgör om ett CDN löser ditt problem

Ett innehållsleveransnätverk, CDN, kan leverera resurser från flera geografiska platser. Det kan vara värdefullt när besökarna finns långt från ursprungsservern och innehållet går att återanvända. Men resultatet beror på vilka resurser som levereras, cacheträffar och var besökarna faktiskt befinner sig.

Börja med en geografisk fråga: var finns dina läsare och var finns servern? Om den långsamma delen är ett lokalt databasarbete som ändå måste utföras för varje begäran, kan ett nätverk för statiska filer lämna just den flaskhalsen orörd. Mät samma typ av sida från relevanta platser innan du bedömer nyttan.

Kontrollera också hur innehåll uppdateras. Bilder och stilmallar måste kunna få nya versioner, och personliga svar får inte oavsiktligt hamna i en gemensam cache. Se över certifikat, värdnamn och hur ursprungsservern kan nås. Förändringen påverkar fler delar än bara den ruta i en rapport som visar laddningstid.

Lägg till detta steg när du vet varför det behövs. För en liten webbplats kan rätt bildstorlekar, tidigt synligt innehåll och fungerande servercache vara enklare första åtgärder. För en internationell publik kan leveransavstånd däremot bli en viktig del av helheten. Undvik att jämställa en ny tjänst med en automatiskt färdigoptimerad webbplats.

Gör en före- och efterkontroll som går att lita på

Avsluta varje arbetsomgång med samma adresser och samma testförhållanden som du började med. Skriv upp ändringen, tidpunkten och resultatet. Spara gärna både den typiska mätningen och spridningen mellan körningarna. Om skillnaden är mindre än den normala variationen bör du vara försiktig med att kalla den en säker förbättring.

Kontrollera sedan funktionerna. Skicka ett formulär, använd menyn med tangentbord, prova sökning och granska sidan på telefon. I en butik behöver du även testa ett köp i lämpligt testläge. Kontrollera utloggat och inloggat läge samt det första besöket efter att cachen tömts. De vägarna kan ge olika resultat.

En praktisk prioritering är att börja med ett tydligt fel som påverkar många besökare och har en hanterbar lösning. En felaktigt stor huvudbild kan vara ett bättre första projekt än att lägga en hel dag på några små filer. Men om servern väntar flera sekunder innan något skickas behöver den väntan undersökas först.

Följ upp efter nästa innehållsändring också. En ny video, ett nytt typsnitt eller en kampanjruta kan förändra förutsättningarna. Gör därför prestandakontrollen till en del av publiceringen. Målet är inte att få en enda perfekt skärmbild av ett testresultat, utan att behålla en webbplats där läsaren kan börja läsa, förstå och agera utan onödig väntan.