Weboldali képek optimalizálása

A képoptimalizálás a WordPress teljesítményének egyik “leghálásabb” aspektusa: azonos oldalszerkezet és téma esetén, amennyiben a képek mérete, mérete, formázása és szállítása megfelelő, a betöltési élmény azonnal javulni fog.

De a képoptimalizálás is a legkönnyebb módja a zűrzavarnak, és nem azért, mert technikailag túl nehéz, hanem mert az információ túlságosan töredezett:
Elolvastál néhány cikket, és már tudod, hogy “tömörítés”, “WebP/AVIF”, “lusta betöltés”, aztán megnézed a bővítmény leírását, és ott meg azt írják, hogy “havonta 100 ingyenes kredit”, “ingyenes 20MB”, “képenként 1 kredit”, és ettől csak még jobban összezavarodsz — akkor végül mire elég az ingyenes keret? Hogyan vonják le a díjat? Lehet, hogy félreértetted, mi számít “ugyanannak a dolognak”? És a legfontosabb:Tényleg hatott, miután megcsináltad, vagy nem?

Ez a cikk csak három dolgot tesz:

1. Adjon egy futtatható fájltútiterv (szintén ábra)(Mit tegyünk először, mit tegyünk másodszor)
2. Legyen világos, hogy melyik opciót választja (mi a különbség az ingyenes és a fizetős között, és kinek melyik alkalmas).
3. Írd ki előre a leggyakoribb buktatókat (így nem kell keresgélned a hibaelhárításhoz, amikor végeztél).

1. A lényeg: Mit tartalmaz a WordPress és mit nem?

Ha nem találod ki először, hogy mit csinál már a WordPress magja, akkor könnyen két dolog közül az egyiket teheted:

• Ahelyett, hogy kihasználnád a “szabad kapacitást”, amit élvezned kellene, időt töltesz/pénzt fizetsz, hogy újra és újra megépítsd a kereket.
• Azt hittem, hogy a WordPress “automatikusan konvertálja az összes régi képet WebP/AVIF-be”, de kiderült, hogy nem!

A WordPress magja rendelkezik ezekkel a beépített kulcsfontosságú képességekkel:

• Responsive képek (srcset/sizes): A WordPress 4.4-től kezdve a core képeket ad ki a srcset 与 sizes, és felhasználja a feltöltés során generált többméretű képeket, hogy a böngésző a képernyő körülményei alapján kiválaszthassa a betöltésre alkalmasabb erőforrást.
• Natív lusta betöltés: A WordPress 5.5-től kezdődően alapértelmezés szerint lehetővé teszi a képek natív, lusta betöltését a HTML-szabványok segítségével. loading attribútum megvalósítása.
• WebP feltöltés támogatása: A WordPress 5.8 óta a WebP JPEG/PNG formátumban is feltölthető és használható (feltéve, hogy a tárhely környezet támogatja a WebP-t).
• AVIF feltöltésének támogatása: A WordPress 6.5-től kezdve képes feltölteni és használni az AVIF-et JPEG/PNG formátumban (ez a tárhely támogatásától is függ).

De figyeljetek:
“Feltöltés/felhasználás támogatása” ≠ “Automatikus átalakítás/automatikus kézbesítés”.
Vagyis: még ha már WP 6.5-nél is vagy, a médiatáradban lévő JPG/PNG-k nem fognak maguktól WebP/AVIF-é változni; nem fogod automatikusan megkapni a teljes “AVIF/WebP kimenet a böngésző képességeinek megfelelően, és a nem támogatott böngészők esetében visszaáll az eredeti képre” linket! --ezt a részt általában egy pluginnal vagy szolgáltatással kell javítani.

2. Útiterv: képoptimalizálás 5 lépésben

Mit kell tenni, miért, mit kell tenni a kvalifikációhoz, és milyen egy tipikus gödör.

2.1 Először a “méret” helyes beállítása (a leginkább figyelmen kívül hagyott, de a leghasznosabb)

Sok állomás nem azért lassú, mert a tömörítés nem történik meg, hanem aLetöltött egy nagyméretű képet, amely jóval túlnyúlik a kijelzőn：
Például, ha az oldal valójában csak 900px széles, és arra kéri a látogatót, hogy töltse le az eredeti 3000px-es képet, a böngésző csak “letölti, majd összezsugorítja”. Ez pazarolja a sávszélességet, növeli a dekódolási időt és lassítja az első képernyőt.

WordPress 4.4+Reagáló képi mechanizmus（srcset/sizes) éppen ezt a problémát hivatott kezelni.

Csináld azt, ami passznak számít:

• Ha egy oldalt mobiltelefonon nyit meg, a letöltött kép méretének jelentősen kisebbnek kell lennie, mint az asztali számítógépen.
• Ugyanaz a kép különböző erőforrásméretekkel töltődik be a különböző eszközökön (ahelyett, hogy mindig az eredeti képet töltené le).

A leggyakoribb buktatók:

• Vannak olyan témák/építők, amelyek a diagramokat CSS-háttérképként kezelik, vagy olyan egyéni módon adják ki őket, amely megkerüli a srcsetAz eredmény egy nagy kép lett a
• Használhat külsőleg összekapcsolt képágyakat, harmadik féltől származó képblokkokat, és megkerülheti a médiatár által generált többméretű rendszert is.

---

2.2 Tömörítés (csökkentse a KB-mennyiséget, de ne “zúzza össze” a minőséget)

A tömörítés lényege nem a “minél kisebb, annál jobb”, hanem a “szabad szemmel alig látható különbség, de a térfogatcsökkenés nyilvánvaló”.

A szabályok a következők:

• Fényképek/élőképek (emberek, termékek, tájak): Elsőbbségi veszteséges tömörítés (maximális erősítés)
• Pillanatképek a kezelőfelületről / szöveges képek: A tömörítésnek konzervatívabbnak kell lennie a homályos szöveg elkerülése érdekében.
• Logó/Ikon: Prioritás SVG vagy diszkrét veszteségmentes (veszteséges könnyen beilleszthető)

Csináld azt, ami passznak számít:

• Jelentős képméret-csökkentés a legtöbb oldalon
• Nincs látható zaj, zavaros élek, színtömbök törése, elmosódott szöveg

---

2.3 WebP / AVIF (formátumstratégia: kisebb az azonos felbontásért)

A WordPress már támogatja a feltöltést WebP (5,8) vs. AVIF (6,5)。
Ahhoz azonban, hogy a Next Generation Format valóban működjön, általában két dolgot kell megoldani:

1. Hogyan lehet kötegelt módon konvertálni a történelmi médiatárakat(Ellenkező esetben csak a “később feltöltött új képekhez” optimalizál)
2. Másolat készítése vagy az eredeti kép cseréje(Ez egy kockázatos vízválasztó; később a Plus WebP “Eredeti kép cseréje és törlése” funkciójára fogunk összpontosítani.)

Ajánlott írásmód:

• WebP: alapértelmezettként általában előnyben részesül (stabilabb kompatibilitás)
• AVIF: egy további tömörítési irány, amely nagyméretű képek/első képernyő nagyméretű képei/album képekhez alkalmas (de többFüggés a környezeti támogatástól）

---

2.4 A lusta betöltést helyesen kell használni (nem egy méret illik mindenre)

WordPress 5.5-től kezdveAlapértelmezett lusta betöltésKép.
Ez csökkenti a sávszélesség-használatot a kezdeti renderelés során:

• Lusta betöltés a “képernyőn kívüli erőforrásokhoz”
• Az első képernyő legkritikusabb nagyméretű képe (és sok esetben az első képernyő legfontosabb képe) gyakran nem alkalmas a késleltetett betöltésre.

---

2.5 Szállítási szint: CDN / Kép CDN

A tömörítés, a méretezés és a formázás megoldja a “kisebb, megfelelő méretű fájlok” problémáját.
Ha azonban a képeket mindig a forrástól távolabbról húzzák, a hálózati késleltetés még mindig jelentősen befolyásolja az élményt. Itt jön be a képátviteli réteg (CDN/kép CDN) megoldása.

Két tipikus irány:

• Cloudflare lengyel：Cloudflare dokumentációBemutatják a lengyel tömörítési módszereket (veszteségmentes/veszteséges/WebP), és megemlítik, hogy a tömörítés a format=auto A WebP/AVIF formátum megengedett.
• Jetpack oldalgyorsító：Jetpack dokumentációElmagyarázza, hogy optimalizálja a képeket, és a statikus erőforrásokkal együtt terjeszti azokat a hálózatán keresztül.

A képoptimalizálás felelős azért, hogy kisebb és megfelelőbb legyen.CDN felelős a közelebbi és stabilabb szállításért

3. Kiválasztás: csak két fő útvonal

A képoptimalizálás leggyakoribb hibája nem a “nincs plugin”, hanem a túl sok plugin, ami kettős feldolgozáshoz vezet:
A tömörít, B tömörít, A WebP/AVIF-be konvertál, B konvertál, A megváltoztatja az URL-címeket, B átírja - még azt sem lehet tudni, mi történik az állomáson.

Szabályok:

Csak egy út van: vagy az összes ingyenes helyi vagy felhőalapú tömörítés a három közül.

• A útvonal (minden ingyenes helyi járat):Plusz WebP vagy AVIF + EWWW képoptimalizáló(vagy csak egy)
• B útvonal (felhő tömörítés hármas opció):ShortPixel / Imagify / TinyPNG

---

3.1 A útvonal: Teljes ingyenes helyi (plusz WebP vagy AVIF vagy EWWW)

Ezt az útvonalat a következők jellemzik:

• Ön nem támaszkodik harmadik fél “havonta/laponként” nyújtott tömörítési szolgáltatásaira (bár egyes funkciókat opcionális szolgáltatásként kínálnak).
• Ára: a kötegelt feldolgozás jobban terhelheti a szerver CPU/IO-ját, ezért jobban kell figyelned a “stratégiára és a kockázatra”

3.1.1 Plusz WebP vagy AVIF: a mag a “generálás/helyettesítés”, ez nem a hagyományos “tömörítő eszköz”.”

• Teljes térfogatú képek készítésekor:Az eredeti képfájl azonosítóját a WebP/AVIF felülírja, az eredeti fájl törlődik, és a tartalomban szereplő URL-cím lecserélődik.。
• A plugin WP-CLI parancsokat biztosít, és emlékeztet: a WP-CLI megbízhatóbb, ha sok fájl van.

Ez azt jelenti, hogy ahelyett, hogy “csendben generálna neked egy WebP-t”, ez lehet egyEszközök migrációja(Különösen, ha bekapcsolja a “Kicserélni és törölni az eredeti képet” opciót).

A két modell közötti különbségek

1. mód: Az eredeti kép megtartása + WebP/AVIF másolat létrehozása (stabilabb)

• Előnyök: Könnyebb visszaesni kompatibilitási problémák esetén
• Költségek: A lemezhasználat megnő (eredeti kép + új formátum + több méretű miniatűr)

2. mód: Az eredeti kép cseréje és törlése (agresszívebb)

• Előnyök: a lemezek nem bővülnek olyan gyorsan; az állomáshivatkozások közvetlenül az új formátumra mennek át.
• Kockázat: “megváltoztatod az eszközöket + megváltoztatod a hivatkozásokat”, ami költségesebbé teszi a kompatibilitási problémák elhárítását (különösen, ha néhány külső rendszer vagy téma logikája függ az eredeti fájlnévtől/útvonaltól/formátumtól).

A Plus WebP vagy AVIF tipikus buktatói

1. A teljes könyvtár cseréje után néhány oldalkép rendellenesen jelenik meg.
   Ennek oka általában nem az, hogy a kép “elromlott”, hanem az, hogy az URL-helyettesítés, a gyorsítótárazási folyamat, a miniatűrökre vonatkozó irányelvek stb. valamelyik láncszeme nem megfelelő.
2. Minél nagyobb a miniatűrök száma, annál nagyobb a módosítás hatóköre.
   A WordPress többféle méretet generál a kép feltöltéséhez; a témák/pluginek további méreteket is hozzáadhatnak. A teljes csere azt jelenti, hogy egy nagyon nagy fájlgyűjteményt módosíthatsz.
3. A formátumváltás nem feltétlenül jelenti azt, hogy a kötet mindig a legkisebb lesz.
   A WebP/AVIF általában kisebb, de a “méretstratégia” és a “tömörítési stratégia” még mindig kritikus. Ne gondoljon a Plus WebP-re úgy, hogy “egy kattintással gyorsabb”.

---

3.1.2 EWWW képoptimalizáló: a szabad helyi tömörítés képviselője

Az EWWW plugin oldal nagyon jól pozícionált:

• A szerveren optimalizálható egy sor eszközzel (jpegtran, optipng, pngout, pngquant, gifsicle, cwebp, stb.)
• Ha nagyobb tömörítésre vagy nagyobb CPU-megtakarításra van szüksége, akkor az CPU-fogyasztó feldolgozást a kiszolgálóra is áthelyezheti (opcionális).

Milyen szerepet kell vállalnia az EWWW-nek az A útvonalban?

Ha a Plus WebP-t “formátumváltási/helyettesítő stratégiaként” használja, akkor az EWWW jobban megfelel:

• Tömörítés és térfogatoptimalizálás(különösen a nyers erőforrások, mint például a JPG/PNG súlyának csökkentése)
• Tömeges optimalizálás a történelmi médiatárban(inkább a “volumencsökkentés”, mint az “URL-helyettesítés” céljával)

Az EWWW tipikus gödre

1. Megnövekedett szerverterhelés kötegelt optimalizálás során
   Mivel a helyi tömörítés megeszi az CPU/IO-t, a megoldás nem a “ne használd”, hanem a “kötegelt, alacsony csúcsérték, szükség esetén offload/felhő opció”.
2. “A ”WebP generálódik" nem jelenti azt, hogy a frontendnek WebP-t kell létrehoznia.
   Sok plugin szenved ettől a félreértéstől: a generálás egy dolog, a szállítási stratégiák (átírások, képcímkék, cache-találatok stb.) egy másik dolog.
3. Ugyanazt a dolgot újra és újra más pluginekkel csinálni
   Ha az A útvonalat választod, próbáld meg, hogy ne fedd le a ShortPixel/Imagify/TinyPNG típusú felhőtömörítést; ha a B útvonalat választod, ne kapcsold be a Plus WebP helyettesítő logikát. Alapelv:Egy út a végére.

---

3.2 B útvonal: Felhő tömörítés hármas választása (ShortPixel / Imagify / TinyPNG)

Ez az útvonal azok számára alkalmas, akik “szerver erőforrásokat akarnak megtakarítani, kevesebb erőfeszítéssel akarnak kötegelt munkát végezni, és elfogadják a kredit/mennyiségenkénti számlázást”.
De a felhőtömörítéssel kapcsolatban a legfélrevezetőbb pont az:Az ingyenes kreditek nem olyan egyszerűek, mint az “ingyenes lapok”!.. A miniatűrök száma, a WebP/AVIF generálása vagy sem, valamint az ismételt újrasajtolás vagy sem jelentősen befolyásolhatja a fogyasztást.

A következőkben elmagyarázzuk: mi történik az ingyenességgel/díjjal, hogyan vonják le a krediteket, milyen buktatókba lehet leginkább belelépni, és milyen oldaltípusok megfelelőek.

---

3.2.1 ShortPixel100 ingyenes kredit/hó, de a krediteket a miniatűrök és a WebP/AVIF nagyítások fogyasztják.

Mi történik az ingyenes/fizetős

A ShortPixel plugin leírása egyértelműen kimondja:

• 100 ingyenes kredit havonta
• Vannak “Extra korlátlan havi kreditek” is (a plugin oldal tájékoztatást ad a megfelelő árakról).
• “Egyszeri kreditcsomagként is elérhető, amely soha nem jár le” (kezdőárral)

Tipp:

• Ingyenes: adjon egy bizonyos mennyiségű kreditet havonta könnyű oldalakhoz vagy teszteléshez
• Egyszer használatos csomagok: alkalmasak olyan nagy médiatárral rendelkező webhelyek számára, amelyek egyszerre szeretnék kiüríteni a készletüket (egyszer vásárolja meg és használja fel, általában nem jár le).
• Havi/korlátlan: alkalmas folyamatosan frissített képekkel rendelkező oldalakhoz és hosszú távú stabil optimalizáláshoz.

ShortPixel hivatalos KB is adott egy frissítést a “One Time Pack vs Unlimited Monthly”.kifejezett magyarázat: A Unlimited Monthly egy havi (vagy éves) fizetés, amely korlátlan számú kreditet kínál fix CDN keretösszeggel; egyszeri kreditek, amelyek nem járnak le, így Ön nagyobb kontrollt kap, hogy szükség szerint használhassa őket.

A lényeg: hogyan számítják ki a ShortPixel krediteket?

ShortPixel hivatalos dokumentációja KB nagyon nyers volt:

• A WordPress több miniatűr képet generál, amikor feltöltesz egy képet;
• Minden egyes miniatűr optimalizálás egy kreditnek számít.；
• Ha úgy dönt, hogy WebP vagy AVIF formátumot hoz létre, aAz eredeti kép és a miniatűr kép minden egyes WebP/AVIF változata további kreditet igényel.；
• A kreditfogyasztás csökkentése érdekében kizárhat bizonyos miniatűröket az optimalizálásból.

Példa kreditek：

Tegyük fel, hogy feltöltesz 1 képet, és a téma/plugin 8 miniatűr képet generál:

• Csak az eredeti kép + miniatűrök optimalizálása: 1 (eredeti) + 8 (miniatűrök) = 9 kreditpont
• Ha WebP/AVIF-et is szeretne generálni: még egy next-gen verzió a fenti 9 közül mindegyikhez → +9 kredit.
  Más szóval, amit Ön “1 képnek” gondol, az valójában közel “2 számjegyű kreditet” fogyaszt.

Szóval:“Az ”ingyenes 100 kredit“ nem ugyanaz, mint az ”ingyenes 100 kép".

A ShortPixel leggyakoribb buktatói

1. Ingyenes 100 kredit gyorsan elfogy
   Gyökér ok: sok miniatűr + extra kreditek a WebP/AVIF generálásáért.
   javaslat：

• Először értékelje az oldal miniatűrjeinek számát
• A felesleges miniatűrméretek kizárása (csak a ténylegesen használt méreteket optimalizálja)
• A tömörítési stratégia meghatározása a tömeges futtatás előtt, hogy elkerülje az ismételt próbálkozás és hiba fogyasztást.

2. Más konverter plug-inek egyidejű egymásra helyezése
   Ha Plus WebP cserék és ShortPixel újgenerációs címkéket generál/beilleszt, a logika felhalmozódik, és nehezebbé válik a hibaelhárítás. A B útvonal esetében hagyja, hogy a ShortPixel egyedül csinálja.
3. Azt hittem, ha telepítem, akkor “WebP/AVIF az előtérben” lesz.”
   ShortPixel plugin oldalMegemlítette, hogy WebP/AVIF konvertál és képes a következő generációs képeket hozzáadni a címlaphoz (pl. címkézéssel).
   De még mindig fontos, hogy ellenőrizze az eredményeket, miután ezt megtette.

---

3.2.2 ImagifyIngyenes: 20MB/hó; a kvóta az “eredeti kép mérete + a miniatűrök száma” alapján kerül levonásra, ismételt levonás történik az újbóli sajtolás miatt.

Szabad összeg és pozicionálás

Imagify hivatalos ároldalAz írás világos:Ingyenes fiók havi 20MB kvóta。
A plugin oldaláról az is kiderül, hogy képes a WebP/AVIF tömörítésére, átméretezésére és konvertálására.

Hogyan történik a kvóta levonása?

Imagify hivatalos dokumentáció “A ”Hogyan számítják ki a kvótakihasználást?" nagyon világosan bemutatja a levonási mechanizmust:

• A miniatűrök száma befolyásolja a fogyasztástPéldául, ha 10 miniatűr méret van, akkor 1 kép optimalizálása 11 kép optimalizálásává válik (eredeti + 10 miniatűr), amelyek mind hozzájárulnak a kvótafogyasztáshoz.
• A kontingens levonása az eredeti dokumentum mérete szerint: Ha például 100 KB-os képet küld az Imagify-nak, 100 KB levonásra kerül a kvótából.
• A tömörítési szint megváltoztatása és az újbóli optimalizálás ismét fogyasztja a kvótát.。
• Ugyanaz az API-kulcs több webhelyhez is használható, de a kvóták megoszlanak közöttük.

Ez az Imagify “alapvető megértési módja”:
Inkább olyan, mint egy forgalmi csomag: annyit von le, amennyit küldesz; minél több miniatűröd van, annál többet von le; és a levonás megismétlődik, ha többször újra megnyomod.

Könnyen olvasható Imagify kvóta példa

Tegyük fel, hogy feltöltesz egy 800 KB méretű eredeti képet, és az oldal 8 miniatűr képet generál.

• Az Imagify az “eredeti kép + 8 miniatűr kép” optimalizálására optimalizál (ha úgy dönt, hogy mindet optimalizálja), ami azt jelenti, hogy ez az egyetlen művelet az “összes fájl eredeti méretének” megfelelő kvótát fogyaszt.
  Ezért érzik úgy egyes oldalak, hogy a “20MB” nagyon gyorsan elfogy: nem azért, mert az Imagify nem elég, hanem mert a feltöltött képeid minden alkalommal túl nagyok, túl sok bélyegkép készül, és lehet, hogy még a tömörítési szinteket is újra meg újra próbálgatod.

Az Imagify leggyakoribb buktatói

1. Ingyenes 20MB Nem elég a “teljes helyszíni leltárhoz”
   A 20MB általában jobban alkalmas könnyű frissítésekkel történő tesztelésre; ha a médiatár már nagy, egy egyszeri tisztítás valószínűleg frissítést igényel.
2. A tömörítési szintek ismételt beállítása a kvóták kettős felhasználását eredményezi.
   Imagify világossá teszi, hogyAz újbóli optimalizálás ismét felemészti a kvótát.
   Javaslom, hogy a “stratégiát” tegye egyértelművé ezen az oldalon:

• Kezdje kis számú képpel a tömörítési szint és a megjelenés meghatározásához.
• Határozza meg a stratégiát, majd futtassa ömlesztve
  Kerülje el az ismételt próbálkozást és hibázást a teljes könyvtárral kapcsolatban.

3. Több webhely közös API-kulcsa “megmagyarázhatatlan kvótacsökkentéshez” vezet.”
   Ha ugyanazt az API-kulcsot több állomáshoz használja, a kvóta megosztásra kerül.
   Így a csapat/több állomásos forgatókönyvek esetében a legjobb, ha tisztázzuk: mely állomásokat használjuk közösen, és melyeket egyénileg, hogy elkerüljük az ellenőrizhetetlen költségvetést.

---

3.2.3 TinyPNG(Tiny Compress Images): ingyenes 500 kredit/hó; WebP/AVIF-re váltás esetén “méretenként 1 kreditet von le”.”

Ingyenes kreditek és számlázási ötletek

A TinyPNG WordPress plugin oldala nagyon egyértelmű:

• 500 kredit havonta ingyen
• Az “Általános WordPress telepítés”, akkor valószínűleg tömöríteni a Kb. 100 kép/hónap
• Ha azonban az AVIF vagy WebP konverzió engedélyezve van:Minden képméret további kreditet fogyasztTehát feltehetően csak tömöríteni és átalakítani lehet. Kb. 50 kép/hónap(attól függően, hogy hány miniatűr méret van).

Eközben a Tinify (a TinyPNG/TinyJPG fejlesztői) szintén elkészítette a API árképzési oldalLeírás: Regisztráljon és kap 500 ingyenes kompressziót havonta; ezután a sikeres kompressziók száma alapján számlázunk, nincs kötelező előfizetés.

Foglalja össze a TinyPNG értelmezését egy mondatban:
Számolja a krediteket; minél több miniatűr méret van, és minél több WebP/AVIF van bekapcsolva, annál gyorsabban fogynak a kreditek.

Könnyen olvasható példák a TinyPNG kreditekre

Tegyük fel, hogy webhelye 8 miniatűr képméretet generál minden egyes képhez:

• Csak tömörítés: eredeti + 8 miniatűr → 9 kredit szükséges
• Ha a WebP/AVIF konverzió be van kapcsolva: méretenként egy plusz kredit → valószínűleg majdnem a duplája!
  Ez megfelel a bővítmény oldalán található leírásnak: a bekapcsolás után az ingyenes mennyiség körülbelül “100 kártya/hó” helyett “50 kártya/hó” lesz.

A TinyPNG leggyakoribb buktatói

1. Gondoltam 500 kredit = 500 kép
   Nem az. A “képméret/variáns” fogyasztja. A plugin oldala egyértelműen figyelmeztet, hogy “A konverziók minden képméret után további 1 kreditet vonnak le”.
2. A témák/e-kereskedelmi bővítmények túl sok méretet generálnak, és az ingyenes kreditek jelentősen csökkennek.
   Minél több méret van, annál könnyebb a krediteket felskálázni és elfogyasztani.
3. Miután engedélyezte az átalakítást, azt tapasztalja, hogy a kreditek hirtelen fel nem használtak.
   Ez nem hiba, hanem a számlázási mechanizmusa.
   Stratégiai tanácsadás:

• Ha az ingyenes fázist elsősorban tömörítésre és súlycsökkentésre használja, kezdheti csak a tömörítéssel, és csak akkor kapcsolhatja be a konverziót, amikor már biztos benne, hogy az oldal szerkezete stabil, és valóban szüksége van a next-genre.

4. Alforgatókönyv-ajánlás: hogyan válasszuk ki a különböző típusú helyszíneket?

A WordPress, a tartalmi oldalak, az e-kereskedelmi oldalak, a portfóliók és a tagsági oldalak nem rendelkeznek ugyanazokkal a “nyomáspontokkal” a képek tekintetében.

4.1 Tartalmi oldalak/blogok (sok cikkgrafika, közepes gyakoriságú frissítések)

Kiemelt ajánlások:

1. Méretezési stratégia (1. lépés)
2. Tömörítés (2. lépés)
3. WebP (3. lépés)

Megfelelőbb útvonal:

• Menteni szeretne: Route B Triple Choice (ShortPixel / Imagify / TinyPNG)
• Ha szabadon akarsz menni: A útvonal (Plusz WebP + EWWW), de ajánlott a “konzervatív móddal (az eredeti kép törlése nélkül)” kezdeni, hogy felmérd a kockázatot.

Tipikus gödör:

• A cikk oldalának első képe nagyon nagy, helytelen lusta betöltési stratégiaLassítja az első képernyőt

4.2 E-commerce/termékoldal (sok miniatűr, sok képváltozat, stabilitás az első)

E-kereskedelem a legvalószínűbb, hogy a probléma nem a “tömörítési hatás nem jó”, de “optimalizált néhány méret nem megfelelő, hiányzó miniatűrök, elülső komponensek nem kap a képet”.

Kiemelt ajánlások:

1. Először a stabilitás: konzervatív tömörítési stratégia, ne cserélje le azonnal a teljes könyvtárat.
2. A miniatűrök méretének értékelése: az e-kereskedelmi témák általában több méretet generálnak, és a fogyasztás megnövekszik (a ShortPixel/TinyPNG különösen észrevehető).
3. Kisléptékű validálás a tételes gyártás előtt (nagyon kritikus)

Megfelelőbb útvonal:

• A B útvonal általában problémamentesebb: a ShortPixel/Imagify/TinyPNG mind kötegelni tud, és kritikus, hogy megértse a kvótamechanizmust és előre felmérje a költségeket.
• Az A útvonal jó, de légy óvatosabb a Plus WebP “ID-k felülírása/törlése eredeti képek/ URL-ek cseréje” viselkedésével: ez egy eszközmigráció, és nem ajánlott az egészet rögtön lecserélni.

4.3 Portfólió/fotóállomás (egyetlen kép minőségére érzékeny, nagyméretű képek, nagy igény a megtekintésre)

Kiemelt ajánlások:

1. Méretstratégia (kijelzőterület-szabályozás)
2. Tömörítési stratégia (jobb nagyobbnak lenni, mint összezúzni a részleteket)
3. WebP/AVIF (a nagyméretű jelenet előnyei nyilvánvalóak, de ellenőrizze a nézetet)

Megfelelőbb útvonal:

• Imagify: Vonja le a kvótát az “eredeti kép mérete” szerint, ez a fajta oldal könnyebben “költségvetés-szabályozható” (tudja, hogy mennyit kell levonni minden egyes nagy képnél), de elkerülhetőek az ismételt elnyomások.
• ShortPixel: Ha a miniatűr méret nem sok, a kreditek is nagyon intuitívak; de ha sok méretet generálsz +next-gen, a kreditek fogyasztása megnő, és előre kell tervezned.

5. Kontingens/számlázás összehasonlítás: az “ingyen nem elég” perspektívába helyezése

Melyik a jobb ajánlat és meddig tart az ingyenesség?

5.1 Három visszaterhelési modell

• ShortPixel(kreditek): A kreditek kiszámítása az “eredeti kép + a miniatűrök száma” alapján történik; minden egyes megfelelő WebP/AVIF-verzió után további kreditet vonunk le.
• Imagify(MB kontingens): A kvótát az “eredeti fájlméret” szerint vonja le; minél több miniatűr, annál több levonás; az újbóli megnyomás ismét levonást eredményez.
• TinyPNG(kreditek): 500 kredit havonta; a WebP/AVIF konverzió engedélyezése további krediteket von le minden egyes képméret után.

5.2 Gyors becslési módszerek

Ezt így lehet megbecsülni:

1. Keressen egy véletlenszerű “gyakran feltöltött eredeti képet”, és nézze meg, hogy mekkora (pl. 300KB / 1MB / 3MB).
2. Attól függően, hogy hány miniatűrméretet generál a webhelye (pl. 5 / 10 / 20).
3. Döntse el, hogy WebP/AVIF-et szeretne-e generálni (igen/nem)

Ezután használja a következő “mentális matematikát” a fogyasztás megértéséhez:

• ShortPixel: ≈ (1 + a miniatűrök száma) kreditek képenként; WebP/AVIF generálás esetén ≈ ismét megduplázódik (mivel a next-gen verzió is kreditet vesz fel)
• Imagify: Minden egyes kép ≈ (eredeti méret + minden egyes miniatűr méret) levonja a kvótát; a tömörítési szint módosítása és az újbóli tömörítés ismét levonja a kvótát.
• TinyPNG: 500 kredit ingyen; ha a webhelye sok méretet generál képenként, és a konverzió engedélyezve van, az ingyenes kreditek száma jelentősen csökken (a plugin oldal vizuálisan “~100 kredit/hó” vs. “~50 kredit/hó”).

6. Kockázati figyelmeztetések

Kockázat 1: Ne hagyja, hogy több plugin újra és újra ugyanazt a dolgot csinálja.

Ez a leggyakoribb “katasztrófaforrás”.”

• A útvonal:Plusz WebP vagy AVIF + EWWW(Ossza meg a munkát a kettő között, ne végezzen egyidejűleg hasonló átalakításokat és szállításokat, vagy csak az egyiket telepítse.)
• B útvonal: ShortPixel / Imagify / TinyPNG válasszon hármat(válasszon egyet a next-gen tömörítéshez)

Kockázat 2: Plusz a WebP “ID felülírása / Eredeti kép törlése / URL cseréje” egy eszköz migrációja.

Kiemelés hozzáadva:Plusz WebP A leírás egyértelműen kimondja, hogy a teljes generálás felülírja az eredeti képazonosítót, törli az eredeti fájlt, és helyettesíti a tartalom URL-címét.
Ez azt jelenti, hogy nem egy “bármikor visszavonható kis beállításról” van szó, hanem eszközszintű változásról.

A javasolt stratégiának a következőnek kell lennie:

• Először kis teszt (néhány tucat és néhány száz között)
• Ellenőrizze, hogy a frontend megjelenítése, a miniatűrök és a gyorsítótár frissítései megfelelően működnek-e.
• A teljes könyvtári feldolgozás újragondolása

3. kockázat: A felhőtömörítés “ingyenes kreditjeinek” tényleges fogyasztása a miniatűrök számától és a next-gen kiválasztástól függ.

• ShortPixel: A miniatűrök és a next-gen jelentősen befolyásolják a krediteket.
• TinyPNG: A WebP/AVIF engedélyezése minden egyes képméret után további kreditet von le.
• Imagify: az eredeti kép méretének megfelelően levonva, minél több miniatűr levonva, annál több, a nagy nyomás megismétli a levonást!

4. kockázat: A “WebP/AVIF generált” nem jelenti azt, hogy “a WebP/AVIF-et a front office szállítja”.”

Sokan úgy érzik, hogy a konverzió után “nem gyorsabb”, mert a frontend még mindig JPG/PNG-t ad ki (a gyorsítótár/újraírás/címkézés/böngésző-tárgyalás nincs a megfelelő helyen).

7. Hogyan lehet ellenőrizni, hogy a végrehajtás után a módosítás hatályba lépett-e?

4 nagyon egyszerű érvényesítési pont:

1. Ugyanaz az oldal másodszor is frissül-e, és töltődik-e be következetesebben és gyorsabban.(Cache és optimalizálása a fizikai értelemben, hogy működik-e)
2. A mobiltelefonokon és az asztali számítógépeken betöltött képek mérete jelentősen különbözik-e?(érzékeny) srcset/sizes (függetlenül attól, hogy működnek-e vagy sem)
3. Néhány kép szúrópróbaszerű ellenőrzése: WebP vagy AVIF fájlok/források megléte(A webhely valóban a next-gen）
4. Vegyen mintát néhány képről: nagyítsa ki, hogy lássa, láthatóan zavarosak-e, elmosódott-e a szöveg.(a tömörített tömeg nem túlzott)

Ha mind a négy egyezik, akkor a kiválasztott útvonal lefutott. Következő lépés. CDN “Szállítási réteg”, az összkép stabilabb lesz.

8. Intézkedési ajánlások

1. Először válassza ki az útvonalat:

• Próbálok minél szabadabb lenni.: Plusz WebP vagy AVIF + EWWW (vagy csak az egyik)
• Szeretne szerver erőforrásokat megtakarítani, fizetni kreditenként a nagyobb nyugalomért: ShortPixel / Imagify / TinyPNG - válasszon egyet!

2. Először végezzen egy kis tesztet (néhány tucat).
3. Győződjön meg róla, hogy minden rendben van, mielőtt elkezdené a kötegelését.
4. A szállítási stabilitás további javítására van szükség:olvasd el CDN Gyorsítás

gyakori problémák

1. Hány bővítményt kell telepítenem? Telepíthetem mindet?

Próbáljon meg csak egy útvonalat választani.

• A útvonal: Plusz WebP vagy AVIF + EWWW Image Optimizer (vagy csak az egyik)
• B útvonal: ShortPixel / Imagify / TinyPNG - válasszon egyet!
  Ugyanabban az állomáson egyidejűleg hagyja, hogy egynél több plug-in csinálni “tömörítés / átvitel WebP / AVIF / változás URL / szállítás átírása”, a legvalószínűbb, hogy egyre több és több kaotikus, de a legnehezebb ellenőrizni.

2. A WordPress nem támogatja már a WebP/AVIF formátumot? Még mindig szükségem van egy pluginra?

Ezt el kell különíteni:
“Feltöltés/felhasználás támogatása” ≠ “Automatikus átalakítás/automatikus kézbesítés”.
A WordPress 6.5 szintén nem konvertálja automatikusan a régi JPG/PNG-ket WebP/AVIF-be, és nem végzi el automatikusan az egész “AVIF/WebP exportálása böngésző-képes és fallback” dolgot. Általában egy plugin vagy szolgáltatás kell ahhoz, hogy ezt pótolja, és jó ötlet, hogy a történelmi médiatárak is kövessék ezt a példát.

3. Mi a leg “kifizetődőbb” lépés a képoptimalizálásban?

Ez általában Először a “méreteket” kell helyesen beállítani (srcset/sizes).。
Sok oldal nem azért lassú, mert nincs tömörítés, hanem azért, mert az oldal csak 900 pixeles, és a felhasználónak egy 3000 pixeles képet kell letöltenie. A tömörítéssel KB-okat lehet megtakarítani, de a “rossz méret” miatt többszörös mennyiségű adatot kell letölteni a semmiért.

4. Hogyan lehetek biztos abban, hogy a “kisebbik” képet töltöm be, és nem az eredeti képet örökre?

Nézzünk meg két jelenséget:

• Amikor egy oldalt megnyit egy mobiltelefonon, a letöltött kép mérete észrevehetően kisebb, mint az asztali számítógépen.
• Ugyanaz a kép különböző erőforrásméretekkel töltődik be különböző eszközökön
  Ha az eredeti kép örökre letöltődik, annak gyakori oka, hogy a téma/építő a képet CSS-háttérképként vagy egyéni kimenetként kezeli, megkerülve a médiatár srcset segítségével történő többméretű méretezését.

5. A “WebP/AVIF generált” azt jelenti, hogy a frontendnek WebP/AVIF-et kell előállítania?

Nem egyenlő.
A generálás csak a “fájlréteget” jelenti; az, hogy a frontend valóban WebP/AVIF-et szolgáltat-e, az átírásoktól, a képcímkézési irányelvektől, a gyorsítótár találataitól, a böngésző hatályos egyeztetésétől és így tovább függ. Ha kész, mindenképpen “szúrópróbaszerűen ellenőrizzen néhány képet erőforrástípusok szempontjából”.

6. Plusz Mi a veszélyes a WebP-ben vagy az AVIF-ben? Lefuttathatom az egész könyvtárat egy kattintással?

Kockázati pontja nem a “tömörítés”, hanem aAz eszközök migrációs szintjének változása：

• A teljes generálás felülírhatja az eredeti képfájl azonosítóját, törölheti az eredeti fájlt, és kicserélheti az URL-t a tartalomban.
  az ok, amiértNem ajánlott rögtön az egész könyvtárat lecserélni.: Először kis léptékben teszteljük (több tíz-száz) + legyen elérhető biztonsági mentés, mielőtt a teljes könyvtár feldolgozását fontolóra vennénk.

7. Mi a választás a Plus WebP két módja között: az eredeti kép megtartása vs. az eredeti kép cseréje és törlése?

Egyszerű megérteni:

• 1. mód: Az eredeti kép megtartása + WebP/AVIF másolat létrehozása (stabilabb): Kényelmes a visszatöltéshez, de a lemez megnő (eredeti kép + új formátum + több méretű miniatűr).
• 2. mód: Az eredeti kép cseréje és törlése (agresszívebb): A lemezek kevésbé hajlamosak a felfúvódásra, de “változó eszközök + változó hivatkozások”, ami drágábbá teszi a kompatibilitási problémák elhárítását.
  Minél összetettebb a webhely (e-kereskedelem/multi plugin/multi méret), annál inkább ajánlott egy stabilabb modellel kezdeni.

8. Elég az EWWWW Image Optimizer ingyenes helyi tömörítés? Túlterheli a szervert?

Az EWWW inkább “helyi kompresszor”: CPU/IO-t eszik.
Gyakori, hogy a terhelés megnő a kötegelt optimalizálás során, ami nem azt jelenti, hogy “nem működik”, hanem azt, hogy a stratégiának megfelelőnek kell lennie: kötegelt, alacsony csúcsok, és szükség esetén offloading/felhő opciók.
Ha megtakarítást szeretne elérni, vagy ha szűkösek a szerver erőforrásai, a B útvonal a szerverbarátabb.

9. ShortPixel 100 ingyenes kredit/hónap, miért érzem úgy, hogy pár kép alatt elfogyott?

a következők miatt A kreditek nem a “képek száma”.”A next-gen a next-gen-nel együtt egy miniatűrrel lesz nagyítva:

• Eredeti kép + minden miniatűr kép kreditnek számít
• WebP/AVIF generálása esetén minden egyes megfelelő verzióhoz további kredit kerül felhasználásra.
  Tehát amit Ön “1 képnek” gondol, az valójában közel “2 számjegyű kreditet” fogyaszt. shortPixel

10. Imagify ingyenes 20MB/hó, miért fogy el az is gyorsan?

Az Imagify inkább egy “forgalmi csomag”:

• Ahogy küldted.Eredeti fájlméreta kvóták levonása
• Minél több miniatűrje van, annál többet fogyaszt
• A tömörítési szint megváltoztatása az újraoptimalizáláshoz ismét fogyasztja a kvótát.
• Ugyanaz az API kulcs több webhelyhez, kvótamegosztás
  Tehát a “20MB hamarosan elfogy” gyakran a túl nagy képek, a túl sok miniatűr kép, vagy az ismételt próbálkozás és hiba okozza.

11. A TinyPNG 500 kredit/hónapig ingyenes, miért mondja a plugin, hogy csak kb. 100 kredit/hónap, majd 50 kredit/hónap a WebP/AVIF-fel?

Mivel a TinyPNG kreditek is a “size/variant” szerint vannak felnagyítva:

• Egy átlagos WordPress telepítés valószínűleg körülbelül 100 lap/hónapot tömörít.
• AVIF vagy WebP konverzió engedélyezése:Minden képméret további kreditet fogyasztÍgy valószínűleg csak körülbelül 50 képet tudsz tömöríteni és konvertálni havonta (a miniatűrök számától függően).
  Tehát 500 kredit ≠ 500 kép.

12. Hány miniatűr van az oldalamon? Miért fontos ez ennyire?

A WordPress többféle méretet generál a kép feltöltéséhez; a témák/pluginok (különösen az e-kereskedelem) több méretet adhatnak hozzá.
A felhőtömörítési kreditek/kvóták általában “eredeti + miniatűrök együtt”, tehát minél több miniatűröd van, annál kevesebb szabad kreditet kell felhasználnod.

13. A lusta betöltés mindig gyorsabb? Miért mondják egyesek, hogy a lusta betöltés lassítja a dolgokat?

A lusta betöltés a “képernyőn kívüli erőforrások” számára alkalmas.
Ha az első képernyőn a legkritikusabb nagy kép is késleltetett betöltése, lelassíthatja az első képernyő élményt. WordPress 5.5 mivel az alapértelmezett lusta betöltése rendben van, de nem “egy méret illik mindenre”.

14. Az A vagy B útvonalon utazom. Mikor van szükségem az CDN / CDN képre?

A tömörítés, a méretezés és a formázás megoldja a “kisebb, megfelelő méretű fájlok” problémáját;
CDN A megoldás az, hogy közelebbi és stabilabb。
Ha a képeket a forrásoldaltól távolabbról húzzák, ami jelentős késleltetést eredményez, akkor az CDN/képek kiegészítése CDN-vel (pl. Cloudflare Polish / Jetpack Site Accelerator) összességében stabilabb lesz, olvassa el WordPress CDN Gyorsítás。

15. Mi a legegyszerűbb módja annak, hogy meggyőződjek arról, hogy “tényleg működik”, ha elkészültem?

A legidőhatékonyabb ellenőrzési módszer:

• Ugyanaz az oldal másodszor is frissül-e, és töltődik-e be következetesebben és gyorsabban.
• A mobiltelefonokon és asztali számítógépeken betöltött képek mérete észrevehetően különbözik (az srcset/méretek is szerepet játszanak)?
• Néhány kép szúrópróbaszerű ellenőrzése: WebP vagy AVIF fájlok/források megléte
• Vegyen mintát néhány képről: nagyítsa ki, hogy lássa, láthatóan zavarosak-e, elmosódott-e a szöveg.