Verkkosivuston kuvaoptimointi

Kuvien optimointi on yksi WordPressin suorituskyvyn “palkitsevimmista” näkökohdista: kunhan kuvan koko, mitat, muotoilu ja toimitus ovat oikeat, latauskokemus paranee välittömästi, kunhan sivun rakenne ja teema ovat samat.

Kuvien optimointi on kuitenkin myös helpoin tapa saada aikaan sotkua, ei siksi, että se olisi teknisesti liian vaikeaa, vaan siksi, että tieto on liian hajanaista:
Luet muutaman artikkelin, tiedät, että “pakkaus”, “WebP / AVIF”, “laiska lastaus”, ja sitten katsoa plugin esittely ja sanoi “ilmainen joka kuukausi!”. 100 krediittiä kuukaudessa“, ”Ilmainen 20MB“, ”1 krediitti per kuva“, mutta mitä enemmän luen, sitä enemmän hämmennyn... Onko ilmainen tarpeeksi? Miten maksu vähennetään? Ymmärsitkö väärin ”saman asian"? Ja mikä tärkeintä:Vaikuttiko se todella sen jälkeen, kun teit sen vai ei?

Tässä artikkelissa tehdään vain kolme asiaa:

1. Antaa sinulle suoritettavan tiedostontiekartta (myös kuva)(Mitä tehdä ensin, mitä tehdä sitten)
2. Ole selvillä siitä, mitä vaihtoehtoa valitset (mikä on ilmaisen ja maksullisen vaihtoehdon ero ja kenelle kumpikin sopii).
3. Kirjoita yleisimmät sudenkuopat etukäteen (jotta sinun ei tarvitse etsiä vianmääritystä, kun olet valmis).

1. Lopputulos: Mitä WordPress sisältää ja mitä se ei sisällä?

Jos et ensin ota selvää, mitä WordPressin ydin jo tekee, on helppo tehdä jompikumpi kahdesta asiasta:

• Sen sijaan, että käyttäisit “vapaata kapasiteettia”, josta sinun pitäisi nauttia, käytät aikaa/kulutat rahaa pyörän rakentamiseen yhä uudelleen ja uudelleen.
• Luulin, että WordPress “muuntaa kaikki vanhat kuvat automaattisesti WebP/AVIF-muotoon”, mutta kävi ilmi, että se ei tee niin!

WordPressin ytimessä on nämä keskeiset ominaisuudet sisäänrakennettuina:

• Responsiiviset kuvat (srcset/koko): WordPress 4.4:stä lähtien ydin tuottaa kuvia WordPressin srcset 与 sizesja hyödyntää latauksen aikana luotuja monikokoisia kuvia, jotta selain voi valita näytön olosuhteiden mukaan sopivamman resurssin ladattavaksi.
• Oma laiska lataus: WordPress 5.5:stä lähtien mahdollistaa oletusarvoisesti kuvien natiivin laiskan lataamisen HTML-standardeja käyttäen. loading attribuutin toteutus.
• Tuki WebP:n lataamiselle: WordPress 5.8:sta lähtien voit ladata ja käyttää WebP:tä JPEG/PNG:nä (edellyttäen, että hosting-ympäristö tukee WebP:tä).
• Tuki AVIF-tiedostojen lataamiselle: WordPress 6.5:stä lähtien voit ladata ja käyttää AVIF:ää JPEG/PNG:nä (riippuu myös hosting-tuesta).

Mutta ole tarkkana:
“Tuki lataamiselle/käytölle” ≠ “Automaattinen muuntaminen/automaattinen toimitus”.
Toisin sanoen: vaikka olisit jo WP 6.5:ssä, mediakirjastossasi olevat JPG/PNG-kuvat eivät muutu WebP/AVIF:ksi itsestään; et saa automaattisesti täyttä “AVIF/WebP-tulostusta selaimen ominaisuuksien mukaan ja palautusta alkuperäiseen kuvaan tukemattomille selaimille” -linkkiä! -- tämä osa on yleensä korjattava lisäosalla tai palvelulla.

2. Etenemissuunnitelma: Kuvan optimointi viidessä vaiheessa

Mitä pitää tehdä, miksi, mitä pitää tehdä karsintojen suorittamiseksi ja millainen on tyypillinen varikko.

2.1 “Koon” määrittäminen ensin (eniten unohdettu, mutta palkitsevin tapa).

Monet asemat eivät ole hitaita sen vuoksi, että pakkausta ei ole tehty, muttaLatasi suuren kuvan, joka ulottuu huomattavasti näyttöaluetta laajemmalle.：
Jos esimerkiksi sivu on todellisuudessa vain 900 pikseliä leveä ja pyydät kävijää lataamaan alkuperäisen 3000 pikseliä leveän kuvan, selain vain “lataa sen ja sitten pienentää sitä”. Tämä tuhlaa kaistanleveyttä, lisää dekoodausaikaa ja hidastaa ensimmäisen näytön katselua.

WordPress 4.4+Responsiivinen kuvamekanismi（srcset/sizes) on suunniteltu juuri tämän ongelman ratkaisemiseksi.

Tee se, mikä lasketaan syötöksi:

• Kun sivu avataan matkapuhelimella, ladattavan kuvan koon pitäisi olla huomattavasti pienempi kuin työpöydällä.
• Sama kuva latautuu eri resurssikokojen kanssa eri laitteilla (sen sijaan, että ladattaisiin aina alkuperäinen kuva).

Yleisimmät sudenkuopat:

• On olemassa teemoja/rakentajia, jotka käsittelevät kaavioita CSS-taustakuvina tai tuottavat ne mukautetulla tavalla, joka voi ohittaa srcsetTuloksena on ollut suuri kuva
• Voit käyttää ulkoisesti linkitettyjä kuvapohjia, kolmannen osapuolen kuvalohkoja ja voit myös ohittaa mediakirjaston luoman monikokoisen järjestelmän.

---

2.2 Pakkaus (pienennä KB:ta, mutta älä “murskaa” laatua)

Tiivistämisen ydin ei ole “mitä pienempi, sitä parempi”, vaan “ero on tuskin paljain silmin havaittavissa, mutta tilavuuden lasku on ilmeinen”.

Säännöt ovat seuraavat:

• Valokuvat/elävät kuvat (ihmiset, tuotteet, maisemat): Ensisijainen häviöllinen pakkaus (maksimaalinen vahvistus)
• Kuvakaappaukset käyttöliittymästä / tekstipainotteiset kuvat: Pakkauksen pitäisi olla konservatiivisempi epäselvän tekstin välttämiseksi.
• Logo/kuvake: Prioriteetti SVG tai häviötön häviötön (häviöllinen on helppo liittää reunaan).

Tee se, mikä lasketaan syötöksi:

• Kuvakoon merkittävä pienentäminen useimmilla sivuilla
• Ei näkyvää kohinaa, epäselviä reunoja, värikatkoksia, epätarkkaa tekstiä.

---

2.3 WebP / AVIF (formaattistrategia: pienempi, jotta määritelmä olisi sama)

WordPress tukee jo lataamista WebP (5.8) vs. AVIF (6.5)。
Jotta seuraavan sukupolven formaatti todella toimisi, on yleensä ratkaistava kaksi asiaa:

1. Miten muuntaa historiallisia mediakirjastoja eräajona(Muuten optimoit vain “uudet kuvat ladataan myöhemmin” -tilanteeseen).
2. Luodaanko kopio vai korvataanko alkuperäinen kuva?(Tämä on riskialtis vedenjakaja; keskitymme Plus WebP:n “Korvaa ja poista alkuperäinen kuva” -toimintoon myöhemmin.)

Suositeltu kirjoitustyyli:

• WebP: yleensä mieluummin oletusarvo (vakaampi yhteensopivuus)
• AVIF: uusi pakkaussuunta, joka soveltuu suurille kuville/ensikuvan suurille kuville/albumikuville (mutta enemmän kuin AVIF).Riippuvuus ympäristön tuesta）

---

2.4 Laiskaa latausta on käytettävä oikein (ei yksi koko sopii kaikille).

WordPress 5.5 alkaenOletuksena laiska latausKuva.
Se vähentää kaistanleveyden käyttöä alkuperäisen renderöinnin aikana:

• Laiska lataus “näytön ulkopuolisille resursseille”
• Ensimmäisen näytön kriittisin suuri kuva (ja monissa tapauksissa ensimmäisen näytön avainkuva) ei useinkaan sovellu viivästettyyn lataukseen.

---

2.5 Toimituskerros: CDN / Kuva CDN

Pakkaaminen, koon määrittäminen ja muotoilu ratkaisevat “pienempien, sopivien tiedostojen” ongelman.
Jos kuvat kuitenkin vedetään aina kaukaa lähteestä, verkon viive voi silti vaikuttaa kokemukseen merkittävästi. Tässä kohtaa “jakelukerros”-ratkaisu (CDN/kuva CDN) tulee kuvaan.

Kaksi tyypillistä suuntaa:

• Cloudflare Puolan：Cloudflare-dokumentaatioPuolalaiset pakkausmenetelmät (lossless/lossy/WebP) esitellään, ja mainitaan, että pakkaus, jossa käytetään häviöttömiä/loosy/WebP-menetelmiä. format=auto WebP/AVIF-muoto on sallittu.
• Jetpack-sivuston kiihdytin：Jetpackin dokumentaatioSelitä, että se optimoi kuvia ja jakaa niitä verkossaan yhdessä staattisten resurssien kanssa.

Kuvien optimointi on vastuussa siitä, että kuvat ovat pienempiä ja tarkoituksenmukaisempia.CDN Vastaa tiiviimmästä ja vakaammasta tuotannosta.

3. Valinta: vain kaksi pääreittiä

Yleisin epäonnistuminen kuvan optimoinnissa ei ole “ei liitännäisiä”, vaan liian monta liitännäistä, jotka johtavat päällekkäiseen käsittelyyn:
A pakkaa, B pakkaa, A muuntaa WebP:ksi/AVIF:ksi, B muuntaa, A muuttaa URL-osoitteita, B kirjoittaa uudelleen - et edes tiedä, mitä asemalla tapahtuu.

Säännöt:

Valittavana on vain yksi reitti: joko kaikki ilmainen paikallinen tai pilvipakkaus kolmesta vaihtoehdosta.

• Reitti A (kaikki ilmaiset paikallisliikennepalvelut):Plus WebP tai AVIF + EWWW Image Optimizer (EWWW-kuvanoptimointiohjelma)(tai vain yksi)
• Reitti B (pilvipakkauksen kolmoisvaihtoehto):ShortPixel / Imagify / TinyPNG

---

3.1 Reitti A: Täysin ilmainen paikallinen (sekä WebP tai AVIF tai EWWW)

Tälle reitille on ominaista:

• Et ole riippuvainen kolmannen osapuolen pakkauspalveluista (vaikka joitakin ominaisuuksia saatetaankin tarjota valinnaisina palveluina).
• Kustannukset: Eräkäsittely voi olla CPU/IO:ssa palvelinvaltaisempaa, jolloin sinun on kiinnitettävä enemmän huomiota strategiaan ja riskiin.“

3.1.1 Plus WebP tai AVIF: Ydin on “generate/replace”, se ei ole perinteinen “pakkaustyökalu”.”

• Kun tuotetaan täysimittaisia kuvia:WebP/AVIF korvaa alkuperäisen kuvatiedoston tunnuksen, alkuperäinen tiedosto poistetaan ja sisällön URL-osoite korvataan.。
• Lisäosa tarjoaa WP-CLI-komentoja ja muistuttaa: WP-CLI on luotettavampi, kun tiedostoja on paljon.

Tämä tarkoittaa sitä, että sen sijaan, että “tuottaisit hiljaa WebP:n puolestasi”, se voisi ollaOmaisuuserien siirtyminen(Varsinkin jos otat käyttöön vaihtoehdon “Korvaa ja poista alkuperäinen kuva”).

Näiden kahden mallin väliset erot

Tila 1: Säilytä alkuperäinen kuva + luo WebP/AVIF-kopio (vakaampi).

• Hyvät puolet: Helpompi turvautua yhteensopivuusongelmien varalta.
• Kustannukset: Levyn käyttö lisääntyy (alkuperäinen kuva + uusi muoto + monikokoiset pikkukuvat).

Tila 2: Korvaa ja poista alkuperäinen kuva (aggressiivisempi).

• Plussat: levyt eivät laajene yhtä nopeasti; asemaviittaukset siirtyvät suoraan uuteen muotoon.
• Riski: “vaihdat resursseja + vaihdat viitteitä”, mikä tekee yhteensopivuusongelmien vianmäärityksestä kalliimpaa (varsinkin jos jotkin ulkoiset järjestelmät tai teemalogiikat ovat riippuvaisia alkuperäisestä tiedostonimestä/polusta/formaatista).

Plus WebP:n tai AVIF:n tyypilliset sudenkuopat

1. Kun koko kirjasto on vaihdettu, jotkin sivukuvat näkyvät epänormaalisti.
   Syynä ei yleensä ole se, että kuva olisi “rikki”, vaan se, että jokin URL-osoitteen korvaamisen, välimuistitallennuksen, pikkukuvakäytännön jne. ketjussa ei toimi oikein.
2. Mitä enemmän pikkukuvia, sitä laajempi muutos on.
   WordPress luo useita eri kokoja kuvan lataamista varten; teemat/pluginit voivat myös lisätä lisää kokoja. Täydellinen korvaaminen tarkoittaa, että saatat muuttaa hyvin suurta tiedostokokoelmaa.
3. Pelkkä muodonsiirto ei välttämättä tarkoita, että tilavuus on aina pienin.
   WebP/AVIF ovat yleensä pienempiä, mutta “kokostrategia” ja “pakkausstrategia” ovat silti ratkaisevia. Älä ajattele, että Plus WebP on “yhden klikkauksen nopeampi”.

---

3.1.2 EWWW Image Optimizer: vapaan paikallisen puristuksen edustaja

EWWW:n laajennussivu on hyvin sijoitettu:

• Se voidaan optimoida palvelimellasi käyttämällä erilaisia työkaluja (jpegtran, optipng, pngout, pngquant, gifsicle, cwebp jne.).
• Voit myös siirtää CPU:tä vaativan käsittelyn palvelimelle (valinnainen), jos tarvitset suurempaa pakkausta tai enemmän CPU-säästöjä.

Millainen rooli EWWW:llä pitäisi olla Route A:ssa?

Jos käytät Plus WebP:tä “formaatinsiirto-/korvausstrategiana”, EWWW on parempi vaihtoehto:

• Tiivistäminen ja tilavuuden optimointi(erityisesti JPG/PNG:n kaltaisten raakaresurssien painon vähentäminen).
• Historiallisen mediakirjaston eräoptimointi(kohdistetaan pikemminkin “volyymin vähentämiseen” kuin “URL-osoitteen korvaamiseen”).

Tyypillinen EWWW-kuoppa

1. Suurentunut palvelinkuorma erän optimoinnin aikana
   Koska paikallinen pakkaus syö CPU/IO:ta, ratkaisu ei ole “älä käytä sitä”, vaan “eräajo, matala huippu, offload/pilvipalveluvaihtoehto tarvittaessa”.
2. “WebP luodaan” ei tarkoita, että etusivun on tuotettava WebP.
   Monet liitännäiset kärsivät tästä väärinkäsityksestä: generointi on yksi asia, toimitusstrategiat (uudelleenkirjoitukset, kuvatunnisteet, välimuistitunnisteet jne.) ovat toinen asia.
3. Saman asian tekeminen uudelleen ja uudelleen muiden lisäosien kanssa
   Jos valitset reittiä A, yritä olla käyttämättä ShortPixel/Imagify/TinyPNG-tyyppistä pilvipakkausta; jos valitset reittiä B, älä ota Plus WebP -korvauslogiikkaa käyttöön. Keskeinen periaate:Yksi reitti loppuun.

---

3.2 Reitti B: Pilvipakkauksen kolmoisvalinta (ShortPixel / Imagify / TinyPNG)

Tämä reitti sopii ihmisille, jotka “haluavat säästää palvelimen resursseja, haluavat tehdä eriä vähemmällä vaivalla ja hyväksyvät luottokohtaisen tai volyymikohtaisen laskutuksen”.
Mutta kaikkein harhaanjohtavin seikka pilvipakkauksesta on:Ilmaiset hyvitykset eivät ole niin yksinkertaisia kuin “ilmaiset lakanat”!.. Pienoiskuvakokojen määrä, se, luodaanko WebP/AVIF ja painetaanko se toistuvasti uudelleen, voivat vaikuttaa merkittävästi kulutukseen.

Seuraavassa selitetään: mitä tapahtuu ilmaisen/maksullisen suhteen, miten hyvitykset vähennetään, mihin sudenkuoppiin todennäköisimmin astutaan ja mitkä sivustotyypit ovat sopivia.

---

3.2.1 ShortPixel100 ilmaista krediittiä/kuukausi, mutta pienoiskuvat ja WebP/AVIF-suurennokset kuluttavat krediittejä.

Mitä tapahtuu ilmaisten/maksullisten

ShortPixel-liitännäisen kuvauksessa sanotaan selvästi:

• 100 ilmaista krediittiä kuukaudessa
• On myös “Extra Unlimited Monthly Credits” (plugin sivu antaa tietoa vastaavista hinnoista).
• Saatavana myös “kertaluonteisina hyvityspaketteina, jotka eivät koskaan vanhene” (lähtöhintatietoineen).

Vinkki:

• Ilmainen: anna tietty määrä krediittejä kuukaudessa kevyitä sivustoja tai testausta varten.
• Kertakäyttöpakkaukset: sopivat sivustoille, joilla on suuret mediakirjastot ja jotka haluavat tyhjentää varastonsa kerralla (osta kerran ja käytä se loppuun, se ei yleensä vanhene).
• Kuukausittainen/rajaton: sopii sivustoille, joilla on jatkuvasti päivitettyjä kuvia ja pitkäaikainen vakaa optimointi.

ShortPixelin virallinen KB on myös antanut päivityksen “One Time Pack vs Unlimited Monthly”.selkeä selitys: Rajoittamaton kuukausimaksu on kuukausittainen (tai vuosittainen) maksu, joka tarjoaa rajattomasti krediittejä kiinteällä CDN-määrällä; kertaluonteisia krediittejä, jotka eivät vanhene, jolloin voit käyttää niitä tarpeen mukaan.

Lopputulos: miten ShortPixel-hyvitykset lasketaan?

ShortPixelin virallinen dokumentaatio KB oli hyvin suorasukainen:

• WordPress luo useita pikkukuvia, kun lataat kuvan;
• Jokainen pikkukuvan optimointi lasketaan krediitiksi.；
• Jos valitset WebP- tai AVIF-tuotteen.Jokainen WebP/AVIF-versio alkuperäisestä kuvasta ja pikkukuvasta kuluttaa lisäkrediitin.；
• Voit sulkea tietyt pikkukuvat pois optimoinnista vähentääksesi krediitin kulutusta.

Hyvitys Esimerkki：

Oletetaan, että lataat 1 kuvan ja teema/plugin luo 8 pikkukuvaa:

• Optimoi vain alkuperäinen kuva + pikkukuvat: 1 (alkuperäinen) + 8 (pikkukuvat) = 9 opintopistettä.
• Jos haluat myös luoda WebP/AVIF: yksi next-gen-versio kutakin edellä mainittua 9:ää varten → +9 opintopistettä.
  Toisin sanoen se, mitä luulet olevan “1 kuva”, voi itse asiassa kuluttaa lähes “2-numeroisia krediittejä”.

Niinpä:“Ilmaiset 100 krediittiä” ei ole sama kuin “ilmaiset 100 kuvaa”.

ShortPixelin yleisimmät sudenkuopat

1. Ilmainen 100 krediittiä loppuu nopeasti
   Juurisyy: paljon pikkukuvia + ylimääräisiä krediittejä WebP/AVIF:n luomisesta.
   ehdotus：

• Arvioi ensin sivuston pikkukuvien määrä.
• Sulje pois tarpeettomat pikkukuvakoot (optimoi vain ne koot, joita todella käytetään).
• Määritä pakkausstrategia ennen massatulostusta, jotta vältytään toistuvilta kokeiluilta ja virheiltä.

2. Muiden muuntimien pinoaminen samaan aikaan.
   Jos sinulla on Plus WebP -korvauksia ja ShortPixel tuottaa/lisää seuraavan sukupolven tunnisteita, logiikka kasaantuu ja vianmääritys vaikeutuu. Reitti B: anna ShortPixelin tehdä se yksin.
3. Luulin, että jos asentaisin sen, se olisi “WebP/AVIF etualalla”.”
   ShortPixel-lisäosan sivuMainittiin, että se muuntaa WebP/AVIF-kuvia ja voi lisätä seuraavan sukupolven kuvia etusivulle (esim. merkitsemällä).
   On kuitenkin tärkeää tarkistaa tulokset tämän jälkeen.

---

3.2.2 ImagifyIlmainen: 20MB/kk; kiintiö vähennetään “alkuperäisen kuvan koon + pikkukuvien määrän” mukaan, toistuvat vähennykset tehdään uudelleen painamisesta.

Vapaa määrä ja paikannus

Imagifyn virallinen hintasivuKirjoitus on selkeä:Ilmainen tili Kuukausittainen 20MB Kiintiö。
Sen laajennussivulla kerrotaan myös, että se voi pakata, muuttaa kokoa ja muuntaa WebP/AVIF-muotoja.

Miten kiintiö vähennetään?

Imagify Virallinen dokumentaatio “How is Quota Usage Calculated?” selittää vähennysmekanismin hyvin selkeästi:

• Pienoiskuvien määrä vaikuttaa kulutukseenJos sinulla on esimerkiksi 10 pikkukuvakokoa, yhden kuvan optimoinnista tulee 11 kuvan optimointi (alkuperäinen + 10 pikkukuvaa), jotka kaikki vaikuttavat kiintiön kulutukseen.
• Kiintiön vähennys alkuperäisen asiakirjan koon mukaan.: Jos esimerkiksi lähetät 100KB:n kuvan Imagifyyn, 100KB vähennetään kiintiöstä.
• Pakkaustason muuttaminen ja uudelleen optimointi kuluttaa kiintiön uudelleen.。
• Samaa API-avainta voidaan käyttää useilla sivustoilla, mutta kiintiöt jaetaan niiden kesken.

Tämä on Imagifyn “keskeinen tapa ymmärtää”:
Se on enemmänkin kuin liikennepaketti: se vähentää niin paljon kuin lähetät; mitä enemmän pikkukuvia sinulla on, sitä enemmän se vähentää; ja vähennys toistuu, jos painat sitä toistuvasti uudelleen.

Helppolukuinen Imagify-kiintiöesimerkki

Oletetaan, että lataat alkuperäisen 800 kilotavun kuvan ja sivusto luo 8 pikkukuvaa.

• Imagify optimoi “alkuperäisen kuvan + 8 pikkukuvaa” (jos haluat optimoida kaikki), mikä tarkoittaa, että tämä yksittäinen toimenpide kuluttaa kiintiön, joka on lähellä “kaikkien näiden tiedostojen alkuperäistä kokoa”.
  Siksi joillakin sivustoilla tuntuu, että “20MB loppuu nopeasti”: kyse ei ole siitä, että Imagify ei riitä, vaan siitä, että lataat liian monta kuvaa kerrallaan, liian monta pikkukuvaa ja luultavasti kokeilet pakkaustasoja uudelleen ja uudelleen.

Imagifyn yleisimmät sudenkuopat

1. Vapaa 20MB Ei riitä “täydelliseen inventointiin”.”
   20MB soveltuu yleensä paremmin kevyiden päivitysten testaamiseen; jos mediakirjastosi on jo suuri, kertaluonteinen tyhjennys vaatii todennäköisesti päivityksen.
2. Tiivistystasojen toistuva säätäminen johtaa kiintiöiden päällekkäiseen kulutukseen.
   Imagify tekee selväksi, ettäUudelleenoptimointi kuluttaa kiintiön uudelleen.
   Ehdotan, että teet “strategian” selväksi tällä sivulla:

• Aloita pienellä määrällä kuvia pakkaustason ja ulkoasun määrittämiseksi.
• Määritä strategia ja aja sitten irtotavarana
  Vältä toistuvia kokeiluja ja virheitä koko kirjastossa.

3. Useiden sivustojen yhteinen API-avain johtaa “selittämättömään kiintiön pienenemiseen”.”
   Jos käytät samaa API-avainta useammalle kuin yhdelle asemalle, kiintiö jaetaan.
   Joten tiimi- tai moniasemakohtaisissa skenaarioissa on parasta tehdä selväksi, mitkä asemat ovat yhteisiä ja mitkä käytetään erikseen, jotta vältytään hallitsemattomilta budjeteilta.

---

3.2.3 TinyPNG(Tiny Compress Images): ilmaiseksi 500 krediittiä/kuukausi; siirtyminen WebP/AVIF:iin “vähentää 1 krediitin per koko”.”

Ilmaiset hyvitykset ja sen laskutusideat

TinyPNG:n WordPress-lisäosan sivu on hyvin selkeä:

• 500 krediittiä kuukaudessa ilmaiseksi
• Vuonna “Yleinen WordPress asennus”, voit luultavasti pakata Noin 100 kuvaa/kuukausi
• Jos AVIF- tai WebP-muunnos on kuitenkin käytössä:Jokainen kuvakoko kuluttaa ylimääräisen krediitinJoten oletettavasti se voidaan vain pakata ja muuntaa... Noin 50 kuvaa/kuukausi(riippuen siitä, kuinka monta pikkukuvakokoa sinulla on).

Samaan aikaan Tinify (TinyPNG/TinyJPG:n kehittäjät) on myös tehnyt oman API-hinnoittelusivuKuvaus: Rekisteröidy ja saat 500 ilmaista puristusta kuukaudessa; sen jälkeen sinua laskutetaan onnistuneiden puristusten määrän mukaan, ei pakollista tilausta.

Tiivistä yhteen lauseeseen, miten TinyPNG ymmärretään:
Se laskee krediittejä; mitä enemmän pikkukuvakokoja sinulla on ja mitä enemmän WebP/AVIF-kuvia olet ottanut käyttöön, sitä nopeammin krediittejä kuluu.

Helppolukuisia esimerkkejä TinyPNG-krediiteistä

Oletetaan, että sivustosi luo 8 pikkukuvan kokoa jokaiselle kuvalle:

• Vain pakkaus: alkuperäinen + 8 pikkukuvaa → 9 opintopistettä vaaditaan.
• Jos WebP/AVIF-muunnos on päällä: yksi lisäpiste per koko → luultavasti lähes kaksinkertainen!
  Tämä vastaa lisäosan sivulla olevaa kuvausta: kun lisäosa on kytketty päälle, ilmainen määrä muuttuu noin “100 kortista/kuukausi” “50 korttiin/kuukausi”.

TinyPNG:n yleisimmät sudenkuopat

1. Ajatus 500 krediittiä = 500 kuvaa
   Se ei ole. Sitä kuluttaa “kuvakoko/muunnos”. Lisäosan sivulla varoitetaan selvästi, että “Conversions deduct an additional 1 credit for each image size”.
2. Teemat/e-commerce-liitännäiset tuottavat liikaa kokoja ja ilmaiset krediitit laskevat merkittävästi.
   Mitä enemmän kokoja on, sitä helpommin luottoja on mahdollista skaalata ja kuluttaa.
3. Kun olet ottanut muuntamisen käyttöön, huomaat, että hyvitykset ovat yhtäkkiä käyttämättä.
   Se ei ole vika, vaan se on sen laskutusmekanismi.
   Strategianeuvoja:

• Jos ilmaista vaihetta käytetään pääasiassa pakkaamiseen ja painonpudotukseen, voit aloittaa pelkällä pakkauksella ja ottaa muuntamisen käyttöön vasta sitten, kun olet varma, että sivustosi rakenne on vakaa ja että todella tarvitset next-geniä.

4. Alaskenaarioita koskeva suositus: miten valita erityyppiset kohteet?

Myöskään WordPress-, sisältö-, verkkokauppa-, portfolio- ja jäsensivustoilla ei ole samoja “paineita” kuvien suhteen.

4.1 Sisältösivustot/blogit (paljon artikkeligrafiikkaa, päivitystiheys keskinkertainen)

Ensisijaiset suositukset:

1. Mitoitusstrategia (vaihe 1)
2. Puristus (vaihe 2)
3. WebP (vaihe 3)

Sopivampi reitti:

• Haluatko tallentaa: Route B Triple Choice (ShortPixel / Imagify / TinyPNG)
• Jos haluat mennä ilmaiseksi: Reitti A (Plus WebP + EWWW), mutta on suositeltavaa aloittaa “konservatiivisella tilalla (poistamatta alkuperäistä kuvaa)” riskin arvioimiseksi.

Tyypillinen kuoppa:

• Artikkelisivun ensimmäinen kuva on hyvin suuri, epäasianmukainen laiska latausstrategia.Hidastaa ensimmäistä näyttöä

4.2 Verkkokauppa/tuotesivusto (monia pikkukuvia, monia kuvavaihtoehtoja, vakaus ensin)

Sähköinen kaupankäynti on todennäköisimmin ongelma ei ole “pakkausvaikutus ei ole hyvä”, mutta “optimoitu osa koosta ei ole oikea, puuttuvat pikkukuvat, etukomponentit eivät saa kuvaa”.

Ensisijaiset suositukset:

1. Vakaus etusijalla: konservatiivinen pakkausstrategia, älä vaihda kirjastoa kokonaan heti.
2. Pikkukuvakokojen arviointi: sähköisen kaupankäynnin teemat tuottavat yleensä enemmän kokoja, ja kulutus kasvaa (ShortPixel/TinyPNG on erityisen huomattava).
3. Tee pienessä mittakaavassa validointi ennen erän valmistusta (erittäin kriittinen).

Sopivampi reitti:

• Reitti B on yleensä vaivattomampi: ShortPixel/Imagify/TinyPNG voivat kaikki tehdä eriä, ja on tärkeää, että ymmärrät kiintiöjärjestelmän ja arvioit kustannukset etukäteen.
• Reitti A on hyvä, mutta ole varovaisempi Plus WebP:n “korvaa tunnukset/poista alkuperäiset kuvat/korvaa URL-osoitteet” -käyttäytymisen kanssa: kyseessä on omaisuuserien siirto, eikä ole suositeltavaa korvata koko kokonaisuutta heti alkuunsa.

4.3 Portfolio-/valokuvausasema (yksittäisen kuvan laatu herkkä, suuret kuvat, suuret vaatimukset katselulle)

Ensisijaiset suositukset:

1. Kokostrategia (näyttöalueen hallinta)
2. Pakkausstrategia (parempi olla suurempi kuin murskata yksityiskohdat).
3. WebP/AVIF (suurkuvanäkymän edut ovat ilmeiset, mutta tarkista näkymä)

Sopivampi reitti:

• Imagify: Vähennä kiintiö “alkuperäisen kuvan koon” mukaan, tällainen sivusto on helpompi tehdä “budjettikontrolloitavissa” (tiedät kuinka paljon vähennettävä jokaisesta suuresta kuvasta), mutta vältä toistuvia repressioita.
• ShortPixel: Jos pikkukuvakoko ei ole suuri, krediitit ovat myös hyvin intuitiivisia; mutta jos tuotat paljon kokoja +next-gen, krediittien kulutus kasvaa, ja sinun on suunniteltava etukäteen.

5. Kiintiö- ja laskutusvertailu: “ilmainen ei riitä” oikeaan perspektiiviin.

Kumpi on parempi tarjous ja kuinka kauan ilmainen kestää?

5.1 Kolme takaisinmaksumallia

• ShortPixel(opintopisteet): Krediitit lasketaan seuraavasti: “alkuperäinen kuva + pikkukuvien määrä”; lisäkrediitti vähennetään jokaisesta vastaavasta WebP/AVIF-versiosta, joka on luotu.
• Imagify(MB-kiintiö): Vähennä kiintiötä “alkuperäisen tiedoston koon” mukaan; mitä enemmän pikkukuvia, sitä enemmän vähennyksiä; uudelleen painaminen vähentää jälleen.
• TinyPNG(opintopisteet): 500 krediittiä kuukaudessa; WebP/AVIF-muunnoksen käyttöönotto vähentää lisäkrediittejä kutakin kuvakokoa kohden.

5.2 Nopeat arviointimenetelmät

Voit arvioida sen näin:

1. Etsi satunnainen “alkuperäinen kuva, jonka lataat usein” ja katso, kuinka suuri se on (esim. 300KB / 1MB / 3MB).
2. Riippuen siitä, kuinka monta pikkukuvakokoa sivustosi tuottaa (esim. 5 / 10 / 20).
3. Päätä, haluatko luoda WebP/AVIF-tiedoston (kyllä/ei).

Käytä sitten seuraavaa “henkistä matematiikkaa” kulutuksen ymmärtämiseksi:

• ShortPixel: ≈ (1 + pikkukuvien määrä) krediittiä kuvaa kohti; jos luodaan WebP/AVIF, ≈ kaksinkertaistuu jälleen (koska myös next-gen-versio ottaa krediitin).
• Imagify: Jokainen kuva ≈ (alkuperäinen koko + kunkin pikkukuvan koko) vähentää kiintiötä; pakkaustason muuttaminen ja uudelleenpakkaaminen vähentää jälleen.
• TinyPNG: 500 krediittiä ilmaiseksi; jos sivustosi tuottaa paljon kokoja kuvaa kohden ja muuntaminen on käytössä, ilmaisten krediittien määrä laskee merkittävästi (lisäosan sivulla annetaan visuaalinen odotusarvo “~100 krediittiä/kk” vs. “~50 krediittiä/kk”).

6. Riskihälytykset

Riski 1: Älä anna useiden liitännäisten tehdä samaa asiaa yhä uudelleen ja uudelleen.

Se on yleisin “katastrofin lähde”.”

• Reitti A:Plus WebP tai AVIF + EWWW(Jaa työ näiden kahden välillä, älä tee samanlaisia muunnoksia ja toimituksia samaan aikaan tai asenna vain toinen niistä.)
• Reitti B: ShortPixel / Imagify / TinyPNG valitse kolme(valitse yksi pakattavaksi next-genillä)

Riski 2: Plus WebP:n “Korvaa ID / Poista alkuperäinen kuva / Korvaa URL-osoite” on omaisuuden siirto.

Korostus lisätty:Plus WebP Kuvauksessa todetaan selvästi, että täysi sukupolvi korvaa alkuperäisen kuvatunnuksen, poistaa alkuperäisen tiedoston ja korvaa sisällön URL-osoitteen.
Tämä tarkoittaa, että kyseessä ei ole “pieni asetus, joka voidaan peruuttaa milloin tahansa”, vaan varallisuustason muutos.

Suositeltava strategia olisi oltava:

• Pieni testi ensin (muutamasta kymmenestä muutamaan sataan).
• Vahvista, että etusivun näyttö, pikkukuvat ja välimuistin päivitykset toimivat oikein.
• Harkitse uudelleen koko kirjaston käsittelyä

Riski 3: Pilvipakkauksen “ilmaisten krediittien” todellinen kulutus riippuu pikkukuvien määrästä ja next-gen-valinnasta.

• ShortPixel: Pienoiskuvat ja next-gen vaikuttavat merkittävästi krediitteihin.
• TinyPNG: WebP/AVIF:n ottaminen käyttöön vähentää lisähyvityksen kutakin kuvakokoa kohti.
• Imagify: vähennetään alkuperäisen kuvan koon mukaan, mitä enemmän pikkukuvia vähennetään enemmän, voimakas paine toistaa vähennyksen!

Riski 4: “WebP/AVIF generoitu” ei tarkoita, että “WebP/AVIF toimitetaan etutoimistosta”.”

Monista ihmisistä tuntuu, että muuntamisen jälkeen “ei ole nopeampaa”, koska etusivu tuottaa edelleen JPG/PNG:tä (välimuistitallennus/uudelleenkirjoitus/tunnistaminen/selainneuvottelut eivät ole oikeassa paikassa).

7. Miten tarkistetaan, että se on tullut voimaan sen jälkeen, kun se on tehty?

4 hyvin yksinkertaista validointipistettä:

1. Päivittyykö sama sivu toisen kerran ja latautuuko se tasaisemmin ja nopeammin?(Välimuistitallennus ja optimointi fyysinen tunne siitä, toimiiko se).
2. Onko matkapuhelimiin ja pöytätietokoneisiin ladattujen kuvien koot merkittävästi erilaiset?(reagoiva) srcset/sizes (riippumatta siitä, toimivatko ne vai eivät)
3. Tarkista pistokokein muutama kuva: onko WebP- tai AVIF-tiedostoja/resursseja mukana.(Käyttääkö sivusto todella seuraavan sukupolven）
4. Tutki muutamaa kuvaa: suurenna ja katso, ovatko ne selvästi epäselviä, onko teksti epäselvää...(puristettu massa ei ole liiallinen)

Jos kaikki neljä näistä täsmäävät, valitsemasi reitti on ajettu. Seuraavaksi. CDN “Toimituskerros”, kokonaisuus on vakaampi.

8. Toimenpidesuositukset

1. Valitse reitti ensin:

• Yritän olla mahdollisimman vapaa.: Plus WebP tai AVIF + EWWW (tai vain yksi niistä)
• Haluatko säästää palvelimen resursseja, maksaa määrän mukaan enemmän huolestuttavaa: ShortPixel / Imagify / TinyPNG - valitse yksi!

2. Tee ensin pieni testi (muutama kymmenen).
3. Varmista, että se on kunnossa ennen erän valmistamista.
4. Toimitusvakautta on parannettava edelleen:lue CDN Kiihtyvyys

yleiset ongelmat

1. Kuinka monta lisäosaa minun on asennettava? Voinko asentaa ne kaikki?

Yritä kulkea vain yhtä reittiä.

• Reitti A: Plus WebP tai AVIF + EWWW Image Optimizer (tai vain yksi niistä).
• Reitti B: ShortPixel / Imagify / TinyPNG - valitse yksi!
  Samalla asemalla samaan aikaan anna useamman kuin yhden plug-inin tehdä “pakkaus / siirto WebP / AVIF / muutos URL / toimitus uudelleenkirjoittaa”, todennäköisimmin saada enemmän ja enemmän kaoottinen, mutta myös vaikein tarkistaa.

2. Eikö WordPress jo tue WebP/AVIF:ää? Tarvitsenko vielä lisäosan?

Se on erotettava toisistaan:
“Tuki lataamiselle/käytölle” ≠ “Automaattinen muuntaminen/automaattinen toimitus”.
WordPress 6.5 ei myöskään automaattisesti eräkonvertoi vanhoja JPG/PNG-tiedostoja WebP/AVIF:ksi, eikä se tee automaattisesti koko “AVIF/WebP-vientiä selaimelle, joka pystyy selaimeen ja fallbackiin” -juttua puolestasi. Se vaatii yleensä lisäosan tai palvelun, jotta historiallinen mediakirjasto toimisi.

3. Mikä on “palkitsevin” vaihe kuvan optimoinnissa?

Se on yleensä Määritä ensin “koot” oikein (srcset/sizes).。
Monet sivustot eivät ole hitaita siksi, että niillä ei ole pakkausta, vaan siksi, että sivu on vain 900 pikseliä ja käyttäjää pyydetään lataamaan 3000 pikseliä pitkä kuva. Pakkaus säästää kilotavua, mutta “väärän kokoinen” kuva saa käyttäjän lataamaan moninkertaisen määrän dataa turhaan.

4. Miten voin olla varma, että lataan “pienemmän” enkä alkuperäistä kuvaa ikuisesti?

Tarkastellaan kahta ilmiötä:

• Kun sivu avataan matkapuhelimella, ladatun kuvan koko on huomattavasti pienempi kuin työpöydällä.
• Sama kuva latautuu eri resurssikokojen kanssa eri laitteilla.
  Jos alkuperäistä kuvaa ladataan ikuisesti, yleinen syy on, että teema/rakentaja käsittelee kuvaa CSS-taustakuvana tai mukautettuna tulosteena ohittaen mediakirjaston monikokoisuuden srcsetillä.

5. Tarkoittaako “WebP/AVIF generated” sitä, että frontendin on tuotettava WebP/AVIF?

Eivät ole tasa-arvoisia.
Generointi on vain “tiedostokerros”; se, toimittaako etusivu todella WebP/AVIF-tiedostot, riippuu uudelleenkirjoituksista, kuvien merkintäkäytännöistä, välimuistiin osumista, selaimen voimassa olevista neuvotteluista ja niin edelleen. Kun olet valmis, muista “tarkistaa pistokokein muutama kuva resurssityyppien osalta”.

6. Plus Mitä vaarallista WebP:ssä tai AVIF:ssä on? Voinko ajaa koko kirjaston yhdellä napsautuksella?

Sen riskipiste ei ole “puristus”, vaan se onMuutokset omaisuuserien siirtymätasoissa：

• Täydellinen luominen voi korvata alkuperäisen kuvatiedoston tunnuksen, poistaa alkuperäisen tiedoston ja korvata URL-osoitteen sisällössä.
  miksiKoko kirjastoa ei kannata vaihtaa heti alkuun.: Testaa pienessä mittakaavassa (kymmenistä satoihin) + ota varmuuskopiot käyttöön ennen kuin harkitset koko kirjaston käsittelyä.

7. Mikä on valinta Plus WebP:n kahden tilan välillä: alkuperäisen kuvan säilyttäminen vs. alkuperäisen kuvan korvaaminen ja poistaminen?

Helppo ymmärtää:

• Tila 1: Säilytä alkuperäinen kuva + luo WebP/AVIF-kopio (vakaampi).: Kätevä palautuksia varten, mutta levy kasvaa (alkuperäinen kuva + uusi formaatti + monikokoiset pikkukuvat).
• Tila 2: Korvaa ja poista alkuperäinen kuva (aggressiivisempi).: Levyt ovat vähemmän alttiita paisumiselle, mutta “vaihdat resursseja + vaihdat viittauksia”, mikä tekee yhteensopivuusongelmien korjaamisesta kalliimpaa.
  Mitä monimutkaisempi sivusto on (verkkokauppa/monimutkainen liitännäinen/monikokoinen), sitä suositeltavampaa on aloittaa vakaammalla mallilla.

8. Riittääkö EWWW Image Optimizer -ohjelman ilmainen paikallinen pakkaus? Ylikuormittaako se palvelimen?

EWWW on enemmänkin “paikallinen kompressori”: se syö CPU/IO:ta.
Kuormitus kasvaa usein erän optimoinnin aikana, mikä ei tarkoita, ettei se “toimi”, vaan pikemminkin sitä, että strategian pitäisi olla oikea: erän käyttö, alhaiset huippuarvot ja tarvittaessa offloading-/pilvipalveluvaihtoehdot.
Jos etsit säästöjä tai jos palvelinresurssit ovat vähissä, reitti B on palvelinystävällisempi.

9. ShortPixelin 100 ilmaista krediittiä/kuukausi, miksi minusta tuntuu, että se on mennyt muutamassa kuvassa?

seuraavista syistä hyvitys ei ole “kuvien määrä”.”Next-gen suurennetaan pienoiskuvalla next-genillä:

• Alkuperäinen kuva + jokainen pikkukuva lasketaan krediitiksi.
• Jos luodaan WebP/AVIF-tiedosto, kuluu lisäkrediitti kutakin vastaavaa versiota varten.
  Joten se, mitä luulet olevan “1 kuva”, voi itse asiassa kuluttaa lähes “2-numeroisia krediittejä”. shortPixel

10. Imagifyn ilmainen 20MB/kk, miksi sekin loppuu nopeasti?

Imagify on enemmänkin “liikennepaketti”:

• Kuten lähetit sen.Alkuperäisen tiedoston kokokiintiöiden vähentäminen
• Mitä enemmän pikkukuvia sinulla on, sitä enemmän kulutat rahaa.
• Pakkaustason muuttaminen uudelleen optimoimiseksi kuluttaa kiintiön uudelleen.
• Sama API-avain useille sivustoille, kiintiöiden jakaminen
  Joten “20MB loppuu pian” johtuu usein liian suurista kuvista, liian monista pikkukuvista tai toistuvista kokeiluista ja virheistä.

11. TinyPNG on ilmainen 500 krediittiä/kuukausi, miksi plugin sanoo, että se on vain noin 100 krediittiä/kuukausi ja sitten 50 krediittiä/kuukausi WebP/AVIF:n kanssa?

Koska TinyPNG-krediittejä suurennetaan myös “size/variant” -menetelmällä:

• Tavallinen WordPress-asennus pakkaa luultavasti noin 100 arkkia kuukaudessa.
• Ota AVIF- tai WebP-muunnos käyttöön:Jokainen kuvakoko kuluttaa ylimääräisen krediitinVoit siis luultavasti pakata ja muuntaa vain noin 50 kuvaa kuukaudessa (riippuen pikkukuvien koosta).
  Joten 500 krediittiä ≠ 500 kuvaa.

12. Kuinka monta pikkukuvaa sivustollani on? Miksi sillä on niin paljon merkitystä?

WordPress luo useita eri kokoja kuvan lataamista varten; teemat/pluginit (erityisesti verkkokauppa) voivat lisätä lisää kokoja.
Pilvipakkauksen krediitit/kiintiöt ovat yleensä “alkuperäinen + pikkukuvat yhdessä”, joten mitä enemmän pikkukuvia sinulla on, sitä vähemmän vapaita krediittejä sinulla on käytettävänä.

13. Onko laiska lataus aina nopeampaa? Miksi jotkut sanovat, että laiska lataaminen hidastaa toimintaa?

Laiska lataus sopii “näytön ulkopuolisille resursseille”.
Jos ensimmäinen näyttö kriittisin suuri kuva on myös viivästynyt lataus, voi hidastaa ensimmäisen näytön kokemus. WordPress 5.5 koska oletuksena laiska lataus on hieno, mutta älä “yksi koko sopii kaikille”.

14. Matkustan reitillä A tai B. Milloin tarvitsen CDN / Kuva CDN?

Pakkaaminen, koon määrittäminen ja muotoilu ratkaisevat “pienempien, sopivien tiedostojen” ongelman;
CDN Ratkaisu on tarjota lähempänä ja vakaampi。
Kun kuvia vedetään kaukaa lähdesivustosta, mikä aiheuttaa merkittävää latenssia, niin CDN:n/kuvien täydentäminen CDN:llä (esim. Cloudflare Polish / Jetpack Site Accelerator) on kaiken kaikkiaan vakaampaa, lue WordPress CDN Kiihdytys。

15. Mikä on helpoin tapa varmistaa, että “se todella toimii”, kun olen valmis?

Ajallisesti tehokkain tarkastusmenetelmä:

• Päivittyykö sama sivu toisen kerran ja latautuuko se tasaisemmin ja nopeammin?
• Ovatko matkapuhelimissa ja pöytätietokoneissa ladattujen kuvien koot huomattavan erilaiset (vaikuttaako srcset/sizes asiaan)?
• Tarkista pistokokein muutama kuva: onko WebP- tai AVIF-tiedostoja/resursseja mukana.
• Tutki muutamaa kuvaa: suurenna ja katso, ovatko ne selvästi epäselviä, onko teksti epäselvää...