Detta är en återkommande fråga då PageSpeed Insights och liknande andra tjänster i första hand är anpassade för att kolla hur snabbt en generell hemsida laddar, inte hur snabbt en webbshop laddar. Så det kommer att bli missvisande att bara titta på en sådan rapport för en webbshop som behöver ha mer bilder för att visa artiklar och som dessutom för en del sid-typer behöver göra en del databasuppslag som ju också tar några millisekunder. Så det snabba svaret om du inte vill behöva läsa resten av den här artikeln brukar bli "Nej, så länge din sida inte ser ut att ladda långsamt när du laddar den själv så behöver du nog inte oroa dig."
Vi kommer ändå nedan gå igenom de vanligaste rubriker testet kan klaga på, i den ordning de faktiskt kan vara värda att ändå titta på.
Komprimera bilder
Bilder i filarean
Här kan det finnas laddningstid att spara om din startsida laddar bilder ifrån filarean, det vill säga bilder som inte är artikelbilder. Speciellt illa kan det bli om en sida har ett bildspel med många för stora bilder, endera i antal pixlar eller i filstorlek. Bilder du själv laddar upp till filarean komprimeras inte ytterligare av systemet, då vi inte kan veta hur bilden kommer användas och därför inte heller schablonmässigt kan komprimeras. Så där bör du se till att själv ändra storlek och komprimera bilder innan de laddas upp. Se guiderna Hur väljer jag rätt bildstorlek och komprimering? respektive Att beskära och ändra storlek på bilder.
Artikelbilder
Kvaliteten på din butiks tumnagelbilder, vilka oftast är de som är flest av på förstasidan, är satta av oss på E37 när vi satte upp din butik och baserades då på vad som är lämpligt för den typ av varor din butik säljer; en butik som säljer tapeter vill typiskt ha högre bildkvalitet än en butik som säljer biljetter till event.
Högre komprimeringsgrad betyder lägre kvalitet, så om vi höjer komprimeringen så blir det mer jpg-artefakter på bilderna. Speciellt om dina artikelbilder är frilagda mot en uniform bakgrundsfärg kan dessa artefakter bli störande. Om du verkligen vill minska kvaliteten på bilderna så kan vi sänka den, men att göra det enbart baserat på en automatisk rapport vore nog inte rätt.
Två bilder, den vänstra med låg komprimeringsgrad och den högra med (för) hög komprimering. Notera de fula artefakterna på den högra bilden på till exempel armens kanter.
Eliminera visningsblockerande JavaScript och CSS i innehåll ovanför mitten
och
Se hur script kan göra webbplatsen långsammare
Kontrollera att du inte lagt in egna script i sidhuvudet på alla sidor som inte absolut måste ligga där. Detta ser du under Inställningar -> Webbplats -> Allmänt -> Fliken Script och längst ned fältet Egna scriptinkluderingar i head. Externt laddade script här kan vara extra kostsamt.
Det enda script som som är inbyggt i systemet och som testet kanske skulle kunna flagga som blockerande skulle vara hantering av varukorgen vilken såklart måste ligga där för att butiken ska fungera.
Script för Google Analytics och andra tjänster systemet har inbyggt stöd för ligger inlagda sist så att de inte är blockerande.
Vad gäller script på andra platser, se gärna över så du inte har kvar några onödiga tredjepartsscripts för tjänster du inte längre använder. Detta ser du dels i de övriga rutorna på tabben Script och om det finns script inlagda med widgeten Fri HTML-kod på enskilda sidor eller under Webbplats -> Widgethållare. Script inlagda med widgeten Fri HTML-kod på enskilda sidor bör också ligga sist av alla widgets så att de inte måste laddas klart innan andra widgetar laddas.
Använd cachelagring i webbläsare
Detta är inte riktigt applicerbart i en butik där vilka artiklar som visas ska bero på lagersaldon, bästsäljare, kundens beteende och liknande.
Komprimera HTML, CSS och JavaScript
Eftersom Googles egna script och även andra tredjepartstjänster från till exempel Facebook brukar dyka upp som "icke-optimerade script" så måste vi nog erkänna att de är företag som har långt bättre resurser att optimera dessa än vad våra 10 anställda på E37 kan göra. Mer troligt så varnar tjänsten för alla lite större script här. Att optimera HTML-storleken är också minimalt i vilken vinst det skulle ge på laddningstider.
Mobil hastighet
Vad gäller statistik som att "70% av alla mobilnätverksanslutningar i hela världen kommer att ske med 3G eller långsammare fram till år 2020." som kanske visades upp under testet så stämmer det troligen, men är det verkligen hela världens mobiler du bryr dig om din målgrupp främst är Sverige? Sverige ligger klart över världssnittet för mobila surfhastigheter.
Så även här är det nog även här mer rimligt att göra en egen okulärbesiktning. Det vill säga koppla ifrån wifi på din telefon och ladda mobilsidan. Känns det som att den är seg? Om inte så är det nog inte heller ett problem.
Minska serversvarstiden
De filer där det är möjligt ligger i vår molndrift lagrade på RAM för snabb läsning. Vissa sidladdningar i en webbshop kräver databasuppslag för att veta till exempel vilka artiklar som ska visas i skyltfönster, men där cachar vi sådan information på server-sidan så att dessa uträkningar inte behöver göras varje gång. Så ja, om vi på E37 kunde minska serversvarstiden så skulle vi också gärna göra det, men om rapporten klagar på det beror nog mer på att det är att jämföra äpplen och päron att titta på en webbshop jämföra med hur fort en statisk mobilsida borde kunna ladda.
Testa andra marknadsledande sajter och se hur de klarar sig
Över lag behöver du alltså inte vara så orolig för att få ett dåligt testresultat på din webbshop på Google PageSpeed eller liknande tjänster. Om du fortfarande inte är övertygad, testa att knappa in aftonbladet.se eller cdon.com i testet så ser du troligen att deras resultat faktiskt är sämre. Enligt testet så blir Aftonbladet i skrivande stund av med 28% av sina besökare pga långsamma laddningstider vilket vi faktiskt tvivlar på stämmer.