Så åtgärdar du bildleverans i PageSpeed Insights

1. 01Öppna den berörda sidan i PageSpeed Insights eller Lighthouse. Välj mobil- eller datorrapporten som du vill förbättra, öppna avsnittet om bildleverans och anteckna bildens URL och den föreslagna ändringen.
2. 02Hitta bilden på sidan. Jämför den hämtade bilden med visningsmåtten i webbläsarens utvecklarverktyg och ta hänsyn till skärmens pixeltäthet. Kontrollera vald källa, inte bara originalet i mediebiblioteket.
3. 03Om bilden som levereras har för många pixlar rättar du först responsiva storlekar eller temainställningar. Om måtten passar jämför du komprimering eller ett annat format som stöds.
4. 04Förbered en kopia med rätt mått i en bildredigerare. Använd Bitinz bildkomprimerare för lämpliga filer och granska text, kanter, genomskinlighet och toningar innan något ersätts.
5. 05Publicera ersättningen eller malländringen. Kontrollera att sidan begär den nya bilden i stället för en gammal cachad version och kör rapporten igen med samma enhetsinställning.

Chrome uppskattar besparingen utifrån bildens hämtningsstorlek och ett effektivt förhållande mellan byte och pixlar för formatet. Bilder med uppskattad besparing under 4 KiB markeras inte. Det är en rapporteringsgräns, inte rekommenderad maximal bildstorlek.

Lighthouse 13 ersatte äldre bildgranskningar med denna insikt; Lighthouse 12 hade redan gjort insikterna till rapportens standardvy. Formatvarningar, för stora mått och tunga animationer kan kräva olika åtgärder. Det bredare arbetsflödet beskrivs i så komprimerar du bilder för webben.

• WordPress: kontrollera bildstorleken som valts i blocket eller temat samt faktisk srcset- och sizes-kod. WordPress skapar responsiva bildalternativ, men en egen mall eller felaktig layoutbeskrivning kan ändå leverera olämplig storlek. Om bara originalet rättas kan befintliga genererade kopior fortsätta användas.
• Shopify: butikens bilder optimeras redan via Shopifys CDN, även formatvalet. Shopify säger att manuell komprimering före uppladdning är onödig. Vid en varning granskar du temats begärda bildbredd och responsiva kod i stället för att försämra källan upprepade gånger. En temautvecklare kan kontrollera image_url och image_tag.
• Next.js: använd Image-komponentens responsiva inställningar och ge sizes ett värde som motsvarar den faktiska layouten, särskilt med fill. Utan ett lämpligt värde kan en smal bild behandlas som hela visningsytans bredd och ett större alternativ hämtas. Bara ändrad kvalitet rättar inte den skillnaden i layout.

Spara ett redigerbart original. För bilder som levereras separat jämför du filens faktiska storlek och utseende; jämförelsen av JPG, PNG och WebP hjälper dig välja. Bitinz ändrar inte bildmått. WebP-konvertering kan ge en större fil, så behåll den version som passar sidan.

Vid återkommande publicering kan utvecklar-API:t behandla lämpliga filer med konto och månadskvot. Det rättar inte temakod eller responsiv layout. Kontrollera sidan igen efter att automatiseringen kopplats in.

• Den markerade adressen motsvarar bilden och versionen du ändrade.
• Webbläsaren väljer en lämplig källa på olika skärmstorlekar.
• Komprimeringen bevarar viktiga detaljer, genomskinlighet och mjuka toningar.
• Huvudbilden som syns fördröjs inte av en olämplig inställning för uppskjuten laddning.
• Den nya rapporten använder samma enhetsinställning; sidans verkliga utseende och laddning kontrolleras också.