Optimering af billeder på hjemmesiden

Billedoptimering er et af de mest “givende” aspekter af WordPress' ydeevne: For den samme sidestruktur og det samme tema vil indlæsningsoplevelsen straks blive bedre, så længe billedstørrelsen, dimensionerne, formateringen og leveringen er korrekt.

Men billedoptimering er også den nemmeste måde at lave rod på, ikke fordi det er teknisk for svært, men fordi informationen er for fragmenteret:
Du læser et par artikler, ved, at “komprimering”, “WebP/AVIF”, “lazy loading”, og ser derefter på plugin-introduktionen og sagde “gratis hver måned! 100 kreditter pr. måned”, “Gratis 20MB”, “1 kredit pr. billede”, men jo mere jeg læser, jo mere forvirret bliver jeg... Er gratis nok? Hvordan trækker man gebyret fra? Har du misforstået “det samme”? Og vigtigst af alt:Virkede det rent faktisk, efter at du havde gjort det, eller ej?

Denne artikel gør kun tre ting:

1. Giv dig en eksekverbar filKøreplan (også fig.)(Hvad skal man gøre først, hvad skal man gøre bagefter)
2. Vær klar over, hvilken mulighed du går efter (hvad er forskellen på gratis/betalt, og hvem passer de hver især til).
3. Skriv de mest almindelige faldgruber ned på forhånd (så du ikke behøver at lede efter fejlfinding, når du er færdig).

1. Bundlinjen: Hvad WordPress kommer med, og hvad det ikke gør

Hvis du ikke først finder ud af, hvad WordPress-kernen allerede gør, er det nemt at gøre en af to ting:

• I stedet for at bruge den “frie kapacitet”, du burde nyde, bruger du tid/betaler penge på at bygge hjulet igen og igen.
• Jeg troede, at WordPress “automatisk ville konvertere alle gamle billeder til WebP/AVIF”, men det viser sig, at det gør den ikke!

WordPress-kernen har disse nøglefunktioner indbygget:

• Responsive billeder (srcset/størrelser): Fra og med WordPress 4.4 vil kernen sende billeder ud til srcset 与 sizesog udnytter de billeder i flere størrelser, der genereres under upload, så browseren kan vælge en mere passende ressource at indlæse ud fra skærmforholdene.
• Indbygget doven indlæsningWordPress 5.5 og fremefter muliggør indbygget lazy loading af billeder som standard ved hjælp af HTML-standarder. loading attribut-implementering.
• Understøttelse af upload af WebP: Siden WordPress 5.8 kan du uploade og bruge WebP som JPEG/PNG (forudsat at dit hostingmiljø understøtter WebP).
• Understøttelse af upload af AVIF: Siden WordPress 6.5 kan du uploade og bruge AVIF som JPEG/PNG (afhænger også af hosting-support).

Men vær opmærksom:
“Understøttelse af upload/brug” ≠ “Automatisk konvertering/automatisk levering”.
Det vil sige: Selv hvis du allerede er på WP 6.5, vil JPG/PNG'erne i dit mediebibliotek ikke blive til WebP/AVIF af sig selv; du får ikke automatisk det fulde “output AVIF/WebP i henhold til browserens muligheder og fallback til det originale billede for ikke-understøttede browsere”-link! --denne del skal normalt patches af et plugin eller en tjeneste.

2. Køreplan: Billedoptimering i 5 trin

Hvad man skal gøre, hvorfor, hvad man skal gøre for at kvalificere sig, og hvad en typisk pit er.

2.1 Få den rigtige “størrelse” først (det mest oversete, men det mest givende)

Mange stationer er langsomme, ikke fordi komprimeringen ikke er udført, men fordiDownloadet et stort billede, der strækker sig langt ud over skærmområdet：
Hvis siden f.eks. kun er 900 px bred, og du beder den besøgende om at downloade det oprindelige billede på 3000 px, vil browseren bare “downloade det og derefter formindske det”. Det spilder båndbredde, øger afkodningstiden og gør den første skærm langsommere.

WordPress 4.4+Responsiv billedmekanisme（srcset/sizes) er designet til at løse netop dette problem.

Gør det, der tæller som en aflevering:

• Når du åbner en side på en mobiltelefon, skal størrelsen på det downloadede billede være betydeligt mindre end på skrivebordet.
• Det samme billede indlæses med forskellige ressourcestørrelser på forskellige enheder (i stedet for altid at downloade det originale billede)

De mest almindelige faldgruber:

• Der er temaer/bygherrer, der behandler diagrammer som CSS-baggrundsbilleder eller udsender dem på en brugerdefineret måde, der kan omgå srcsetResultatet er blevet et stort billede af
• Du bruger eksternt linkede billedsenge, tredjeparts billedblokke og kan også omgå det multi-size-system, der genereres af mediebiblioteket.

---

2.2 Komprimering (reducer KB, men “knus” ikke kvaliteten)

Kernen i komprimering er ikke “jo mindre, jo bedre”, men “forskellen er knap nok synlig med det blotte øje, men volumenfaldet er tydeligt”.

Reglerne er som følger:

• Fotografier/live shots (mennesker, produkter, landskaber): Prioriteret tabsgivende komprimering (maksimal gevinst)
• Skærmbilleder af grænsefladen / teksttunge billeder: Komprimering bør være mere konservativ for at undgå uklar tekst
• Logo/Icon: Prioriteret SVG eller diskret tabsfri (tabsfri er let at indsætte i kanten)

Gør det, der tæller som en aflevering:

• Betydelig reduktion i billedstørrelse på de fleste sider
• Ingen synlig støj, mudrede kanter, brud på farveblokke, sløret tekst

---

2.3 WebP / AVIF (formatstrategi: mindre for samme definition)

WordPress understøtter allerede upload WebP (5.8) vs. AVIF (6.5)。
Men for at få Next Generation-formatet til at fungere, er der normalt to ting, der skal løses:

1. Sådan batchkonverterer du historiske mediebiblioteker(Ellers optimerer du kun til “nye billeder uploades senere”).
2. Om der skal genereres en kopi eller erstattes det originale billede(Dette er et risikabelt farvand; vi vil fokusere på Plus WebP's “Erstat og slet det originale billede” senere)

Anbefalet skrivestil:

• WebP: generelt foretrukket som standard (mere stabil kompatibilitet)
• AVIF: en yderligere komprimeringsretning, velegnet til store billeder/store billeder på første skærm/albumbilleder (men mereAfhængighed af støtte fra omgivelserne）

---

2.4 Lazy loading skal bruges korrekt (ikke en størrelse, der passer til alle)

WordPress 5.5 og fremefterStandard lazy loadingBillede.
Det reducerer brugen af båndbredde under den første rendering:

• Lazy loading for “ressourcer uden for skærmen”
• Det mest kritiske store billede på den første skærm (og i mange tilfælde det vigtigste billede på den første skærm) er ofte uegnet til forsinket indlæsning.

---

2.5 Leveringslag: CDN / Foto CDN

Komprimering, dimensionering og formatering løser problemet med “mindre filer, der passer”.
Men hvis billederne altid hentes fra en afstand fra kilden, vil netværksforsinkelsen stadig påvirke oplevelsen betydeligt. Det er her, løsningen med et “leveringslag” (CDN/billede CDN) kommer ind i billedet.

To typiske retninger:

• Cloudflare polsk：Cloudflare-dokumentationPolske komprimeringsmetoder (lossless/lossy/WebP) introduceres, og det nævnes, at komprimering med format=auto WebP/AVIF-format er tilladt.
• Jetpack Site Accelerator：Jetpack-dokumentationForklar, at den vil optimere billeder og distribuere dem gennem sit netværk sammen med statiske ressourcer.

Billedoptimering er ansvarlig for at blive mindre og mere passende.CDN Ansvarlig for at levere tættere og mere stabile

3. Udvælgelse: kun to hovedruter

Den mest almindelige fejl i billedoptimering er ikke “ingen plugins”, men for mange plugins, der fører til dobbeltbehandling:
A komprimerer, B komprimerer, A konverterer til WebP/AVIF, B konverterer, A ændrer URL'er, B omskriver - man kan ikke engang se, hvad der sker på stationen.

Regler:

Der er kun én vej at gå: enten helt gratis lokal eller cloud-komprimering af de tre.

• Rute A (alt gratis lokalt):Plus WebP eller AVIF + EWWW Image Optimizer(eller bare én)
• Rute B (tredobbelt mulighed for cloud-komprimering):ShortPixel / Imagify / TinyPNG

---

3.1 Rute A: Helt gratis lokalt (plus WebP eller AVIF eller EWWW)

Denne rute er kendetegnet ved:

• Du er ikke afhængig af tredjeparts komprimeringstjenester “pr. måned/pr. ark” (selvom nogle funktioner kan tilbydes som valgfrie tjenester).
• Omkostningerne: Batchbehandling kan være mere serverhungrende ved CPU/IO, hvilket kræver, at du er mere opmærksom på “strategi og risiko”.”

3.1.1 Plus WebP eller AVIFkernen er “generere/erstatte”, det er ikke et traditionelt “komprimeringsværktøj”.”

• Når du genererer billeder i fuld størrelse:Den oprindelige billedfils ID overskrives af WebP/AVIF, den oprindelige fil slettes, og URL'en i indholdet erstattes.。
• Plugin'et giver WP-CLI-kommandoer og minder om: WP-CLI er mere pålidelig, når der er mange filer.

Det betyder, at i stedet for “stille og roligt at generere en WebP for dig”, kan det være enMigration af aktiver(Især hvis du slår indstillingen “Erstat og slet det originale billede” til).

Forskelle mellem de to modeller

Mode 1: Behold det originale billede + generer WebP/AVIF-kopi (mere stabilt)

• Fordele: Lettere at falde tilbage på i tilfælde af kompatibilitetsproblemer
• Omkostninger: Diskforbruget vil stige (originalbillede + nyt format + thumbnails i flere størrelser)

Mode 2: Erstat og slet det originale billede (mere aggressivt)

• Fordele: diske udvides ikke så hurtigt; stationsreferencer går direkte til det nye format
• Risiko: Du “ændrer aktiver + ændrer referencer”, hvilket gør det dyrere at fejlfinde kompatibilitetsproblemer (især hvis nogle eksterne systemer eller temalogikker er afhængige af det oprindelige filnavn/sti/format).

Typiske faldgruber ved Plus WebP eller AVIF

1. Efter udskiftning af hele biblioteket vises nogle sidebilleder unormalt.
   Årsagen er normalt ikke, at billedet er “ødelagt”, men at et eller andet led i kæden af URL-substitution, caching, thumbnail-politik osv. ikke er korrekt.
2. Jo flere thumbnails, jo større er ændringens omfang.
   WordPress genererer flere størrelser, når du uploader et billede; temaer/plugins kan også tilføje flere størrelser. Fuld udskiftning betyder, at du måske ændrer en meget stor samling af filer.
3. Bare det at lave en formatmigrering betyder ikke nødvendigvis, at volumen altid er den mindste
   WebP/AVIF er generelt mindre, men “størrelsesstrategi” og “komprimeringsstrategi” er stadig afgørende. Tænk ikke på Plus WebP som “et klik hurtigere”.

---

3.1.2 EWWW Image Optimizer: repræsentant for fri lokal kompression

EWWW-plugin-siden er meget velplaceret:

• Det kan optimeres på din server ved hjælp af en række værktøjer (jpegtran, optipng, pngout, pngquant, gifsicle, cwebp osv.).
• Du kan også aflaste CPU-forbrugende behandling til serveren (valgfrit), hvis du har brug for højere komprimering eller flere CPU-besparelser.

Hvad skal EWWW's rolle være på rute A?

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

• Komprimering og volumenoptimering(især vægtreduktion af råmaterialer som JPG/PNG)
• Batch-optimering af historisk mediebibliotek(rettet mod “volumenreduktion” snarere end “URL-erstatning”)

Typisk pit af EWWW

1. Forhøjet serverbelastning under batch-optimering
   Da lokal komprimering æder CPU/IO, er løsningen ikke “lad være med at bruge det”, men “batch, lav spidsbelastning, offload/cloud-mulighed om nødvendigt”.
2. “En WebP genereres” betyder ikke, at frontenden skal producere en WebP.
   Mange plugins lider af denne misforståelse: Generering er én ting, leveringsstrategier (rewrites, picture tags, cache hits osv.) er en anden.
3. At gøre det samme igen og igen med andre plugins
   Hvis du vælger rute A, så prøv ikke at overlejre ShortPixel/Imagify/TinyPNG-type cloud-komprimering; hvis du vælger rute B, så lad være med at slå Plus WebP-erstatningslogik til. Kerneprincip:En vej til enden.

---

3.2 Rute B: Cloud Compression Triple Choice (ShortPixel / Imagify / TinyPNG)

Denne rute er velegnet til folk, der “ønsker at spare serverressourcer, ønsker at lave batch med mindre indsats og accepterer fakturering per kredit/per volumen”.
Men den mest misvisende pointe om cloud-komprimering er:Gratis kreditter er ikke så enkle som “gratis ark”!.. Antallet af miniaturestørrelser, om der genereres WebP/AVIF eller ej, og om det gentagne gange sættes under tryk eller ej, kan påvirke forbruget betydeligt.

I det følgende forklares det, hvad der sker med gratis/gebyr, hvordan kreditter trækkes fra, hvilke faldgruber der er størst sandsynlighed for at træde i, og hvilke sidetyper der er passende.

---

3.2.1 KortPixel100 gratis credits/måned, men credits forbruges af thumbnails og WebP/AVIF-forstørrelser.

Hvad sker der med gratis/betalt

I beskrivelsen af ShortPixel-pluginnet står der tydeligt:

• 100 gratis kreditter pr. måned
• Der er også “Ekstra ubegrænsede månedlige kreditter” (plugin-siden giver oplysninger om de tilsvarende priser)
• Fås også som “engangskreditpakker, der aldrig udløber” (med oplysninger om startpris)

Tip:

• Gratis: Giv et vist antal kreditter pr. måned til lette sider eller testning
• Engangspakker: Velegnede til websteder med store mediebiblioteker, der ønsker at tømme deres lager på én gang (køb én gang og brug det op, det udløber normalt ikke).
• Månedlig/ubegrænset: velegnet til websteder med løbende opdaterede billeder og langsigtet stabil optimering

ShortPixels officielle KB har også givet en opdatering om “One Time Pack vs Unlimited Monthly”.eksplicit forklaringUnlimited Monthly er en månedlig (eller årlig) betaling, der tilbyder ubegrænsede kreditter med en fast CDN-tildeling; engangskreditter, der ikke udløber, hvilket giver dig mere kontrol til at bruge dem efter behov.

Bundlinjen: Hvordan beregnes ShortPixel-kreditter?

ShortPixels officielle dokumentation KB var meget direkte:

• WordPress genererer flere thumbnails, når du uploader et billede;
• Hver thumbnail-optimering tæller som en credit；
• Hvis du vælger at generere en WebP eller AVIF, vilHver WebP/AVIF-version af det originale billede og miniaturebilledet koster en ekstra kredit.；
• Du kan udelukke visse thumbnails fra at blive optimeret for at reducere forbruget af credits.

Eksempel på kreditering：

Lad os sige, at du uploader 1 billede, og at temaet/plugin'et genererer 8 thumbnails:

• Optimer kun det originale billede + miniaturebilleder: 1 (original) + 8 (miniaturebilleder) = 9 credits
• Hvis du også vil generere WebP/AVIF: endnu en next-gen-version for hver af de 9 ovenstående → +9 credits.
  Med andre ord kan det, du tror er “1 billede”, faktisk forbruge tæt på “2-cifrede kreditter”.

Så..:“Gratis 100 credits” er ikke det samme som “gratis 100 billeder”.

ShortPixels mest almindelige faldgruber

1. Gratis 100 credits løber hurtigt ud
   Grundårsag: mange miniaturebilleder + ekstra credits til generering af WebP/AVIF.
   forslag：

• Vurder først antallet af sidens thumbnails
• Undgå unødvendige miniaturestørrelser (optimer kun størrelser, der rent faktisk vil blive brugt)
• Bestem komprimeringsstrategien, før du kører i bulk for at undgå gentagne forsøg og fejlforbrug.

2. Stakning af andre converter-plug-ins på samme tid
   Hvis du har Plus WebP-udskiftninger og ShortPixel, der genererer/indsætter next-gen-tags, bliver logikken mere kompliceret og sværere at fejlfinde. For rute B, lad ShortPixel gøre det alene.
3. Jeg troede, at hvis jeg installerede det, ville det være “WebP/AVIF i forgrunden”.”
   ShortPixel-plugin-sideNævnte, at den konverterer WebP/AVIF og kan tilføje næste generations billeder til forsiden (f.eks. ved at tagge).
   Men det er stadig vigtigt at kontrollere resultaterne, når man har gjort det.

---

3.2.2 ImagifyGratis: 20MB/måned; kvoten fratrækkes i henhold til “original billedstørrelse + antal thumbnails”, gentagne fratrækninger vil blive foretaget for genpresning.

Fri mængde og positionering

Imagifys officielle prissideSkriften er tydelig:Gratis konto Månedlig 20MB-kvote。
Plugin-siden gør det også klart, at den kan komprimere, ændre størrelse og konvertere WebP/AVIF.

Hvordan trækkes kvoten fra?

Imagifys officielle dokumentation “Hvordan beregnes kvoteforbruget?” beskriver fradragsmekanismen meget tydeligt:

• Antallet af thumbnails påvirker forbrugetHvis du f.eks. har 10 thumbnail-størrelser, bliver optimering af 1 billede til optimering af 11 billeder (original + 10 thumbnails), som alle bidrager til kvoteforbruget.
• Fratrækning af kvote i henhold til størrelsen på det originale dokumentHvis du f.eks. sender et billede på 100 KB til Imagify, vil der blive trukket 100 KB fra kvoten.
• Ændring af komprimeringsniveauet og genoptimering vil forbruge kvoten igen。
• Den samme API-nøgle kan bruges til flere sites, men kvoterne deles mellem dem.

Dette er Imagifys “centrale måde at forstå på”:
Det er mere som en trafikpakke: Den trækker lige så meget fra, som du sender; jo flere thumbnails du har, jo mere trækker den fra; og du gentager fradraget, hvis du trykker på den igen og igen.

Letlæseligt eksempel på Imagify-kvote

Lad os sige, at du uploader et originalt billede på 800 KB, og at webstedet genererer 8 miniaturer.

• Imagify optimerer til at inkludere “originalbilledet + 8 miniaturer” (hvis du vælger at optimere dem alle), hvilket betyder, at denne ene handling bruger en kvote, der er tæt på “originalstørrelsen på alle disse filer tilsammen”.
  Det er derfor, nogle sider føler, at “20MB løber hurtigt tør”: Det er ikke, fordi Imagify ikke er nok, det er, fordi du uploader for mange billeder ad gangen, for mange thumbnails, og du prøver sandsynligvis komprimeringsniveauer igen og igen.

Imagifys mest almindelige faldgruber

1. Gratis 20MB Ikke nok til at lave en “fuld opgørelse over stedets historie”
   20MB er normalt bedre egnet til test med lette opdateringer; hvis dit mediebibliotek allerede er stort, vil en engangsudrensning sandsynligvis kræve en opgradering.
2. Gentagen justering af komprimeringsniveauer resulterer i dobbelt kvoteforbrug
   Imagify gør det klart, atGenoptimering vil opbruge kvoten igen.
   Jeg foreslår, at du gør “strategien” klar på denne side:

• Start med et lille antal billeder for at bestemme komprimeringsniveau og look and feel
• Fastlæg strategien, og kør så i løs vægt
  Undgå gentagne forsøg og fejl på hele biblioteket

3. Flere websteder, der deler API-nøgle, fører til “uforklarlig kvotereduktion”.”
   Hvis du bruger den samme API-nøgle til mere end én station, deles kvoten.
   Så i team-/multistationsscenarier er det bedst at være klar over, hvilke stationer der deles, og hvilke der bruges individuelt for at undgå ukontrollerbare budgetter.

---

3.2.3 TinyPNG(Tiny Compress Images): gratis 500 kreditter/måned; skift til WebP/AVIF vil “fratrække 1 kredit pr. størrelse”.”

Gratis kreditter og ideer til fakturering

TinyPNG's WordPress-plugin-side er meget overskuelig:

• 500 credits om måneden gratis
• I den “Generelle WordPress-installation” kan du sandsynligvis komprimere Ca. 100 billeder/måned
• Men hvis AVIF- eller WebP-konvertering er aktiveret:Hver billedstørrelse bruger en ekstra kreditSå det kan formentlig kun komprimeres og konverteres Ca. 50 billeder/måned(afhængigt af hvor mange thumbnail-størrelser du har).

I mellemtiden har Tinify (udviklerne af TinyPNG/TinyJPG) også gjort deres API-prissideBeskrivelse: Tilmeld dig og få 500 gratis kompressioner pr. måned; derefter faktureres du efter antallet af vellykkede kompressioner, intet obligatorisk abonnement.

Sammenfat den måde, TinyPNG forstås på, i én sætning:
Den tæller kreditter; jo flere miniaturestørrelser du har, og jo mere WebP/AVIF du har slået til, desto hurtigere forbruges kreditterne.

Letlæselige eksempler på TinyPNG-kreditter

Antag, at dit websted genererer 8 miniaturestørrelser for hvert billede:

• Kun komprimering: original + 8 miniaturebilleder → 9 credits påkrævet
• Hvis WebP/AVIF-konvertering er slået til: et ekstra point pr. størrelse → sandsynligvis næsten det dobbelte!
  Dette svarer til beskrivelsen på plugin-siden: Efter aktivering ændres det gratis beløb fra ca. “100 kort/måned” til “50 kort/måned”.

De mest almindelige faldgruber i TinyPNG

1. Tænkte 500 credits = 500 billeder
   Det er det ikke. Det forbruges af “billedstørrelse/variant”. Plugin-siden advarer tydeligt om, at “Konverteringer fratrækker yderligere 1 kredit for hver billedstørrelse”.
2. Temaer/e-handelsplugins genererer for mange størrelser, og de gratis kreditter falder markant
   Jo flere størrelser der er, jo lettere er det at opskalere og forbruge kreditter.
3. Når du har aktiveret konverteringen, opdager du, at kreditterne pludselig er ubrugte.
   Det er ikke en fejl, det er dens afregningsmekanisme.
   Råd om strategi:

• Hvis den frie fase primært bruges til komprimering og vægtreduktion, kan du starte med kun at bruge komprimering og derefter slå konvertering til, når du er sikker på, at din webstedsstruktur er stabil, og du virkelig har brug for next-gen.

4. Anbefaling af underscenarier: hvordan man vælger forskellige typer af steder

WordPress, indholdssider, e-handelssider, porteføljer og medlemssider har heller ikke de samme “trykpunkter” for billeder.

4.1 Indholdssider/blogs (masser af artikelgrafik, medium opdateringsfrekvens)

Prioriterede anbefalinger:

1. Strategi for dimensionering (trin 1)
2. Kompression (trin 2)
3. WebP (trin 3)

En mere passende rute:

• Vil du gemme: Route B Triple Choice (ShortPixel / Imagify / TinyPNG)
• Hvis du vil gå gratis: Rute A (Plus WebP + EWWW), men det anbefales at starte med “konservativ tilstand (uden at slette det originale billede)” for at vurdere risikoen.

Typisk pit:

• Det første billede på artikelsiden er meget stort, forkert lazy loading-strategiGør den første skærm langsommere

4.2 E-handel/produktside (mange thumbnails, mange billedvarianter, stabilitet først)

Problemet med e-handel er sandsynligvis ikke “komprimeringseffekten er ikke god”, men “optimeret noget af størrelsen er ikke rigtig, der mangler miniaturebilleder, frontkomponenter kan ikke få billedet”.

Prioriterede anbefalinger:

1. Stabilitet først: konservativ komprimeringsstrategi, udskift ikke hele biblioteket med det samme
2. Evaluering af miniaturestørrelser: e-handelstemaer genererer normalt flere størrelser, og mængden af forbrug forstørres (ShortPixel/TinyPNG er særlig mærkbar).
3. Udfør validering i lille skala før batch (meget kritisk)

En mere passende rute:

• Rute B plejer at være mere problemfri: ShortPixel/Imagify/TinyPNG kan alle batches, og det er vigtigt, at du forstår kvotemekanismen og vurderer omkostningerne på forhånd.
• Rute A er fin, men vær mere forsigtig med Plus WebP's “overskriv ID'er/slette originale billeder/erstatte URL'er”-adfærd: Det er en aktivmigrering, og det anbefales ikke at erstatte det hele lige med det samme.

4.3 Portfolio/fotostation (følsom over for enkeltbilledkvalitet, store billeder, høje krav til visning)

Prioriterede anbefalinger:

1. Størrelsesstrategi (kontrol af skærmområde)
2. Komprimeringsstrategi (det er bedre at være større end at knuse detaljerne)
3. WebP/AVIF (gevinster ved store billeder er indlysende, men kontroller visningen)

En mere passende rute:

• Imagify: Træk kvoten fra i henhold til “størrelsen på det originale billede”, denne type side er lettere at gøre “budgetkontrollerbar” (du ved, hvor meget der skal trækkes fra for hvert stort billede), men undgå gentagne undertrykkelser.
• KortPixel: Hvis miniaturestørrelsen ikke er stor, er kreditter også meget intuitive; men hvis du genererer mange størrelser +next-gen, bliver forbruget af kreditter større, og du er nødt til at planlægge i forvejen.

5. Sammenligning af kvoter og fakturaer: Sæt “gratis er ikke nok” i perspektiv

Hvilken er det bedste tilbud, og hvor længe varer det gratis?

5.1 Tre tilbageførselsmodeller

• KortPixel(kreditter)Kreditter baseret på “originalbillede + antal thumbnails”; yderligere kreditter vil blive fratrukket for hver tilsvarende version af WebP/AVIF, der genereres.
• Imagify(MB-kvote): Træk kvoten fra i henhold til den “oprindelige filstørrelse”; jo flere miniaturer, jo flere fradrag; genpresning vil trække fra igen.
• TinyPNG(kreditter): 500 kreditter pr. måned; aktivering af WebP/AVIF-konvertering fratrækker yderligere kreditter for hver billedstørrelse.

5.2 Hurtige estimeringsmetoder

Du kan beregne det sådan her:

1. Find et tilfældigt “originalbillede, du ofte uploader”, og se, hvor stort det er (f.eks. 300KB / 1MB / 3MB).
2. Afhængigt af hvor mange miniaturestørrelser dit websted genererer (f.eks. 5 / 10 / 20)
3. Beslut, om du vil generere WebP/AVIF (ja/nej)

Brug derefter følgende “mentale matematik” til at forstå forbruget:

• KortPixel: ≈ (1 + antal miniaturer) kreditter pr. billede; hvis der genereres WebP/AVIF, fordobles ≈ igen (da næste generations version også tager kredit)
• Imagify: Hvert billede ≈ (originalstørrelse + hver miniaturestørrelse) fratrækker kvote; ændring af komprimeringsniveau og genkomprimering vil fratrække igen.
• TinyPNG: 500 gratis kreditter; hvis dit websted genererer mange størrelser pr. billede, og konvertering er aktiveret, falder antallet af gratis kreditter betydeligt (plugin-siden giver en visuel forventning om “~100 kreditter/måned” vs. “~50 kreditter/måned”)

6. Risikoadvarsler

Risiko 1: Lad ikke flere plugins gøre det samme igen og igen

Det er den mest almindelige “kilde til katastrofe”.”

• Rute A:Plus WebP eller AVIF + EWWW(Del arbejdet mellem de to, lav ikke like-for-like konverteringer og leverancer på samme tid, eller installer kun en af dem).
• Rute B: ShortPixel / Imagify / TinyPNG Vælg tre(vælg en til at komprimere med next-gen)

Risiko 2: Plus WebP's “Overskriv ID / Slet originalbillede / Erstat URL” er en aktivmigration.

Understregning tilføjet:Plus WebP I beskrivelsen står der tydeligt, at fuld generering overskriver det oprindelige billed-ID, sletter den oprindelige fil og erstatter indholdets URL.
Det betyder, at det ikke er en “lille indstilling, der kan trækkes tilbage når som helst”, men en ændring på aktivniveau.

Den foreslåede strategi bør være:

• Lille test først (et par dusin til et par hundrede)
• Bekræft, at frontend-visning, miniaturebilleder og cache-opdateringer fungerer korrekt
• Genovervej fuld biblioteksbehandling

Risiko 3: Det reelle forbrug af “gratis kreditter” til cloud-komprimering afhænger af antallet af thumbnails og valget af næste generation.

• KortPixel: Thumbnails og next-gen påvirker credits betydeligt.
• TinyPNG: Aktivering af WebP/AVIF fratrækker en ekstra kredit for hver billedstørrelse.
• Imagify: fratrukket i henhold til størrelsen på det originale billede, jo flere thumbnails, der fratrækkes mere, vil hårdt pres gentage fratrækningen!

Risiko 4: “WebP/AVIF genereret” betyder ikke “WebP/AVIF leveres af front office”

Mange føler sig “ikke hurtigere” efter konverteringen, fordi frontend stadig udsender JPG/PNG (caching/omskrivning/tagging/browserforhandling er ikke på det rigtige sted).

7. Hvordan man kontrollerer, at det er trådt i kraft, når det er gjort

4 meget enkle valideringspunkter:

1. Om den samme side opdateres en anden gang og indlæses mere konsekvent og hurtigere(Caching og optimering af den fysiske fornemmelse af, om det virker)
2. Er der stor forskel på størrelsen af de billeder, der indlæses på mobiltelefoner og computere?(lydhør) srcset/størrelser (uanset om de virker eller ej)
3. Stikprøvekontrol af nogle få billeder: om WebP- eller AVIF-filer/ressourcer er til stede(Bruger webstedet faktisk næste generation）
4. Prøv et par billeder: zoom ind for at se, om de er synligt mudrede, om teksten er utydelig(komprimeret masse er ikke for stor)

Hvis alle fire stemmer overens, er den rute, du har valgt, blevet kørt. Næste skridt. CDN “Leveringslag”bliver det hele mere stabilt.

8. Anbefalinger til handling

1. Vælg din rute først:

• Prøver at være så fri som muligt.: Plus WebP eller AVIF + EWWW (eller bare en af dem)
• Vil du spare serverressourcer, så betal pr. kredit for at spare endnu mere!: ShortPixel / Imagify / TinyPNG - vælg en!

2. Lav en lille test først (et par dusin)
3. Sørg for, at det er okay, før du starter
4. Der er behov for yderligere forbedringer af leveringsstabiliteten:læse CDN Acceleration

almindelige problemer

1. Hvor mange plug-ins skal jeg installere? Kan jeg installere dem alle?

Prøv kun at tage én rute.

• Rute A: Plus WebP eller AVIF + EWWW Image Optimizer (eller bare en af dem)
• Rute B: ShortPixel / Imagify / TinyPNG - vælg en!
  I den samme station på samme tid lade mere end et plug-in gøre “komprimering / overførsel WebP / AVIF / ændre URL / levering omskrive”, den mest sandsynlige at få mere og mere kaotisk, men også den sværeste at kontrollere.

2. Understøtter WordPress ikke allerede WebP/AVIF? Har jeg stadig brug for et plugin?

Det skal adskilles:
“Understøttelse af upload/brug” ≠ “Automatisk konvertering/automatisk levering”.
WordPress 6.5 konverterer heller ikke automatisk gamle JPG/PNG'er til WebP/AVIF, og den gør heller ikke automatisk hele “eksporter AVIF/WebP til browser-kompatibel og fallback”-tingen for dig. Det kræver normalt et plugin eller en tjeneste at få det historiske mediebibliotek til at fungere.

3. Hvad er det mest “givende” trin i billedoptimering?

Det er som regel Få styr på “størrelserne” først (srcset/sizes).。
Mange sider er langsomme, ikke fordi de ikke har komprimering, men fordi siden kun er 900 px, og brugeren bliver bedt om at downloade et billede på 3000 px. Komprimering sparer KB'er, men den “forkerte størrelse” får dig til at downloade flere gange mere data for ingenting.

4. Hvordan kan jeg være sikker på, at jeg indlæser det “mindre” og ikke det originale billede for altid?

Se på to fænomener:

• Når du åbner en side på en mobiltelefon, er størrelsen på det downloadede billede mærkbart mindre end på skrivebordet.
• Det samme billede indlæses med forskellige ressourcestørrelser på forskellige enheder
  Hvis det originale billede downloades for evigt, er en almindelig årsag, at temaet/byggeren behandler billedet som et CSS-baggrundsbillede eller brugerdefineret output og omgår mediebibliotekets multi-sizing med srcset.

5. Betyder “WebP/AVIF genereret”, at frontenden skal producere WebP/AVIF?

Ikke ens.
Generering er kun “fillaget”; om frontenden rent faktisk leverer WebP/AVIF afhænger af omskrivninger, politikker for billedmærkning, cache-hits, browserforhandlinger osv. Når du er færdig, skal du huske at “stikprøvekontrollere et par billeder for ressourcetyper”.

6. plus Hvad er der så farligt ved WebP eller AVIF? Kan jeg køre hele biblioteket med et enkelt klik?

Dens risikopunkt er ikke “kompression”, det erÆndringer i aktivmigrationsniveauer：

• Fuld generering kan overskrive det oprindelige billedfil-ID, slette den oprindelige fil og erstatte URL'en i indholdet.
  grunden til, atDet anbefales ikke at udskifte hele biblioteket med det samme.: Test først i lille skala (tiere ~ hundreder) + hav tilgængelige sikkerhedskopier, og overvej derefter fuld biblioteksbehandling.

7. Hvad er valget mellem de to tilstande i Plus WebP: at beholde det oprindelige billede eller at erstatte og slette det oprindelige billede?

Enkelt at forstå:

• Mode 1: Behold det originale billede + generer WebP/AVIF-kopi (mere stabilt): Praktisk til tilbageførsler, men disken bliver større (originalbillede + nyt format + miniaturebilleder i flere størrelser).
• Mode 2: Erstat og slet det originale billede (mere aggressivt)Diske er mindre tilbøjelige til at blive for store, men du “ændrer aktiver + ændrer referencer”, hvilket gør det dyrere at fejlfinde kompatibilitetsproblemer.
  Jo mere kompleks siden er (e-handel/multi-plugin/multi-størrelse), jo mere anbefales det at starte med en mere stabil model.

8. Er EWWW Image Optimizer gratis lokal komprimering nok? Vil det overvælde serveren?

EWWW er mere en “lokal kompressor”: den spiser CPU/IO.
Det er almindeligt, at belastningen stiger under batchoptimering, hvilket ikke betyder, at det “ikke virker”, men snarere at strategien skal være rigtig: batch, lave spidsbelastninger og offloading/cloud-muligheder, hvis det er nødvendigt.
Hvis du gerne vil spare penge, eller hvis du har få serverressourcer, er rute B mere servervenlig.

9. ShortPixels 100 gratis credits/måned, hvorfor føles det, som om de er væk på et par billeder?

på grund af Credits er ikke “antal billeder”.”Den næste generation bliver forstørret med et miniaturebillede med den næste generation:

• Originalbillede + hvert miniaturebillede tæller som kreditering
• Hvis der genereres en WebP/AVIF, forbruges der en ekstra kredit for hver tilsvarende version.
  Så det, du tror er “1 billede”, kan faktisk forbruge tæt på “2-cifrede kreditter”. shortPixel

10. Imagifys gratis 20MB/måned, hvorfor løber det også hurtigt ud?

Imagify er mere som en “trafikpakke”:

• Som du sendte det.Original filstørrelsefradrag af kvoter
• Jo flere thumbnails du har, jo mere forbruger du
• Ændring af komprimeringsniveau for at genoptimere vil forbruge kvote igen
• Samme API-nøgle til flere sider, deling af kvoter
  Så “20MB løber snart tør” skyldes ofte for store billeder, for mange thumbnails eller gentagne forsøg og fejl.

11. TinyPNG er gratis i 500 credits/måned, hvorfor siger plugin'et, at det kun er omkring 100 credits/måned og derefter 50 credits/måned med WebP/AVIF?

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

• En almindelig WordPress-installation komprimerer sandsynligvis omkring 100 ark om måneden.
• Aktivér AVIF- eller WebP-konvertering:Hver billedstørrelse bruger en ekstra kreditSå du kan sandsynligvis kun komprimere og konvertere omkring 50 billeder om måneden (afhængigt af antallet af thumbnail-størrelser).
  Så 500 credits ≠ 500 billeder.

12. Hvor mange thumbnails er der på min side? Hvorfor betyder det så meget?

WordPress genererer flere størrelser, når man uploader et billede; temaer/plugins (især e-handel) kan tilføje flere størrelser.
Cloud-komprimeringskreditter/kvoter er normalt “original + miniaturebilleder sammen”, så jo flere miniaturebilleder du har, jo færre gratis kreditter skal du bruge.

13. Er lazy loading altid hurtigere? Hvorfor siger nogle mennesker, at lazy loading gør tingene langsommere?

Lazy loading er velegnet til “ressourcer uden for skærmen”.
Hvis det første skærmbillede af det mest kritiske store billede også indlæses forsinket, kan det bremse oplevelsen af det første skærmbillede. WordPress 5.5 har som standard indlæst dovent, men det er ikke “en størrelse, der passer til alle”.

14. Jeg rejser på rute A eller B. Hvornår skal jeg bruge CDN / billede CDN?

Komprimering, dimensionering og formatering løser problemet med “mindre filer, der passer”;
CDN Løsningen er at levere tættere og mere stabile。
Når billeder hentes fra en afstand fra kildesiden, hvilket resulterer i betydelig ventetid, vil det generelt være mere stabilt at supplere CDN/billeder med CDN (f.eks. Cloudflare Polish / Jetpack Site Accelerator), læs WordPress CDN Acceleration。

15. Hvordan kan jeg nemmest kontrollere, at “det virkelig virker”, når jeg er færdig?

Den mest tidseffektive verifikationsmetode:

• Om den samme side opdateres en anden gang og indlæses mere konsekvent og hurtigere
• Er størrelserne på de billeder, der indlæses på mobiltelefoner og stationære computere, mærkbart forskellige (spiller srcset/sizes en rolle)?
• Stikprøvekontrol af nogle få billeder: om WebP- eller AVIF-filer/ressourcer er til stede
• Prøv et par billeder: zoom ind for at se, om de er synligt mudrede, om teksten er utydelig