Pag-optimize ng larawan ng website

Nag-aalok ang pag-optimize ng imahe ng pinakamataas na balik sa puhunan para sa pagganap ng WordPress: sa magkaparehong estruktura ng pahina at tema, ang simpleng pag-aayos ng laki, sukat, format, at paraan ng paghahatid ng imahe ay madalas magdulot ng agarang pagpapabuti sa karanasan sa pag-load.

Gayunpaman, ang pag-optimize ng imahe ang pinaka-malamang na magdulot ng sitwasyon kung saan “kapag mas binabago mo, mas lumalala ito.” Hindi dahil masyadong mahirap ang teknik, kundi dahil masyadong pira-piraso ang impormasyon:
Nakabasa ka na ng ilang artikulo at nalaman mo na ang tungkol sa “compression,” “WebP/AVIF,” at “lazy loading.” Pagkatapos, nakita mo sa pagpapakilala ng plugin na sinasabi nitong “100 libreng credits bawat buwan,” “libreng 20MB,” at “1 credit bawat larawan,” kaya lalo ka lang nalito—sapat ba talaga ang libre? Paano ba ang kaltas ng bayad? Baka mali ang pagkaunawa mo sa “iisang bagay”? At ang pinakamahalaga:Talaga bang nagkabisa ito pagkatapos mong matapos?

Ang artikulong ito ay gumagawa lamang ng tatlong bagay:

1. Narito ang isang konkretong hakbang na maaari mong gawin.Gabay na plano(Ano ang gagawin muna, ano ang gagawin pagkatapos)
2. Ipaliwanag nang malinaw ang mga pagpipiliang nais mong piliin (ano mismo ang pinagkaiba ng libreng bersyon at ng bayad na bersyon, at para kanino ang bawat isa).
3. Ilista nang maaga ang mga pinaka-karaniwang bitag (upang hindi ka na magkaproblema sa pag-aayos pagkatapos ng pagkumpleto)

1. Pangunahing bahagi: Ang mga kasama nang default ng WordPress, at ang mga hindi kasama nito

Kung hindi mo muna mauunawaan kung ano na ang naipatupad ng WordPress core, malamang na makatagpo ka ng dalawang senaryo:

• Sa halip na gamitin ang madaling makuhang libreng kakayahan, nasayang lang ang oras at pera namin sa muling paglikha ng gulong.
• Akala ko awtomatikong kokonvertihin ng WordPress ang lahat ng lumang larawan sa WebP/AVIF, pero lumalabas na hindi pala.

Kasama na sa core ng WordPress ang mga mahahalagang kakayahang ito:

• Mga responsive na imahe (srcset/sizes)Mula sa WordPress 4.4 pataas, maglalabas na ng mga imahe ang core. srcset 与 sizesat gamitin ang mga larawang may iba't ibang sukat na nabuo sa pag-upload, na nagpapahintulot sa browser na pumili ng mas angkop na mga mapagkukunan para sa paglo-load batay sa mga kondisyon ng screen.
• Katutubong tamad na pag-loadSimula sa WordPress 5.5, pinapagana nang default ang katutubong lazy loading para sa mga larawan, gamit ang mga pamantayan ng HTML. loading Pagsasakatuparan ng ari-arian.
• Sinusuportahan ang pag-upload ng mga WebP na file.Simula sa WordPress 5.8, pinapayagan na ang pag-upload at paggamit ng mga WebP file na parang JPEG/PNG (basta sinusuportahan ng hosting environment ang WebP).
• Sinusuportahan ang pag-upload ng AVIFSimula sa WordPress 6.5, pinapayagan na ang pag-upload at paggamit ng mga AVIF file sa parehong paraan tulad ng JPEG/PNG (depende sa suporta ng hosting environment).

Gayunpaman, pakitandaan:
“Suporta sa pag-upload/paggamit” ≠ “Awtomatikong pagbabagong-anyo/awtomatikong paghahatid”
Sa madaling salita: kahit na nasa WP 6.5 ka na, hindi awtomatikong magko-convert ang mga JPG/PNG na file sa iyong media library sa WebP/AVIF; at hindi mo rin agad makukuha ang buong kakayahan na “mag-output ng AVIF/WebP batay sa suporta ng browser, habang bumabalik sa orihinal na imahe para sa mga hindi sumusuportang browser” – karaniwang nangangailangan ito ng mga plugin o karagdagang serbisyo upang makumpleto ang solusyon.

2. Balak: Pag-optimize ng larawan sa 5 hakbang

Ano ang gagawin, bakit, ano ang itinuturing na kasiya-siyang pagkumpleto, at ano ang mga karaniwang bitag.

2.1 Tumpakin muna ang mga sukat (pinakamadaling hindi mapansin, ngunit nagbubunga ng pinakamalaking benepisyo)

Maraming mga site ang mabagal hindi dahil hindi naipapatupad ang compression, kundi dahilNa-download ang isang imahe na mas malaki nang malaki kaysa sa lugar ng display.：
Halimbawa, kung ang isang pahina ay talagang ipinapakita lamang sa lapad na 900px, ngunit pinapagawa mo sa mga bisita na i-download ang orihinal na 3000px na imahe, simpleng i-download ito nang buo ng browser bago ito paliitin para ipakita. Sinasayang nito ang bandwidth, pinapataas ang oras ng pag-decode, at pinapabagal ang pag-load ng unang screen.

WordPress 4.4 at pataasMekanismo ng mga responsive na imahe（srcset/sizes) eksaktong upang tugunan ang isyung ito.

Ano ang itinuturing na marka ng paglipas:

• Kapag binubuksan ang pahina sa isang mobile device, dapat na kapansin-pansing mas maliit ang sukat ng na-download na larawan kaysa sa desktop.
• Ang laki ng mapagkukunan ng parehong imahe ay nag-iiba-iba sa iba't ibang aparato (sa halip na palaging mag-download ng orihinal na imahe).

Ang pinakakaraniwang mga patibong:

• Maaaring balewalain ito ng ilang tema o tagabuo sa pamamagitan ng pagtrato sa mga imahe bilang mga background image sa CSS o paggamit ng mga pasadyang paraan ng pag-output. srcsetna nagreresulta sa patuloy na pagda-download ng malalaking larawan
• Sa pamamagitan ng paggamit ng panlabas na serbisyo sa pagho-host ng mga imahe at mga third-party na bloke ng imahe, maaari mong lampasan ang multi-size na sistema na nilikha ng media library.

---

2.2 Kompresyon (Bawasan ang laki ng KB, ngunit huwag isakripisyo ang kalidad)

Ang diwa ng compression ay hindi “mas maliit, mas mabuti”, kundi “halos hindi napapansin ng hubad na mata ang pagkakaiba, ngunit makabuluhang pagbawas sa dami”.

Ang mga patakaran ay ang mga sumusunod:

• Mga litrato/aktwal na kuha (mga portrait, mga produkto, mga tanawin)Unahin ang lossy compression (pinakamalaki ang kita)
• Screenshot/Larawan na may maraming tekstoDapat mas konserbatibo ang compression upang hindi magmukhang malabo ang teksto.
• Logo/IkonUnahin ang SVG o pumili ng lossless na compression (madaling mag-blur ng mga gilid ang lossy na compression)

Ano ang itinuturing na marka ng paglipas:

• Ang laki ng mga larawan sa karamihan ng mga pahina ay lubos na nabawasan.
• Walang kapansin-pansing ingay, malabong mga gilid, colour banding, o pagkalabo ng teksto.

---

2.3 WebP / AVIF (Patakaran sa format: Mas maliit na laki ng file para sa katumbas na kalinawan)

Sinusuportahan na ngayon ng WordPress ang pag-upload. WebP (5.8) at AVIF (6.5)。
Gayunpaman, upang tunay na mailapat ang “format ng susunod na henerasyon” sa praktikal na paggamit, karaniwang kailangang tugunan ang dalawang bagay:

1. Paano mag-batch na mag-convert ng mga makasaysayang media archive(Kung hindi, na-optimize mo lamang ang mga bagong larawang ia-upload sa hinaharap)
2. Dapat bang gumawa ng kopya, o dapat bang palitan ang orihinal na imahe?(Ito ang kritikal na yugto; pagtuunan natin ng pansin mamaya ang pagpapalit at pagbura ng orihinal na imahe ng Plus WebP)

Inirerekomendang pananalita:

• WebP: Karaniwang ito ang default na pinipiling format (nag-aalok ng mas matatag na katugma)
• AVIF: Isang karagdagang hakbang sa compression, angkop para sa malalaking imahe/mga banner sa unang screen/mga larawan ng album (bagaman mas...Umaasa sa suporta ng kapaligiran）

---

2.4 Dapat maayos na ipatupad ang lazy loading (iwasan ang pangkalahatang pamamaraan)

Mula sa WordPress 5.5 pataasAwtomatikong tamad na pag-loadLarawan.
Pinapababa nito ang paggamit ng bandwidth sa paunang pagre-render:

• Ang lazy loading ay angkop para sa mga mapagkukunan na hindi nakikita sa screen.“
• Ang pinakamahalagang imahe sa unang screen (madalas ang pangunahing imahe sa unang screen) ay madalas hindi angkop para sa naantalang pag-load.

---

2.5 Antas ng paghahatid: CDN / Larawan CDN

Ang compression, laki, at format ay tumutugon sa pangangailangan para sa mas maliliit at mas angkop na mga file.
Ngunit kung palaging kinukuha ang mga larawan mula sa pinagmulang site sa malayong distansya, malinaw pa ring maaapektuhan ng pagkaantala sa network ang karanasan. Sa ganitong sitwasyon, kailangan ang solusyon sa “delivery layer” (CDN/larawan CDN).

Dalawang karaniwang pamamaraan:

• Cloudflare Poland：Dokumentasyon ng CloudflareIpinapakilala ng artikulo ang mga pamamaraan ng compression ng Polish (lossless/lossy/WebP) at binabanggit ang paggamit nito format=auto Pinapayagan ang paggamit ng mga format na WebP/AVIF.
• Jetpack Pabilis ng Site：Dokumentasyon ng JetpackI-o-optimize nito ang mga imahe at ipapamahagi ang mga ito kasama ng mga static na mapagkukunan sa pamamagitan ng network nito.

Ang pag-optimize ng imahe ay responsable sa pagbabawas ng laki at pagtiyak ng pagiging angkop.CDN responsable sa mas malapit at mas matatag na paghahatid

3. Pagtatapon: Dalawa lamang sa mga pangunahing ruta ang dapat isakatuparan.

Ang pinakakaraniwang bitag sa pag-optimize ng imahe ay hindi ang “pagkabigong mag-install ng mga plugin”, kundi ang pag-install ng masyadong maraming plugin na nagreresulta sa paulit-ulit na pagpoproseso:
Pinipiga ni A, pinipiga rin ni B; kinokonbert ni A sa WebP/AVIF, kinokonbert din ni B; binabago ni A ang mga URL, muling sinusulat naman ni B ang mga ito—sa huli, hindi mo na nga maipaliwanag kung ano ang nangyayari sa site.

Mga patakaran:

Isang daan lamang ang pasulong: alinman sa ganap na libreng lokal na imbakan, o pag-compress sa cloud na may tatlong pagpipilian.

• Ruta A (ganap na libreng lokal na serbisyo):Dagdag pa ang WebP o AVIF + EWWW Image Optimizer(o pumili lamang ng isa sa kanila)
• Ruta B (Pumili ng isa sa tatlong opsyon sa pag-compress ng ulap):ShortPixel / Imagify / TinyPNG

---

3.1 Ruta A: Ganap na Libre Lokal (Kasama ang WebP o AVIF o EWWW)

Ang mga pangunahing katangian ng rutang ito ay:

• Hindi ka umaasa sa mga third-party na serbisyo ng compression na gumagana batay sa buwanang quota o bawat file (bagaman ang ilang tampok ay maaaring mag-alok ng opsyonal na serbisyo).
• Ang kapalit ay: maaaring mas mabigat sa server ang batch processing na CPU/IO, kaya kailangan mong mas pagtuunan ang “estratehiya at panganib”

3.1.1 Dagdag pa ang WebP o AVIFAng pangunahing konsepto ay “paglikha/pamumalit”, at hindi ito isang “kagamitan sa pag-compress” sa tradisyunal na kahulugan.”

• Kapag gumagawa ng mga larawan na buong resolusyon:Mapapalitan ng WebP/AVIF na file ang ID ng orihinal na image file, mabubura ang orihinal na file, at mapapalitan din ang URL sa loob ng nilalaman.。
• Nagbibigay ang plugin ng mga utos ng WP-CLI at nagpapayo na mas maaasahan ang WP-CLI kapag humahawak ng maraming file.

Ito ay nangangahulugang: hindi ito tahimik na gumagawa ng WebP para sa iyo, kundi maaaring ito ay isang beses na pangyayari.Paglilipat ng Ari-arian(lalo na kapag pinagana mo ang opsyon na “Palitan at burahin ang orihinal na larawan”).

Ang pagkakaiba sa pagitan ng dalawang mode

Mode 1: Panatilihin ang orihinal na imahe + gumawa ng kopya na WebP/AVIF (mas matatag)

• Bentahe: Mas madaling ibalik kung sakaling magkaroon ng mga isyu sa pagiging tugma.
• Gastos: Tataas ang paggamit ng espasyo sa disk (orihinal na imahe + bagong format + thumbnails sa iba't ibang sukat)

Mode 2: Palitan at burahin ang orihinal na imahe (mas radikal)

• Mga kalamangan: Hindi kasing bilis lumalawak ang mga disk; awtomatikong na-convert ang mga panloob na sanggunian sa bagong format.
• Mga panganib: Kapag sabay na binabago ang mga asset at sanggunian, mas nagiging magastos ang pag-troubleshoot ng mga isyu sa compatibility (lalo na kapag umaasa ang mga panlabas na sistema o lohika ng tema sa orihinal na mga pangalan ng file, landas, o format).

Karaniwang mga patibong sa WebP o AVIF

1. Pagkatapos ng kumpletong pagpapalit ng database, ang ilang mga imahe ng pahina ay hindi ipinapakita nang tama.
   Karaniwan, hindi dahil “sirang-sira ang imahe,” kundi dahil may ilang link sa kadena – gaya ng pagpapalit ng URL, pag-cache, o mga estratehiya sa thumbnail – na hindi maayos na naayos.
2. Habang mas marami ang bilang ng mga thumbnail, mas malawak ang saklaw ng mga pagbabago.
   Ang pag-upload ng larawan sa WordPress ay lumilikha ng iba't ibang sukat; maaaring magdagdag pa ng karagdagang dimensyon ang mga tema o plugin. Ang ganap na pagpapalit ay nangangahulugang maaaring binabago mo ang isang malaking koleksyon ng mga file.
3. Ang pagsasagawa ng format migration lamang ay hindi ginagarantiyahan ang pinakamaliit na posibleng bolyum.
   Ang mga file ng WebP/AVIF ay karaniwang mas maliit, ngunit mahalaga pa rin ang “estratehiya sa laki” at “estratehiya sa compression”. Huwag ituring ang Plus WebP bilang “one-click fix”.

---

3.1.2 EWWW Image OptimizerLibreng lokal na solusyon sa compression

Napakalinaw ng posisyon ng pahina ng plugin na EWWW:

• Maaari itong gamitin upang i-optimize ang iyong server gamit ang isang hanay ng mga kasangkapan (jpegtran, optipng, pngout, pngquant, gifsicle, cwebp, atbp.).
• Kung kailangan mo ng mas mataas na compression o mas matipid sa CPU, maaari mo ring ilipat sa server nito ang pagproseso na kumokonsumo ng CPU (opsyonal).

Anong papel ang dapat gampanan ng EWWW sa Ruta A?

Kung ginagamit mo ang Plus WebP para sa estratehiya sa paglilipat o pagpapalit ng format, mas angkop ang EWWW para gawin ito:

• Optimizasyon ng Kompresyon at Dami(lalo na ang pagbabawas ng laki ng mga hilaw na mapagkukunan tulad ng mga JPG/PNG na file)
• Optimizasyon ng maramihang makasaysayang mga silid-aklatan ng media(Nilalayon ang “pagbabawas ng dami” kaysa sa “pamalit ng URL”)

Ang mga klasikong patibong ng EWWW

1. Tumaas ang load ng server habang isinasagawa ang batch optimisation.
   Dahil ang lokal na compression ay talagang kumakain ng CPU/IO. Ang tamang paraan ay hindi “huwag gamitin” kundi “hatiin sa batch, gawin sa off-peak, at kung kailangan ay pumili ng offload/cloud na solusyon”.
2. “Ang paglikha ng mga WebP file ay hindi nangangahulugang ang frontend ang nagse-serbisyo ng WebP.
   Maraming plugin ang naghihirap dahil sa maling akala na ito: ang pagbuo ay isang bagay, ang estratehiya sa paghahatid (muling pagsulat, mga tag ng larawan, mga cache hit, atbp.) ay ibang usapin.
3. Paggaya sa parehong pag-andar ng iba pang mga plugin.
   Kung pipiliin mo ang Ruta A, iwasan ang pag-pila-pila ng mga cloud compressor tulad ng ShortPixel/Imagify/TinyPNG; kung pipiliin mo ang Ruta B, huwag paganahin ang lohika ng pagpapalit ng Plus WebP. Pangunahing prinsipyo:Manatili sa isang paraan ng pagkilos.

---

3.2 Ruta B: Pumili ng isa sa tatlong serbisyo sa pag-compress ng larawan sa cloud (ShortPixel / Imagify / TinyPNG)

Ang rutang ito ay angkop para sa mga nais magtipid sa mga mapagkukunan ng server, mas gusto ang mas walang abalang paraan sa pagproseso nang maramihan, at kumportable sa pay-as-you-go na pagpepresyo.
Gayunpaman, ang pinaka-karaniwang punto ng hindi pagkakaunawaan tungkol sa pag-compress sa cloud ay:Ang libreng allowance ay hindi lamang usapin ng “mga libreng pahina”.Ang bilang ng mga sukat ng thumbnail, kung ginagawa ang mga format na WebP/AVIF, at kung isinasagawa ang paulit-ulit na pagrekompres ay malaki ang epekto sa pagkonsumo ng mga mapagkukunan.

Sa ibaba ipapaliwanag namin kung paano gumagana ang mga libreng at bayad na antas, kung paano nababawas ang mga quota, ang mga pinaka-karaniwang bitag na dapat iwasan, at kung aling uri ng site ang pinakaangkop.

---

3.2.1 Maikling Pixel100 libreng kredito bawat buwan, ngunit mauubos ang mga kredito sa mga thumbnail at pagpapalaki ng WebP/AVIF.

Ano ang deal sa libre/bayad?

Malinaw na nakasaad sa paglalarawan ng plugin ng ShortPixel:

• 100 libreng kredito bawat buwan
• Mayroon ding “karagdagang walang limitasyong buwanang kredito” (ang pahina ng plugin ay nagbibigay ng kaukulang impormasyon sa presyo).
• Nag-aalok din ng “mga pakete ng kredito na isang beses at hindi nag-e-expire” (kasama ang paunang impormasyon tungkol sa presyo)

Tandaan:

• Libreng buwanang paglalaan ng mga kredito para sa magagaan na site o para sa pagsubok.
• Isang beses na pakete: Angkop para sa mga site na may malawak na media library na nais linisin ang imbentaryo nang sabay-sabay (binili para sa isang beses na paggamit lamang, karaniwang walang takdang oras ng pag-expire).
• Buwanang/Walang Hanggan: Angkop para sa mga site na nangangailangan ng tuloy-tuloy na pag-update ng mga imahe at pangmatagalang matatag na optimisasyon.

Tinutukoy din ng opisyal na knowledge base ng ShortPixel ang pagkakaiba sa pagitan ng “one-off packages” at "limitless monthly plans."Malinaw na paliwanagAng walang limitasyong buwanan ay sinisingil buwan-buwan (o taon-taon), nagbibigay ng walang limitasyong credits, at may kasamang nakapirming CDN quota; ang minsanang credits ay hindi nag-e-expire, kaya mas may kontrol ka sa paggamit ayon sa pangangailangan.

Ang pinakamahalagang punto: Paano kinakalkula ang mga kredito ng ShortPixel?

Opisyal na Dokumentasyon ng ShortPixel Diretsahan itong sinabi ni KB:

• Ang pag-upload ng larawan sa WordPress ay lumilikha ng maraming thumbnail;
• Bawat pag-optimize ng thumbnail ay binibilang bilang isang kredito.；
• Kung pipiliin mong gumawa ng WebP o AVIF,Bawat bersyon ng orihinal na imahe sa WebP/AVIF at ang thumbnail nito ay magkakaroon ng karagdagang singil sa kredito.；
• Maaari mong i-exclude ang ilang thumbnail sa optimisasyon upang mabawasan ang pagkonsumo ng credit.

Halimbawa ng mga kredito：

Sabihin nating mag-upload ka ng isang larawan, at ang tema/plugin ay gumagawa ng walong thumbnail:

• Optimizasyon ng orihinal na imahe + mga thumbnail lamang: 1 (orihinal na imahe) + 8 (mga thumbnail) = 9 kredito
• Kung kinakailangan din ang paglikha ng WebP/AVIF: magdagdag ng isang susunod na henerasyong bersyon para sa bawat isa sa siyam na nabanggit na format → pagkatapos ay magdagdag ng karagdagang siyam na kredito.
  Sa madaling salita, ang sa tingin mong “isang imahe” ay maaaring kumonsumo ng halos “dalawang-digit na kredito”.

Kaya:“Ang ”Libreng 100 kredito“ ay hindi katumbas ng ”libreng 100 larawan".

Pinakakaraniwang mga bitag ng ShortPixel

1. Mabilis maubos ang libreng 100 credits.
   Pangunahing sanhi: maraming thumbnail at karagdagang kredito ang kinakailangan para sa paglikha ng WebP/AVIF.
   Rekomendasyon：

• Una, suriin ang bilang ng mga thumbnail sa site.
• Alisin ang mga hindi kinakailangang sukat ng thumbnail (i-optimize lamang ang mga sukat na talagang gagamitin)
• Una, tukuyin muna ang estratehiya sa compression bago magpatakbo nang maramihan, upang maiwasan ang paulit-ulit na pagsubok at pagkakamali na kumokonsumo ng mga mapagkukunan.

2. Sabay na mag-overlay ng iba pang mga plugin para sa pag-convert ng format.
   Kung i-enable mo pareho ang Plus WebP replacement at ang pagbuo/pagsingit ng next-gen tags ng ShortPixel, mag-ooverlap ang lohika, na magpapahirap sa pag-troubleshoot. Sa Ruta B, hayaan mo na lang ang ShortPixel na hawakan ito nang mag-isa.
3. Ang pag-aakala na ang simpleng pag-install nito ay ginagarantiyahan na ang frontend ay nagse-serve ng WebP/AVIF.“
   Pahina ng Plugin ng ShortPixelMaaari nitong i-convert ang mga format na WebP/AVIF at isama ang mga susunod na henerasyong imahe sa mga front-end na pahina (halimbawa, sa pamamagitan ng pag-tag).
   Gayunpaman, kapag nakumpleto na, kailangang beripikahin pa rin ang mga resulta.

---

3.2.2 ImahinifyLibre 20MB/buwan; ibabawas ang quota batay sa “laki ng orihinal na larawan + bilang ng thumbnail”, at ang muling pag-compress ay muling magbabawas

Libreng allowance at pagposisyon

Opisyal na Pahina ng Presyo ng ImagifyNakasulat nang malinaw:Libreng account buwan-buwan 20MB quota。
Malinaw ding nakasaad sa pahina ng plugin nito na kaya nitong mag-compress, mag-resize, at mag-convert ng mga WebP/AVIF na file.

Paano binabawas ang mga quota?

Opisyal na Dokumentasyon ng Imagify “Paano Kinakalkula ang Paggamit ng Quota? ay malinaw na nagpapaliwanag ng mekanismo ng pagbabawas:

• Ang bilang ng mga thumbnail ay nakakaapekto sa pagkonsumo.Halimbawa, kung mayroon kang 10 sukat ng thumbnail, ang pag-optimize ng isang imahe ay nagiging pag-optimize ng 11 imahe (ang orihinal na imahe at 10 thumbnail), na lahat ay nag-aambag sa pagkonsumo ng quota.
• Ibawas ang quota batay sa orihinal na laki ng file.Halimbawa, kung magpapadala ka ng 100KB na imahe sa Imagify, mababawas ang 100KB mula sa iyong quota.
• Ang pagbabago ng antas ng compression at muling pag-optimize ay muling kakain sa quota.。
• Maaaring gamitin ang parehong API key sa maraming site, ngunit ang mga quota ay paghahatiin ng mga site na ito.

Ito ang “pangunahing pamamaraan ng pag-unawa” ng Imagify:
Mas parang pakete ng datos ito: kung anong allowance ang ibibigay mo, iyon ang kakainin nito; habang mas maraming thumbnail ang ginagawa mo, mas marami itong ibabawas; ang paulit-ulit na mabigat na compression ay magdudulot ng paulit-ulit na pagbabawas.

Mga halimbawa ng quota ng Imagify na madaling maunawaan

Sabihin mong nag-upload ka ng orihinal na larawan na 800KB, at gumagawa ang site ng walong thumbnail.

• Kapag nag-o-optimize gamit ang Imagify, kasama ang orihinal na imahe at walong thumbnail (kung pipiliin mo ang “Optimise All”). Ibig sabihin, ang isang operasyong ito ay kakain ng halagang quota na halos katumbas ng kabuuang orihinal na laki ng lahat ng mga file na ito.
  Ito ang dahilan kung bakit pakiramdam ng ilang site na “mabilis maubos ang 20MB”: hindi dahil kulang ang Imagify, kundi dahil masyadong malalaki ang mga larawang ina-upload mo sa bawat pagkakataon, masyadong marami ang mga thumbnail, at posibleng paulit-ulit mo pang sinusubukan ang antas ng compression.

Karaniwang mga patibong sa Imagify

1. Libre ang 20MB, hindi sapat para gawin ang Buong-site na makasaysayang paglilinis ng database“
   20MB ay karaniwang mas angkop para sa pagsubok at magagaang pag-update; kung malaki na talaga ang media library mo, malamang na kakailanganing mag-upgrade kung lilinisin mo ito nang minsanan.
2. Ang paulit-ulit na pagsasaayos sa antas ng compression ay nagreresulta sa paulit-ulit na pagkonsumo ng quota.
   Malinaw na sinasabi ng ImagifyMuli na namang kakainin ng reoptimisation ang quota.
   Ipinapayo na malinaw na ilahad ang estratehiya sa pahinang ito:

• Una, tukuyin ang antas ng compression at kalidad ng visual gamit ang ilang larawan.
• Tapusin ang estratehiya bago patakbuhin nang maramihan.
  Iwasan ang paulit-ulit na pagsubok at pagkakamali sa buong database.

3. Ang pagbabahagi ng mga API key sa iba't ibang site ay nagdudulot ng misteryosong pagbaba ng mga quota.“
   Kung gagamit ka ng parehong API Key sa iba't ibang site, magkakabahagi ang mga quota.
   Kaya naman, sa mga senaryo ng koponan o maramihang lokasyon, mainam na malinaw na tukuyin kung aling mga lokasyon ang magbabahagi ng mga mapagkukunan at alin ang mag-ooperate nang mag-isa, upang maiwasan ang hindi makontrol na paggasta.

---

3.2.3 Maliit na PNG(Maliit na Pag-compress ng Larawan): Libreng 500 kredito bawat buwan; ang pag-convert sa WebP/AVIF ay nagkakahalaga ng karagdagang 1 kredito bawat sukat.“

Libreng allowance at ang pamamaraan ng pagsingil nito

Ang pahina ng TinyPNG WordPress plugin ay nakasulat nang napakalinaw:

• 500 libreng kredito bawat buwan
• Sa isang “karaniwang pag-install ng WordPress”, maaari itong ma-compress ng humigit-kumulang Mga humigit-kumulang 100 larawan bawat buwan
• Gayunpaman, kung naka-enable ang konbersyon sa AVIF o WebP:Bawat sukat ng larawan ay magkakaroon ng karagdagang singil sa kredito.Kaya marahil maaari lamang itong i-compress at i-convert. Mga 50 larawan bawat buwan(Depende sa kung ilang laki ng thumbnail ang mayroon ka).

Samantala, inihayag din ng Tinify (developer ng TinyPNG/TinyJPG) sa kaniyang Pahina ng Presyo ng APITandaan: Magrehistro upang makatanggap ng 500 libreng compression bawat buwan. Lampas sa limitasyong ito, may bayad batay sa bilang ng matagumpay na compression, nang walang kinakailangang subscription.

Upang buodin ang TinyPNG sa isang pangungusap:
Gumagana ito sa isang sistemang nakabatay sa kredito; habang mas maraming sukat ng thumbnail ang ginagamit mo at mas maraming format na WebP/AVIF ang pinapagana mo, mas mabilis mauubos ang iyong mga kredito.

Isang madaling maunawaan na halimbawa ng mga kredito ng TinyPNG

Sabihin na ang iyong site ay gumagawa ng walong sukat ng thumbnail para sa bawat larawan:

• Compression lamang: Orihinal na imahe + 8 thumbnail → Nangangailangan ng 9 na kredito
• Kung naka-enable ang konbersyon sa WebP/AVIF: May karagdagang bawas sa kredito para sa bawat sukat → Maaaring halos madoble ang gastos.
  Ito ay eksaktong tumutugma sa paglalarawan ng pahina ng plugin: kapag na-enable ang conversion, nagbabago ang libreng quota mula sa humigit-kumulang “100 larawan bawat buwan” patungong “50 larawan bawat buwan”.

Karaniwang mga patibong sa TinyPNG

1. Kung ipagpapalagay na 500 kredito = 500 larawan
   Hindi. Gumagamit ito ng mga kredito batay sa “sukat/bersyon ng imahe”. Malinaw na nakasaad sa pahina ng plugin: “Ang konbersyon ay magbabawas ng karagdagang 1 kredito para sa bawat sukat ng imahe”.
2. Ang tema/e-commerce plugin ay lumilikha ng labis na sukat, na nagreresulta sa kapansin-pansing pagbawas ng libreng quota.
   Habang mas malaki ang sukat, mas madaling dumami at magamit ang mga kredito.
3. Matapos i-enable ang konbersyon, napansin kong biglang hindi na sapat ang credit limit.
   Hindi ito bug; ito ang mekanismo ng pagsingil nito.
   Mga Estratehikong Rekomendasyon:

• Kung ang libreng tier ay pangunahing ginagamit para sa compression at pagbabawas ng bigat, maaari mong pansamantalang ituon lamang ang pansin sa compression. Kapag nakumpirma mo nang matatag ang estruktura ng site at talagang kinakailangan ang next-gen compression, maaari mo nang simulan ang konbersyon.

4. Mga Rekomendasyong Batay sa Konteksto: Paano Pumili para sa Iba't Ibang Uri ng Site

Bagaman lahat ay tumatakbo sa WordPress, ang mga site ng nilalaman, mga plataporma ng e-commerce, mga portfolio, at mga site ng miyembro ay bawat nagdudulot ng natatanging mga hamon kaugnay ng mga imahe.

4.1 Mga website/blog na nakatuon sa nilalaman (may maraming larawan bawat artikulo at katamtamang dalas ng pag-update)

Mga prayoridad na rekomendasyon:

1. Estratehiya sa Dimensyon (Hakbang 1)
2. Kompresyon (Hakbang 2)
3. WebP (Hakbang 3)

Mas angkop na ruta:

• Para sa walang abalang opsyon: Pumili ng isa sa tatlong alternatibo (ShortPixel / Imagify / TinyPNG)
• Pumili ng libre: Ruta A (Plus WebP + EWWW), ngunit inirerekomenda na magsimula sa pagsusuri ng mga panganib sa “conservative mode (nang hindi binubura ang mga orihinal na imahe)”.

Karaniwang mga bitag:

• Napakalaki ng header image ng artikulo, at hindi angkop ang estratehiya ng lazy-loading.Magpapabagal sa unang screen

4.2 Mga Site ng E-commerce/Produkto (Maraming thumbnail, iba't ibang baryante ng imahe, pinakamahalaga ang katatagan)

Ang pinaka-karaniwang mga isyu sa e-commerce ay hindi nagmumula sa “mahinang resulta ng compression”, kundi sa “maling sukat pagkatapos ng optimisasyon, nawawalang thumbnails, o pagkabigo ng mga front-end na bahagi na kunin ang mga larawan”.

Mga prayoridad na rekomendasyon:

1. Magpatuloy nang maingat: gumamit ng konserbatibong pamamaraan sa mga estratehiya sa compression; iwasang agad na isagawa ang buong pagpapalit ng database.
2. Pagsusuri sa sukat ng thumbnail: Karaniwang lumilikha ang mga tema ng e-commerce ng mas maraming sukat, na nagpapalaki sa paggamit ng quota (lalo itong kapansin-pansin sa ShortPixel/TinyPNG).
3. Magsagawa ng maliliit na pag-validate bago palawakin (napakahalaga)

Mas angkop na ruta:

• Ang Ruta B ay kadalasang mas tuwiran: sinusuportahan ng ShortPixel, Imagify, at TinyPNG ang batch processing. Ang susi ay maunawaan ang kanilang mekanismo ng quota at tasahin ang mga gastos nang maaga.
• Posible rin ang Ruta A, ngunit kailangang mag-ingat nang higit kaugnay sa pag-uugali ng Plus WebP na “paglalagpas sa mga ID/pagtatanggal ng mga orihinal na imahe/pamumalit ng mga URL”: itinuturing itong paglilipat ng mga asset, at hindi inirerekomenda na isagawa ang malawakang pagpapalit mula pa sa simula.

4.3 Portfolio/Website ng Potograpiya (Maselan sa kalidad ng bawat imahe, malalaking laki ng file, mataas na pamantayan sa biswal)

Mga prayoridad na rekomendasyon:

1. Estratehiya sa Dimensyon (Kontrol sa Lugar ng Pagpapakita)
2. Estratehiya sa compression (mas mabuting magkamali sa bahagyang mas malaki kaysa sa mawalan ng detalye)
3. WebP/AVIF (nagbibigay ng makabuluhang benepisyo para sa malalaking larawan, bagaman ang kalidad ng biswal ay kailangang beripikahin)

Mas angkop na ruta:

• ImahinifyAng paglalaan ng mga quota batay sa “orihinal na laki ng imahe” ay ginagawang mas angkop ang mga ganitong site para sa “kontrol sa badyet” (dahil alam mo nang halos kung magkano ang kakainin ng bawat malaking imahe), ngunit iwasan ang paulit-ulit na muling pagkompresyon.
• Maikling PixelKung limitado ang bilang ng mga sukat ng thumbnail, nananatiling kontrolado ang paggamit ng kredito; gayunpaman, kapag gumagawa ng maraming sukat kasabay ng mga next-gen na asset, tumataas nang malaki ang paggamit ng kredito, kaya kinakailangan ang maagang pagpaplano.

5. Paghahambing ng Allowance/Billing: Pagpapaliwanag Kung Sapat na ang Libreng Allowance

Alin ang mas sulit sa gastos, at gaano katagal tatagal ang libreng panahon?

5.1 Tatlong Modelo ng Pagbawas ng Bayad

• Maikling Pixel(mga kredito)Kinakalkula ang mga kredito batay sa bilang ng mga orihinal na imahe at mga thumbnail; ang paglikha ng mga bersyon ng WebP/AVIF ay magdudulot ng karagdagang pagbawas sa kredito para sa bawat katugmang format.
• Imahinify(Quota ng MB)Ang pagbawas sa quota ay batay sa orihinal na laki ng file; kapag mas maraming thumbnail, mas malaki ang pagbawas; ang muling pag-compress ay magdudulot ng karagdagang pagbawas.
• Maliit na PNG(mga kredito): 500 kredito bawat buwan; ang pagpapagana ng pag-convert sa WebP/AVIF ay magkakaroon ng karagdagang kredito depende sa laki ng imahe.

5.2 Mga Paraan ng Mabilisang Tinatayang Pagtataya

Maaari mong tantiyahin ito ng sumusunod:

1. Maghanap lang ng isang “orihinal na larawang madalas mong i-upload” at tingnan kung gaano ito kalaki (hal. 300KB / 1MB / 3MB)
2. Tantiyahin ang humigit-kumulang bilang ng mga sukat ng thumbnail na ginagawa ng iyong site (hal., 5 / 10 / 20)
3. Tukuyin kung lilikhain ang WebP/AVIF (Oo/Hindi)

Pagkatapos, gamitin ang sumusunod na “mental arithmetic” upang maunawaan ang konsumo:

• Maikling PixelBawat imahe ≈ (1 + bilang ng mga thumbnail) kredito; Kung gumagawa ng WebP/AVIF, ≈ halos doble ng halagang iyon (dahil nangangailangan din ng kredito ang mga susunod na henerasyong bersyon).
• ImahinifyBawat imahe ay binibilang sa quota bilang (sukat ng orihinal na imahe + kabuuang sukat ng lahat ng thumbnails). Ang pag-aayos ng antas ng compression at muling pag-compress ay magdudulot ng karagdagang pagbawas sa quota.
• Maliit na PNGLibre: 500 kredito; kung ang iyong site ay gumagawa ng maraming sukat ng imahe bawat isa at naka-enable ang conversion, malaki ang pagbawas sa libreng allowance (ang pahina ng plugin ay nagbibigay ng madaling tantiya na “mga 100 imahe bawat buwan” kumpara sa “mga 50 imahe bawat buwan”).

6. Pahayag ng Panganib

Panganib 1: Iwasan ang pagkakaroon ng maraming plugin na paulit-ulit na gumagawa ng parehong tungkulin.

Ito ang pinaka-karaniwang pinagmumulan ng sakuna.“

• Ruta A:Dagdag pa ang WebP o AVIF + EWWW(Hatiin ang mga responsibilidad sa pagitan ninyong dalawa; huwag isagawa nang sabay ang magkaparehong pagbabagong-anyo at paghahatid, o mag-install lamang ng isa sa mga ito.)
• Ruta B: ShortPixel / Imagify / TinyPNG Pumili ng isa sa tatlo(Pumili ng isa na responsable sa compression at sa susunod na henerasyon)

Panganib 2: Ang kakayahan ng Plus WebP na “override ID / burahin ang orihinal na imahe / palitan ang URL” ay itinuturing na migrasyon ng asset.

Muli, kailangang bigyang-diin:Dagdag pa ang WebP Malinaw na nakasaad sa paglalarawan na sa buong pagbuo, mapapalitan ang orihinal na ID ng imahe, mabubura ang orihinal na file, at mapapalitan ang URL ng nilalaman.
Ito ay nangangahulugang hindi ito isang maliit na pagsasaayos na madaling mababaliktad, kundi isang pagbabago sa antas ng asset.

Ang inirerekomendang estratehiya ay dapat:

• Paunang maliliit na pagsubok (dosenang hanggang daan-daang item)
• Kumpirmahin na maayos na gumagana ang display sa harap, ang mga thumbnail, at ang pag-update ng cache.
• Isaalang-alang ang pagpoproseso ng buong database.

Panganib 3: Ang aktwal na paggamit ng libreng allowance sa cloud compression ay nakadepende sa bilang ng mga thumbnail at mga opsyon ng susunod na henerasyon na pinili.

• Maikling PixelMalaki ang magiging epekto ng thumbnails at ng susunod na henerasyon sa mga kredito.
• Maliit na PNGAng pagpapagana ng WebP/AVIF ay magdudulot ng karagdagang pagbawas ng kredito para sa bawat laki ng larawan.
• Imahinify: Magbawas ayon sa orihinal na sukat ng imahe; habang mas maraming thumbnail, mas malaki ang bawas. Ang matinding compression ay magreresulta sa paulit-ulit na pagbabawas.

Panganib 4: Ang “Nilikhang WebP/AVIF” ay hindi katumbas ng “Paghatid ng WebP/AVIF sa frontend”

Maraming gumagamit ang nag-uulat na pakiramdam nila ay hindi naging mas mabilis ang kanilang site matapos ang conversion, na ang ugat ng problema ay patuloy na naglalabas ang frontend ng mga JPG/PNG na file (dahil sa hindi pagtutugma sa anumang yugto ng proseso: caching, rewriting, tags, o browser negotiation).

7. Paano ko masusuri kung naging epektibo na ito matapos makumpleto ang gawain?

Apat na napakasimpleng punto ng beripikasyon:

1. Kapag in-refresh ang parehong pahina nang pangalawang beses, mas matatag at mas mabilis ba ang proseso ng paglo-load?(Perceived effectiveness of caching and optimisation)
2. May kapansin-pansing pagkakaiba ba sa sukat ng imahe kapag ina-load sa mobile at desktop?(Tugon) srcset/sizes Kung ito ay epektibo
3. Suriin nang mabilis ang ilang mga imahe: Mayroon bang mga WebP o AVIF na file/mapagkukunan?Talaga bang ginagamit ito ng site? susunod na henerasyon）
4. Suriin nang mabilis ang ilang larawan: mag-zoom in upang matukoy kung ang mga ito ay kitang-kitang malabo o kung ang teksto ay malabong makita.(Sobra ba ang kalidad ng compression?)

Kung natutugunan ang lahat ng apat na pamantayan, ipinapahiwatig nito na ang rutang pinili mo ay gumagana na. Magpatuloy sa susunod na hakbang. Antas ng paghahatid“Mapapalakas ang pangkalahatang katatagan.

8. Mga Rekomendasyon para sa Aksyon

1. Una, piliin ang iyong ruta:

• Gusto kong panatilihing libre ito hangga't maaari.Dagdag pa ang WebP o AVIF + EWWW (o mag-install ng isa lang sa mga ito)
• Upang makatipid sa mga mapagkukunan ng server at maranasan ang kapanatagan ng isip na dulot ng pagbabayad ayon sa quotaPumili ng isa mula sa ShortPixel / Imagify / TinyPNG

2. Isagawa ang isang maliit na pagsubok (ilang dosenang item)
3. Siguraduhin na ayos ang lahat bago isagawa ang batch.
4. Kinakailangan pa ng karagdagang pagpapabuti upang mapabuti ang katatagan ng paghahatid:Pagbabasa CDN Pagpabilis

Madalas Itanong na Mga Katanungan

1. Ilan ba ang dapat kong i-install na plugin? Pwede ko ba silang lahat i-install?

Subukang manatili sa isang ruta.

• Route A: Plus WebP o AVIF + EWWW Image Optimizer (o mag-install lamang ng isa sa mga ito)
• Ruta B: Pumili ng isa mula sa ShortPixel / Imagify / TinyPNG
  Ang pagkakaroon ng maraming plugin na sabay-sabay na nagsasagawa ng “compression/conversion sa WebP/AVIF/pagbabago ng URL/muling pagsulat ng paghahatid” sa loob ng iisang site ay malamang na lalong maging magulo at ang pinakamahirap ayusin.

2. Hindi ba sinusuportahan na ng WordPress ang WebP/AVIF? Kailangan ko pa ba ng plugin?

Kinakailangan na pag-ibahin:
“Suporta sa pag-upload/paggamit” ≠ “Awtomatikong pagbabagong-anyo/awtomatikong paghahatid”
Hindi awtomatikong magko-convert nang maramihan ang WordPress 6.5 ng mga lumang JPG/PNG file sa WebP/AVIF, at hindi rin nito awtomatikong hahawakan ang buong daloy ng trabaho ng “pag-output ng AVIF/WebP batay sa kakayahan ng browser na may fallback”. Upang mai-update ang mga lumang media library, karaniwang kailangan ng mga plugin o serbisyo upang makumpleto ang proseso.

3. Sa pag-optimize ng imahe, aling hakbang ang nag-aalok ng pinakamataas na balik sa pamumuhunan?

Karaniwan itong Una, itama ang mga sukat (srcset/sizes)。
Maraming site ang mabagal tumakbo hindi dahil kulang sila sa compression, kundi dahil ipinapakita ng mga pahina ang 900px lamang habang pinipilit ang mga gumagamit na mag-download ng buong 3000px na imahe. Nakakatipid ng kilobyte ang compression, ngunit ang hindi tugmang sukat ay maaaring mag-aksaya ng ilang beses na dami nito sa hindi kinakailangang pagda-download.

4. Paano ko masisiguro na ang larawang kasalukuyang ina-load ay ang “mas maliit”, sa halip na palaging ina-download ang orihinal?

Obserbahan ang dalawang penomena:

• Kapag binubuksan ang pahina sa isang mobile device, kapansin-pansin na mas maliit ang sukat ng na-download na larawan kaysa sa desktop.
• Nag-iiba ang laki ng mapagkukunan ng parehong imahe kapag na-load ito sa iba't ibang aparato.
  Kung palaging na-download ang mga orihinal na imahe, karaniwang sanhi nito ay itinuturing ng tema o tagabuo ang imahe bilang background na imahe sa CSS o pasadyang output, kaya nalalampasan ang multi-size at srcset na kakayahan ng media library.

5. Ang “generated WebP/AVIF” ba ay nangangahulugang ang frontend ay nagpo-output ng WebP/AVIF?

Hindi ito pareho sa.
Ang generation ay simpleng pagkumpleto ng “file layer”; kung ang frontend ay talagang nagse-serve ng WebP/AVIF ay nakadepende sa mga salik tulad ng muling pagsulat, estratehiya sa picture tag, mga cache hit, at bisa ng browser negotiation. Kapag tapos ka na, kailangan mong “suriin nang pabirong ang uri ng mga mapagkukunan ng ilang mga imahe”.

6. Ano nga ba talaga ang panganib ng WebP o AVIF? Maaari ko bang gawin ang one-click na conversion sa buong library?

Ang punto ng panganib nito ay hindi “pagkikompres”, kundiPagbabago ng Antas ng Paglilipat ng Ari-arian：

• Sa buong pagbuo, maaaring masulat sa ibabaw ang ID ng orihinal na file ng imahe, mabura ang orihinal na file, at mapalitan ang mga URL sa loob ng nilalaman.
  KayaHindi inirerekomenda na palitan agad ang buong database.Una, magsagawa ng maliliit na pagsubok (dosenang hanggang daan-daang tala) at tiyaking may mga backup bago isaalang-alang ang buong pagpoproseso ng database.

7. Paano pumili sa pagitan ng dalawang mode para sa Plus WebP: Panatilihin ang orihinal na imahe vs Pinalitan at burahin ang orihinal na imahe?

Sa simpleng salita:

• Mode 1: Panatilihin ang orihinal na imahe + gumawa ng kopya na WebP/AVIF (mas matatag)Maginhawa para sa pagbabalik sa dati, ngunit tataas ang espasyo sa disk (orihinal na imahe + bagong format + thumbnail na iba't ibang sukat).
• Mode 2: Palitan at burahin ang orihinal na imahe (mas radikal)Hindi madaling makamit ang pagpapalawak ng disk, ngunit kapag sabay mong binabago ang mga asset at mga sanggunian, lumilitaw ang mga isyu sa pagiging tugma na nagpapataas nang malaki sa gastos ng pag-troubleshoot.
  Habang mas kumplikado ang site (e-commerce/maraming plugin/iba't ibang sukat), mas mainam na magsimula sa mas matatag na pamamaraan.

8. Sapat na ba ang libreng lokal na compression na inaalok ng EWWW Image Optimizer? Maaari ba itong magdulot ng sobrang pasanin sa server?

Mas parang “lokal na compression worker” ang EWWW: kumokonsumo ng CPU/IO.
Karaniwan na tumataas ang load sa panahon ng batch optimisation. Hindi ito nangangahulugang hindi sapat ang pamamaraan, kundi dapat angkop ang estratehiya: magpatupad nang paisa-isa sa mga oras na hindi mataas ang demand, at pumili ng pag-unload o solusyong cloud kapag kinakailangan.
Kung naghahanap ka ng solusyong walang abala o nakakaranas ka ng kakulangan sa mapagkukunan ng server, mas episyente sa server ang Ruta B.

9. Ang 100 libreng kredito ng ShortPixel bawat buwan – bakit pakiramdam ko naubos na ito pagkatapos ng ilang larawan lang?

Dahil Ang mga kredito ay hindi ang bilang ng mga larawan.“Mababawasan sa mga thumbnail at pagpapalaki para sa susunod na henerasyon:

• Ang orihinal na imahe at bawat thumbnail ay binibilang bilang kredito.
• Kung nabuo ang WebP/AVIF, ang bawat katugmang bersyon ay magkakaroon ng karagdagang pagkonsumo ng kredito.
  Kaya't maaaring isipin mong ang “1 larawan” ay maaaring kumonsumo ng halos “dalawang-digit na kredito”. ShortPixel

10. Bakit mabilis ding maubos ang libreng 20MB/buwan ng Imagify?

Ang Imagify ay mas kahawig ng isang “data package”:

• Ayon sa iyong mensaheOrihinal na laki ng filebawas sa quota
• Mas maraming thumbnail, mas mataas ang konsumo.
• Ang pagbabago ng antas ng compression para muling i-optimize ay muling kukuha ng quota.
• Isang API key lamang ang ibinabahagi sa maraming site, at ang mga quota ay ibinabahagi nang naaayon.
  Kaya ang “20MB ay mabilis maubos” ay kadalasang dulot ng masyadong malalaking larawan, napakaraming thumbnail, o paulit-ulit na pagsubok at pagkakamali.

11. Nag-aalok ang TinyPNG ng 500 libreng kredito bawat buwan, kaya bakit sinasabi ng plugin na mga 100 lamang na larawan bawat buwan? At bakit bumababa ito sa 50 na larawan bawat buwan pagkatapos i-enable ang WebP/AVIF?

Dahil ang mga kredito ng TinyPNG ay pinalalaki rin ng “size/variant”:

• Karaniwang kinokompres ng isang karaniwang pag-install ng WordPress ang humigit-kumulang 100 larawan bawat buwan.
• I-enable ang konbersyon ng AVIF o WebP:Bawat sukat ng larawan ay magkakaroon ng karagdagang singil sa kredito.Kaya malamang na posible lamang mag-compress at mag-convert ng humigit-kumulang 50 larawan bawat buwan (depende sa bilang ng mga sukat ng thumbnail).
  Kaya, 500 kredito ≠ 500 larawan.

12. Ilan ang mga thumbnail sa aking site? Bakit ito may napakalaking epekto?

Ang pag-upload ng larawan sa WordPress ay lumilikha ng iba't ibang sukat; ang mga tema at plugin (lalo na ang mga pang-e-commerce) ay maaaring magdagdag pa ng karagdagang sukat.
Karaniwang kinakalkula ang mga kredito/kwota para sa pag-compress sa cloud bilang “orihinal na imahe + pinagsamang thumbnail”, kaya kapag mas marami ang thumbnail, mas hindi tatagal ang libreng allowance.

13. Palagi bang pinapabilis ng lazy loading ang mga bagay? Bakit sinasabi ng iba na pinapabagal pa nga nito ang mga bagay?

Ang lazy loading ay angkop para sa mga mapagkukunan na hindi nakikita sa screen.
Kung ang pinakamahalagang malaking imahe sa unang screen ay naantala rin, maaari nitong pabagalin ang paunang karanasan sa paglo-load. Bagaman karaniwang katanggap-tanggap ang default na lazy loading ng WordPress 5.5, iwasan ang pangkalahatang pamamaraan.

14. Kailan ko kailangan ang CDN / larawan CDN kung dadaan ako sa rutang A o B?

Ang compression, laki, at format ay tumutugon sa pangangailangan para sa “mas maliliit at mas angkop na mga file”;
CDN ang solusyon para sa mas malapit at mas matatag na paghahatid。
Kapag ang mga larawan ay kinukuha mula sa pinagmulang site sa malayong distansya at nagdudulot ng kapansin-pansing pagkaantala, ang pagdaragdag pa ng CDN/larawan CDN (halimbawa, Cloudflare Polish / Jetpack Site Accelerator) ay magiging mas matatag sa kabuuan, para sa pagbabasa Pagbilis ng WordPress CDN。

15. Ano ang pinakasimpleng paraan para masiguro na talagang gumagana ito pagkatapos kong gawin?

Ang pinaka-makatipid sa oras na pamamaraan ng beripikasyon:

• Kapag in-refresh ang parehong pahina nang pangalawang beses, mas matatag at mas mabilis ba ang proseso ng paglo-load?
• May kapansin-pansing pagkakaiba ba sa sukat ng imahe sa pagitan ng paglo-load sa mobile at desktop (nag-uugnay ba nang tama ang srcset/sizes ayon sa inaasahan)?
• Suriin nang mabilis ang ilang mga imahe: Mayroon bang mga WebP o AVIF na file/mapagkukunan?
• Suriin nang mabilis ang ilang larawan: mag-zoom in upang matukoy kung ang mga ito ay kitang-kitang malabo o kung ang teksto ay malabong makita.