Att få riktigt hög score på Google PageSpeed på en ehandels-site är svårt. Saker som personalisering, mycket content, detaljerad design, stora bilder, egna fonter och tredjepart-script påverkar alla till en lägre score. Vad kan man då göra för att ändå höja sin PageSpeed-score?
Google PageSpeed är ett verktyg man som ehandlare inte kan undvika. Det är viktigt av flera anledningar, men det ska inte vara det enda verktyg du använder för att jobba med prestanda. Läs mer om vad Google PageSpeed innebär för dig här.
Den viktigaste anledningen att jobba med din PageSpeed-score är för att säkerställa att din Google-ranking är så bra som möjligt. Google har sannolikt alltid tagit in PageSpeed som en faktor i rankingen, men har sedan Juli 2021 gett tydliga besked om att det är en faktor i hur du rankar. Content is king fortfarande, så en hög PageSpeed-score kommer inte att göra att du helt plötsligt seglar förbi dina konkurrenter. Men det kan vara faktorn som gör att du rankar förbi en konkurrent som gör ett i övrigt lika bra SEO-jobb som du. En bra PageSpeed-score gör också att Google kan visa upp din site som förslag i Google Discover vilket gör dig synlig för helt nya kunder utan att de aktivt söker.
För att lyckas få bra score måste man först förstå faktorerna bakom betygsättningen. Och tyvärr går dessa faktorer lite stick i stäv med hur en modern ehandels-site ser ut.
Högst betyg delas ut till en site helt utan content. En blank sida helt enkelt. Den är extremt snabb att ladda på alla enheter och alla nätverk. Varje sak du sen lägger på riskerar att sänka ditt betyg. Men en site helt utan content kommer inte få kunder att vilja handla, så det gäller att hitta en balans mellan saker man lägger till, och det PageSpeed-score man siktar på.
Som ehandlare vill man förstås både ha kakan och äta den. Man vill ha massvis med content, stora och bra bilder, så mycket tracking-verktyg som möjligt för att följa och mäta kundens resa och beteende, och en snygg och detaljrik design. Alla dessa bidrar tyvärr till ett lägre PageSpeed-score, men det finns sätt att åtminstone ha kakan och få äta hälften.
De två tveklöst största faktorerna i din score är bilder och JavaScript. En ehandels-site har nästan alltid en stor bild överst på sidan. Antingen en produkt-bild på produktsidan eller en lockande banner på startsidan. Det är oerhört viktigt för din score hur denna eller dessa översta bilder laddas och hur resterande bilder laddas för din score. Om dessa inte laddas optimalt så kommer det påverka din Largest Contentful Paint (LCP) negativt, och den står för 25% av betyget.
Den andra största faktorn är mängden JavaScript som används på siten. Har man mycket JavaScript så kommer det ta tid att ladda och köra det, vilket ofta sänker betyget i First Input Delay (FID), Time to Interactive (TTI) och Total Blocking Time (TBT).
Mängden JavaScript är oftast något du inte kan styra över utan det är dina utvecklare som måste jobba med detta. Men det du kan göra är att tänka både en och två gånger innan du drar in tredjeparts-script för olika tracking-tjänster som ofta drastiskt ökar mängden JavaScript som laddas. Gör PageSpeed-mätningar med och utan dessa för att avgöra vilken påverkan det får.
För att få optimal Largest Contentful Paint (LCP) behöver man så tidigt som möjligt berätta för webbläsaren vilka bilder som ska visas. En typisk sida har ofta många bilder, och bara ett fåtal av dem är direkt synliga för kunden innan hen har hunnit scrolla. Dessa bilder behöver laddas i förväg via image preloading. Man kan använda både <link>-element i <head> och HTTP-headers för detta, och HTTP-headers är att föredra eftersom webbläsaren upptäcker de tidigare än HTML-element. Att använda HTTP headers kommer bli ännu mer viktigare när/om Early Hints blir en standard eftersom det tillåter en att skicka ut HTTP headers i flera omgångar istället för alla på en gång. Då kan man skicka ut en preload hint nästan direkt och långt innan servern är färdig med det totala svaret.
Har man responsiva bilder så att en mobil visar en bild i lägre upplösning än en desktop behöver man vara noggrann med vilken variant av bilden det är man preloadar. Eftersom PageSpeed bedöms med Chrome som webbläsare kan man använda Chrome-specifik funktionalitet, vilket beskrivs i den här artikeln. Tyvärr stöds inte preloading för responsiva bilder i alla webbläsare så för att vara på den säkra sidan behöver servern skicka ut olika preload-instruktioner för mobil och desktop genom user agent detection. Tyvärr skickar inte webbläsaren med hur stor skärm kunden använder så det enda alternativ man har är att gissa skärm-storlek baserat på vilken webbläsare kunden använder.
På en produkt-sida är det ofta ganska enkelt att veta vilken bild som kommer synas överst men på en CMS-sida som startsidan med väldigt dynamiskt innehåll är det betydligt svårare. Startsidan kan ha två banners som båda är synliga för en mobil, eller en enda banner som tar hela mobil-skärmen. Dina val av system är väldigt viktiga här för dessa måste vara byggda så att den här informationen kan tas fram utan allt för hög komplexitet. Ditt val av utvecklare/partner blir också väldigt viktigt här eftersom de måste förstå hur de ska få fram den här informationen och skicka ut den på rätt sätt. Att göra fel här kan kosta runt 20 poäng i din score.
Eftersom poängen sätts baserat på hur lång tid det tar att ladda och visa bilderna är det väldigt viktigt att en optimal storlek skickas ut. Ifall man laddar upp en original-bild på 2000px måste denna skalas ner till en optimal storlek för just den kundens skärmstorlek. Det är även viktigt att ha ett CDN för bilder eftersom bilder som laddas via ett CDN laddas många gånger snabbare än utan.
För sidor med många bilder är det viktigt att de bilder som inte är synliga innan man scrollar inte heller ska laddas. Detta kan uppnås med image lazy loading, vilket säger till webbläsaren att inte ladda bilder som inte ligger synliga innan man scrollat. Alla webbläsare stödjer inte detta (framförallt iOS) och till dess behöver man implementera det själv. På samma sätt som man preloadar bilder som man avgör är direkt synliga, så lazy loadar man resterande bilder.
Det pratas en hel del om att minska mängden JavaScript man skickar ut och det är ett bra råd. Men den verkligen kostnaden ligger i när JavaScript koden exekveras. Att ladda in t.ex. jQuery men sen inte använda det har förvånande liten påverkan. Det beror på att JavaScript-motorer är väldigt kompetenta vad gäller att ladda ner JavaScript-kod och bara exekvera det som verkligen behöver exekveras. Du måste fortfarande vara försiktig med mängden JavaScript men det första du ska försöka optimera är den kod som faktiskt körs.
Idag byggs många ehandels-siter som SPAs (Single Page Application) vilket betyder att siten byggs som en applikation i JavaScript och att all rendering kräver JavaScript. Det betyder att koden ska först exekveras en gång på servern för att skicka ut svaret och att samma kod sen ska köras i webbläsaren för att väcka applikationen. Vilket kan tyckas onödigt, men det är så applikationen vet vilka delar som är interaktiva och vilka delar som är mer statiska.
Kostnaden för detta blir bara högre och högre desto större och mer komplexa sidor du har. För en sida som ryms på en mobilskärm är den knappt märkbar, men på en sida med fem mobilskärmers höjd och komplex interaktivitet som bildspel blir den en kostnad som kommer påverka ditt score.
Det bästa sättet att komma runt det är att vänta med att rendera tills det verkligen behövs. Ifall en kund kommer in med mobil måste bara det som syns på skärmen renderas och bli interaktivt, och resten av innehållet kan renderas vid scroll. Är det innehåll som inte är SEO-viktigt är det bäst att servern listar ut hur mycket innehåll som måste renderas och istället bara skicka ut datan som behövs för att rendera resten. Är det innehåll som är viktigt ur SEO-perspektiv så kan man använda sk. partial hydration.
Att få hög score är inte ett engångsarbete. Det är ganska vanligt att en ny lösning lanseras med bra eller godkänt score och sen efterhand som förändringar görs och nya features läggs till så går scoren sakta ner. Och man vet inte riktigt varför. Därför är det viktigt att hela tiden göra nya mätningar, och mäta i test-miljöer innan det går ut i produktion.
Google Chrome innehåller verktyg för att göra mätningar lokalt vilket man kan göra från sin dator. Men två olika personer kan få helt olika score från sina datorer eftersom de datorerna har olika processorer och minne. Det är därför viktigt att alltid mäta med det officiella PageSpeed-verktyget eftersom det är scoren där som sen verkligen spelar roll.
Ny funktionalitet som byggs bör skrivas så att man kan mäta med och utan den. I vissa fall är det lätt att i ens CMS slå av och på content/funktionalitet och göra mätningar, men oftast är det svårare än så. Se istället till att koden skrivs så att funktionalitet kan stängas av genom url-parametrar, vilket gör det lätt att mäta i det officiella verktyget med och utan, men också för att man då kan mäta den egna upplevelsen i en riktig mobil.
Att göra saker mätbara på det här sättet är det bästa sättet att påbörja en prestanda-utredning. Ifall du inte gjort mätningar på länge och ser att du har 25 i score men vill få upp det till 75 så kan det kännas som ett obestigligt berg för alla inblandade. Genom att lägga in möjligheter att mäta med och utan vissar delar kan du lättare bilda dig en uppfattning om vad det är som kostar. Sannolikt finns det en del lågt hängande frukt men för att komma från 50 och uppåt är det många små saker som behöver förbättras snarare än enskilda saker som kan ge mycket poäng.
Relaterade artiklar
AI gör inte bara utvecklingen snabbare, den flyttar förmågan ut i hela verksamheten. Plötsligt kan vem som helst bygga och ändra i systemen. Det är enormt kraftfullt, men med gamla arbetssätt blir det antingen kaos eller ingen effekt alls. Här är hur du leder skiftet från trädvårdare till skogsvaktare innan entropin springer ifrån dig.
Teknisk skuld är mer än ett tekniskt begrepp, det är en affärskritisk realitet som påverkar allt från time-to-market till kundupplevelse. I e-handelsvärlden, där varje millisekund och varje klick räknas, kan valen du gör i den tekniska plattformen få långtgående konsekvenser. När snabba lösningar prioriteras framför långsiktig hållbarhet byggs en osynlig men växande skuld upp. Den påverkar inte bara utvecklingstakten och stabiliteten, utan kan i värsta fall bromsa företagets innovationsförmåga och konkurrenskraft. För att möta framtiden på rätt sätt måste teknisk skuld förstås, kvantifieras och hanteras som den strategiska investering det faktiskt är.
För svenska handlare finns en rad möjligheter att möta detta hot genom att bygga vidare på det som de kinesiska jättarna inte kan erbjuda: starka och lokala varumärkesberättelser, produktsäkerhet och hållbarhet som konkurrensfördelar och en närvaro som binder samman den digitala och fysiska handeln. Temu har ju inga butiker. Än.
