Optimering av webbplatsens bilder

Bildoptimering är en av de mest “belönande” aspekterna av WordPress prestanda: för samma sidstruktur och tema, så länge som bildstorleken, dimensionerna, formateringen och leveransen är korrekt, kommer laddningsupplevelsen att förbättras omedelbart.

Men bildoptimering är också det enklaste sättet att ställa till med oreda, inte för att det är tekniskt svårt, utan för att informationen är för fragmenterad:
Du läser några artiklar, vet att “komprimering”, “WebP / AVIF”, “lat laddning”, och sedan titta på plugin-introduktionen och sa “gratis varje månad! 100 krediter per månad”, “Gratis 20MB”, “1 kredit per bild”, men ju mer jag läser, desto mer förvirrad blir jag--. Är gratis tillräckligt? Hur drar man av avgiften? Har du missförstått “samma sak”? Och viktigast av allt:Fick det någon effekt efter att du gjorde det eller inte?

Den här artikeln gör bara tre saker:

1. Ge dig en körbar filfärdplan (även fig.)(Vad ska man göra först, vad ska man göra sedan)
2. Var tydlig med vilket alternativ du väljer (vad är skillnaden mellan gratis/betalt och vem passar respektive alternativ för)
3. Skriv ner de vanligaste fallgroparna i förväg (så att du inte behöver leta runt för att felsöka när du är klar)

1. Slutsatsen: Vad WordPress kommer med och vad det inte gör

Om du inte först tar reda på vad WordPress Core redan gör, är det lätt att göra en av två saker:

• I stället för att utnyttja den “lediga kapacitet” som du borde ha, lägger du tid/betalar pengar för att bygga hjulet om och om igen.
• Jag trodde att WordPress skulle “automatiskt konvertera alla gamla bilder till WebP/AVIF”, men det visar sig att det inte gör det!

WordPress-kärnan har dessa viktiga funktioner inbyggda:

• Responsiva bilder (srcset/storlekar): Från och med WordPress 4.4 kommer kärnan att mata ut bilder för srcset 与 sizesoch utnyttjar de bilder i flera storlekar som genereras under uppladdningen för att webbläsaren ska kunna välja en mer lämplig resurs att ladda utifrån skärmförhållandena.
• Inbyggd latent laddningWordPress 5.5 och framåt möjliggör inbyggd latent laddning av bilder som standard, med hjälp av HTML-standarder. loading implementering av attribut.
• Stöd för uppladdning av WebP: Sedan WordPress 5.8 kan du ladda upp och använda WebP som JPEG/PNG (förutsatt att din hosting-miljö stöder WebP).
• Stöd för uppladdning av AVIF: Sedan WordPress 6.5 kan du ladda upp och använda AVIF som JPEG/PNG (beror också på värdstöd).

Men var uppmärksam:
“Stöd för uppladdning/användning” ≠ “Automatisk konvertering/automatisk leverans”.
Det vill säga: även om du redan är på WP 6.5, kommer dessa JPG/PNG i ditt mediebibliotek inte att förvandlas till WebP/AVIF på egen hand; du kommer inte automatiskt att få hela “utdata AVIF/WebP enligt webbläsarens kapacitet och fallback till originalbilden för webbläsare som inte stöds” länk! --den här delen behöver vanligtvis patchas av ett plugin eller en tjänst.

2. Färdplan: Bildoptimering i 5 steg

Vad man ska göra, varför, vad man ska göra för att kvalificera sig och hur en typisk grop ser ut.

2.1 Att först få rätt “storlek” (det mest förbisedda, men det mest givande)

Många stationer är långsamma, inte för att komprimeringen inte är klar, utan för attNedladdning av en stor bild som sträcker sig långt utanför visningsområdet：
Om sidan t.ex. bara är 900 pixlar bred och du ber besökaren att ladda ner originalbilden på 3000 pixlar, kommer webbläsaren bara att “ladda ner den och sedan krympa den”. Detta slösar bandbredd, ökar avkodningstiden och gör den första skärmen långsammare.

WordPress 4.4+.Responsiv bildmekanism（srcset/sizes) är utformad för att hantera just detta problem.

Gör det som räknas som ett pass:

• När du öppnar en sida på en mobiltelefon bör storleken på den nedladdade bilden vara betydligt mindre än på skrivbordet
• Samma bild laddas med olika resursstorlekar på olika enheter (istället för att alltid ladda ner originalbilden)

De vanligaste fallgroparna:

• Det finns teman/byggare som behandlar diagram som CSS-bakgrundsbilder eller matar ut dem på ett anpassat sätt som kan kringgå srcsetResultatet har blivit en stor bild av
• Du använder externt länkade bildbäddar, bildblock från tredje part och kan också kringgå det system med flera storlekar som genereras av mediebiblioteket

---

2.2 Komprimering (minska antalet KB, men “krossa” inte kvaliteten)

Kärnan i komprimering är inte “ju mindre desto bättre”, utan “skillnaden är knappt synlig för blotta ögat, men volymminskningen är uppenbar”.

Reglerna är som följer:

• Fotografier/live shots (människor, produkter, landskap): Prioriterad komprimering med förlust (maximal vinst)
• Skärmdumpar av gränssnittet / texttunga bilder: Komprimeringen bör vara mer konservativ för att undvika luddig text
• Logotyp/Icon: Prioriterad SVG eller diskret förlustfri (förlustfri är lätt att kantklistra)

Gör det som räknas som ett pass:

• Betydande minskning av bildstorleken på de flesta sidor
• Inget synligt brus, grumliga kanter, färgbrytningar, suddig text

---

2.3 WebP / AVIF (formatstrategi: mindre för samma definition)

WordPress stöder redan uppladdning WebP (5,8) jämfört med AVIF (6,5)。
Men för att Next Generation Format verkligen ska fungera måste två saker lösas:

1. Hur man batchkonverterar historiska mediebibliotek(Annars optimerar du bara för “nya bilder laddas upp senare”)
2. Om en kopia ska skapas eller om originalbilden ska ersättas(Detta är en riskabel vattendelare; vi kommer att fokusera på Plus WebP:s “Ersätt och ta bort originalbild” senare)

Rekommenderad skrivstil:

• WebP: allmänt föredragen som standard (stabilare kompatibilitet)
• AVIF: en ytterligare komprimeringsriktning, lämplig för stora bilder/stora bilder för första skärmen/albumbilder (men merBeroende av stöd från omgivningen）

---

2.4 Lazy loading ska användas på rätt sätt (inte en storlek passar alla)

WordPress 5.5 och framåtStandard för latladdningBild.
Det minskar bandbreddsanvändningen under den första renderingen:

• Latent laddning för “resurser utanför skärmen”
• Den mest kritiska stora bilden på den första skärmen (och i många fall nyckelbilden på den första skärmen) är ofta olämplig för fördröjd laddning

---

2.5 Leveranslager: CDN / Foto CDN

Komprimering, storleksanpassning och formatering löser problemet med “mindre filer som får plats”.
Men om bilderna alltid hämtas från ett avstånd från källan kommer nätverksfördröjningen fortfarande att påverka upplevelsen avsevärt. Det är här lösningen med ett “leveranslager” (CDN/bild CDN) kommer in i bilden.

Två typiska riktningar:

• Cloudflare Polsk：Dokumentation om CloudflarePolska komprimeringsmetoder (lossless/lossy/WebP) introduceras, och det nämns att komprimering med format=auto WebP/AVIF-format är tillåtet.
• Jetpack webbplatsaccelerator：Jetpack-dokumentationFörklara att den kommer att optimera bilder och distribuera dem genom sitt nätverk tillsammans med statiska resurser.

Bildoptimeringen ansvarar för att bilderna blir mindre och mer ändamålsenliga.CDN Ansvarig för att leverera närmare och mer stabila

3. Urval: endast två huvudvägar

Det vanligaste felet vid bildoptimering är inte “inga plugins”, utan för många plugins som leder till dubbel bearbetning:
A komprimerar, B komprimerar, A konverterar till WebP/AVIF, B konverterar, A ändrar URL:er, B skriver om - det går inte ens att se vad som händer på stationen.

Regler:

Det finns bara en väg att gå: antingen helt gratis lokalt eller molnkomprimering av de tre.

• Väg A (alla gratis lokalresor):Plus WebP eller AVIF + EWWW Image Optimizer(eller bara en)
• Sträcka B (trippelalternativ för molnkomprimering):ShortPixel / Imagify / TinyPNG

---

3.1 Väg A: Helt gratis lokalt (plus WebP eller AVIF eller EWWW)

Denna rutt kännetecknas av:

• Du förlitar dig inte på tredje parts komprimeringstjänster “per månad/per ark” (även om vissa funktioner kan erbjudas som tillvalstjänster).
• Kostnaden: batchbehandling kan vara mer serverhungrig vid CPU/IO, vilket kräver att du ägnar mer uppmärksamhet åt “strategi och risk”.”

3.1.1 Plus WebP eller AVIF: kärnan är “generera/ersätta”, det är inte det traditionella “komprimeringsverktyget”.”

• Vid generering av fullvolymsbilder:Den ursprungliga bildfilens ID skrivs över av WebP/AVIF, originalfilen raderas och URL:en i innehållet ersätts.。
• Pluginet tillhandahåller WP-CLI-kommandon och påminner: WP-CLI är mer tillförlitligt när det finns många filer.

Detta innebär att istället för att “tyst generera en WebP åt dig”, kan det vara enMigration av tillgångar(Särskilt om du aktiverar alternativet “Ersätt och radera originalbilden”).

Skillnader mellan de två modellerna

Läge 1: Behåll originalbilden + generera WebP/AVIF-kopia (stabilare)

• Fördelar: Lättare att falla tillbaka på i händelse av kompatibilitetsproblem
• Kostnad: Diskanvändningen kommer att öka (originalbild + nytt format + miniatyrer i flera storlekar)

Läge 2: Byt ut och radera originalbilden (mer aggressivt)

• Fördelar: diskar expanderar inte lika snabbt; stationsreferenser går direkt till det nya formatet
• Risk: Du “byter tillgångar + byter referenser”, vilket gör det dyrare att felsöka kompatibilitetsproblem (särskilt om vissa externa system eller temalogiker är beroende av det ursprungliga filnamnet/sökvägen/formatet).

Typiska fallgropar med Plus WebP eller AVIF

1. Efter att hela biblioteket har bytts ut visas vissa sidbilder på ett onormalt sätt.
   Orsaken till detta är oftast inte att bilden är “trasig”, utan att någon länk i kedjan av URL-ersättning, cachning, miniatyrbildspolicy etc. inte är korrekt.
2. Ju större antal miniatyrbilder, desto större omfattning av förändringen
   WordPress genererar flera storlekar när du laddar upp en bild; teman/plugins kan också lägga till fler storlekar. Fullständig ersättning innebär att du kan komma att ändra en mycket stor samling filer.
3. Att bara göra en formatmigrering innebär inte nödvändigtvis att volymen alltid är den minsta
   WebP/AVIF är i allmänhet mindre, men “storleksstrategi” och “komprimeringsstrategi” är fortfarande avgörande. Tänk inte på Plus WebP som “ett klick snabbare”.

---

3.1.2 EWWW bildoptimerare: representant för fri lokal kompression

EWWW-plugin-sidan är mycket väl placerad:

• Den kan optimeras på din server med hjälp av en rad olika verktyg (jpegtran, optipng, pngout, pngquant, gifsicle, cwebp etc.)
• Du kan också avlasta CPU-förbrukande bearbetning till dess server (tillval) om du behöver högre komprimering eller mer CPU-besparingar.

Vilken roll ska EWWW ha i Route A?

Om du använder Plus WebP som en “formatmigrerings-/ersättningsstrategi” passar EWWW bättre:

• Komprimering och volymoptimering(särskilt viktreduktion av råa resurser som JPG/PNG)
• Batchoptimering av historiskt mediabibliotek(inriktad på “volymminskning” snarare än “URL-ersättning”)

Typisk grop för EWWW

1. Förhöjd serverbelastning under batchoptimering
   Eftersom lokal komprimering äter CPU/IO är lösningen inte “använd det inte”, utan “batch, låg topp, avlastning/molnalternativ vid behov”.
2. “En WebP genereras” betyder inte att frontend måste producera en WebP.
   Många plugins lider av detta missförstånd: generering är en sak, leveransstrategier (rewrites, picture tags, cache hits etc.) är en annan.
3. Göra samma sak om och om igen med andra plugins
   Om du väljer väg A, försök att inte lägga över ShortPixel/Imagify/TinyPNG-typ av molnkomprimering; om du väljer väg B, slå inte på Plus WebP-ersättningslogik. Grundläggande princip:En väg till slutet.

---

3.2 Väg B: Trippelval för molnkomprimering (ShortPixel / Imagify / TinyPNG)

Den här vägen är lämplig för personer som “vill spara serverresurser, vill göra batch med mindre ansträngning och accepterar fakturering per kredit/per volym”.
Men den mest missvisande punkten om molnkomprimering är:Gratis krediter är inte lika enkelt som “gratis lakan”!.. Antalet miniatyrstorlekar, om WebP/AVIF genereras eller inte och om den trycksätts upprepade gånger eller inte kan påverka förbrukningen avsevärt.

I det följande förklaras: vad som gäller för free/fee, hur krediter dras av, vilka fallgropar som är mest troliga att trampa i och vilka typer av webbplatser som är lämpliga.

---

3.2.1 KortPixel100 gratis krediter/månad, men krediterna förbrukas av miniatyrbilder och WebP/AVIF-förstoringar.

Vad händer med gratis/betalt

Beskrivningen av ShortPixel-pluginet anger tydligt:

• 100 gratis krediter per månad
• Det finns också “Extra Unlimited Monthly Credits” (plugin-sidan ger information om motsvarande priser)
• Finns även som “engångspaket som aldrig går ut” (med information om startpris)

Tips:

• Gratis: ge ett visst antal krediter per månad för lätta webbplatser eller testning
• Engångspaket: lämpliga för webbplatser med stora mediebibliotek som vill tömma sitt lager på en gång (köp en gång och använd upp det, det går vanligtvis inte ut).
• Monthly/Unlimited: lämplig för webbplatser med kontinuerligt uppdaterade bilder och långsiktigt stabil optimering

ShortPixels officiella KB har också gett en uppdatering om “One Time Pack vs Unlimited Monthly”.uttrycklig förklaring: Unlimited Monthly är en månatlig (eller årlig) betalning som erbjuder obegränsade krediter med en fast tilldelning på CDN; engångskrediter löper inte ut, vilket ger dig mer kontroll att använda dem efter behov.

Slutsatsen: hur beräknas ShortPixel-krediter?

ShortPixel Officiell dokumentation KB uttryckte det mycket rakt på sak:

• WordPress genererar flera miniatyrbilder när du laddar upp en bild;
• Varje optimering av en miniatyrbild räknas som en kredit；
• Om du väljer att generera en WebP- eller AVIF-fil, kommerVarje WebP/AVIF-version av originalbilden och miniatyrbilden förbrukar ytterligare en kredit.；
• Du kan utesluta vissa miniatyrbilder från att optimeras för att minska kreditförbrukningen.

Exempel på krediter：

Låt oss säga att du laddar upp 1 bild och temat/pluginet genererar 8 miniatyrbilder:

• Optimera endast originalbilden + miniatyrbilder: 1 (original) + 8 (miniatyrbilder) = 9 poäng
• Om du också vill generera WebP/AVIF: ytterligare en next-gen-version för var och en av de 9 ovan → +9 poäng.
  Med andra ord, det du tror är “1 bild” kan i själva verket konsumera nära “2-siffriga krediter”.

Så..:“Gratis 100 krediter” är inte samma sak som “gratis 100 bilder”.

ShortPixels vanligaste fallgropar

1. Gratis 100 krediter tar slut snabbt
   Grundorsak: många miniatyrbilder + extra poäng för generering av WebP/AVIF.
   förslag：

• Bedöm först antalet miniatyrbilder på webbplatsen
• Uteslut onödiga miniatyrstorlekar (optimera bara storlekar som faktiskt kommer att användas)
• Bestäm kompressionsstrategin innan du kör i bulk för att undvika upprepade försök och felkonsumtion

2. Stackning av andra konverterings plug-ins på samma gång
   Om du har Plus WebP-ersättningar och ShortPixel som genererar / infogar nästa generations taggar, staplas logiken upp och blir svårare att felsöka. För rutt B, låt ShortPixel göra det ensam.
3. Jag trodde att om jag installerade det skulle det vara “WebP/AVIF i förgrunden”.”
   ShortPixel plugin-sidaNämnde att den konverterar WebP/AVIF och kan lägga till nästa generations bilder på förstasidan (t.ex. genom taggning).
   Men det är fortfarande viktigt att verifiera resultaten efter att ha gjort det.

---

3.2.2 ImagifyGratis: 20MB/månad; kvoten dras av enligt “originalbildstorlek + antal miniatyrbilder”, upprepade avdrag kommer att göras för ompressning.

Fri mängd och positionering

Imagify Officiell prissidaTexten är tydlig:Gratis konto Månad 20MB Kvot。
Dess plugin-sida gör det också klart att det kan komprimera, ändra storlek och konvertera WebP / AVIF.

Hur dras kvoten av?

Imagify Officiell dokumentation “Hur beräknas kvotanvändningen?” beskriver avdragsmekanismen på ett mycket tydligt sätt:

• Antal miniatyrbilder påverkar förbrukningenOm du t.ex. har 10 miniatyrbilder blir optimeringen av 1 bild en optimering av 11 bilder (original + 10 miniatyrbilder), som alla bidrar till kvotförbrukningen.
• Avdrag från kvoten beroende på originalhandlingens storlek: Om du t.ex. skickar en bild på 100 kB till Imagify dras 100 kB av från kvoten.
• Om du ändrar komprimeringsnivån och optimerar på nytt kommer kvoten att förbrukas igen。
• Samma API-nyckel kan användas för flera webbplatser, men kvoterna delas mellan dem.

Detta är Imagifys “grundläggande sätt att förstå”:
Det är mer som ett trafikpaket: det drar av lika mycket som du skickar; ju fler miniatyrbilder du har, desto mer drar det av; och du upprepar avdraget om du upprepade gånger trycker på det.

Lättläst exempel på Imagify-kvot

Låt oss säga att du laddar upp en originalbild på 800 KB och webbplatsen genererar 8 miniatyrer.

• Imagify optimerar för att inkludera “originalbilden + 8 miniatyrbilder” (om du väljer att optimera dem alla), vilket innebär att denna enda åtgärd förbrukar en kvot som är nära “originalstorleken för alla dessa filer tillsammans”.
  Det är därför som vissa webbplatser upplever att “20MB tar slut snabbt”: det är inte så att Imagify inte räcker till, det är så att du laddar upp för många bilder åt gången, för många miniatyrbilder, och du provar förmodligen komprimeringsnivåer om och om igen.

Imagifys vanligaste fallgropar

1. Gratis 20MB Inte tillräckligt för att göra en “fullständig historisk inventering av platsen”
   20MB är vanligtvis bättre lämpad för testning med lätta uppdateringar; om ditt mediebibliotek redan är stort kommer en engångsrensning sannolikt att kräva en uppgradering.
2. Upprepad justering av kompressionsnivåer leder till dubbel kvotförbrukning
   Imagify klargör attEn ny optimering kommer att förbruka kvoten igen.
   Jag föreslår att du klargör “strategin” på den här sidan:

• Börja med ett litet antal bilder för att bestämma komprimeringsnivå och utseende
• Bestäm strategin och kör sedan i bulk
  Undvik upprepade försök och misstag på hela biblioteket

3. Flera webbplatser som delar API-nyckel leder till “oförklarlig kvotminskning”.”
   Om du använder samma API-nyckel för mer än en station delas kvoten.
   Så i scenarier med team och flera stationer är det bäst att vara tydlig med vilka stationer som delas och vilka som används individuellt för att undvika okontrollerbara budgetar.

---

3.2.3 LitenPNG(Tiny Compress Images): gratis 500 krediter/månad; byte till WebP/AVIF kommer att “dra av 1 kredit per storlek”.”

Gratis krediter och dess faktureringsidéer

TinyPNG:s WordPress plugin-sida är mycket tydlig:

• 500 krediter per månad utan kostnad
• I “Allmän WordPress-installation” kan du förmodligen komprimera Cirka 100 bilder/månad
• Men om AVIF- eller WebP-konvertering är aktiverad:Varje bildstorlek förbrukar en extra kreditSå antagligen kan det bara komprimeras och konverteras Cirka 50 bilder/månad(beroende på hur många miniatyrbildsstorlekar du har).

Under tiden har Tinify (utvecklarna av TinyPNG/TinyJPG) också gjort sina API-prissidaBeskrivning: Registrera dig och få 500 gratis kompressioner per månad; efter det faktureras du efter antalet lyckade kompressioner, ingen obligatorisk prenumeration.

Sammanfatta hur TinyPNG uppfattas i en mening:
Den räknar krediter; ju fler miniatyrstorlekar du har och ju mer WebP/AVIF du har aktiverat, desto snabbare förbrukas krediterna.

Lättlästa exempel på TinyPNG-krediter

Anta att din webbplats genererar 8 miniatyrstorlekar för varje bild:

• Endast komprimering: original + 8 miniatyrbilder → 9 poäng krävs
• Om WebP/AVIF-konvertering är aktiverad: en extra poäng per storlek → förmodligen nästan dubbelt så mycket!
  Detta motsvarar beskrivningen på plugin-sidan: efter att ha slagit på ändras det fria beloppet från cirka “100 kort/månad” till “50 kort/månad”.

De vanligaste fallgroparna med TinyPNG

1. Tanke 500 krediter = 500 bilder
   Det är det inte. Den konsumeras av “bildstorlek/variant”. Plugin-sidan varnar tydligt för att “Konverteringar drar av ytterligare 1 kredit för varje bildstorlek”.
2. Teman/e-handelsplugins genererar för många storlekar och de fria krediterna sjunker avsevärt
   Ju fler storlekar det finns, desto lättare är det att skala upp och konsumera krediter.
3. När du har aktiverat konverteringen upptäcker du att krediterna plötsligt är oanvända.
   Det är inte en bugg, det är dess faktureringsmekanism.
   Råd om strategi:

• Om den fria fasen huvudsakligen används för komprimering och viktminskning kan du börja med enbart komprimering och sedan aktivera konvertering när du är säker på att webbplatsens struktur är stabil och att du verkligen behöver nästa generation.

4. Rekommendation för underscenario: hur man väljer olika typer av platser

WordPress, innehållssajter, e-handelssajter, portfolios och medlemssajter har inte heller samma “tryckpunkter” för bilder.

4.1 Innehållssajter/bloggar (mycket artikelgrafik, medelhög uppdateringsfrekvens)

Prioriterade rekommendationer:

1. Strategi för dimensionering (steg 1)
2. Komprimering (steg 2)
3. WebP (steg 3)

En mer lämplig väg:

• Vill du spara: Route B Triple Choice (ShortPixel / Imagify / TinyPNG)
• Om du vill gå gratis: Väg A (Plus WebP + EWWW), men det rekommenderas att börja med det “konservativa läget (utan att ta bort originalbilden)” för att bedöma risken.

Typisk grop:

• Den första bilden på artikelsidan är mycket stor, felaktig strategi för latladdningSaktar ner den första skärmen

4.2 Webbplats för e-handel/produkter (många miniatyrbilder, många bildvarianter, stabilitet först)

E-handel är mest sannolikt att vara problemet är inte “komprimeringseffekten är inte bra”, utan “optimerad en del av storleken är inte rätt, saknade miniatyrbilder, främre komponenter kan inte få bilden”.

Prioriterade rekommendationer:

1. Stabilitet först: konservativ kompressionsstrategi, gör inte ett fullständigt byte av bibliotek direkt
2. Utvärdering av miniatyrbildsstorlekar: e-handelsteman genererar vanligtvis fler storlekar, och mängden förbrukning förstoras (ShortPixel/TinyPNG är särskilt märkbart)
3. Gör validering i liten skala före batch (mycket kritiskt)

En mer lämplig väg:

• Väg B tenderar att vara mer problemfri: ShortPixel/Imagify/TinyPNG kan alla batcha, och det är viktigt att du förstår kvotmekanismen och bedömer kostnaden i förväg
• Väg A är bra, men var mer försiktig med Plus WebPs “skriv över ID:n/radera originalbilder/ersätt webbadresser”-beteende: det är en migrering av tillgångar, och det rekommenderas inte att ersätta hela saken direkt.

4.3 Portfolio/fotostation (kvalitetsmässigt känslig enkelbild, stora bilder, höga krav på betraktning)

Prioriterade rekommendationer:

1. Storleksstrategi (kontroll av visningsyta)
2. Komprimeringsstrategi (bättre att vara större än att krossa detaljerna)
3. WebP/AVIF (vinsterna med stora bilder är uppenbara, men verifiera vyn)

En mer lämplig väg:

• Imagify: Dra av kvoten enligt “originalbildens storlek”, den här typen av webbplats är lättare att göra “budgetkontrollerbar” (du vet hur mycket du ska dra av för varje stor bild), men undvik upprepade förtryck.
• KortPixel: Om miniatyrstorleken inte är mycket är krediter också mycket intuitiva; men om du genererar många storlekar +next-gen kommer kreditförbrukningen att förstoras och du måste planera framåt.

5. Jämförelse mellan kvot och fakturering: att sätta “gratis är inte tillräckligt” i perspektiv

Vilken är den bästa affären och hur länge kommer gratis att vara?

5.1 Tre modeller för återbetalning av avgifter

• KortPixel(krediter): Krediter baseras på “originalbild + antal miniatyrbilder”; ytterligare krediter kommer att dras av för varje motsvarande version av WebP/AVIF som genereras.
• Imagify(MB kvot): Dra av kvoten enligt “originalfilstorleken”; ju fler miniatyrbilder, desto fler avdrag; ompressning drar av igen.
• LitenPNG(krediter): 500 krediter per månad; aktivering av WebP/AVIF-konvertering drar av ytterligare krediter för varje bildstorlek.

5.2 Metoder för snabb uppskattning

Du kan uppskatta det så här:

1. Hitta en slumpmässig “originalbild som du ofta laddar upp” och se hur stor den är (t.ex. 300KB / 1MB / 3MB).
2. Beroende på hur många miniatyrstorlekar din webbplats genererar (t.ex. 5 / 10 / 20)
3. Bestäm om du vill generera WebP/AVIF (ja/nej)

Använd sedan följande “mentala matematik” för att förstå konsumtionen:

• KortPixel: ≈ (1 + antal miniatyrbilder) krediter per bild; om WebP/AVIF genereras fördubblas ≈ igen (eftersom nästa generations version också tar kredit)
• Imagify: Varje bild ≈ (originalstorlek + varje miniatyrstorlek) drar av kvoten; ändra komprimeringsnivå och komprimera igen kommer att dra av igen.
• LitenPNG: 500 krediter gratis; om din webbplats genererar många storlekar per bild, och konvertering är aktiverad, sjunker antalet gratis krediter avsevärt (plugin-sidan ger en visuell förväntan på “~ 100 krediter / månad” jämfört med “~ 50 krediter / månad”)

6. Riskvarningar

Risk 1: Låt inte flera plugins göra samma sak om och om igen

Det är den vanligaste “katastrofkällan”.”

• Väg A:Plus WebP eller AVIF + EWWW(Dela upp arbetet mellan de två, gör inte likadana konverteringar och leveranser samtidigt, eller installera bara en av dem)
• Väg B: ShortPixel / Imagify / TinyPNG välj tre(välj en för att komprimera med next-gen)

Risk 2: Plus WebP:s “Skriva över ID / Ta bort originalbild / Ersätta URL” är en migrering av tillgångar.

Understrykning tillagd:Plus WebP I beskrivningen anges tydligt att fullständig generering skriver över det ursprungliga bild-ID:t, raderar originalfilen och ersätter innehållets URL.
Detta innebär att det inte är en “liten inställning som kan tas ut när som helst”, utan en förändring på tillgångsnivå.

Den föreslagna strategin bör vara:

• Små test först (några dussin till några hundra)
• Bekräfta att frontend-visningen, miniatyrbilderna och cache-uppdateringarna fungerar som de ska
• Ompröva fullständig bearbetning av biblioteket

Risk 3: Den verkliga förbrukningen av “gratiskrediter” för molnkomprimering beror på antalet miniatyrbilder och valet av nästa generation.

• KortPixel: Miniatyrbilder och next-gen påverkar krediterna avsevärt.
• LitenPNG: Om WebP/AVIF aktiveras dras en extra kredit av för varje bildstorlek.
• Imagify: dras av enligt storleken på originalbilden, ju fler miniatyrbilder som dras av mer, tungt tryck kommer att upprepa avdraget!

Risk 4: “WebP/AVIF genereras” betyder inte “WebP/AVIF levereras av front office”

Många känner sig “inte snabbare” efter konverteringen eftersom frontend fortfarande skickar ut JPG/PNG (caching/omskrivning/taggning/webbläsarförhandling är inte på rätt plats).

7. Hur man kontrollerar att det har trätt i kraft efter att det har gjorts

4 mycket enkla valideringspunkter:

1. Om samma sida uppdateras en andra gång och laddas mer konsekvent och snabbare(Cachelagring och optimering av den fysiska känslan av om det fungerar)
2. Är storleken på bilder som laddas på mobiltelefoner och stationära datorer väsentligt olika(lyhörd) srcset/storlekar (oavsett om de fungerar eller inte)
3. Stickprovskontrollera några bilder: om WebP- eller AVIF-filer/resurser finns(Använder webbplatsen faktiskt nästa generation）
4. Prova några bilder: zooma in för att se om de är synligt grumliga, om texten är suddig(komprimerad massa är inte överdriven)

Om alla fyra stämmer överens har den rutt du har valt körts. Nästa steg. CDN “Leveranslager”blir helheten mer stabil.

8. Rekommendationer för åtgärder

1. Välj din rutt först:

• Försöker vara så fri som möjligt.: Plus WebP eller AVIF + EWWW (eller bara en av dem)
• Vill du spara serverresurser, betala per kredit för att spara ännu mer!: ShortPixel / Imagify / TinyPNG - välj en!

2. Gör ett litet test först (några dussin)
3. Se till att det är okej innan du batchar
4. Ytterligare förbättringar av leveransstabiliteten krävs:läsa CDN Acceleration

gemensamma problem

1. Hur många plug-ins måste jag installera? Kan jag installera dem alla?

Försök att bara ta en väg.

• Väg A: Plus WebP eller AVIF + EWWW Image Optimizer (eller bara en av dem)
• Väg B: ShortPixel / Imagify / TinyPNG - välj en!
  I samma station samtidigt låt mer än en plug-in göra “komprimering / överföring WebP / AVIF / ändra URL / leverans omskrivning”, det mest troliga att bli mer och mer kaotiskt, men också det svåraste att kontrollera.

2. Har WordPress inte redan stöd för WebP/AVIF? Behöver jag fortfarande ett plugin?

Den måste separeras:
“Stöd för uppladdning/användning” ≠ “Automatisk konvertering/automatisk leverans”.
WordPress 6.5 batchkonverterar inte heller automatiskt gamla JPG/PNG till WebP/AVIF, och gör inte heller automatiskt hela “exportera AVIF/WebP till webbläsarkapacitet och fallback”-grejen åt dig. Det krävs vanligtvis ett plugin eller en tjänst för att få det historiska mediebiblioteket att fungera.

3. Vilket är det mest “givande” steget i bildoptimeringen?

Det är vanligtvis Se till att “storlekarna” stämmer först (srcset/sizes).。
Många webbplatser är långsamma inte för att de inte har komprimering, utan för att sidan bara är 900 pixlar och användaren ombeds ladda ner en bild på 3000 pixlar. Komprimering sparar kB, men “fel storlek” gör att du laddar ner flera gånger mer data för ingenting.

4. Hur kan jag vara säker på att jag laddar den “mindre” och inte originalbilden för alltid?

Titta på två företeelser:

• När du öppnar en sida på en mobiltelefon är storleken på den nedladdade bilden märkbart mindre än på skrivbordet
• Samma bild laddas med olika resursstorlekar på olika enheter
  Om originalbilden laddas ner för evigt är en vanlig orsak att temat/byggaren behandlar bilden som en CSS-bakgrundsbild eller anpassad utdata, och kringgår mediebibliotekets multistorlek med srcset.

5. Innebär “WebP/AVIF genererad” att frontend måste producera WebP/AVIF?

Inte lika.
Generering är bara “filskiktet” färdigt; om frontend faktiskt levererar WebP/AVIF beror på omskrivningar, policyer för bildtaggning, cacheträffar, webbläsarförhandling i kraft och så vidare. När du är klar, se till att “stickprovskontrollera några bilder för resurstyper”.

6. plus Vad är det som är så farligt med WebP eller AVIF? Kan jag köra hela biblioteket med ett klick?

Dess riskpunkt är inte “kompression”, den ärFörändringar i tillgångarnas migrationsnivåer：

• Fullständig generering kan skriva över den ursprungliga bildfilens ID, radera den ursprungliga filen och ersätta URL:en i innehållet.
  anledningen till varförDet är inte rekommenderat att byta ut hela biblioteket på en gång: Testa i liten skala (dussintals till hundratals) + ha tillgängliga säkerhetskopior innan du överväger att bearbeta hela biblioteket.

7. Vad är valet mellan de två lägena för Plus WebP: behåll originalbilden vs. ersätt och ta bort originalbilden?

Enkelt att förstå:

• Läge 1: Behåll originalbilden + generera WebP/AVIF-kopia (stabilare): Bekvämt för återställningar, men disken går upp (originalbild + nytt format + miniatyrer i flera storlekar).
• Läge 2: Byt ut och radera originalbilden (mer aggressivt): Diskar är mindre benägna att svälla, men du “byter tillgångar + byter referenser”, vilket gör det dyrare att felsöka kompatibilitetsproblem.
  Ju mer komplex webbplatsen är (e-handel/multi-plugin/multi-size), desto mer rekommenderas det att börja med en mer stabil modell.

8. Är EWWW Image Optimizer gratis lokal komprimering tillräckligt? Kommer det att överbelasta servern?

EWWW är mer av en “lokal kompressor”: den äter CPU/IO.
Det är vanligt att belastningen ökar under batchoptimering, vilket inte betyder att det “inte fungerar”, utan snarare att strategin bör vara rätt: batch, låga toppar och avlastning/molnalternativ vid behov.
Om du vill spara pengar eller om du har ont om serverresurser är Route B mer servervänlig.

9. ShortPixels 100 gratis krediter/månad, varför känns det som att de är borta på några bilder?

på grund av Credits är inte “antal bilder”.”Nästa generation kommer att förstoras med en miniatyrbild med nästa generation:

• Originalbild + varje miniatyrbild räknas som kredit
• Om en WebP/AVIF genereras, förbrukas ytterligare en kredit för varje motsvarande version.
  Så vad du tror är “1 bild” kan i själva verket konsumera nära “2-siffriga krediter”. shortPixel

10. Imagifys gratis 20MB/månad, varför tar den också slut snabbt?

Imagify är mer som ett “trafikpaket”:

• Som du skickade det.Originalfilens storlekAvdrag för kvoter
• Ju fler miniatyrbilder du har, desto mer förbrukar du
• Om du ändrar komprimeringsnivån för att optimera igen kommer kvoten att förbrukas igen
• Samma API-nyckel för flera webbplatser, kvotdelning
  Så “20MB tar snart slut” orsakas ofta av för stora bilder, för många miniatyrbilder eller upprepade försök och fel.

11. TinyPNG är gratis för 500 krediter / månad, varför säger plugin att det bara är cirka 100 krediter / månad och sedan 50 krediter / månad med WebP / AVIF?

Eftersom TinyPNG-krediter också förstoras med “storlek/variant”:

• En vanlig WordPress-installation komprimerar förmodligen cirka 100 ark/månad.
• Aktivera AVIF- eller WebP-konvertering:Varje bildstorlek förbrukar en extra kreditSå du kan förmodligen bara komprimera och konvertera cirka 50 bilder per månad (beroende på antalet miniatyrbilder).
  Så 500 krediter ≠ 500 bilder.

12. Hur många miniatyrbilder finns det på min webbplats? Varför spelar det så stor roll?

WordPress genererar flera storlekar när du laddar upp en bild; teman/plugins (särskilt e-handel) kan lägga till fler storlekar.
Molnkomprimeringskrediter/kvoter är vanligtvis “original + miniatyrbilder tillsammans”, så ju fler miniatyrbilder du har, desto mindre fria krediter har du att använda.

13. Är latent laddning alltid snabbare? Varför säger vissa människor att lazy loading gör saker långsammare?

Lazy loading är lämpligt för “resurser utanför skärmen”.
Om den första skärmen på den mest kritiska stora bilden också är försenad laddning, kan det sakta ner den första skärmupplevelsen. WordPress 5.5 sedan standard latladdning är bra, men inte “en storlek passar alla”.

14. Jag reser på väg A eller B. När behöver jag CDN / Picture CDN?

Komprimering, storleksanpassning och formatering löser problemet med “mindre filer som får plats”;
CDN Lösningen är att leverera närmare och mer stabila。
När bilder hämtas från ett avstånd från källwebbplatsen, vilket resulterar i betydande latens, kommer det att vara generellt mer stabilt att komplettera CDN/bilder med CDN (t.ex. Cloudflare Polish / Jetpack Site Accelerator), läs WordPress CDN Acceleration。

15. Vad är det enklaste sättet för mig att verifiera att “det verkligen fungerar” när jag är klar?

Den mest tidseffektiva verifieringsmetoden:

• Om samma sida uppdateras en andra gång och laddas mer konsekvent och snabbare
• Är storleken på de bilder som laddas på mobiltelefoner och stationära datorer märkbart olika (spelar srcset/storlekar in?)
• Stickprovskontrollera några bilder: om WebP- eller AVIF-filer/resurser finns
• Prova några bilder: zooma in för att se om de är synligt grumliga, om texten är suddig