Veebisaidi pildi optimeerimine

Piltide optimeerimine on üks WordPressi jõudluse kõige “tasuvamaid” aspekte: sama lehe struktuuri ja teema puhul, kui pildi suurus, mõõtmed, vorming ja edastamine on õiged, paraneb laadimiskogemus kohe.

Kuid pildi optimeerimine on ka kõige lihtsam viis teha jama, mitte sellepärast, et see oleks tehniliselt liiga raske, vaid sellepärast, et teave on liiga killustatud:
Lugesid paar artiklit ja said teada, et vaja on “tihendamist”, “WebP/AVIF-i” ja “laiska laadimist”, siis vaatasid plugina tutvustust, kus öeldi veel “100 tasuta krediiti kuus”, “tasuta 20MB” ja “1 krediit pildi kohta”, aga mida rohkem vaatad, seda segasemaks läheb — kas tasuta mahust üldse piisab? Kuidas tasu maha arvestatakse? Kas said “samast asjast” valesti aru? Ja kõige tähtsam:Kas see mõjus tegelikult pärast seda, kui sa seda tegid, või mitte?

See artikkel teeb ainult kolm asja:

1. Anda teile käivitatavteekaart (ka joonis)(Mida teha kõigepealt, mida teha teiseks)
2. Ole selge, millist varianti valid (mis vahe on tasuta/maksulisel ja kellele kumbki sobib).
3. Kirjutage kõige levinumad lõkse ette (nii et te ei pea vigade kõrvaldamiseks ringi otsima, kui olete lõpetanud).

1. Kokkuvõte: mida WordPress sisaldab ja mida mitte

Kui te ei saa kõigepealt aru, mida WordPressi tuum juba teeb, on lihtne teha ühte kahest asjast:

• Selle asemel, et kasutada “vaba võimsust”, mida te peaksite nautima, kulutate aega/maksate raha, et ehitada ratast ikka ja jälle.
• Ma arvasin, et WordPress “konverteerib kõik vanad pildid automaatselt WebP/AVIF-i”, kuid selgub, et see ei tee seda!

WordPressi tuumik sisaldab neid peamisi sisseehitatud võimeid:

• Responeeruvad pildid (srcset/size): Alates WordPressi versioonist 4.4 väljastab tuum piltide jaoks pilte srcset 与 sizesja kasutab üleslaadimise käigus loodud mitmesuuruseid pilte, et võimaldada brauseril valida sobivam ressurss laadimiseks vastavalt ekraani tingimustele.
• Native laisk laadimine: WordPress alates versioonist 5.5 võimaldab vaikimisi piltide laisket laadimist, kasutades HTML-standardeid. loading atribuudi rakendamine.
• WebP üleslaadimise tugi: Alates WordPressi versioonist 5.8 saab WebP-d üles laadida ja kasutada JPEG/PNG-na (eeldusel, et teie veebimajutuskeskkond toetab WebP-d).
• AVIF-i üleslaadimise tugi: Alates WordPressi versioonist 6.5 saab AVIF-i üles laadida ja kasutada JPEG/PNG-na (sõltub ka hostingu toetusest).

Kuid pöörake tähelepanu:
“Üleslaadimise/kasutamise tugi” ≠ “Automaatne konverteerimine/automaatne edastamine”.
See tähendab, et isegi kui sa oled juba WP 6.5 peal, ei muutu need JPG/PNG-d sinu meediaraamatukogus iseenesest WebP/AVIF-iks; sa ei saa automaatselt täielikku “väljund AVIF/WebP vastavalt brauseri võimalustele ja tagasilangus originaalpildile mitte-toetatavate brauserite puhul” linki! -- seda osa tuleb tavaliselt parandada mõne pluginaga või teenusega.

2. Teekaart: pildi optimeerimine 5 etapis

Mida teha, miks, mida teha, et kvalifitseeruda, ja milline on tüüpiline kaevik.

2.1 Esmalt “suuruse” õigeks saamine (kõige vähem tähelepanu pööratud, kuid kõige tasuvam)

Paljud jaamad on aeglased mitte sellepärast, et kompressioon ei ole tehtud, vaid etAllalaaditud suur pilt, mis ulatub kaugelt üle ekraani ala：
Näiteks kui lehekülg on tegelikult ainult 900px lai ja te palute külastajal laadida alla 3000px laiune originaalpilt, siis brauser lihtsalt “laeb selle alla ja seejärel kahandab seda”. See raiskab ribalaiust, suurendab dekodeerimisaega ja aeglustab esimest ekraani.

WordPress 4.4+Reageeriv pildimehhanism（srcset/sizes) on mõeldud just selle probleemi lahendamiseks.

Tehke seda, mis loetakse passiks:

• Kui avate lehe mobiiltelefonis, peaks allalaaditud pildi suurus olema oluliselt väiksem kui lauaarvutis.
• Sama pilt laetakse eri seadmetes erinevate ressursisuurustega (selle asemel, et laadida alati originaalpilt alla).

Kõige tavalisemad lõkse:

• On teemasid/ehitajaid, mis käsitlevad diagrammi CSS-foonipiltidena või väljastavad neid kohandatud viisil, mis võib mööda minna srcsetTulemuseks on olnud suur pilt.
• Te kasutate väliselt lingitud pildivoodeid, kolmanda osapoole pildiplokke ja võite ka mööda minna meediaraamatukogu poolt loodud mitme suurusega süsteemist.

---

2.2 Kompressioon (vähendage KB-d, kuid ärge “purustage” kvaliteeti)

Kompressiooni tuum ei ole “mida väiksem, seda parem”, vaid “erinevus on palja silmaga vaevalt nähtav, kuid mahu vähenemine on ilmne”.

Reeglid on järgmised:

• Fotod/livefotod (inimesed, tooted, maastikud): Prioriteetne kadudega kompressioon (maksimaalne võimendus)
• Ekraanipildid kasutajaliidesest / tekstirikkad pildid: Kompressioon peaks olema konservatiivsem, et vältida teksti hägusust.
• Logo / ikoon: Prioriteet SVG või diskreetne kadudeta (kadudega on lihtne serva kleepida)

Tehke seda, mis loetakse passiks:

• Pildi suuruse märkimisväärne vähendamine enamikul lehekülgedel
• Puudub nähtav müra, mudased servad, värviplokkide katked, hägune tekst

---

2.3 WebP / AVIF (formaatstrateegia: väiksem võrdse määratluse jaoks)

WordPress toetab juba üleslaadimist WebP (5,8) vs. AVIF (6,5)。
Kuid selleks, et järgmise põlvkonna formaat tõesti toimiks, tuleb tavaliselt lahendada kaks asja:

1. Kuidas konverteerida ajaloolisi meediaraamatukogusid partiidena(Vastasel juhul optimeerite ainult “uued pildid laaditakse üles hiljem”)
2. Kas luua koopia või asendada originaalkujutis(See on riskantne veeuputus; me keskendume Plus WebP “Asenda ja kustuta originaalpilt” hiljem)

Soovitatav kirjastiil:

• WebP: üldiselt eelistatakse vaikimisi (stabiilsem ühilduvus)
• AVIF: täiendav pakkimissuund, mis sobib suurte piltide/eelmise ekraani suurte piltide/albumi piltide jaoks (kuid rohkemSõltuvus keskkonnatoetusest）

---

2.4 Laisku laadimist tuleks kasutada õigesti (mitte üks suurus ei sobi kõigile).

WordPress 5.5 ja edasiVaikimisi laisk laadiminePilt.
See vähendab ribalaiuse kasutamist esialgse renderdamise ajal:

• Laisk laadimine “ekraanivälistele ressurssidele”
• Kõige kriitilisem suur pilt esimesel ekraanil (ja paljudel juhtudel ka põhipilt esimesel ekraanil) on sageli sobimatu hilinenud laadimiseks.

---

2.5 Tarnekihi: CDN / Foto CDN

Kompressioon, suuruse määramine ja vormindamine lahendavad “väiksemate failide, mis sobivad” probleemi.
Kui aga pilte tõmmatakse alati allikast kaugemalt, mõjutab võrgu viivitus ikkagi oluliselt kogemust. Siinkohal tulebki mängu “edastuskihi” lahendus (CDN/kujutis CDN).

Kaks tüüpilist suunda:

• Cloudflare Poola：Cloudflare dokumentatsioonTutvustatakse Poola pakkimismeetodeid (lossless/lossy/WebP) ja mainitakse, et pakkimine koos format=auto Lubatud on WebP/AVIF-vorming.
• Jetpack saidi kiirendi：Jetpacki dokumentatsioonSelgitage, et ta optimeerib pilte ja levitab neid oma võrgu kaudu koos staatiliste ressurssidega.

Pildi optimeerimine vastutab selle eest, et see muutub väiksemaks ja sobivamaks.CDN Vastutab lähemate ja stabiilsemate

3. Valik: ainult kaks peamist marsruuti

Kõige tavalisem viga pildi optimeerimisel ei ole mitte see, et ei ole ühtegi pluginat, vaid see, et on liiga palju pluginaid, mis viib topelttöötlemiseni:
A tihendab, B tihendab, A konverteerib WebP/AVIF-i, B konverteerib, A muudab URL-i, B kirjutab ümber - te isegi ei saa aru, mis jaamas toimub.

Reeglid:

On ainult üks tee, mida valida: kas kõik tasuta kohalik või pilvepõhine pakkimine kolmest.

• Marsruut A (kõik kohalikud tasuta):Plus WebP või AVIF + EWWW Image Optimizer(või ainult üks)
• Marsruut B (pilvede tihendamise kolmikvalikatsioon):ShortPixel / Imagify / TinyPNG

---

3.1 Marsruut A: Täielik tasuta kohalik (pluss WebP või AVIF või EWWW)

Seda marsruuti iseloomustavad:

• Te ei sõltu kolmandate isikute pakkimisteenustest “kuu/lehe kohta” (kuigi mõningaid funktsioone võidakse pakkuda valikuliste teenustena).
• Hind on see: hulgitöötlus võib serveri CPU/IO rohkem koormata ja nõuab sinult suuremat tähelepanu “strateegiale ja riskile”

3.1.1 Lisaks WebP või AVIF: tuum on “generate/replace”, see ei ole traditsiooniline “compression tool”.”

• Täismahuliste piltide genereerimisel:Algse pildifaili ID kirjutatakse üle WebP/AVIF-iga, algne fail kustutatakse ja sisu URL asendatakse.。
• Plugin pakub WP-CLI käske ja tuletab meelde: WP-CLI on usaldusväärsem, kui faile on palju.

See tähendab, et selle asemel, et “vaikselt genereerida WebP teie jaoks”, võib see ollaVarade migratsioon(Eriti kui lülitate sisse valiku “Asenda ja kustuta originaalpilt”).

Erinevused kahe mudeli vahel

Režiim 1: Säilitada originaalpilt + luua WebP/AVIF koopia (stabiilsem)

• Plussid: Lihtsam taganemine ühilduvusprobleemide korral
• Kulud: Ketta kasutamine suureneb (originaalpilt + uus formaat + mitmesuurused pisipildid).

Režiim 2: originaalpildi asendamine ja kustutamine (agressiivsem)

• Plussid: kettad ei laiene nii kiiresti; jaamaviited lähevad otse uude formaati
• Risk: te “muudate varasid + muudate viiteid”, mis muudab ühilduvusprobleemide lahendamise kallimaks (eriti kui mõned välissüsteemid või teemaloogika sõltuvad algsest failinimest/teest/formaadist).

Plus WebP või AVIF-i tüüpilised lõkse

1. Pärast kogu raamatukogu asendamist kuvatakse mõned lehekülje kujutised ebatavaliselt.
   Põhjus ei ole tavaliselt selles, et pilt on “katki”, vaid selles, et mingi lüli URL-i asendamise, vahemälu salvestamise, pisipildi poliitika jne. ahelas ei ole õige.
2. Mida suurem on pisipiltide arv, seda suurem on muudatuse ulatus
   WordPressi pildi üleslaadimine genereerib mitu suurust; teemad/pluginid võivad lisada ka rohkem suurusi. Täielik asendamine tähendab, et te võite muuta väga suurt failikogu.
3. Lihtsalt formaadi migratsiooni tegemine ei tähenda tingimata, et maht on alati kõige väiksem
   WebP/AVIF on üldiselt väiksemad, kuid “suurusstrateegia” ja “pakkimisstrateegia” on siiski kriitilise tähtsusega. Ärge mõelge Plus WebP-st kui “ühe klõpsu võrra kiiremast”.

---

3.1.2 EWWW pildi optimeerija: vaba kohaliku kokkusurumise esindaja

EWWW pluginate leht on väga hästi paigutatud:

• Seda saab oma serveris optimeerida erinevate tööriistade abil (jpegtran, optipng, pngout, pngquant, gifsicle, cwebp jne).
• Samuti saate CPU-d tarbiva töötlemise oma serverisse (valikuline), kui vajate suuremat tihendamist või suuremat CPU-säästu.

Milline peaks olema EWWW roll marsruudil A?

Kui kasutate Plus WebP-d kui “formaadi migratsiooni/asendusstrateegiat”, siis sobib EWWW paremini:

• Kompressioon ja mahu optimeerimine(eriti toorainete, nagu JPG/PNG, kaalu vähendamine)
• Ajaloolise meediakogu partii optimeerimine(suunatud pigem “mahu vähendamisele” kui “URLi asendamisele”)

EWWW tüüpiline kaevik

1. Suurenenud serverikoormus partii optimeerimise ajal
   Kuna kohalik tihendus sööb CPU/IO, ei ole lahendus “ära kasuta seda”, vaid “partii, madal tipp, vajadusel offload/pilvevõimalus”.
2. “WebP genereeritakse” ei tähenda, et frontend peab tootma WebP-d.
   Paljud pluginad kannatavad selle vääritimõistmise all: genereerimine on üks asi, edastamisstrateegiad (ümberkirjutused, pilditagid, vahemälu tabamused jne) on teine asi.
3. Teeme sama asja ikka ja jälle teiste pistikprogrammidega
   Kui valite tee A, proovige mitte üle kanda ShortPixel/Imagify/TinyPNG tüüpi pilvepakkimist; kui valite tee B, ärge lülitage Plus WebP asendusloogika sisse. Põhiprintsiip:Üks tee lõpuni.

---

3.2 Marsruut B: Pilvepakkimise kolmikvalik (ShortPixel / Imagify / TinyPNG)

See marsruut sobib inimestele, kes “soovivad säästa serveriressursse, soovivad teha partiid väiksema vaevaga ja aktsepteerivad krediitide/mahu kohta arveldamist”.
Kuid kõige eksitavam punkt pilvede tihendamise kohta on:Tasuta krediit ei ole nii lihtne kui “tasuta lehed”!.. Tarbimist võib oluliselt mõjutada pisipildi suuruste arv, see, kas luuakse WebP/AVIF või mitte, ja see, kas seda korduvalt uuesti survestatakse või mitte.

Järgnevalt selgitatakse: mis toimub tasuta/maksuga, kuidas krediiti maha arvestatakse, millistesse lõksu kõige tõenäolisemalt astutakse ja millised saiditüübid on sobivad.

---

3.2.1 ShortPixel100 tasuta krediiti/kuu, kuid krediiti tarbivad pisipildid ja WebP/AVIF suurendused.

Mis toimub tasuta/makstud

ShortPixel plugin kirjeldus ütleb selgelt:

• 100 tasuta krediiti kuus
• On olemas ka “Extra Unlimited Monthly Credits” (pluginate lehel on teave vastavate hindade kohta).
• Saadaval ka “ühekordsete krediitide pakettidena, mis ei aegu kunagi” (alghinnaga).

Vihje:

• Tasuta: anda teatud kogus krediiti kuus kergete saitide või testimise jaoks.
• Ühekordsed pakendid: sobivad suurte meediakogudega saitidele, kes soovivad oma varud korraga ära kasutada (osta üks kord ja kasutada ära, tavaliselt ei aegu).
• Igakuine/piiramatu: sobib pidevalt uuendatud piltidega ja pikaajalise stabiilse optimeerimisega saitidele.

ShortPixeli ametlik KB on andnud ka värskenduse “One Time Pack vs Unlimited Monthly” kohta.selgesõnaline selgitus: Unlimited Monthly on igakuine (või aastane) makse, mis pakub piiramatut krediiti fikseeritud CDN kogusega; ühekordseid krediite, mis ei aegu, andes teile suurema kontrolli nende kasutamiseks vastavalt vajadusele.

Kuidas arvutatakse ShortPixeli krediiti?

ShortPixel ametlik dokumentatsioon KB oli väga otsekohene:

• WordPress genereerib pildi üleslaadimisel mitu pisipilti;
• Iga pisipildi optimeerimine loeb krediidiks.；
• Kui valite WebP- või AVIF-vormingu loomise, siis onIga WebP/AVIF-versioon originaalpildist ja pisipildist kulutab täiendavat krediiti.；
• Te saate krediitide tarbimise vähendamiseks teatud pisipiltide optimeerimise välistada.

Krediitide näide：

Oletame, et laadite üles 1 pildi ja teema/plugin genereerib 8 pisipilti:

• Optimeeri ainult originaalpilt + pisipildid: 1 (originaal) + 8 (pisipildid) = 9 krediiti.
• Kui soovite ka WebP/AVIF-i genereerida: veel üks järgmise põlvkonna versioon iga 9 ülaltoodud versiooni kohta → +9 krediiti.
  Teisisõnu, see, mida te peate “1 pildiks”, võib tegelikult kulutada peaaegu “2-kohalisi krediite”.

Niisiis:“Tasuta 100 krediiti” ei ole sama mis “tasuta 100 pilti”.

ShortPixeli kõige levinumad lõkse

1. Tasuta 100 krediiti saab kiiresti otsa
   Põhjus: palju pisipilte + lisakrediit WebP/AVIF-i genereerimiseks.
   ettepanek：

• Hinnake esmalt saidi pisipiltide arvu
• välistage mittevajalikud pisipildi suurused (optimeerige ainult need suurused, mida tegelikult kasutatakse).
• Määrake tihendusstrateegia enne masskasutust, et vältida korduvat proovimise ja eksimuste tarbimist.

2. Teiste konverteripluginate samaaegne virnastamine
   Kui teil on Plus WebP asendused ja ShortPixel genereerib/lisab järgmise põlvkonna sildid, siis loogika kuhjub ja tõrkeotsing muutub raskemaks. Marsruudi B puhul laske ShortPixelil seda üksi teha.
3. Ma arvasin, et kui ma selle paigaldan, siis oleks “WebP/AVIF esiplaanil”.”
   ShortPixel plugin lehekülgMainiti, et see konverteerib WebP/AVIF-i ja saab lisada järgmise põlvkonna pilte esilehele (nt märgistamise teel).
   Kuid pärast seda on siiski oluline tulemusi kontrollida.

---

3.2.2 ImagifyTasuta: 20MB/kuu; kvooti arvestatakse maha vastavalt “originaalpildi suurusele + pisipiltide arvule”, korduvaid mahaarvamisi tehakse uuesti pressimise eest.

Vaba summa ja positsioneerimine

Imagify ametlik hinnalehekülgKirjeldus on selge:Tasuta konto kuine 20MB kvoot。
Selle pluginate lehel on ka selgitatud, et see suudab WebP/AVIF-i kokku suruda, suuruse muuta ja konverteerida.

Kuidas toimub kvoodi mahaarvamine?

Imagify ametlik dokumentatsioon “Kuidas arvutatakse kvootide kasutamist?” kirjeldab mahaarvamismehhanismi väga selgelt:

• Väikepiltide arv mõjutab tarbimistNäiteks kui teil on 10 pisipildi suurust, muutub 1 pildi optimeerimine 11 pildi optimeerimiseks (originaal + 10 pisipilti), mis kõik aitavad kaasa kvoodi tarbimisele.
• Kvoodi mahaarvamine vastavalt originaaldokumendi suurusele: Näiteks kui saadate Imagify'le 100KB suuruse pildi, lahutatakse kvoodist 100KB.
• Kompressioonitaseme muutmine ja uuesti optimeerimine tarbib jälle kvooti.。
• Sama API-võtit saab kasutada mitme saidi jaoks, kuid kvoodid jagatakse nende vahel.

See on Imagify “põhiline mõistmisviis”:
See on pigem nagu liikluspakett: see arvatakse maha nii palju, kui sa saadad; mida rohkem pisipilte sul on, seda rohkem arvatakse maha; ja kui sa seda korduvalt uuesti vajutad, kordub mahaarvamine.

Lihtsalt loetav Imagify kvoodi näide

Ütleme, et laadite üles 800 KB suuruse originaalpildi ja sait genereerib 8 pisipilti.

• Imagify optimeerib “originaalpildi + 8 pisipilti” (kui te otsustate optimeerida kõik), mis tähendab, et see üksik toiming tarbib kvoodi, mis on lähedane “kõigi nende failide algsele suurusele kokku”.
  Sellepärast on mõnel saidil tunne, et “20MB saab kiiresti otsa”: asi ei ole selles, et Imagify ei ole piisav, vaid selles, et te laadite korraga üles liiga palju pilte, liiga palju pisipilte ja tõenäoliselt proovite tihendustasemed ikka ja jälle läbi.

Imagify kõige tavalisemad lõkse

1. Tasuta 20MB Ei piisa “täieliku ajalooinventuuri” tegemiseks.”
   20MB sobib tavaliselt paremini kergete uuendustega testimiseks; kui teie meediakogu on juba suur, nõuab ühekordne puhastamine tõenäoliselt uuendamist.
2. Kompressioonitaseme korduv kohandamine toob kaasa kvootide tarbimise dubleerimise.
   Imagify teeb selgeks, etUuesti optimeerimine kulutab kvoodi uuesti ära.
   Soovitan teil teha “strateegia” sel leheküljel selgeks:

• Alustage väikese arvu piltidega, et määrata kindlaks pakkimise tase ja välimus ning tunnetus.
• Määrake strateegia ja seejärel käivitage lahtiselt
  Vältida korduvaid katsetusi ja vigu kogu raamatukogu kohta

3. Mitu saiti jagavad API-võtit, mis viib “seletamatu kvoodi vähenemiseni”.”
   Kui kasutate sama API-võtit rohkem kui ühe jaama jaoks, jagatakse kvooti.
   Seega on meeskonna/mitmejaamaliste stsenaariumide puhul kõige parem olla selge: milliseid jaamu kasutatakse ühiselt ja milliseid individuaalselt, et vältida kontrollimatuid eelarveid.

---

3.2.3 TinyPNG(Tiny Compress Images): tasuta 500 krediiti/kuu; üleminek WebP/AVIF-ile “vähendab 1 krediiti iga suuruse kohta”.”

Tasuta krediit ja selle arveldusideed

TinyPNG WordPressi pluginate lehekülg on väga selge:

• 500 krediiti kuus tasuta
• “Üldine WordPressi paigaldus”, saate tõenäoliselt tihendada Umbes 100 pilti/kuu
• Kui aga AVIF- või WebP-konversioon on lubatud:Iga pildi suurus tarbib täiendavat krediitiNii et eeldatavasti saab seda ainult tihendada ja teisendada Umbes 50 pilti/kuu(sõltuvalt sellest, kui palju pisipiltide suurusi teil on).

Vahepeal on Tinify (TinyPNG/TinyJPG arendajad) teinud ka oma API hinnakujunduslehtKirjeldus: Registreeruge ja saate 500 tasuta kompressiooni kuus; pärast seda esitatakse teile arve edukate kompressioonide arvu järgi, kohustuslik tellimus puudub.

Võtke ühes lauses kokku, kuidas TinyPNG on arusaadav:
See loeb krediiti; mida rohkem pisipiltide suurusi teil on ja mida rohkem WebP/AVIF-i te olete sisse lülitanud, seda kiiremini kulub krediit.

Lihtsalt loetavad näited TinyPNG krediitidest

Oletame, et teie sait genereerib iga pildi jaoks 8 pisipildi suurust:

• Ainult pakkimine: originaal + 8 pisipilti → 9 krediiti vaja.
• Kui WebP/AVIF konverteerimine on sisse lülitatud: üks lisakrediit iga suuruse kohta → tõenäoliselt peaaegu kahekordne!
  See vastab pluginalehe kirjeldusele: pärast sisselülitamist muutub tasuta summa umbes “100 kaardilt/kuus” “50 kaardile/kuus”.

TinyPNG kõige tavalisemad lõkse

1. Mõtte 500 krediiti = 500 pilti
   See ei ole. Seda tarbib “pildi suurus/variant”. Plugina lehekülg hoiatab selgelt, et “Konversioonid arvestavad iga pildi suuruse kohta täiendavalt 1 krediiti maha”.
2. Teemad/e-kaubanduse pistikprogrammid tekitavad liiga palju suurusi ja tasuta krediitide arv langeb märkimisväärselt
   Mida rohkem suurusi on, seda lihtsam on krediiti suurendada ja tarbida.
3. Pärast konverteerimise lubamist avastate, et krediidid on äkki kasutamata.
   See ei ole viga, see on selle arveldusmehhanism.
   Strateegia nõuanded:

• Kui tasuta faasi kasutatakse peamiselt pakkimiseks ja kaalu vähendamiseks, võite alustada ainult pakkimisega ja lülitada konverteerimise sisse siis, kui olete kindel, et teie saidi struktuur on stabiilne ja teil on tõesti vaja next-geni.

4. Alusstsenaariumi soovitus: kuidas valida eri tüüpi saite

Ka WordPressi, sisu saitidel, e-kaubanduse saitidel, portfellidel ja liikmesuse saitidel ei ole samu “survepunkte” piltide jaoks.

4.1 Sisuga veebilehed/blogid (palju artikligraafikat, uuenduste keskmine sagedus)

Prioriteetsed soovitused:

1. Mõõtmisstrateegia (samm 1)
2. Kokkupressimine (samm 2)
3. WebP (samm 3)

Sobivam marsruut:

• Tahad salvestada: Route B Triple Choice (ShortPixel / Imagify / TinyPNG)
• Kui soovite minna tasuta: marsruut A (Plus WebP + EWWW), kuid riskide hindamiseks on soovitatav alustada “konservatiivse režiimiga (ilma originaalpildi kustutamiseta)”.

Tüüpiline kaevandus:

• Artikli lehekülje esimene pilt on väga suur, ebaõige laisk laadimisstrateegia.Aeglustab esimest ekraani

4.2 E-kaubanduse/toodete veebileht (palju pisipilte, palju pildivariante, stabiilsus esikohal)

E-kaubandus on kõige tõenäolisemalt probleem ei ole “pakkimise mõju ei ole hea”, kuid “optimeeritud mõned suurus ei ole õige, puuduvad pisipildid, esiosa ei saa pilti”.

Prioriteetsed soovitused:

1. Stabiilsus kõigepealt: konservatiivne pakkimisstrateegia, ärge tehke kohe täielikku raamatukogu väljavahetamist.
2. Väikepildi suuruste hindamine: e-kaubanduse teemad genereerivad tavaliselt rohkem suurusi ja tarbitav kogus suureneb (ShortPixel/TinyPNG on eriti märgatav).
3. Teha väikeses mahus valideerimine enne partiide koostamist (väga kriitiline).

Sobivam marsruut:

• Marsruut B kipub olema muretum: ShortPixel/Imagify/TinyPNG võivad kõik pakendada ja on oluline, et te mõistate kvoodimehhanismi ja hindate eelnevalt kulusid.
• Marsruut A on hea, kuid ole ettevaatlikum Plus WebP “ID-de ülekirjutamine/algse pildi kustutamine/ URL-i asendamine” käitumisega: tegemist on varade migratsiooniga ja ei ole soovitatav kogu asja kohe välja vahetada.

4.3 Portfoolio/fotojaam (ühe pildi kvaliteeditundlik, suured pildid, kõrged nõudmised vaatamisele)

Prioriteetsed soovitused:

1. Suurusstrateegia (kuvamisala kontroll)
2. Kompressioonistrateegia (parem olla suurem kui purustada üksikasjad)
3. WebP/AVIF (suure pildi stseeni kasu on ilmselge, kuid kontrollige vaateid)

Sobivam marsruut:

• Imagify: Vähendage kvoot vastavalt “originaalpildi suurusele”, sellist saiti on lihtsam teha “eelarvekontrolli all” (te teate, kui palju tuleb iga suure pildi eest maha arvata), kuid vältige korduvaid repressioone.
• ShortPixel: Kui pisipildi suurust ei ole palju, on ka krediit väga intuitiivne; kuid kui genereerite palju suurusi +next-gen, suureneb krediitide tarbimine ja te peate planeerima ettepoole.

5. Kvootide/arvete võrdlus: “tasuta ei piisa” perspektiivi seadmine

Kumb on parem pakkumine ja kui kaua tasuta kestab?

5.1 Kolm tagasimakse mudelit

• ShortPixel(krediit): Krediit arvutatakse kui “originaalpilt + pisipiltide arv”; täiendav krediit lahutatakse iga vastava loodud WebP/AVIF-versiooni eest.
• Imagify(MB kvoot): Vähendage kvoot vastavalt “originaalfaili suurusele”; mida rohkem pisipilte, seda rohkem mahaarvamisi; uuesti pressimine vähendab jälle.
• TinyPNG(krediit): 500 krediiti kuus; WebP/AVIF-konversiooni võimaldamine vähendab iga pildi suuruse kohta täiendavaid krediite.

5.2 Kiirhinnangu meetodid

Seda võib hinnata nii:

1. Leidke juhuslik “originaalpilt, mida te sageli üles laadite” ja vaadake, kui suur see on (nt 300KB / 1MB / 3MB).
2. Sõltuvalt sellest, mitu pisipildi suurust teie sait genereerib (nt 5 / 10 / 20).
3. Otsustage, kas soovite luua WebP/AVIF (jah/ei)

Seejärel kasutage tarbimise mõistmiseks järgmist “vaimset matemaatikat”:

• ShortPixel: ≈ (1 + pisipiltide arv) krediiti ühe pildi kohta; kui luuakse WebP/AVIF, siis ≈ kahekordistub uuesti (kuna ka next-gen versioon võtab krediiti).
• Imagify: Iga pilt ≈ (originaalsuurus + iga pisipildi suurus) vähendab kvooti; kui muudad tihendamistaset ja pakendad uuesti, vähendad jälle kvooti.
• TinyPNG: 500 krediiti tasuta; kui teie sait genereerib palju suurusi ühe pildi kohta ja konverteerimine on lubatud, väheneb tasuta krediitide arv märkimisväärselt (pluginalehekülg annab visuaalse ootuse “~100 krediiti/kuu” vs. “~50 krediiti/kuu”).

6. Riskihoiatused

Risk 1: Ära lase mitmel pistikprogrammil ikka ja jälle sama asja teha.

See on kõige tavalisem “katastroofi allikas”.”

• Marsruut A:Lisaks WebP või AVIF + EWWW(Jagage töö nende kahe vahel, ärge tehke samasuguseid ümberehitusi ja tarneid korraga või paigaldage ainult üks neist).
• Marsruut B: ShortPixel / Imagify / TinyPNG valige kolm(valige üks, mida tihendada next-geniga)

Risk 2: Plus WebP “Overwrite ID / Delete Original Image / Replace URL” on varade migratsioon.

Rõhutus lisatud:Plus WebP Kirjelduses on selgelt öeldud, et täielik genereerimine kirjutab algse pildi ID üle, kustutab algse faili ja asendab sisu URL-i.
See tähendab, et see ei ole “väike seade, mida saab igal ajal tagasi võtta”, vaid varade tasandil muutus.

Soovitatav strateegia peaks olema:

• Esmalt väike test (paarikümne kuni paarisaja).
• Kinnitage, et esiplaani kuvamine, pisipildid ja vahemälu uuendused toimivad korralikult.
• Täieliku raamatukogutöötluse läbivaatamine

Risk 3: Pilvepakkimise “tasuta krediitide” tegelik tarbimine sõltub pisipiltide arvust ja järgmise põlvkonna valikust.

• ShortPixel: Thumbnails ja next-gen mõjutavad oluliselt krediiti.
• TinyPNG: WebP/AVIF-i sisselülitamine vähendab iga pildi suuruse kohta lisakrediiti.
• Imagify: lahutatakse vastavalt originaalpildi suurusele, mida rohkem pisipilte lahutatakse rohkem, tugev surve kordab mahaarvamist!

Risk 4: “WebP/AVIF loodud” ei tähenda, et “WebP/AVIF edastatakse front office'i poolt”.”

Paljud inimesed tunnevad pärast konverteerimist, et see ei ole kiirem, sest frontend väljastab ikka veel JPG/PNG-d (vahemälu/ümberkirjutamine/tähistamine/läbivaatamine/läbivaatamise läbirääkimised ei ole õiges kohas).

7. Kuidas kontrollida, et see on pärast seda, kui see on tehtud, jõustunud

4 väga lihtsat valideerimispunkti:

1. Kas sama lehekülg värskendatakse teist korda ja laetakse järjekindlamalt ja kiiremini.(Caching ja optimeerimine füüsilise mõttes, kas see töötab)
2. Kas mobiiltelefonidesse ja lauaarvutitesse laaditavate piltide suurused erinevad oluliselt?(reageeriv) srcset/sizes (sõltumata sellest, kas nad töötavad või mitte)
3. Kontrollida pisteliselt mõnda pilti: kas WebP- või AVIF-failid/ressursid on olemas.(Kas sait kasutab tegelikult järgmise põlvkonna）
4. Proovige mõnda pilti: suurendage, et näha, kas need on nähtavalt mudased, kas tekst on ähmane...(kokkusurutud mass ei ole liigne)

Kui kõik neli neist vastavad, on valitud marsruut läbitud. Järgmiseks. CDN “Tarnekihi”, on üldine stabiilsem.

8. Soovitused meetmete võtmiseks

1. Valige kõigepealt oma marsruut:

• Püüan olla võimalikult vaba.: Plus WebP või AVIF + EWWW (või ainult üks neist)
• Tahad säästa serveri ressursse, maksta summa järgi rohkem murettekitavaks: ShortPixel / Imagify / TinyPNG - vali üks!

2. Tehke kõigepealt väike test (paar tosinat).
3. Veenduge, et see on enne partii koostamist korras.
4. Tarne stabiilsust on vaja veelgi parandada:loe CDN Kiirendus

ühised probleemid

1. Mitu pistikprogrammi tuleb paigaldada? Kas ma saan neid kõiki paigaldada?

Püüdke võtta ainult üks marsruut.

• Marsruut A: pluss WebP või AVIF + EWWW Image Optimizer (või ainult üks neist)
• Marsruut B: ShortPixel / Imagify / TinyPNG - vali üks!
  Samas jaamas samal ajal lasta rohkem kui üks plug-in teha “compression / üleandmine WebP / AVIF / muuta URL / tarne ümberkirjutamine”, kõige tõenäolisemalt saada rohkem ja rohkem kaootiline, kuid ka kõige raskem kontrollida.

2. Kas WordPress ei toeta juba WebP/AVIF-i? Kas mul on ikkagi vaja pluginat?

See tuleb eraldada:
“Üleslaadimise/kasutamise tugi” ≠ “Automaatne konverteerimine/automaatne edastamine”.
WordPress 6.5 ei konverteeri ka automaatselt vanu JPG/PNG-sid WebP/AVIF-iks ega tee automaatselt kogu “AVIF/WebP eksportimist brauserisse ja fallbacki” asja sinu eest. Tavaliselt on vaja pluginat või teenust, et ajalooline meediakogu tööle panna.

3. Milline on kõige “tasuvam” samm pildi optimeerimisel?

Tavaliselt on see Esmalt tuleb määrata “suurused” õigesti (srcset/sizes).。
Paljud saidid ei ole aeglased mitte sellepärast, et neil ei ole kompressiooni, vaid sellepärast, et leht on ainult 900px ja kasutajal palutakse alla laadida 3000px suurune pilt. Kompressioon säästab KBs, kuid “vale suurus” paneb teid mitu korda rohkem andmeid tühja laadima.

4. Kuidas ma saan olla kindel, et ma laadin “väiksemat” ja mitte igavesti originaalpilti?

Vaadake kahte nähtust:

• Kui lehekülg avatakse mobiiltelefonis, on allalaaditud pildi suurus märgatavalt väiksem kui lauaarvutis.
• Sama pilt laetakse eri seadmetes erineva ressursisuurusega.
  Kui originaalpilt laaditakse alla igavesti, on tavaline põhjus see, et teema/ehitaja käsitleb pilti CSS-foonipildina või kohandatud väljundina, vältides meediaraamatukogu mitmemõõtmist srcsetiga.

5. Kas “WebP/AVIF genereeritud” tähendab, et frontend peab tootma WebP/AVIFi?

Ei ole võrdne.
Genereerimine on vaid “failikiht”; see, kas frontend tegelikult WebP/AVIF-i edastab, sõltub ümberkirjutustest, pildi märgistamise põhimõtetest, vahemälu tabamustest, kehtivatest brauseri läbirääkimistest jne. Kui olete lõpetanud, kontrollige kindlasti “pisteliselt mõned pildid ressursitüüpide suhtes”.

6. Plus Mis on WebP või AVIFi puhul nii ohtlik? Kas ma saan kogu raamatukogu ühe klõpsuga käivitada?

Selle riskipunkt ei ole “kokkusurumine”, see onMuutused varade migratsiooni tasemes：

• Täielik genereerimine võib algse pildifaili ID üle kirjutada, kustutada algse faili ja asendada sisu URL-i.
  põhjus, miksKogu raamatukogu ei ole soovitatav kohe välja vahetada.: Testige väikeses mahus (kümneid kuni sadu) + kasutage kättesaadavaid varukoopiaid, enne kui kaalute täielikku raamatukogu töötlemist.

7. Milline on valik Plus WebP kahe režiimi vahel: originaalpildi säilitamine vs. originaalpildi asendamine ja kustutamine?

Lihtne mõista:

• Režiim 1: Säilitada originaalpilt + luua WebP/AVIF koopia (stabiilsem): Mugav tagasivõtmiseks, kuid ketas läheb suuremaks (originaalpilt + uus formaat + mitmesuurused pisipildid).
• Režiim 2: originaalpildi asendamine ja kustutamine (agressiivsem): Kettad on vähem altid paisumisele, kuid te “muudate varasid + muudate viiteid”, mis muudab ühilduvusprobleemide lahendamise kallimaks.
  Mida keerulisem on sait (e-kaubandus/multiplugin/multi-size), seda enam on soovitatav alustada stabiilsema mudeliga.

8. Kas EWWW Image Optimizer tasuta kohalik pakkimine on piisav? Kas see koormab serverit?

EWWW on pigem “kohalik kompressor”: see sööb CPU/IO.
On tavaline, et koormus suureneb partii optimeerimise ajal, mis ei tähenda, et see “ei tööta”, vaid pigem seda, et strateegia peaks olema õige: partii, madalad tipud ja vajaduse korral mahalaadimise/pilvevõimalused.
Kui otsite kokkuhoidu või kui teil napib serveriressursse, on marsruut B serverisõbralikum.

9. ShortPixeli 100 tasuta krediiti/kuu, miks mulle tundub, et see on paari pildiga kadunud?

seoses krediit ei ole “piltide arv”.”Next-gen suurendatakse thumbnaili võrra koos next-geniga:

• Originaalpilt + iga pisipilt loeb krediidina.
• Kui luuakse WebP/AVIF, kulub iga vastava versiooni kohta täiendav krediit.
  Nii et see, mida te peate “1 pildiks”, võib tegelikult kulutada peaaegu “2-kohalisi krediite”. shortPixel

10. Imagify tasuta 20MB/kuu, miks see ka kiiresti otsa saab?

Imagify on pigem “liikluspakett”:

• Nagu te selle saatsite.Originaalfaili suuruskvootide mahaarvamine
• Mida rohkem on pisipilte, seda rohkem tarbid sa.
• Kompressioonitaseme muutmine uuesti optimeerimiseks tarbib jälle kvooti
• Sama API võti mitme saidi jaoks, kvootide jagamine
  Seega tähendab “20MB saab kiiresti otsa” sageli seda, et pildid on liiga suured, pisipilte on liiga palju või proovitakse korduvalt katse-eksituse meetodil.

11. TinyPNG on tasuta 500 krediiti/kuu, miks ütleb plugin, et ainult umbes 100 krediiti/kuu ja siis 50 krediiti/kuu koos WebP/AVIF-iga?

Kuna TinyPNG krediteeringud on samuti suurendatud “size/variant” järgi:

• Tavaline WordPressi paigaldus tihendab tõenäoliselt umbes 100 lehte/kuus.
• Lubage AVIF- või WebP-konversioon:Iga pildi suurus tarbib täiendavat krediitiSeega saate tõenäoliselt ainult umbes 50 pilti kuus (sõltuvalt pisipiltide suurusest) kokku suruda ja teisendada.
  Seega 500 krediiti ≠ 500 pilti.

12. Mitu pisipilti on minu saidil? Miks on see nii oluline?

WordPress genereerib pildi üleslaadimiseks mitu suurust; teemad/pluginid (eriti e-kaubandus) võivad lisada rohkem suurusi.
Pilvekompressiooni krediidid/kvoodid on tavaliselt “originaal + pisipildid koos”, nii et mida rohkem pisipilte teil on, seda vähem tasuta krediite on teil kasutada.

13. Kas laisk laadimine on alati kiirem? Miks mõned inimesed ütlevad, et laisk laadimine aeglustab asju?

Laisk laadimine sobib “ekraanivälistele ressurssidele”.
Kui esimene ekraan kõige kriitilisem suur pilt on ka hilinenud laadimine, võib aeglustada esimese ekraani kogemus. WordPress 5.5 kuna vaikimisi laisk laadimine on hea, kuid ei ole “üks suurus sobib kõigile”.

14. Sõidan marsruudil A või B. Millal on mul vaja CDN / Pilt CDN?

Kompressioon, suuruse määramine ja vormindamine lahendavad “väiksemate failide, mis sobivad” probleemi;
CDN Lahendus on pakkuda tihedamat ja stabiilsemat。
Kui pilte tõmmatakse lähtekohast kaugemalt, mille tulemuseks on märkimisväärne latentsus, siis on CDN / piltide täiendamine CDN-ga (nt Cloudflare Polish / Jetpack Site Accelerator) üldiselt stabiilsem, loe WordPress CDN Kiirendus。

15. Milline on minu jaoks kõige lihtsam viis kontrollida, et “see tõesti töötab”, kui ma olen valmis?

Kõige ajaefektiivsem kontrollimise meetod:

• Kas sama lehekülg värskendatakse teist korda ja laetakse järjekindlamalt ja kiiremini.
• Kas mobiiltelefonides ja lauaarvutites laaditavate piltide suurused on märgatavalt erinevad (kas srcset/size mängivad rolli)?
• Kontrollida pisteliselt mõnda pilti: kas WebP- või AVIF-failid/ressursid on olemas.
• Proovige mõnda pilti: suurendage, et näha, kas need on nähtavalt mudased, kas tekst on ähmane...