Ofbyldingsoptimalisaasje foar websiden

Ofbyldingsoptimalisaasje is ien fan de meast “heech-rendabele” ûnderdielen fan WordPress-prestaasjes: mei deselde side-opbou en itselde tema ferbetteret de laadûnderfining faak daliks, salang’t de triemgrutte, ôfmjittings, opmaak en leveringswize fan ôfbyldings goed ynsteld binne.

Mar ôfbyldingsoptimalisaasje soarget der ek it maklikst foar dat men it “hieltyd rommeliger” makket; de reden is net dat de technyk te dreech is, mar dat de ynformaasje te fersnippere is:
Do hast in pear artikels lêzen en witst fan “komprimearje”, “WebP/AVIF” en “lazy loading”, en dan sjochst by de plugin-yntroduksje wer “100 credits fergees yn ”e moanne“, ”20MB fergees“, ”1 credit per ôfbylding“, en úteinlik wurdst allinnich mar betiiziger — is it fergees no eins genôch? Hoe wurde de kosten ôflutsen? Hasto ”itselde ding” miskien ferkeard begrepen? En it wichtichste:Hat it nei'tsto it dien hast eins wol echt effekt hân?

Dit artikel docht mar trije dingen:

1. Jou in útfierbereRoadmap(Earst wat dwaan, dan wat dwaan)
2. Lis dúdlik út hokker opsjesto kieze wolst (wat is krekt it ferskil tusken fergees en betelle, en foar wa is elk geskikt)
3. Skriuw de meast foarkommende falkûlen foarôf op, sadatst net nei ôfrin oeral sykje hoechst om problemen út te finen

1. Basislaach: wat WordPress standert meibringt, en wat net

Asststo net earst begrypt wat de WordPress-kearn al dien hat, komme der maklik twa situaasjes foar:

• De fergese mooglikheden dy't jo brûke koenen, binne net benut, en ynstee is tiid/jild fergriemd oan it opnij útfinen fan it tsjil
• Tinke dat WordPress âlde ôfbyldingen automatysk nei WebP/AVIF omsette soe, mar dat docht it net

WordPress-kearn hat dizze wichtige mooglikheden al ynboud:

• Responsive ôfbyldingen (srcset/sizes): fan WordPress 4.4 ôf sil de kearn foar ôfbyldingen útfiere srcset 与 sizesen de by it uploaden oanmakke ôfbyldingen yn meardere formaten brûke, sadat de browser op basis fan de skermomstannichheden in passender boarne lade kin.
• Native lazy loadingSûnt WordPress 5.5 is native lazy loading standert ynskeakele foar ôfbyldingen, mei de HTML-standert loading Attribút ymplemintaasje.
• WebP-upload stipeFan WordPress 5.8 ôf kinst WebP uploade en brûke, krekt as JPEG/PNG, as de hostomjouwing WebP stipet.
• AVIF-upload stypjeFan WordPress 6.5 ôf kinne jo AVIF krekt as JPEG/PNG uploade en brûke (ek ôfhinklik fan stipe fan de hostingomjouwing).

Mar tink derom:
“Uploaden/brûken stypje ≠ automatysk konvertearje/automatysk leverje
Dat wol sizze: sels as dyn side al op WP 6.5 draait, sille dy JPG/PNG-bestannen yn dyn mediabibleteek net út harsels WebP/AVIF wurde; en do krijst ek net automatysk de folsleine keten fan “AVIF/WebP útleverje neffens wat de browser stipet, en foar browsers sûnder stipe weromfalle op it orizjinele byld” — dat part freget meastentiids om in plugin of tsjinst om it oan te foljen.

2. Roadmap: ôfbyldingsoptimalisaasje yn 5 stappen

Wat te dwaan, wêrom, wat as foldwaande jildt, en wat de typyske falkûlen binne.

2.1 Meitsje earst de “grutte” goed (it wurdt it maklikst oer de holle sjoen, mar leveret it measte op)

In protte trage siden binne net trochdat kompresje net dien is, mar trochdatIn grutte ôfbylding ynladen dy’t folle grutter is as it werjeftegebiet：
Bygelyks wurdt op de side eins mar 900 px breedte werjûn, mar litst de besiker dochs de orizjinele ôfbylding fan 3000 px downloade; de browser docht dan allinnich mar “earst downloade en dan lytser werjaan”. Dat fergriemt bânbreedte, fergruttet de dekodeartiid en fertraget de earste werjefte.

fan WordPress 4.4+ ôfResponsive ôfbyldingsmeganisme（srcset/sizes) krekt om dit probleem op te lossen.

Wat telt as foldwaande:

• By it iepenjen fan de side op in telefoan moat de grutte fan de ynladen ôfbyldingen dúdlik lytser wêze as op it buroblêd
• Deselde ôfbylding lade op ferskate apparaten ferskillende bestânsgruttes yn

Meast foarkommende falstrikken:

• Guon tema's/builders brûke ôfbyldingen as CSS-eftergrûn of toane se op in eigen wize, wat dit mooglik omgean kin srcset, wêrtroch der hieltyd grutte ôfbyldings laden wurde
• As jo eksterne ôfbyldingshosting of in ôfbyldingsblok fan tredden brûke, kin dat ek it systeem mei meardere maten fan de mediabibleteek omgean

---

2.2 Komprimearje (minder KB, mar druk de kwaliteit net “stikken”)

De kearn fan kompresje is net “hoe lytser, hoe better”, mar “mei it bleate each hast gjin ferskil te sjen, wylst de bestânsgrutte dúdlik ôfnimt”.

De regels binne as folget:

• Foto's/echte opnamen (minsken, produkten, lânskip): Ferliesjende kompresje earst (grutste winst)
• Skermôfbylding/ôfbylding mei in soad tekst: de kompresje moat foarsichtiger wêze om tefoaren te kommen dat tekst wazich wurdt
• Logo/ikoan: Jou foarrang oan SVG of brûk mei foarsichtigens ferliesleas (mei ferlies wurde de rânen maklik wazich)

Wat telt as foldwaande:

• De measte sideôfbyldingen binne dúdlik lytser wurden
• Gjin dúdlike lûdsoer, wazige rânen, kleurbanding of wazige tekst

---

2.3 WebP / AVIF (formaatstrategy: lytser by deselde skerpte)

WordPress stipet no uploads WebP (5.8) en AVIF (6.5)。
Mar om “folgjende-generaasje-formaten” echt te brûken, moatte meastal twa dingen oplost wurde:

1. Hoe kinne jo de histoaryske mediabibleteek yn bulk konvertearje(Oars hawwe jo allinnich de “nije ôfbyldingen dy't letter upload wurde” optimalisearre)
2. In kopy oanmeitsje, of de orizjinele ôfbylding ferfange(Dit is de skiedingsline foar risiko; hjirnei leit de klam op “ferfange en de orizjinele ôfbylding wiskje” fan Plus WebP)

Oanrikkemandearre skriuwwize:

• WebP: meastal as standert earste kar (stabilere kompatibiliteit)
• AVIF: fierdere kompresjerjochting, geskikt foar grutte ôfbyldings/hero-ôfbyldings/albymôfbyldings (mar minderFereasket stipe nedich）

---

2.4 Lazy loading moat goed brûkt wurde (net alles oer ien kam skere)

Fan WordPress 5.5 ôfStandert lazy loadingOfbylding.
It kin it bânbreedtegebrûk by de earste rendering ferminderje:

• Lazy loading is geskikt foar boarnen bûten it skerm“
• De wichtichste grutte ôfbylding op it earste skerm is faak net geskikt om letter te laden

---

2.5 Leveringslaach: CDN / Ofbylding CDN

Kompresje, ôfmjittings en bestânsformaat lossen op dat in bestân lytser en gaadliker is.
Mar as ôfbyldingen altyd fan de boarnesite oer in grutte ôfstân laden wurde, sil netwurkfertraging de ûnderfining noch altyd dúdlik beynfloedzje. Dan is in oplossing op “leveringslaach”-nivo nedich (CDN/ôfbylding CDN).

Twa typyske rjochtingen:

• Cloudflare Polish：Cloudflare dokumintaasjeYntrodusearre de kompresjemetoaden fan Polish (ferliesfrij/ferliesjend/WebP), en neamde it gebrûk fan format=auto WebP/AVIF-formaat tastien.
• Jetpack Site Accelerator：Jetpack dokumintaasjeFerklearje dat it ôfbyldingen optimalisearret en tegearre mei statyske assets fia syn netwurk ferspraat.

Ofbyldingsoptimalisaasje makket lytser en passenderCDN ferantwurdlik foar tichtere en stabilere levering

3. Kar: allinnich twa haadrûtes

De meast foarkommende mislearring by ôfbyldingsoptimalisaasje is net “gjin plugin ynstallearre”, mar dat der tefolle plugins ynstallearre binne, wat ta dûbele ferwurking liedt:
A is oan it komprimearjen, B ek; A set om nei WebP/AVIF, B ek; A past de URL oan, B skriuwt wer opnij — úteinlik kinst sels net mear dúdlik sizze wat der no eins op de side bart.

Regels:

Rin mar ien rûte: of hielendal fergees lokaal, of kies ien fan de trije wolkekompresje-opsjes.

• Rûte A (folslein fergees lokaal):Plus WebP of AVIF + EWWW Image Optimizer(of kies mar ien)
• Rûte B (kies ien fan trije foar wolkkompresje):ShortPixel / Imagify / TinyPNG

---

3.1 Rûte A: folslein fergees lokaal (Plus WebP of AVIF of EWWW)

Dizze rûte hat as skaaimerken:

• Do bist net ôfhinklik fan in kompresjetsjinst fan tredden mei moanlikse limyt of betelling per ôfbylding (guon funksjes kinne fansels ek as opsjonele tsjinst oanbean wurde)
• De priis is: batchferwurking kin mear fan de server CPU/IO freegje, en freget fan dy mear omtinken foar strategy en risiko“

3.1.1 Plus WebP of AVIFKearn is “generearje/ferfange”, net in tradisjoneel “kompresje-ark”

• By it generearjen fan alle ôfbyldingen:Oarspronklike ôfbyldingsbestân-ID wurdt oerskreaun troch WebP/AVIF, it oarspronklike bestân wurdt fuortsmiten en URL's yn de ynhâld wurde ek ferfongen。
• De plugin biedt WP-CLI-kommando’s en jout oan: by in soad bestannen is WP-CLI betrouberder.

Dit betsjut: it is net “stiekem in WebP foar dy oanmeitsje”, mar mooglik in kearAssetmigraasje(benammen as jo de besibbe opsje “Ferfange en orizjinele ôfbylding fuortsmite” ynskeakelje).

Ferskil tusken de twa modi

Modus 1: bewarje orizjinele ôfbylding + meitsje WebP/AVIF-kopyen (stabiler)

• Foardielen: by kompatibiliteitsproblemen is it makliker om werom te gean
• Neidiel: it skiifgebrûk sil tanimme (orizjinele ôfbylding + nij formaat + miniatueren yn meardere formaten)

Modus 2: Ferfange en wiskje de orizjinele ôfbylding (agressiver)

• Foardielen: de skiif groeit net sa hurd op; ynterne ferwizingen wurde streekrjocht omset nei it nije formaat
• Risiko: as do “asset oanpasse + ferwizingen oanpasse”, wurde de kosten foar it opspoaren fan kompatibiliteitsproblemen heger (benammen as guon eksterne systemen of tema-logika ôfhinklik binne fan de oarspronklike bestânsnamme/paad/opmaak)

Typyske problemen mei Plus WebP of AVIF

1. Nei folsleine bibleteekferfanging wurde op guon siden ôfbyldingen net goed werjûn
   De oarsaak is meastentiids net dat “de ôfbylding stikken is”, mar dat der yn de keatling fan URL-ferfanging, cache, miniatuerstrategy en soksoarte dingen earne wat net goed opinoar oanslút.
2. Hoe mear miniatueren, hoe grutter it oanpassingsberik
   By it uploaden fan in ôfbylding makket WordPress meardere formaten oan; tema's/plugins kinne noch mear formaten tafoegje. Folslein ferfangen betsjut datst miskien in grutte samling bestannen oanpast.
3. Allinnich opmaak oerdrage betsjut net dat de triemgrutte altyd it lytst is
   WebP/AVIF is meastal lytser, mar “gruttestrategy” en “kompresjestrategy” bliuwe tige wichtich. Sjoch Plus WebP net as “ien klik flugger”.

---

3.1.2 EWWW Image Optimizer: in foarbyld fan fergese lokale kompresje

De posisjonearring fan de EWWW-pluginpagina is tige dúdlik:

• It kin op dyn server optimalisearre wurde mei in rige ark (jpegtran, optipng, pngout, pngquant, gifsicle, cwebp, ensfh.)
• As jo hegere kompresje of minder CPU nedich hawwe, kinne jo ek de ferwurking dy't CPU ferbrûkt nei syn server útbesteegje (opsjoneel).

Hokker rol moat EWWW yn rûte A spylje?

As jo Plus WebP brûkst foar formaatmigraasje/ferfangingsstrategy, dan is EWWW better geskikt foar:

• Kompresje en grutte-optimalisaasje(benammen it ferminderjen fan de grutte fan oarspronklike boarnen lykas JPG/PNG)
• Skiednis fan batchoptimalisaasje fan de mediabibleteek(rjochte op “fermindering fan grutte”, net op “URL ferfange”)

Typyske falstrikken fan EWWW

1. Serverlêst nimt ta by batchoptimalisaasje
   Om’t lokale kompresje gewoan CPU/IO opslokt. De oplossing is net “net brûke”, mar “yn batches, bûten piektiden, en as it nedich is kieze foar offload-/wolkoplossingen”.
2. “WebP oanmakke” betsjut net dat de foarkant perfoarst WebP útfiert
   In protte plugins hawwe dit misferstân: generearjen is ien ding, leveringsstrategyen (herskriuwen, picture-tag, cache-treffer ensfh.) binne wat oars.
3. Docht itselde as oare plugins
   Assto rûte A nimst, stapel dan sa folle mooglik gjin wolkkompresje lykas ShortPixel/Imagify/TinyPNG derby; as do rûte B nimst, set dan de ferfanglogika fan Plus WebP net mear oan. It kearnprinsipe:Ien rûte oant de ein ta.

---

3.2 Rûte B: kies 1 fan 3 foar wolkkompresje (ShortPixel / Imagify / TinyPNG)

Dizze rûte is geskikt foar minsken dy't serverboarnen besparje wolle, makliker yn batches wurkje wolle en beteljen op basis fan limyt of gebrûk akseptearje.
Mar it punt dat by cloud-kompresje it maklikst ta misferstannen liedt, is:It fergese tegoed is net sa simpel as allinnich “fergees oantal”It oantal thumbnailgruttes, oft WebP/AVIF oanmakke wurdt, en oft der werhelle kompresje is, hawwe allegear grutte ynfloed op it ferbrûk.

Hjirûnder wurdt útlein: hoe’t fergees/betelle wurket, hoe’t it kwotum ôfskreaun wurdt, hokker falkûlen it meast foarkomme, en foar hokker soarten websiden it gaadlik is.

---

3.2.1 ShortPixel100 fergese credits/moanne, mar credits wurde flugger opmakke troch miniatueren en WebP/AVIF

Wat is der mei fergees/betelle?

De beskriuwing fan de ShortPixel-plugin seit dúdlik:

• 100 fergese credits yn ’e moanne
• Ekstra ûnbeheinde moanlikse credits beskikber
• Ek biede ek “ienmalige credits-pakketten dy't nea ferrinne” oan (mei in startpriis)

Taljochting:

• Fergees: elke moanne in bepaald oantal credits, foar lytse sites of testen
• Ienmalich pakket: geskikt foar sites mei in grutte mediabibleteek dy't dy yn ien kear leechmeitsje wolle (ien kear keapje en brûke oant it op is, meastal sûnder ferfaldatum)
• Moanliks/ûnbeheind: geskikt foar websiden mei trochgeande ôfbyldingsupdates en lange-termyn stabile optimalisaasje

De offisjele KB fan ShortPixel joech ek oer “ienmalich pakket vs ûnbeheind moanliks”Dúdlike útlis: Unlimited Monthly wurdt moannebliks (of jierliks) betelle, biedt ûnbeheinde credits, en komt mei in fêste CDN-kwota; ienmalige credits ferrinne net, sadatst se mear kontroleare nei ferlet brûke kinst.

It wichtichste: hoe wurde de credits fan ShortPixel berekkene?

Offisjele dokumintaasje fan ShortPixel KB seit it tige rjochtút:

• As jo ien ôfbylding nei WordPress uploade, wurde der meardere miniatueren oanmakke;
• Elke optimalisaasje fan in miniatuer kostet 1 credit；
• As jo kieze om WebP of AVIF te generearjenFoar elke orizjinele ôfbylding en miniatuer kostet de WebP/AVIF-ferzje 1 ekstra credit；
• Do kinst bepaalde miniatueren útslute fan optimalisaasje om it ferbrûk fan credits te ferminderjen.

credits foarbyld：

Stel dat jo 1 ôfbylding uploade, dan genereart it tema/de plugin 8 miniatueren:

• Allinnich de orizjinele ôfbylding + miniatuerôfbyldings optimalisearje: 1 (orizjinele ôfbylding) + 8 (miniatuerôfbyldings) = 9 credits
• As ek ek WebP/AVIF generearje wol: foar de 9 hjirboppe komt der fan elk noch in next-gen ferzje by → dan +9 credits
  Dat wol sizze, do tinkst dat it “1 ôfbylding” is, mar yn werklikheid kin it hast “in twasifers tal credits” kostje.

Dus:“Fergees 100 credits” betsjut net “fergees 100 ôfbyldings”.

De meast foarkommende flaters fan ShortPixel

1. Fergees 100 credits reitsje gau op
   Oarsaak: mear miniatueren + ekstra credits foar it oanmeitsjen fan WebP/AVIF
   Suggestje：

• Earst it oantal sideskeamkes beoardielje
• Skeakel ûnnedige miniatuermaten út (optimalisearje allinnich maten dy't echt brûkt wurde)
• Bepaal earst de kompresjestrategy en ferwurkje dan yn batches, om werhelle besykjen en flaters te foarkommen

2. Tagelyk oare konverzjeplugins oerlizze
   As jo ek Plus WebP-ferfanging oansette en ShortPixel next-gen-tags generearje/ynfoegje litte, stapelt de logika him op en wurdt it dreger om problemen op te spoaren. Opsje B lit ShortPixel dit allinnich ôfhannelje.
3. Tinke dat as it ynstallearre is, de foarkant perfoarst WebP/AVIF útjout“
   ShortPixel-pluginpaginaNeamt dat it WebP/AVIF omsette kin en next-gen ôfbyldingen oan de frontend-side tafoegje kin (bygelyks fia tags)
   Mar jo moatte it effekt noch kontrolearje nei't it dien is.

---

3.2.2 ImagifyFergees 20MB/moanne; kwota wurdt ôfskreaun op basis fan “orizjinele ôfbyldingsgrutte + tal miniatueren”, opnij komprimearje lûkt nochris ôf

Fergese limyt en posysjonearring

Offisjele priisside fan ImagifyDúdlik skreaun:Fergees akkount mei in moanliks kwotum fan 20MB。
De pluginpagina jout ek dúdlik oan dat it ôfbyldingen komprimearje, de grutte oanpasse en nei WebP/AVIF omsette kin.

Hoe wurdt it kwotum ôflutsen?

Offisjele dokumintaasje fan Imagify “Hoe wurdt kwotagebrûk berekkene?” leit it kostenmeganisme hiel dúdlik út:

• It oantal miniatueren hat ynfloed op it ferbrûkBygelyks, as jo 10 miniatuerôfmetingen hawwe, dan wurdt it optimalisearjen fan 1 ôfbylding it optimalisearjen fan 11 ôfbyldingen (de oarspronklike ôfbylding + 10 miniatueren); dy telle allegear mei foar it ferbrûk fan it kwotum.
• Neffens de orizjinele bestânsgrutte fan it kwotum ôflûkeBygelyks as asto in ôfbylding fan 100 KB nei Imagify stjoerst, wurdt der 100 KB fan it kwotum ôflutsen.
• Feroarje it kompresjenivo en optimalisearje opnij; dit ferbrûkt de quota opnij。
• Deselde API-kaai kin foar meardere siden brûkt wurde, mar it kwotum wurdt tusken dy siden dield.

Dit is de “kearnbegrypmetoade” fan Imagify:
It liket mear op in gegevensbundel: watsto ek joust, dat wurdt ôfskreaun; hoe mear miniatuerôfbyldings, hoe mear der ôfskreaun wurdt; as do it hieltyd wer swier komprimearrest, wurdt it opnij ôfskreaun.

Maklik te begripen foarbyld fan Imagify-kwota

Stel datst in orizjinele ôfbylding fan 800 KB uploadest, en de side 8 miniatuerôfbyldingen generearret.

• By it optimalisearjen nimt Imagify sawol de “orizjinele ôfbylding + 8 miniatueren” mei (as jo kieze foar alles optimalisearje), wat betsjut dat dizze aksje hast it kwotum ferbrûkt fan “de totale oarspronklike grutte fan al dizze bestannen”.
  Dêrom fiele guon websiden dat “20MB gau op is”: net om’t Imagify net genôch is, mar om’t de ôfbyldingen dy’tst eltse kear uploadst te grut binne, der te folle miniatueren binne, en ast mooglik ek hieltyd wer ferskillende kompresjenivo’s útprobearrest.

De meast foarkommende pitfalls fan Imagify

1. Fergees 20MB net genôch foar “folsleine side-skiednis-opromming”
   20MB is meast geskikt foar testen en lichte updates; as dyn mediabibleteek fan natuere al grut is, sil in folsleine opskjinaksje yn ien kear nei alle gedachten in upgrade fereaskje.
2. It hieltyd oanpassen fan it kompresjenivo soarget foar dûbel ferbrûk fan it kwotum
   Imagify dúdlik útlizzeOpnij optimalisearje sil opnij kwota ferbrûke.
   Ik advisearje dy om op dizze side it “belied” dúdlik te beskriuwen:

• Brûk earst in pear ôfbyldingen om it kompresjenivo en de fisuele yndruk te bepalen
• Nei it fêststellen fan de strategy yn batch útfiere
  Foarkom werhelle probearjen op de hiele databank

3. Deselde API-kaai foar meardere siden soarget foar ûnferklearber minder kwota“
   As jo deselde API-kaai op meardere siden brûke, wurdt it kwotum dield.
   Dus yn team-/multi-site-senario’s is it it bêste om dúdlik fêst te lizzen: hokker sites dielde wurde en hokker apart brûkt wurde, om foar te kommen dat it budzjet net mear te behearskjen is.

---

3.2.3 TinyPNG(Tiny Compress Images): fergees 500 credits/moanne; nei WebP/AVIF omsette kostet “1 ekstra credit per grutte”

Fergese limyt en hoe’t it yn rekken brocht wurdt

De WordPress-pluginpagina fan TinyPNG is hiel dúdlik skreaun:

• 500 credits fergees yn ’e moanne
• Yn in “standert WordPress-ynstallaasje” kin it sawat komprimearre wurde Sawat 100 ôfbyldingen/moanne
• Mar as AVIF- of WebP-konverzje ynskeakele is:Elke ôfbyldingsgrutte kostet in ekstra creditDêrom kin it wierskynlik allinnich komprimearre en omset wurde Likernôch 50 ôfbyldingen/moanne(Ofhinklik fan hoefolle thumbnail-grutten jo hawwe).

Tagelyk is Tinify (de ûntwikkelder fan TinyPNG/TinyJPG) ek yn syn API-priissideFermeld dúdlik: by registraasje krije jo alle moannen 500 fergese kompresjes; dêrnei wurdt der per suksesfolle kompresje ôfrekkenje, sûnder ferplichte abonnemint.

Fetsje yn ien sin gear hoe’t TinyPNG it begrypt:
It telt op basis fan credits; hoe mear thumbnailformaten en hoe mear WebP/AVIFst ynskeakelst, hoe flugger credits ferbrûkt wurde.

Maklik te begripen TinyPNG-credits foarbyld

Stel dat jo side foar elke ôfbylding 8 miniatuergrutten oanmakket:

• Allinnich komprimearje: orizjinele ôfbylding + 8 miniatueren → 9 credits nedich
• As WebP/AVIF-konverzje ynskeakele is: foar elke grutte wurdt nochris in credit ôflutsen → kin hast ferdûbelje
  Dit komt krekt oerien mei de útlis op de pluginpagina: nei it ynskeakeljen fan de konverzje wurdt it fergese kwotum sa’n bytsje fan “100 st./moanne” nei “50 st./moanne”.

De meast foarkommende TinyPNG-falkûlen

1. Tinke 500 credits = 500 ôfbyldings
   Nee. It wurdt per ôfbyldingsgrutte/fariant ferbrûkt. Op de pluginpagina stiet al dúdlik: “Konverzje kostet 1 ekstra credit per ôfbyldingsgrutte.”
2. Tema/e-commerce-plugin makket te folle maten oan, de fergese limyt sakket hiel dúdlik
   Hoe mear maten, hoe makliker credits yn gruttere hoemannichten ferbrûkt wurde.
3. Nei it ynskeakeljen fan oerskeakeljen liket it saldo ynienen folle hurder op te gean
   Dit is gjin bug, mar syn fakturearringsmeganisme.
   Strategy oanbefellings:

• As de fergese faze benammen brûkt wurdt foar kompresje en it ferminderjen fan grutte, kinst earst allinnich komprimearje. Skeakelje konverzje nei next-gen pas yn as de sitestruktuer stabyl is en it echt nedich is.

4. Oanrikkemandaasjes per senario: hoe kiesst foar ferskillende soarten websiden

Sels mei WordPress binne de “drukpunten” fan ôfbyldingen by ynhâldssiden, webshops, portfolio’s en lidmaatskipssiden net itselde.

4.1 Ynhâldside/Blog (in protte ôfbyldings, middelmatige fernijingsfrekwinsje)

Prioriteitsadvys:

1. Maatbelied (Stap 1)
2. Ynpakke (Stap 2)
3. WebP (Stap 3)

Mear geskikte rûte:

• Wolst it maklik hâlde: kies 1 fan 3 foar opsje B (ShortPixel / Imagify / TinyPNG)
• Wolst it fergees: rûte A (Plus WebP + EWWW), mar it is oan te rieden om earst mei “foarsichtige modus (orizjinele ôfbylding net fuortsmite)” te begjinnen om it risiko te beoardieljen

Typyske falstrik:

• Grutte haadôfbylding fan it artikel, ferkearde lazy-loadstrategyFertraget it earste skerm

4.2 Webshop-/produktside (in protte miniatuerôfbyldingen, in protte ôfbyldingsfarianten, stabiliteit foarop)

It plak dêr’t by e-commerce it maklikst problemen ûntsteane, is net “minne kompresjekwaliteit”, mar “nei optimalisaasje kloppe guon ôfmjittings net, ûntbrekke miniatueren, of kinne front-end-komponinten de ôfbylding net ophelje”.

Prioriteitsadvys:

1. Earst stabyl: hâld de kompresjestrategy wat foarsichtiger en ferfang net fuortendaliks de hiele databank
2. Beoardielje miniatuergrutte: e-commerce-tema's meitsje meastal mear formaten oan, wêrtroch it ferbrûk flugger omheech giet (benammen by ShortPixel/TinyPNG)
3. Doch earst in lytse test, dan pas yn bulk

Mear geskikte rûte:

• Rûte B is faak makliker: ShortPixel/Imagify/TinyPNG kinne allegear yn bulk, mar it wichtichste is datst it limytmeganisme begrypst en de kosten foarôf ynskattest
• Rûte A kin ek, mar gean foarsichtiger om mei it gedrach fan Plus WebP by “ID oerskriuwe / orizjinele ôfbylding fuortsmite / URL ferfange”: dit heart by assetmigraasje en it is net oan te rieden om fuortendaliks alles yn ien kear te ferfangen.

4.3 Portfolio/Fotografyside（gefoelich foar de kwaliteit fan losse ôfbyldings, grutte ôfbyldings, hege easken oan fisuele ûnderfining）

Prioriteitsadvys:

1. Gruttestrategy (werjeftegebietkontrôle)
2. Kompresjestrategy (leaver wat grutter, as details stikken komprimearje)
3. WebP/AVIF (foardiel by grutte ôfbyldingen is dúdlik, mar fisuele kwaliteit moat ferifiearre wurde)

Mear geskikte rûte:

• Imagify: op basis fan “orizjinele ôfbyldingsgrutte” wurdt it kwotum ôflutsen; mei sokke siden is it makliker om “it budzjet ûnder kontrôle” te hâlden (do witst sa'n bytsje hoefolle eltse grutte ôfbylding kostet), mar foarkom werhelle swiere kompresje.
• ShortPixelAs de thumbnailformaten net folle binne, binne credits ek hiel oersichtlik; mar ast in protte formaten + next-gen generearrest, rint it creditsferbrûk op en moatst foarút planne.

5. Limyt/fakturearring fergeliking: dúdlik meitsje oft “fergees” genôch is

Hokker is no foardieliger, en hoe lang hâldt fergees it út?

5.1 Trije fakturearringsmodellen

• ShortPixel（credits）credits wurde berekkene op basis fan “orizjinele ôfbylding + oantal miniatueren”; it generearjen fan WebP/AVIF kostet ekstra credit foar elke oerienkommende ferzje.
• Imagify(MB kwota): neffens “orizjinele triemgrutte” wurdt it kwotum ôflutsen; hoe mear miniatuerôfbyldingen, hoe mear der ôflutsen wurdt; opnij komprimearje lûkt nochris ôf.
• TinyPNG（credits）: 500 credits yn 'e moanne; it ynskeakeljen fan WebP/AVIF-konverzje kostet ekstra credit foar elke ôfbyldingsgrutte.

5.2 Fluch skatting metoade

Do kinst it sa ynskatte:

1. Sykje gewoan in “orizjinele ôfbylding dy’tst faak uploadest” en sjoch likernôch hoe grut dy is (bygelyks 300KB / 1MB / 3MB)
2. Skat hoefolle miniatuergrutten jo side sawat oanmakket (bygelyks 5 / 10 / 20)
3. Beslút oft jo WebP/AVIF generearje wolle (ja/nee)

Brûk dan de ûndersteande “haadrekenen” om it ferbrûk te begripen:

• ShortPixelPer ôfbylding ≈ (1 + oantal miniatueren) credits; by WebP/AVIF ≈ nochris dûbel (om't de next-gen-ferzje ek credits kostet)
• Imagify: elke ôfbylding ≈ (orizjinele grutte + grutte fan alle miniatuerôfbyldingen) wurdt fan it kwotum ôflutsen; by it opnij komprimearjen mei in oare kompresjegraad wurdt opnij ôflutsen
• TinyPNGFergees 500 credits; as dyn side in protte formaten per ôfbylding makket en konverzje ynskeakele is, giet it tal fergeze ôfbyldingen flink omleech (op de plugin-side stiet as dúdlike ferwachting “sa’n 100 ôfbyldingen/moanne” en “sa’n 50 ôfbyldingen/moanne”)

6. Risiko-oanwizing

Risiko 1: Lit net meardere plugins itselde dwaan litte

Dit is de meast foarkommende oarsaak fan “rampen”

• Rûte A៖Plus WebP of AVIF + EWWWDiel it wurk tusken beiden: doch net tagelyk itselde soarte konverzje en oplevering, of ynstallearje mar ien fan beide
• Rûte B: ShortPixel / Imagify / TinyPNG Kies ien fan trije(Kies ien ferantwurdlik foar kompresje en next-gen)

Risiko 2: Plus WebP syn “ID oerskriuwe / orizjinele ôfbylding wiskje / URL ferfange” heart by assetmigraasje

Nochris beklamme:Plus WebP De beskriuwing seit dúdlik dat by folsleine generaasje de orizjinele ôfbyldings-ID oerskreaun wurdt, it orizjinele bestân wiske wurdt, en de ynhâlds-URL ferfongen wurdt.
Dit betsjut dat it net in “lytse ynstelling is dy't op elk momint weromdraaid wurde kin”, mar in ienmalige wiziging op assetnivo.

De oanrikkemandearre strategy soe wêze moatte:

• Test earst op lytse skaal (tsientallen oant hûnderten ôfbyldingen)
• Kontrolearje oft de frontend-werjefte, miniatueren en cache-updates allegear normaal binne
• Hele bibleteek opnij beskôgje

Risiko 3: It echte ferbrûk fan it “fergese kwotum” fan wolkekompresje hinget ôf fan it tal miniatueren en de kar foar next-gen

• ShortPixelMiniatueren en next-gen hawwe in grutte ynfloed op credits
• TinyPNGIt ynskeakeljen fan WebP/AVIF kostet ekstra credits foar elke ôfbyldingsgrutte
• Imagify: ôflûke neffens de orizjinele ôfbyldingsgrutte; hoe mear miniatuerôfbyldings, hoe mear der ôflutsen wurdt; by swier yndrukken wurdt it werhelle ôflutsen

Risiko 4: “WebP/AVIF oanmakke” betsjut net “de frontend leveret WebP/AVIF”

In protte minsken fine nei de konverzje dat it “net flugger” wurden is; de oarsaak is dat de frontend noch altyd JPG/PNG útjout (cache/rewrites/tags/browserûnderhanneling ensfh. sitte dan earne net goed).

7. Hoe kontrolearje ik oft it wurket nei't ik klear bin

4 hiel ienfâldige ferifikaasjepunten

1. Twadde ferfarsking fan deselde side: stabiler en flugger laden?(fielt oft cache en optimalisaasje wurkje)
2. Binne de ôfbyldingsmaten op mobyl en buroblêd dúdlik oars?Responsyf srcset/sizes Hat it effekt?
3. In pear ôfbyldingen kontrolearje: komme WebP- of AVIF-bestannen/boarnen foar(Brûkt de side it echt) next-gen）
4. Kontrolearje in pear ôfbyldings: zoom yn om te sjen oft se dúdlik wazich binne en oft de tekst ûnskerp liket(Te folle kompresjekwaliteit)

As dizze fjouwer allegear klopje, betsjut dat dat de rûte dy'tst keazen hast al draait. Gean dêrnei fierder mei it dwaan fan “Leveringslaach”, it gehiel sil stabiler wêze.

8. Oanrikkemandaasjes foar aksje

1. Kies earst in rûte:

• Sa fergees mooglik: Plus WebP of AVIF + EWWW (of ynstallearje mar ien dêrfan)
• Wolst serverboarnen besparje en is beteljen neffens gebrûk soarchleazerKies ien fan ShortPixel / Imagify / TinyPNG

2. Doch earst in lytse test (in pear tsientallen)
3. Kontrolearje earst, dan yn bulk ferwurkje
4. De leveringsstabiliteit moat fierder ferbettere wurde:Lêze CDN fersnelle

Faak stelde fragen

1. Hoefolle plugins moat ik no eins ynstallearje? Kin ik se allegear ynstallearje?

Besykje safolle mooglik mar ien rûte te nimmen.

• Rûte A: Plus WebP of AVIF + EWWW Image Optimizer (of ynstallearje mar ien dêrfan)
• Opsje B: ShortPixel / Imagify / TinyPNG, kies ien fan de trije
  Troch yn deselde side tagelyk meardere plugins kompresje/WebP- of AVIF-konverzje/URL-wiziging/leveringsherskriuwing dwaan te litten, wurdt it al gau in gaos en is it it dreechst om op te lossen.

2. Unterstütet WordPress WebP/AVIF net al? Ha ik noch in plugin nedich?

Moat dúdlik ûnderskieden wurde:
“Uploaden/brûken stypje ≠ automatysk konvertearje/automatysk leverje
WordPress 6.5 sil ek net automatysk âlde JPG/PNG-bestannen yn bulk omsette nei WebP/AVIF, en it sil ek net automatysk de folsleine keten foar dy regelje fan “AVIF/WebP útfier op basis fan browserstipe mei fallback”. Ast ek de besteande mediabibleteek meikrije wolst, hast meastal in plugin of tsjinst nedich om dat oan te foljen.

3. Hokker stap yn byldoptimalisaasje jout no eins it “heechste rendemint”?

Gewoanlik Meitsje earst “grutte” goed (srcset/sizes)。
In protte websites binne net stadich omdat der net komprimearre is, mar omdat de side mar 900 px toant wylst de brûker in orizjinele ôfbylding fan 3000 px downloade moat. Kompresje kin KB besparje, mar in “ferkearde grutte” soarget derfoar datst om 'e nocht ferskate kearen safolle data downloade moatst.

4. Hoe kin ik befêstigje oft no dy “lytsere” ôfbylding laden wurdt, ynstee fan altyd de orizjinele ôfbylding te downloaden?

Sjoch nei twa ferskynsels:

• By it iepenjen fan de side op de telefoan is de grutte fan de downloade ôfbylding dúdlik lytser as op buroblêd
• Deselde ôfbylding laden boarnen fan ferskillende grutte op ferskillende apparaten
  As jo altyd de orizjinele ôfbylding downloade, komt dat faak omdat it tema of de bouwer de ôfbylding as CSS-eftergrûn of oanpaste útfier brûkt, en sa de meardere formaten en srcset fan de mediabibleteek omgiet.

Betsjut 5. “WebP/AVIF generearre” dat de foarkant perfoarst WebP/AVIF toant?

Is net gelyk oan.
It oanmeitsjen is allinnich op it “bestânsnivo” klear; oft de frontend echt WebP/AVIF leveret, hinget ek ôf fan herskriuwing, de strategy foar picture-tags, oft de cache rekke wurdt, oft browserûnderhanneling effektyf is, ensfh. Nei'tst klear bist, moatst perfoarst “by in pear ôfbyldings it boarnetype steekproefsgewize kontrolearje”.

6. Wêr sit krekt it risiko fan Plus WebP of AVIF? Kin ik de hiele bibleteek mei ien klik útfiere?

It risikopunt is net “kompresje”, marWizigingen op it nivo fan gegevensmigraasje：

• By folsleine generaasje kinne de triem-ID's fan de orizjinele ôfbyldingen oerskreaun wurde, de orizjinele triemmen wiske wurde, en URL's yn de ynhâld ferfongen wurde.
  DusNet oan te rieden om fuortendaliks de hiele databank te ferfangen: test earst op lytse skaal (tsientallen oant hûnderten stikken) + mei in brûkbere reservekopy, beskôgje dan pas ferwurking fan de hiele databank.

7. Hoe kies ik tusken de twa modi fan Plus WebP: orizjinele ôfbylding behâlde of ferfange en de orizjinele ôfbylding wiskje?

Koart begrepen:

• Modus 1: bewarje orizjinele ôfbylding + meitsje WebP/AVIF-kopyen (stabiler): Handich om werom te setten, mar it skiifgebrûk nimt ta (orizjinele ôfbylding + nij formaat + meardere grutte miniatueren).
• Modus 2: Ferfange en wiskje de orizjinele ôfbylding (agressiver): de skiif wurdt net maklik grutter, mar asto “assets oanpasse + ferwizingen oanpasse”, binne de kosten foar it opspoaren fan kompatibiliteitsproblemen heger.
  Hoe komplekser de side (webwinkel/meardere plugins/meardere formaten), hoe mear it oan te rieden is om mei in stabiler modus te begjinnen.

8. Is EWWW Image Optimizer fergees lokale kompresje genôch? Sil it de server oerlêstje?

EWWW liket mear op in lokale kompresjewurker: brûkt CPU/IO។
Faak rint de lading op by batchoptimalisaasje. Dat betsjut net dat it net goed is, mar dat de strategy klopje moat: yn batches, by lege belesting, en as it nedich is in offload-/cloud-oplossing kieze.
As do gemak sykje, of as de serverboarnen krap binne, is rûte B better foar de server.

9. Wêrom lykje de 100 fergese credits fan ShortPixel yn 'e moanne al nei in pear ôfbyldingen op te wêzen?

Om’t credits is net “oantal ôfbyldingen”Sil útwreide wurde troch miniatueren en next-gen

• Orizjinele ôfbylding + elke miniatuer telt as in credit
• As WebP/AVIF oanmakke wurdt, kostet elke oerienkommende ferzje ek ekstra credits
  Dus do tinkst miskien “1 ôfbylding”, mar yn werklikheid wurdt der hast “in kredytbedrach mei 2 sifers” ferbrûkt. ShortPixel

Wêrom is de fergese 20MB/anne fan Imagify ek sa gau op?

Imagify is mear as in “databonke”:

• Neffens watsto ferstjoerd hastOarspronklike triemgrutteKwota ôflûke
• Hoe mear miniatueren, hoe grutter it ferbrûk
• Optimalisearje opnij mei in oanpast kompresjenivo; dit ferbrûkt opnij kredyt
• Deselde API-kaai foar meardere siden, kwota dield
  Dus “20MB gau op” komt faak troch te grutte ôfbyldings, tefolle miniatueren, of troch hieltyd wer te probearjen en te mislearjen.

11. TinyPNG fergees 500 credits/moanne, wêrom seit de plugin mar sa’n 100 ôfbyldings/moanne, en mei WebP/AVIF oan noch mar 50 ôfbyldings/moanne?

Om't de credits fan TinyPNG ek fergrutte wurde troch “Ofmjitting/fariant”

• Gewoane WordPress-ynstallaasje komprimearret sa’n 100 ôfbyldingen/moanne
• AVIF- of WebP-konverzje ynskeakelje:Elke ôfbyldingsgrutte kostet in ekstra creditDêrom kinne der nei skatting mar sa’n 50 ôfbyldings yn ’e moanne komprimearre en konvertearre wurde (ôfhinklik fan it tal thumbnailgruttes).
  Dat betsjut dat 500 credits ≠ 500 ôfbyldingen.

12. Hoefolle miniatueren steane der eins op myn side? Wêrom hat dat sa’n grutte ynfloed?

By it uploaden fan in ôfbylding makket WordPress meardere formaten oan; tema's/plugins (benammen foar webwinkels) kinne ek noch mear formaten tafoegje.
Cloud-kompresje-credits/kwota wurde meastal berekkene as “orizjinele ôfbylding + miniatuer tegearre”, dus hoe mear miniatueren, hoe flugger de fergese limyt opraakt.

13. Makket lazy loading it altyd flugger? Wêrom sizze guon minsken dat lazy loading krekt stadiger wurdt?

Lazy loading is geskikt foar “boarnen bûten it skerm”.
As dy grutste en wichtichste ôfbylding op it earste skerm ek pas letter laden wurdt, kin dat de ûnderfining fan it earste skerm fertrage. De standert lazy loading sûnt WordPress 5.5 is prima, mar pas it net sûnder ûnderskie op alles ta.

Wannear haw ik CDN / ôfbylding CDN nedich as ik rûte A of B nim?

Kompresje, ôfmetingen en formaat losse op dat “it bestân lytser en gaadliker is”;
CDN lost tichterby en stabiler op。
As ôfbyldingen fan de oarspronklike side oer in grutte ôfstân ophelle wurde en dat dúdlike fertraging feroarsaket, dan makket it tafoegjen fan CDN/ôfbylding CDN (bygelyks Cloudflare Polish / Jetpack Site Accelerator) it gehiel stabiler, ek by it lêzen WordPress CDN fersnelling。

15. Wat is de ienfâldichste manier om nei ôfrin te kontrolearjen oft it echt wurket?

De fluchste ferifikaasjemetoade:

• Twadde ferfarsking fan deselde side: stabiler en flugger laden?
• Is de ôfbyldingsgrutte by laden op mobyl en buroblêd dúdlik oars (wurket srcset/sizes)
• In pear ôfbyldingen kontrolearje: komme WebP- of AVIF-bestannen/boarnen foar
• Kontrolearje in pear ôfbyldings: zoom yn om te sjen oft se dúdlik wazich binne en oft de tekst ûnskerp liket