Optimalisering av bilder på nettstedet

Bildeoptimalisering er et av de mest “givende” aspektene ved WordPress-ytelse: Så lenge bildestørrelsen, dimensjonene, formateringen og leveringen er riktig, vil innlastingsopplevelsen umiddelbart bli bedre for samme sidestruktur og tema.

Men bildeoptimalisering er også den enkleste måten å rote det til på, ikke fordi det er for teknisk vanskelig, men fordi informasjonen er for fragmentert:
Du leser noen få artikler, vet at “komprimering”, “WebP / AVIF”, “lat lasting”, og se deretter på plugin-introduksjonen og sa “gratis hver måned! 100 studiepoeng per måned”, “Gratis 20MB”, “1 kreditt per bilde”, men jo mer jeg leser, jo mer forvirret blir jeg -. Er gratis nok? Hvordan trekke fra avgiften? Misforstod du “det samme”? Og viktigst av alt:Virket det faktisk etter at du gjorde det eller ikke?

Denne artikkelen gjør bare tre ting:

1. Gi deg en kjørbar filveikart (også fig.)(Hva du skal gjøre først, hva du skal gjøre etterpå)
2. Vær tydelig på hvilket alternativ du går for (hva er forskjellen mellom gratis/betalt og hvem passer de ulike alternativene for)
3. Skriv ned de vanligste fallgruvene på forhånd (slik at du ikke trenger å lete rundt for å feilsøke når du er ferdig)

1. Poenget: Hva WordPress kommer med og hva det ikke gjør

Hvis du ikke først finner ut hva WordPress-kjernen allerede gjør, er det lett å gjøre én av to ting:

• I stedet for å bruke den “ledige kapasiteten” du burde hatt, bruker du tid/betaler penger på å bygge hjulet om og om igjen.
• Jeg trodde WordPress ville “automatisk konvertere alle gamle bilder til WebP/AVIF”, men det viser seg at det ikke gjør det!

WordPress-kjernen har disse nøkkelfunksjonene innebygd:

• Responsive bilder (srcset/størrelser): Fra og med WordPress 4.4 vil kjernen sende ut bilder for srcset 与 sizesog utnytter bildene i flere størrelser som genereres under opplastingen, slik at nettleseren kan velge en mer passende ressurs å laste inn ut fra skjermforholdene.
• Innfødt lat lasting: WordPress 5.5 og nyere muliggjør innfødt lat lasting av bilder som standard, ved hjelp av HTML-standarder. loading implementering av attributtet.
• Støtte for opplasting av WebP: Siden WordPress 5.8 kan du laste opp og bruke WebP som JPEG/PNG (forutsatt at vertsmiljøet ditt støtter WebP).
• Støtte for opplasting av AVIF: Siden WordPress 6.5 kan du laste opp og bruke AVIF som JPEG/PNG (avhenger også av hostingstøtte).

Men vær oppmerksom:
“Støtte for opplasting/bruk” ≠ “Automatisk konvertering/automatisk levering”.
Det vil si: selv om du allerede er på WP 6.5, vil ikke JPG / PNG-ene i mediebiblioteket ditt bli til WebP / AVIF på egen hånd; du får ikke automatisk den fulle “output AVIF / WebP i henhold til nettleserens evner og fallback til originalbildet for nettlesere som ikke støttes” -lenken! --Denne delen må vanligvis oppdateres av en plugin eller tjeneste.

2. Veikart: Bildeoptimalisering i 5 trinn

Hva du skal gjøre, hvorfor, hva du må gjøre for å kvalifisere deg, og hva en typisk pit er.

2.1 Få “størrelsen” riktig først (det mest oversette, men det mest givende)

Mange stasjoner er trege, ikke fordi komprimeringen ikke er ferdig, men fordiLastet ned et stort bilde som strekker seg langt utenfor visningsområdet：
Hvis siden for eksempel bare er 900 px bred, og du ber den besøkende om å laste ned det opprinnelige bildet på 3000 px, vil nettleseren bare “laste det ned og deretter krympe det”. Dette sløser med båndbredde, øker dekodingstiden og reduserer hastigheten på den første skjermen.

WordPress 4.4+Responsiv bildemekanisme（srcset/sizes) er utformet for å løse nettopp dette problemet.

Gjør det som teller som en pasning:

• Når du åpner en side på en mobiltelefon, bør størrelsen på det nedlastede bildet være betydelig mindre enn på skrivebordet
• Det samme bildet lastes inn med forskjellige ressursstørrelser på ulike enheter (i stedet for alltid å laste ned originalbildet)

De vanligste fallgruvene:

• Det finnes temaer/byggere som behandler diagrammer som CSS-bakgrunnsbilder, eller som gir dem ut på en tilpasset måte som kan omgå srcsetResultatet har blitt et stort bilde av
• Du kan bruke eksternt koblede bildesenger, bildeblokker fra tredjeparter, og du kan også omgå systemet med flere størrelser som genereres av mediebiblioteket

---

2.2 Komprimering (få ned KB, men ikke “knus” kvaliteten)

Kjernen i komprimering er ikke “jo mindre, jo bedre”, men “forskjellen er knapt synlig for det blotte øye, men volumfallet er åpenbart”.

Reglene er som følger:

• Fotografier/livebilder (mennesker, produkter, landskap): Prioritert komprimering med tap (maksimal forsterkning)
• Skjermbilder av grensesnittet / teksttunge bilder: Komprimeringen bør være mer konservativ for å unngå utydelig tekst
• Logo/Icon: Prioritert SVG eller diskret lossless (lossy er enkelt å lime inn på kanten)

Gjør det som teller som en pasning:

• Betydelig reduksjon i bildestørrelse på de fleste sider
• Ingen synlig støy, grumsete kanter, fargeblokkbrudd, uskarp tekst

---

2.3 WebP / AVIF (formatstrategi: mindre for lik definisjon)

WordPress støtter allerede opplasting WebP (5,8) vs. AVIF (6,5)。
Men for at Next Generation Format virkelig skal fungere, er det vanligvis to ting som må løses:

1. Slik batchkonverterer du historiske mediebiblioteker(Ellers optimaliserer du bare for “nye bilder som lastes opp senere”)
2. Om du vil generere en kopi eller erstatte originalbildet(Dette er et risikabelt farvann; vi skal fokusere på Plus WebPs “Erstatt og slett originalbilde” senere)

Anbefalt skrivestil:

• WebP: generelt foretrukket som standard (mer stabil kompatibilitet)
• AVIF: en ytterligere komprimeringsretning, egnet for store bilder/store bilder på første skjerm/albumbilder (men merAvhengighet av støtte fra omgivelsene）

---

2.4 Lazy loading bør brukes riktig (ikke en størrelse som passer alle)

WordPress 5.5 og nyereStandard lat lastingBilde.
Det reduserer båndbreddebruken under den første gjengivelsen:

• Lazy loading for “ressurser utenfor skjermen”
• Det mest kritiske store bildet på det første skjermbildet (og i mange tilfeller nøkkelbildet på det første skjermbildet) er ofte uegnet for forsinket innlasting

---

2.5 Leveringslag: CDN / Image CDN

Komprimering, dimensjonering og formatering løser problemet med “mindre filer som får plass”.
Men hvis bildene alltid hentes fra en viss avstand fra kilden, vil nettverksforsinkelsen fortsatt påvirke opplevelsen betydelig. Det er her “leveringslagsløsningen” (CDN/Image CDN) kommer inn i bildet.

To typiske retninger:

• Cloudflare polsk：Cloudflare-dokumentasjonPolske komprimeringsmetoder (lossless/lossy/WebP) introduseres, og det nevnes at komprimering med format=auto WebP/AVIF-format er tillatt.
• Jetpack Site Accelerator：Jetpack-dokumentasjonForklar at de vil optimalisere bilder og distribuere dem gjennom nettverket sammen med statiske ressurser.

Bildeoptimalisering er ansvarlig for at bildene blir mindre og mer hensiktsmessige.CDN Ansvarlig for å levere tettere og mer stabile

3. Utvalg: kun to hovedruter

Den vanligste feilen i bildeoptimalisering er ikke “ingen plugins”, men for mange plugins som fører til dobbel behandling:
A komprimerer, B komprimerer, A konverterer til WebP/AVIF, B konverterer, A endrer URL-adresser, B omskriver - det er ikke engang mulig å se hva som skjer på stasjonen.

Regler:

Det er bare én vei å gå: enten helt gratis lokal komprimering eller skykomprimering av de tre.

• Rute A (alt gratis lokaltrafikk):Pluss WebP eller AVIF + EWWW Image Optimizer(eller bare én)
• Rute B (trippelalternativ for skykomprimering):ShortPixel / Imagify / TinyPNG

---

3.1 Rute A: Full Free Local (pluss WebP eller AVIF eller EWWW)

Denne ruten kjennetegnes av:

• Du er ikke avhengig av komprimeringstjenester fra tredjeparter (selv om enkelte funksjoner kan tilbys som valgfrie tjenester).
• Kostnaden: Batchbehandling kan være mer serverkrevende på CPU/IO, noe som krever at du må være mer oppmerksom på “strategi og risiko”.”

3.1.1 Pluss WebP eller AVIF: Kjernen er “generere/erstatte”, det er ikke et tradisjonelt “komprimeringsverktøy”.”

• Når du genererer fullvolumbilder:Den opprinnelige bildefil-ID-en overskrives av WebP/AVIF, den opprinnelige filen slettes, og URL-en i innholdet erstattes.。
• Plugin-programmet gir WP-CLI-kommandoer og minner om: WP-CLI er mer pålitelig når det er mange filer.

Dette betyr at i stedet for å “stille og rolig generere en WebP for deg”, kan det være enMigrering av eiendeler(Spesielt hvis du slår på alternativet “Erstatt og slett originalbilde”).

Forskjeller mellom de to modellene

Modus 1: Behold originalbildet + generer WebP/AVIF-kopi (mer stabil)

• Fordeler: Lettere å falle tilbake i tilfelle kompatibilitetsproblemer
• Kostnad: Diskbruken vil øke (originalbilde + nytt format + miniatyrbilder i flere størrelser)

Modus 2: Erstatt og slett originalbildet (mer aggressivt)

• Fordeler: diskene utvides ikke like raskt; stasjonsreferanser går direkte til det nye formatet
• Risiko: Du “endrer ressurser + endrer referanser”, noe som gjør det dyrere å feilsøke kompatibilitetsproblemer (spesielt hvis noen eksterne systemer eller temalogikker er avhengige av det opprinnelige filnavnet/stien/formatet).

Typiske fallgruver med Plus WebP eller AVIF

1. Etter at hele biblioteket er byttet ut, vises noen sidebilder på en unormal måte.
   Årsaken til dette er vanligvis ikke at bildet er “ødelagt”, men at et eller annet ledd i kjeden av URL-erstatning, hurtigbufring, miniatyrbildepolicy osv. ikke er korrekt.
2. Jo flere miniatyrbilder, desto større blir omfanget av endringen
   WordPress genererer flere størrelser når du laster opp et bilde; temaer/plugins kan også legge til flere størrelser. Full erstatning betyr at du kan endre en svært stor samling filer.
3. En formatmigrering betyr ikke nødvendigvis at volumet alltid er det minste
   WebP/AVIF er generelt mindre, men “størrelsesstrategi” og “komprimeringsstrategi” er fortsatt avgjørende. Ikke tenk på Plus WebP som “ett klikk raskere”.

---

3.1.2 EWWW Image Optimizer: representant for fri lokal komprimering

EWWW-plugin-siden er veldig godt plassert:

• Den kan optimaliseres på serveren din ved hjelp av en rekke verktøy (jpegtran, optipng, pngout, pngquant, gifsicle, cwebp osv.)
• Du kan også overføre CPU-forbrukende behandling til serveren (valgfritt) hvis du trenger høyere komprimering eller flere CPU-besparelser.

Hvilken rolle bør EWWW ta i Rute A?

Hvis du bruker Plus WebP som en “formatmigrerings-/erstatningsstrategi”, passer EWWW bedre:

• Komprimering og volumoptimalisering(spesielt vektreduksjon av råressurser som JPG/PNG)
• Batchoptimalisering av historisk mediebibliotek(med mål om “volumreduksjon” i stedet for “URL-erstatning”)

Typisk grop av EWWW

1. Forhøyet serverbelastning under batchoptimalisering
   Fordi lokal komprimering spiser CPU/IO, er ikke løsningen “ikke bruk det”, men “batch, lav peak, offload/sky-alternativ om nødvendig”.
2. “En WebP genereres” betyr ikke at frontend må produsere en WebP.
   Mange plugins lider av denne misforståelsen: Generering er én ting, leveringsstrategier (omskriving, bildekoder, cachetreff osv.) er noe annet.
3. Gjør det samme om og om igjen med andre plugins
   Hvis du velger rute A, prøv å ikke legge over ShortPixel / Imagify / TinyPNG-type skykomprimering; hvis du velger rute B, ikke slå på Plus WebP-erstatningslogikken. Kjerneprinsipp:En vei til slutten.

---

3.2 Rute B: Trippelvalg for skykomprimering (ShortPixel / Imagify / TinyPNG)

Denne ruten passer for folk som “ønsker å spare serverressurser, ønsker å gjøre batch med mindre innsats og aksepterer fakturering per kreditt/per volum”.
Men det mest misvisende poenget med skykomprimering er:Gratis studiepoeng er ikke så enkelt som “gratis ark”!.. Antall miniatyrstørrelser, om det genereres WebP/AVIF eller ikke, og om det gjentatte ganger settes under trykk, kan påvirke forbruket betydelig.

I det følgende forklarer vi hva som skjer med gratis/avgift, hvordan kreditter trekkes fra, hvilke fallgruver det er størst sannsynlighet for å tråkke i, og hvilke typer nettsteder som er passende.

---

3.2.1 ShortPixel100 gratis kreditter/måned, men kreditter forbrukes av miniatyrbilder og WebP/AVIF-forstørrelser.

Hva skjer med gratis/betalt

I beskrivelsen av ShortPixel-plugin-modulen står det tydelig:

• 100 gratis kreditter per måned
• Det finnes også “Extra Unlimited Monthly Credits” (plugin-siden gir informasjon om de tilsvarende prisene)
• Også tilgjengelig som “engangspakker som aldri utløper” (med informasjon om startpris)

Tips:

• Gratis: gi et visst antall kreditter per måned for lette nettsteder eller testing
• Engangspakker: Passer for nettsteder med store mediebiblioteker som ønsker å tømme lageret på én gang (kjøp én gang og bruk den opp, den går vanligvis ikke ut på dato).
• Månedlig/ubegrenset: passer for nettsteder med kontinuerlig oppdaterte bilder og langsiktig stabil optimalisering

ShortPixels offisielle KB har også gitt en oppdatering om “One Time Pack vs Unlimited Monthly”.eksplisitt forklaring: Unlimited Monthly er en månedlig (eller årlig) betaling som tilbyr ubegrenset antall kreditter med en fast tildeling på CDN; engangskreditter som ikke utløper, noe som gir deg mer kontroll over bruken din på forespørsel.

Poenget: Hvordan beregnes ShortPixel-kreditter?

ShortPixel Offisiell dokumentasjon KB sa det veldig rett ut:

• WordPress genererer flere miniatyrbilder når du laster opp et bilde;
• Hver miniatyrbildeoptimalisering teller som en kreditt；
• Hvis du velger å generere en WebP- eller AVIF-fil, vilHver WebP/AVIF-versjon av originalbildet og miniatyrbildet krever en ekstra kreditt.；
• Du kan ekskludere visse miniatyrbilder fra optimalisering for å redusere forbruket av kreditter.

Eksempel på studiepoeng：

La oss si at du laster opp ett bilde, og at temaet/plugin-modulen genererer åtte miniatyrbilder:

• Optimaliser bare originalbildet + miniatyrbilder: 1 (original) + 8 (miniatyrbilder) = 9 studiepoeng
• Hvis du også vil generere WebP/AVIF: en nestegenerasjonsversjon til for hver av de 9 ovenfor → +9 studiepoeng.
  Med andre ord kan det du tror er “1 bilde”, i virkeligheten forbruke nærmere “2-sifrede kreditter”.

Så..:“100 gratis kreditter” er ikke det samme som “100 gratis bilder”.

ShortPixels vanligste fallgruver

1. Gratis 100 kreditter går fort ut
   Grunnårsak: mange miniatyrbilder + ekstra kreditter for generering av WebP/AVIF.
   forslag：

• Vurder først antall miniatyrbilder på nettstedet
• Utelukk unødvendige miniatyrstørrelser (optimaliser bare størrelser som faktisk vil bli brukt)
• Bestem komprimeringsstrategien før du kjører i bulk for å unngå gjentatt prøving og feiling.

2. Stabler andre konverteringsplugin-moduler samtidig
   Hvis du har Plus WebP-erstatninger og ShortPixel som genererer/innsetter nestegenerasjons tagger, blir logikken stablet opp og vanskeligere å feilsøke. For rute B, la ShortPixel gjøre det alene.
3. Jeg trodde at hvis jeg installerte det, ville det være “WebP/AVIF i forgrunnen”.”
   ShortPixel-plugin-sidenNevnte at den konverterer WebP/AVIF og kan legge til neste generasjons bilder på forsiden (f.eks. ved tagging).
   Men det er likevel viktig å verifisere resultatene etter at du har gjort det.

---

3.2.2 ImagifyGratis: 20MB/måned; kvoten trekkes fra i henhold til “original bildestørrelse + antall miniatyrbilder”, gjentatte fradrag vil bli gjort for repressing.

Fribeløp og posisjonering

Imagifys offisielle prissideSkriften er tydelig:Månedlig kvote for gratis konto 20MB。
Plugin-siden gjør det også klart at den kan komprimere, endre størrelse på og konvertere WebP/AVIF.

Hvordan trekkes kvoten fra?

Imagify Offisiell dokumentasjon “Hvordan beregnes kvotebruken?” forklarer fradragsmekanismen på en tydelig måte:

• Antall miniatyrbilder påvirker forbruketHvis du for eksempel har 10 miniatyrbilder, blir optimalisering av 1 bilde til optimalisering av 11 bilder (original + 10 miniatyrbilder), som alle bidrar til å øke kvoteforbruket.
• Trekk av kvote i henhold til størrelsen på originaldokumentetHvis du for eksempel sender et bilde på 100 KB til Imagify, vil 100 KB bli trukket fra kvoten.
• Hvis du endrer komprimeringsnivået og optimaliserer på nytt, vil kvoten bli brukt opp igjen。
• Den samme API-nøkkelen kan brukes for flere nettsteder, men kvotene deles mellom dem.

Dette er Imagifys “kjerneforståelse”:
Det er mer som en trafikkpakke: Den trekker fra så mye som du sender; jo flere miniatyrbilder du har, jo mer trekker den fra; og du vil gjenta fradraget hvis du trykker på det gjentatte ganger.

Eksempel på Imagify-kvoter som er enkle å lese

La oss si at du laster opp et originalbilde på 800 KB, og at nettstedet genererer 8 miniatyrbilder.

• Imagify optimaliserer til å inkludere “originalbildet + 8 miniatyrbilder” (hvis du velger å optimalisere alle), noe som betyr at denne ene handlingen bruker en kvote som er nær “originalstørrelsen på alle disse filene til sammen”.
  Det er derfor noen nettsteder føler at “20MB går fort tom”: Det er ikke fordi Imagify ikke er nok, det er fordi du laster opp for mange bilder om gangen, for mange miniatyrbilder, og du prøver sannsynligvis komprimeringsnivåer om og om igjen.

Imagifys vanligste fallgruver

1. Gratis 20MB Ikke nok til å gjøre en “fullstendig oversikt over stedets historie”
   20MB er vanligvis bedre egnet for testing med lette oppdateringer. Hvis mediebiblioteket ditt allerede er stort, vil en engangsrensing sannsynligvis kreve en oppgradering.
2. Gjentatt justering av komprimeringsnivåene fører til dobbelt kvoteforbruk
   Imagify gjør det klart atRe-optimalisering vil forbruke kvoten igjen.
   Jeg foreslår at du gjør “strategien” tydelig på denne siden:

• Begynn med et lite antall bilder for å finne ut hvilket komprimeringsnivå og utseende du ønsker.
• Fastsett strategien, og kjør deretter i bulk
  Unngå gjentatt prøving og feiling på hele biblioteket

3. Flere nettsteder som deler API-nøkkel fører til “uforklarlig kvotereduksjon”.”
   Hvis du bruker samme API-nøkkel for mer enn én stasjon, deles kvoten.
   Så i team-/flerstasjonsscenarioer er det best å ha klart for seg hvilke stasjoner som deles og hvilke som brukes individuelt for å unngå ukontrollerbare budsjetter.

---

3.2.3 TinyPNG(Tiny Compress Images): gratis 500 kreditter/måned; bytte til WebP/AVIF vil “trekke 1 kreditt per størrelse”.”

Gratis kreditter og faktureringsideer

TinyPNGs WordPress-plugin-side er veldig oversiktlig:

• 500 studiepoeng per måned gratis
• I “Generell WordPress-installasjon” kan du sannsynligvis komprimere Ca. 100 bilder per måned
• Men hvis AVIF- eller WebP-konvertering er aktivert:Hver bildestørrelse bruker en ekstra kredittSå antageligvis kan den bare komprimeres og konverteres Ca. 50 bilder per måned(avhengig av hvor mange miniatyrstørrelser du har).

I mellomtiden har Tinify (utviklerne av TinyPNG/TinyJPG) også gjort sine API-prisingssideBeskrivelse: Registrer deg og få 500 gratis kompresjoner per måned; etter det blir du fakturert etter antall vellykkede kompresjoner, uten obligatorisk abonnement.

Oppsummer hvordan TinyPNG forstås i én setning:
Den teller kreditter; jo flere miniatyrstørrelser du har, og jo mer WebP/AVIF du har slått på, desto raskere forbrukes kredittene.

Lettleste eksempler på TinyPNG-kreditter

Anta at nettstedet ditt genererer 8 miniatyrstørrelser for hvert bilde:

• Kun komprimering: original + 8 miniatyrbilder → 9 studiepoeng kreves
• Hvis WebP/AVIF-konvertering er slått på: ett ekstra poeng per størrelse → sannsynligvis nesten det dobbelte!
  Dette samsvarer med beskrivelsen på plugin-siden: Etter at den er slått på, endres gratisbeløpet fra omtrent “100 kort/måned” til “50 kort/måned”.

De vanligste fallgruvene ved bruk av TinyPNG

1. Tenkte 500 studiepoeng = 500 bilder
   Det er det ikke. Det forbrukes av “bildestørrelse / variant”. Plugin-siden advarer tydelig om at “Konverteringer trekker ytterligere 1 kreditt for hver bildestørrelse”.
2. Temaer/e-handel-plugins genererer for mange størrelser, og de gratis kredittene synker betydelig
   Jo flere størrelser det finnes, desto lettere er det å skalere opp og forbruke kreditter.
3. Etter at du har aktivert konverteringen, oppdager du at kredittene plutselig er ubrukte.
   Det er ikke en feil, det er faktureringsmekanismen.
   Strategiråd:

• Hvis gratisfasen hovedsakelig brukes til komprimering og vektreduksjon, kan du starte med kun komprimering, og deretter slå på konvertering når du er sikker på at nettstedstrukturen er stabil og du virkelig trenger neste generasjon.

4. Anbefaling av underscenarioer: Hvordan velge ulike typer lokaliteter

WordPress, innholdssider, e-handelssider, porteføljer og medlemssider har heller ikke de samme “trykkpunktene” for bilder.

4.1 Innholdssider/blogger (mye artikkelgrafikk, middels oppdateringsfrekvens)

Prioriterte anbefalinger:

1. Strategi for dimensjonering (trinn 1)
2. Komprimering (trinn 2)
3. WebP (trinn 3)

En mer passende rute:

• Vil du lagre: Route B Triple Choice (ShortPixel / Imagify / TinyPNG)
• Hvis du vil gå gratis: Rute A (Plus WebP + EWWW), men det anbefales å starte med “konservativ modus (uten å slette originalbildet)” for å vurdere risikoen.

Typisk grop:

• Det første bildet på artikkelsiden er veldig stort, feil lazy loading-strategiBremser det første skjermbildet

4.2 E-handel/produktside (mange miniatyrbilder, mange bildevarianter, stabilitet først)

E-handel er mest sannsynlig å være problemet er ikke “komprimeringseffekten er ikke bra”, men “optimalisert noen av størrelsen er ikke riktig, mangler miniatyrbilder, frontkomponenter kan ikke få bildet”.

Prioriterte anbefalinger:

1. Stabilitet først: konservativ komprimeringsstrategi, ikke bytt ut hele biblioteket med en gang
2. Evaluering av miniatyrbildestørrelser: e-handelstemaer genererer vanligvis flere størrelser, og forbruket blir større (ShortPixel/TinyPNG er spesielt merkbart)
3. Utfør validering i liten skala før batch (svært kritisk)

En mer passende rute:

• Rute B er som regel mer problemfri: ShortPixel/Imagify/TinyPNG kan alle batches, og det er viktig at du forstår kvotemekanismen og vurderer kostnadene på forhånd.
• Rute A er bra, men vær mer forsiktig med Plus WebPs “overskriv ID-er/slette originale bilder/erstatte URL-er”-atferd: det er en migrering av ressurser, og det anbefales ikke å erstatte alt med en gang.

4.3 Mappe/fotostasjon (enkeltbilder som er følsomme for kvalitet, store bilder, høye krav til visning)

Prioriterte anbefalinger:

1. Størrelsesstrategi (kontroll av visningsområdet)
2. Komprimeringsstrategi (bedre å være større enn å knuse detaljene)
3. WebP/AVIF (gevinsten ved store bilder er åpenbar, men kontroller visningen)

En mer passende rute:

• Imagify: Trekk kvoten i henhold til “størrelsen på det opprinnelige bildet”, dette nettstedet er lettere å gjøre “budsjettkontrollert” (du vet hvor mye du skal trekke for hvert stort bilde), men for å unngå gjentatte represjoner.
• ShortPixel: Hvis miniatyrbildestørrelsen ikke er stor, er kreditter også veldig intuitive; men hvis du genererer mange størrelser + neste generasjon, vil kredittforbruket bli forstørret, og du må planlegge fremover.

5. Sammenligning av kvote/fakturering: å sette “gratis er ikke nok” i perspektiv

Hvilken er den beste avtalen, og hvor lenge varer gratis?

5.1 Tre modeller for tilbakebetaling

• ShortPixel(studiepoeng): Kreditter basert på “originalbilde + antall miniatyrbilder”; ytterligere kreditter vil bli trukket fra for hver tilsvarende versjon av WebP/AVIF som genereres.
• Imagify(MB-kvote): Trekk fra kvoten i henhold til “original filstørrelse”; jo flere miniatyrbilder, desto flere fradrag; hvis du trykker på nytt, trekkes det fra igjen.
• TinyPNG(studiepoeng): 500 kreditter per måned; aktivering av WebP/AVIF-konvertering trekker ekstra kreditter for hver bildestørrelse.

5.2 Metoder for rask estimering

Du kan anslå det slik:

1. Finn et tilfeldig “originalbilde du ofte laster opp” og se hvor stort det er (f.eks. 300KB / 1MB / 3MB).
2. Avhengig av hvor mange miniatyrbilder nettstedet ditt genererer (f.eks. 5 / 10 / 20)
3. Bestem om du vil generere WebP/AVIF (ja/nei)

Bruk deretter følgende “mentale matematikk” for å forstå forbruket:

• ShortPixel: ≈ (1 + antall miniatyrbilder) kreditter per bilde; hvis du genererer WebP/AVIF, dobles ≈ igjen (siden neste generasjons versjon også tar kreditt)
• Imagify: Hvert bilde ≈ (originalstørrelse + hver miniatyrstørrelse) trekker fra kvoten; endring av komprimeringsnivå og rekomprimering vil trekke fra igjen.
• TinyPNG: 500 kreditter gratis; hvis nettstedet ditt genererer mange størrelser per bilde, og konvertering er aktivert, synker antallet gratis kreditter betydelig (plugin-siden gir en visuell forventning om “~100 kreditter/måned” vs. “~50 kreditter/måned”)

6. Risikovarsler

Risiko 1: Ikke la flere plugins gjøre det samme om og om igjen

Det er den vanligste “katastrofekilden”.”

• Rute A:Pluss WebP eller AVIF + EWWW(Del arbeidet mellom de to, ikke gjør like-for-like-konverteringer og leveranser samtidig, eller installer bare én av dem)
• Rute B: ShortPixel / Imagify / TinyPNG velg tre(velg en for komprimering og neste generasjon)

Risiko 2: Plus WebPs “Overskriv ID / Slett originalbilde / Erstatt URL” er en aktivamigrering.

Uthevelser tilføyd:Pluss WebP I beskrivelsen står det tydelig at full generering overskriver den opprinnelige bilde-ID-en, sletter den opprinnelige filen og erstatter URL-adressen til innholdet.
Det betyr at det ikke er snakk om en “liten innstilling som kan trekkes tilbake når som helst”, men en endring på formuesnivå.

Den foreslåtte strategien bør være:

• Små tester først (noen titalls til noen hundre)
• Bekreft at frontend-visning, miniatyrbilder og cache-oppdateringer fungerer som de skal
• Vurdere full biblioteksbehandling på nytt

Risiko 3: Det reelle forbruket av “gratiskreditter” for skykomprimering avhenger av antall miniatyrbilder og neste generasjons utvalg.

• ShortPixel: Miniatyrbilder og neste generasjon påvirker krediteringene betydelig.
• TinyPNG: Hvis du aktiverer WebP/AVIF, trekkes det fra en ekstra kreditt for hver bildestørrelse.
• Imagify: trukket i henhold til størrelsen på det opprinnelige bildet, jo flere miniatyrbilder trukket mer, vil tungt trykk gjenta fradraget!

Risiko 4: “WebP/AVIF generert” betyr ikke at “WebP/AVIF blir levert av frontkontoret”

Mange føler seg “ikke raskere” etter konverteringen fordi frontend fortsatt sender ut JPG/PNG (caching/omskriving/tagging/nettleserforhandling er ikke på rett sted).

7. hvordan du kontrollerer at den har trådt i kraft etter at den er utført

4 veldig enkle valideringspunkter:

1. Om den samme siden oppdateres en gang til og lastes inn mer konsekvent og raskere(Caching og optimalisering av den fysiske følelsen av om det fungerer)
2. Er det stor forskjell på størrelsen på bilder som lastes inn på mobiltelefoner og stasjonære datamaskiner?(responsiv) srcset/størrelser (uansett om de fungerer eller ikke)
3. Stikkprøvekontroll av noen få bilder: om WebP- eller AVIF-filer/ressurser er til stede(Bruker nettstedet faktisk neste generasjon）
4. Ta noen bilder: zoom inn for å se om de er tydelig uklare, om teksten er utydelig(komprimert masse er ikke for stor)

Hvis alle fire stemmer overens, har ruten du har valgt, blitt kjørt. Nå er det din tur. CDN “Leveringslag”blir helheten mer stabil.

8. Anbefalinger for tiltak

1. Velg ruten din først:

• Prøver å være så fri som mulig.: Pluss WebP eller AVIF + EWWW (eller bare én av dem)
• Vil du spare serverressurser, kan du betale per kreditt for mer trygghet: ShortPixel / Imagify / TinyPNG - velg en!

2. Gjør en liten test først (noen få dusin)
3. Forsikre deg om at det er i orden før du setter i gang
4. Det er behov for ytterligere forbedringer i leveringsstabiliteten:lese CDN Akselerasjon

vanlige problemer

1. Hvor mange plugin-moduler må jeg installere? Kan jeg installere alle?

Prøv å ta bare én rute.

• Rute A: Pluss WebP eller AVIF + EWWW Image Optimizer (eller bare én av dem)
• Rute B: ShortPixel / Imagify / TinyPNG - velg en!
  I samme stasjon på samme tid la mer enn en plug-in for å gjøre “komprimering / overføring WebP / AVIF / endre URL / levering omskrivning”, mest sannsynlig å bli mer og mer kaotisk, men også den vanskeligste å sjekke.

2. Støtter ikke WordPress allerede WebP/AVIF? Trenger jeg fortsatt en plugin?

Det må skilles fra hverandre:
“Støtte for opplasting/bruk” ≠ “Automatisk konvertering/automatisk levering”.
WordPress 6.5 batch-konverterer heller ikke automatisk gamle JPG/PNG-filer til WebP/AVIF, og gjør heller ikke automatisk hele “eksporter AVIF/WebP til nettleser-kompatibel og fallback”-greia for deg. Det kreves vanligvis en plugin eller tjeneste for å få det historiske mediebiblioteket til å fungere.

3. Hva er det mest “givende” trinnet i bildeoptimalisering?

Det er vanligvis Få “størrelsene” til å stemme først (srcset/sizes).。
Mange nettsteder er trege, ikke fordi de ikke har komprimering, men fordi siden bare er på 900 px og brukeren blir bedt om å laste ned et bilde på 3000 px. Komprimering sparer kB, men “feil størrelse” gjør at du laster ned flere ganger mer data til ingen nytte.

4. Hvordan kan jeg være sikker på at jeg laster inn det “mindre bildet” og ikke originalbildet for alltid?

Se på to fenomener:

• Når du åpner en side på en mobiltelefon, er størrelsen på det nedlastede bildet merkbart mindre enn på skrivebordet
• Det samme bildet lastes inn med ulike ressursstørrelser på ulike enheter
  Hvis originalbildet lastes ned for alltid, er en vanlig årsak at temaet/byggeren behandler bildet som et CSS-bakgrunnsbilde eller egendefinert utdata, og omgår mediebibliotekets multi-størrelse med srcset.

5. Betyr “WebP/AVIF generert” at frontend må produsere WebP/AVIF?

Ikke like.
Generering er bare “fillaget” som er gjort; om frontend faktisk leverer WebP/AVIF, avhenger av omskrivninger, retningslinjer for bildemerking, cache-treff, nettleserforhandlinger og så videre. Når du er ferdig, må du huske å “stikkprøvekontrollere noen bilder for ressurstyper”.

6. pluss Hva er så farlig med WebP eller AVIF? Kan jeg kjøre hele biblioteket med ett klikk?

Risikopunktet er ikke “komprimering”, det erEndringer i migrasjonsnivåer for eiendeler：

• Full generering kan overskrive den opprinnelige bildefil-ID-en, slette den opprinnelige filen og erstatte URL-en i innholdet.
  grunnen til atDet anbefales ikke å bytte ut hele biblioteket med en gang: Test først i liten skala (titalls ~ hundrevis) + ha tilgjengelige sikkerhetskopier, og vurder deretter full biblioteksbehandling.

7. Hva er valget mellom de to modusene i Plus WebP: beholde det opprinnelige bildet vs. erstatte og slette det opprinnelige bildet?

Enkelt å forstå:

• Modus 1: Behold originalbildet + generer WebP/AVIF-kopi (mer stabil): Praktisk for tilbakeføringer, men disken går opp (originalbilde + nytt format + miniatyrbilder i flere størrelser).
• Modus 2: Erstatt og slett originalbildet (mer aggressivt)Disker er mindre utsatt for oppblåsthet, men du “endrer ressurser + endrer referanser”, noe som gjør det dyrere å feilsøke kompatibilitetsproblemer.
  Jo mer komplekst nettstedet er (e-handel/multi-plugin/multi-størrelse), desto mer anbefales det å starte med en mer stabil modell.

8. Er EWWW Image Optimizer gratis lokal komprimering nok? Vil det overvelde serveren?

EWWW er mer en “lokal kompressor”: den spiser CPU/IO.
Det er vanlig at belastningen øker under batchoptimalisering, noe som ikke betyr at det “ikke fungerer”, men snarere at strategien bør være riktig: batch, lave topper og offloading/skyalternativer om nødvendig.
Hvis du ønsker å spare penger, eller hvis du har lite serverressurser, er rute B mer servervennlig.

9. ShortPixels 100 gratis kreditter/måned, hvorfor føles det som om de er borte på noen få bilder?

på grunn av studiepoeng er ikke “antall bilder”.”Neste generasjon vil bli forstørret med et miniatyrbilde med neste generasjon:

• Originalbilde + hvert miniatyrbilde teller som kreditering
• Hvis det genereres en WebP/AVIF, forbrukes det en ekstra kreditt for hver tilsvarende versjon.
  Så det du tror er “1 bilde”, kan i virkeligheten forbruke nærmere “2-sifrede kreditter”. shortPixel

10. Imagifys gratis 20MB/måned, hvorfor går den også fort tom?

Imagify er mer som en “trafikkpakke”:

• Som du sendte det.Opprinnelig filstørrelsefradrag av kvoter
• Jo flere miniatyrbilder du har, desto mer forbruker du
• Hvis du endrer komprimeringsnivået for å optimalisere på nytt, vil kvoten bli brukt opp igjen
• Samme API-nøkkel for flere nettsteder, deling av kvoter
  Så “20MB går snart tom” skyldes ofte for store bilder, for mange miniatyrbilder eller gjentatt prøving og feiling.

11. TinyPNG er gratis for 500 studiepoeng/måned, hvorfor sier plugin-modulen at det bare er omtrent 100 studiepoeng/måned og deretter 50 studiepoeng/måned med WebP/AVIF?

Fordi TinyPNG-kreditter også forstørres med “size/variant”:

• En vanlig WordPress-installasjon komprimerer sannsynligvis rundt 100 ark i måneden.
• Aktiver AVIF- eller WebP-konvertering:Hver bildestørrelse bruker en ekstra kredittDu kan sannsynligvis bare komprimere og konvertere ca. 50 bilder i måneden (avhengig av antall miniatyrbilder).
  Så 500 studiepoeng ≠ 500 bilder.

12. Hvor mange miniatyrbilder er det på nettstedet mitt? Hvorfor er det så viktig?

WordPress genererer flere størrelser når du laster opp et bilde. Temaer/plugins (spesielt e-handel) kan legge til flere størrelser.
Skykomprimeringskreditter/kvoter er vanligvis “original + miniatyrbilder sammen”, så jo flere miniatyrbilder du har, desto færre gratiskreditter har du å bruke.

13. Er lat lasting alltid raskere? Hvorfor sier noen at lazy loading gjør ting tregere?

Lazy loading er egnet for “ressurser utenfor skjermen”.
Hvis det første skjermbildet av det mest kritiske store bildet også er forsinket innlasting, kan det redusere den første skjermopplevelsen. WordPress 5.5 siden standard lat lasting er bra, men ikke “one size fits all”.

14. Jeg reiser på rute A eller B. Når trenger jeg CDN / Picture CDN?

Komprimering, dimensjonering og formatering løser problemet med “mindre filer som får plass”;
CDN løser problemet med å levere tettere og mer stabile。
Når bilder hentes fra en avstand fra kildesiden, noe som resulterer i betydelig ventetid, vil det å supplere CDN/bilder med CDN (f.eks. Cloudflare Polish / Jetpack Site Accelerator) være mer stabilt totalt sett, les WordPress CDN Akselerasjon。

15. Hvordan kan jeg lettest kontrollere at “det virkelig fungerer” når jeg er ferdig?

Den mest tidseffektive verifiseringsmetoden:

• Om den samme siden oppdateres en gang til og lastes inn mer konsekvent og raskere
• Er det merkbare forskjeller i størrelsen på bildene som lastes inn på mobiltelefoner og stasjonære datamaskiner (spiller srcset/størrelser inn)?
• Stikkprøvekontroll av noen få bilder: om WebP- eller AVIF-filer/ressurser er til stede
• Ta noen bilder: zoom inn for å se om de er tydelig uklare, om teksten er utydelig