Optimîzasyona wêneyan a malperê

Optimîzasyona wêneyan ji bo performansa WordPressê vegera herî bilind a veberhênanê pêşkêş dike: bi pêkhate û temayên rûpelan ên wekhev, tenê rastkirina mezinahî, pîvan, format û metoda radestkirinê ya wêneyan gelek caran dikare di ezmûna barkirinê de başbûnên yekser peyda bike.

Lêbelê, optimîzasyona wêneyan di heman demê de herî zêde dibe sedema rewşek ku tê de “çi qas tu lê dixebitî, ew qas xirabtir dibe”. Sedem ne ew e ku teknîk pir zehmet e, lê belê ew e ku agahî pir perçe perçe ne:
We çend gotar xwendine û derbarê “compression”, “WebP/AVIF” û “lazy loading” de fêr bûne, lê paşê hûn li danasîna pêvekê dinêrin û tê de tê gotin “mehane 100 krediyên belaş”, “20MB belaş” û “ji bo her wêneyekê 1 kredî”—û her ku hûn bêtir dixwînin, hûn bêtir serêweş dibin. Gelo ev mîqdara belaş bi rastî bes e? Xerc çawa tên jêbirin? Gelo we “heman tişt” şaş fêm kiriye? Û ya herî girîng:Gelo bi rastî piştî ku te xilas kir, ew ket meriyetê?

Ev gotar tenê sê tiştan dike:

1. Va ye ji bo te yek ku tu dikarî pêk bînî.Nexşerê(Pêşî çi bike, paşê çi bike)
2. Vebijêrkên ku hûn dixwazin hilbijêrin bi zelalî şirove bikin (cudahiya di navbera guhertoyên belaş û bi pere de çi ye, û kîjan ji wan ji bo kê guncaw e).
3. Astengiyên herî berbelav di destpêkê de rêz bike (da ku piştî ku te xilas kir, tu nekevî nav zehmetiya lêgerîna çareseriyan)

1. Bingeh: Tiştên ku WordPress bi awayekî standard dihewîne, û tiştên ku ew nainhewîne

Heke hûn pêşî fêm nekin ka bingeha WordPressê jixwe çi pêk aniye, du rewş îhtîmal e ku derkevin holê:

• Li şûna ku em ji “şiyanên belaş” ên berdest sûd werbigirin, me wext û pereyê xwe bi ji nû ve îcadkirina tekerê winda kir.
• Min digot qey WordPress dê “bi awayekî otomatîk hemû wêneyên kevn veguherîne WebP/AVIF”, lê derket holê ku wisa nake.

Navika WordPressê jixwe van şiyanên bingehîn dihewîne:

• Wêneyên bersivdar (srcset/sizes)Ji WordPress 4.4 û pê de, navik dê wêneyan derxe. srcset 与 sizesû wêneyên pir-mezinahî yên ku di dema barkirinê de hatine çêkirin bi kar bîne, da ku gerok li gorî şertên ekranê ji bo barkirinê çavkaniyên guncantir hilbijêre.
• Barkirina tenbel a xwemalîWordPress 5.5 û guhertoyên paşê, bi awayekî xwemalî û bi bikaranîna standardên HTMLê, ji bo wêneyan barkirina tenbel a (lazy loading) çalak dikin. loading Cîbicîkirina milk.
• Piştgiriya barkirina pelên WebP dike.Ji guhertoya 5.8 û pê de, WordPress rê dide barkirin û bikaranîna pelên WebP, hema wekî yên JPEG/PNG (bi şertê ku hawîrdora hostingê piştgiriya WebP bike).
• Piştgiriya barkirina AVIF dikeWordPress 6.5 û pê de, rê dide barkirin û bikaranîna pelên AVIF bi heman awayî wekî JPEG/PNG (li gorî piştgiriya hawîrdora hostingê).

Lêbelê, bala xwe bidinê:
“Piştgiriya barkirin/bikaranînê” ≠ “Veguherîna otomatîk/radestkirina otomatîk”.
Bi gotineke din: heke hûn jixwe li ser WP 6.5 bin jî, pelên JPG/PNG yên di pirtûkxaneya we ya medyayê de dê bixweber neyên veguherandin bo WebP/AVIF; herwiha hûn ê bixweber negihîjin şiyana tam a “li gorî piştgiriya gerokê AVIF/WebP derxîne, û ji bo gerokên ku piştgirî nakin vegere ser wêneya resen” – ji bo temamkirina vê çareseriyê bi gelemperî pêdivî bi pêvekan (plugin) an xizmetên zêde heye.

2. Nexşerê: Optîmîzasyona wêneyan di 5 gavan de

Çi bike, çima, çi performanseke têrker pêk tîne, û xefkên tîpîk çi ne.

2.1 Pêşî pîvanan rast bi dest bixe (ya herî hêsan tê paşguhkirin, lêbelê encamên herî mezin dide)

Gelek malper ne hêdî ne ji ber ku pêçan (compression) nehatiye bikaranîn, lê belêWêneyek ku ji qada ekranê gelek mezintir bû hate daxistin.：
Mînak, heke rûpelek bi rastî tenê 900px fireh be, lê hûn nehêlin ku serdaner wêneya orîjînal a 3000px daxînin, gerok dê tenê “pêşî wê bi tevahî daxîne û paşê ji bo nîşandanê piçûk bike”. Ev yek bandwithê pûç dike, dema deşîfrekirinê zêde dike, û barkirina rûpela yekem hêdî dike.

WordPress 4.4 û jortirMekanîzmaya wêneyê bersivdar（srcset/sizes) tam ji bo çareserkirina vê pirsgirêkê.

Nîşana derbasbûnê çi ye:

• Dema ku rûpel li ser cîhazeke mobîl tê vekirin, divê mezinahiya wêneyê daxistî bi awayekî berbiçav ji ya sermaseyê piçûktir be.
• Mezinahiya çavkaniyê ya heman wêneyî li gorî cîhazên cuda diguhere (li şûna ku her tim wêneya resen were daxistin).

Xefkên herî berbelav:

• Dibe ku hin tem/avaker vê yekê bi derbaskirina wê, bi bikaranîna wêneyan wekî wêneyên paşxanê yên CSS an jî bi bikaranîna rêbazên derxistinê yên xwerû, derbas bikin. srcsetku dibe sedema daxistina domdar a wêneyên mezin
• Bi bikaranîna xizmetên mêvandarîya wêneyan ên derve û blokên wêneyan ên aliyê sêyem, hûn dikarin sîstema pir-mezinahî ya ku ji alîyê pirtûkxaneya medyayê ve tê çêkirin derbas bikin.

---

2.2 Zexmkirin (Mezinahiya KB'yê kêm bike, lê kalîteyê xirab neke)

Cewhera kompresyonê ne “çi qas piçûk be, ew qas baştir e” ye, lê belê “cûdahiyeke ku bi çavên rût hema hema nayê dîtin, lê dîsa jî kêmkirineke berbiçav a qebareyê” ye.

Rêzik wiha ne:

• Wêne/Şûtên rastîn (mirov, berhem, dîmen)Pêşengiya kompresyona windakî (feydeya herî zêde)
• Wêneyê ekranê/Wêne bi nivîsa berfirehDivê kompresyon parêzgartir be da ku nivîs mat xuya neke.
• Logoyê/ÎkonêSVG'ê pêşîn bigirin an jî kompresyona bê-windahî (lossless) hilbijêrin (kompresyona bi-windahî (lossy) bi hêsanî dibe sedema matbûna keviyan).

Nîşana derbasbûnê çi ye:

• Mezinahiya wêneyan li ser piraniya rûpelan bi awayekî berbiçav kêm bûye.
• Dengê berbiçav, qeraxên mat, şirîta rengê, an jî matbûna nivîsê tune.

---

2.3 WebP / AVIF (Polîtîkaya formatê: Mezinahiya pelê biçûktir ji bo zelaliyeke wekhev)

WordPress niha piştgiriya barkirinê dike. WebP (5.8) û AVIF (6.5)。
Lêbelê, ji bo ku “formata nifşê nû” bi rastî bikeve bikaranîna pratîkî, bi gelemperî pêdivî ye ku du mijar werin çareser kirin:

1. Meriv çawa arşîvên medyayê yên dîrokî bi kom vediguherîne(Wekî din, te tenê “wêneyên nû yên ku di pêşerojê de tên barkirin” xweşbîn kiriye)
2. Gelo kopiyek were çêkirin, an wêneya resen were guhertin?(Ev qonaxa krîtîk e; em ê paşê li ser “cîgirkirin û jêbirina wêneyên resen” ên Plus WebP'ê bisekinin.)

Stîla nivîsandinê ya pêşniyarkirî:

• WebP: Bi giştî vebijêrka pêşdiyarkirî ya bijarte (lihevhatineke bêtir bi îstîqrar pêşkêş dike)
• AVIF: Pêngaveke din a pêşketî di kompresyonê de, ji bo wêneyên mezin/banerên ekrana yekem/wêneyên albumê guncaw e (her çend zêdetir...Girêdayî piştgiriya jîngehê）

---

2.4 Barkirina tenbel divê bi awayekî biaqilane were bikaranîn (ji nêzîkatiyeke giştî dûr bikevin)

WordPress 5.5 û pê deBarkirina tenbelî ya bi awayekî standardWêne.
Ew di dema renderkirina destpêkê de xerckirina bandwidthê kêm dike:

• Barkirina tenbel ji bo “çavkaniyên derveyî ekranê” guncaw e.”
• Wêneyê herî girîng ê li ser ekrana yekem (pir caran wêneyê sereke yê li ser ekrana yekem) gelek caran ji bo barkirina paşve ne guncaw e.

---

2.5 Asta radestkirinê: CDN / Wêne CDN

Pêçan, mezinahî û format bersiva pêdiviya ji bo “pelên piçûktir û guncavtir” didin.
Lêbelê, heke wêne bi berdewamî ji servera resen ji mesafeyên dûr werin standin, derengiya torê dîsa jî dê bi awayekî berbiçav bandorê li ser serpêhatiya bikarhêner bike. Di rewşên weha de, çareseriyek “qata radestkirinê” pêwîst e (CDN/wêne CDN).

Du nêzîkatiyên tîpîk:

• Cloudflare Polonya：Belgeyên CloudflareGotar rêbazên pêlêdanê yên Polish (bê-wenda/wenda/WebP) dide nasîn û behsa bikaranîna wan dike. format=auto Bikaranîna formatên WebP/AVIF destûrdayî ye.
• Lezgera Malperê ya Jetpackê：Belgeya JetpackêEw ê wêneyan xweştir bike û wan li gel çavkaniyên statîk bi rêya tora xwe belav bike.

Optîmîzasyona wêneyan berpirsiyarê kêmkirina mezinahiyê û misogerkirina guncawiyê ye.CDN: Radestkirina nêzîktir û bi pêbawertir

3. Hilbijartin: Tenê du rêyên sereke dê bên şopandin.

Xefka herî berbelav di optimîzasyona wêneyan de ne “nesazkirina pêvekan” e, lê sazkirina pir zêde pêvekan e ku dibe sedema pêvajoyeke zêde:
A pêçanê dike, B jî pêçanê dike; A vediguherîne WebP/AVIF, B jî vediguherîne; A URLan diguherîne, B jî ji nû ve dinivîse— di dawiyê de, tu bi xwe jî nikarî rave bikî ka li ser malperê çi diqewime.

Rêzik:

Tenê yek rê heye: an depokirina herêmî ya bi tevahî azad, an jî pêlêkirina ewrî ya bi sê vebijarkên ji bo hilbijartinê.

• Rêya A (bi tevahî herêmî û belaş):Zêde WebP an AVIF + EWWW Image Optimizer(an jî tenê yek ji wan hilbijêre)
• Rêya B (Yek ji sê vebijarkên pêlêkirina ewr hilbijêre):ShortPixel / Imagify / TinyPNG

---

3.1 Rêya A: Bi tevahî Belaş a Herêmî (Zêde WebP an AVIF an EWWW)

Taybetmendiyên diyarker ên vê rêyê ev in:

• Hûn xwe nespêrin xizmetên kompresyonê yên aliyê sêyemîn ên ku li ser bingeha kûotaya mehane an jî her pelekê dixebitin (her çend dibe ku hin taybetmendî xizmetên bijarte pêşkêş bikin).
• Aliyê neyînî yê vê yekê ew e ku pêvajokirina komî dibe ku di warê CPU/IO de barekî girantir bixe ser serverê, û ev yek ji we dixwaze ku hûn zêdetir bala xwe bidin ser “stratejî û rîskê”.”

3.1.1 Zêde WebP an AVIFTêgeha bingehîn “çêkirin/guhertin” e, ku ne amûreke kevneşopî ya “pêçandinê” ye.”

• Dema ku wêneyên bi rezolûsyona tam tên çêkirin:Nasnameya pelê wêneyê yê resen dê ji aliyê pelê WebP/AVIF ve were şûnikirin, pelê resen dê were jêbirin, û URL'a di nav naverokê de jî dê were guhertin.。
• Pêvek fermanên WP-CLI peyda dike û şîretan dike: Dema ku bi gelek pelan re mijûl dibin, WP-CLI pêbawertir e.

Ev tê wê wateyê: ew ji bo we bi bêdengî WebP'yekê çênake, lê dibe ku tenê carekê biqewime.Veguherandina sermayeyan(bi taybetî dema ku hûn vebijarka “Cihê wêneyê resen bigire û jê bibe” çalak dikin).

Cûdahiya di navbera her du modan de

Mod 1: Wêneyê resen diparêze + kopyayeke WebP/AVIF çêdike (zêdetir stabîl)

• Avantaj: Di rewşa pirsgirêkên lihevhatinê de vegerandina wê hêsantir e.
• Lêçûn: Bikaranîna dîskê dê zêde bibe (wêneyê resen + formatê nû + pêşdîtinên bi gelek pîvanan)

Mod 2: Wêneyê resen biguherîne û jê bibe (zêdetir êrîşkar)

• Avantaj: Dîsk bi lez zêde nabin; referansên navxweyî bixweber bo formata nû tên veguherandin.
• Rîsk: Dema ku sermaye û referans di heman demê de tên guhertin, çareserkirina pirsgirêkên lihevhatinê bi awayekî berbiçav bihatir dibe (bi taybetî dema ku pergalên derve an mantiqê temayê xwe dispêrin navên pelan/rêçên/formatên resen).

Xefkên hevpar ên WebP an AVIF

1. Piştî guhertina tevahî ya databasê, hin wêneyên rûpelan bi awayekî şaş têne nîşandan.
   Sedem bi gelemperî ne ew e ku “wêne xera bûye”, lê belê ew e ku hin girêdan di zincîrê de – wek guhertina URL'ê, keşkirin, an stratejiyên wêneyên piçûk – bi awayekî rast nehatine sererastkirin.
2. Çiqas hejmara pêşdîtinan zêdetir be, qada guhertinan jî ewqas berfirehtir dibe.
   Barkirina wêneyekî li WordPressê gelek mezinahiyên cuda çêdike; temayan an jî pêvekan dibe ku pîvanên din jî lê zêde bikin. Cihgirtineke tam tê wê wateyê ku dibe ku hûn komeke berfireh a pelan biguherînin.
3. Tenê pêkanîna koçberiya formatê, qebareya herî biçûk a gengaz garantî nake.
   Pelên WebP/AVIF bi gelemperî piçûktir in, lê “stratejiya mezinahiyê” û “stratejiya pêçandinê” girîngiya xwe winda nakin. Plus WebP wekî “çareseriyeke yek-klîk ji bo barkirina bileztir” nehesibînin.

---

3.1.2 EWWW Optîmîzkerê WêneyanÇareseriya kompresyonê ya herêmî ya belaş

Pozîsyona rûpela pêveka EWWW pir zelal e:

• Ew dikare ji bo xweşbînkirinê li ser servera we komek amûran (jpegtran, optipng, pngout, pngquant, gifsicle, cwebp, hwd.) bi kar bîne.
• Heke pêdiviya we bi kompresyoneke bilindtir hebe an hûn dixwazin li ser CPU teserûf bikin, hûn dikarin herwiha wî pêvajoyê yê ku CPU dixwe, barî ser servera xwe bikin (ne mecbûrî ye).

Divê EWWW di Rêya A de çi rolê bilîze?

Heke hûn Plus WebP ji bo “stratejiya koçkirin/guhertina formatê” bi kar tînin, wê demê EWWW ji bo pêkanîna vê yekê guncavtir e:

• Optimîzasyona Zexm û Qebarê(bi taybetî kêmkirina mezinahiya çavkaniyên xav ên wekî pelên JPG/PNG)
• Optîmîzasyona komî ya pirtûkxaneyên medyayê yên dîrokî(Armanckirina “kêmkirina qebarê” li şûna “guhertina URL'ê)

Xefkên klasîk ên EWWW'ê

1. Barê serverê di dema optimîzasyona komî de zêde dibe.
   Sedem ev e ku kompresyona herêmî CPU/IO xerc dike. Çareserî ne ew e ku “ji bikaranîna wê were sekinandin”, lê belê ew e ku “di komên mezin de, di demjimêrên kêm-qerebalix de were pêvajokirin, û li cihê ku pêwîst be, vebijarkên barkêşkirinê an çareseriyên ewrî werin hilbijartin”.
2. “Hildana WebP'ê ne hewce ye ku tê wateya ku frontend WebP'ê pêşkêş dike.
   Gelek pêvek di bin vê şaşfêmkirinê de ne: hilberandin tiştek e, stratejiya radestkirinê (ji nû ve nivîsandin, etîketên wêneyan, lêdanên cache, hwd.) tiştekî din e.
3. Dubarekirina heman fonksiyoneliya wekî pêvekên din
   Heke hûn Rêya A hilbijêrin, xwe ji komkirina xizmetên pêşkêşkirina ewrî yên wekî ShortPixel/Imagify/TinyPNG dûr bixin; heke hûn Rêya B hilbijêrin, mantiqa guhertina Plus WebP neçalak bikin. Prensîba bingehîn:Li ser yek rêbazê bisekine.

---

3.2 Rêya B: Yek ji sê xizmetên kompresyona ewrî hilbijêrin (ShortPixel / Imagify / TinyPNG)

Ev rê ji bo kesên ku dixwazin çavkaniyên serverê biparêzin, ji bo pêvajoya komî nêzîkatiyeke bê-derdser tercîh dikin, û bi bihayên li gorî bikaranînê rehet in, guncaw e.
Lêbelê, xala herî berbelav a şaşfêmkirinê ya derbarê kompresyona ewrî de ev e:Sînorê belaş ne tenê meseleyek “rûpelên belaş” e.Hejmara mezinahiyên thumbnailan, gelo formatên WebP/AVIF tên çêkirin, û gelo ji nû ve pêçandina dubare tê kirin, dê hemû bi awayekî berbiçav bandorê li ser xerckirina çavkaniyan bikin.

Li jêr em ê şirove bikin: qatên belaş/bi pere çawa dixebitin, kûota çawa têne kêmkirin, xefkên herî berbelav ên ku divê mirov xwe jê dûr bigire, û kîjan cureyên malperan herî guncaw in.

---

3.2.1 Pîksela KurtHer meh 100 krediyên belaş, lê kredî dê ji bo piçûkneyan û mezinkirinên WebP/AVIF bên xerckirin.

Meseleya belaş/bi pere çi ye?

Di danasîna pêveka ShortPixel de bi awayekî eşkere tê gotin:

• 100 krediyên belaş her meh
• Her wiha “krediyên mehane yên zêde yên bêsînor” jî hene (rûpela pêvekê agahiyên bihayê yên têkildar peyda dike).
• Herwiha “pakêtên krediyê yên yekcarî yên ku demên wan naqedin” jî pêşkêş dike (bi agahiyên destpêkê yên bihayê ve)

Têbînî:

• Belaş: Veqetandina krediyan a mehane ji bo malperên sivik an ji bo mebestên ceribandinê.
• Pakêta yekcarî: Ji bo malperên xwedî pirtûkxaneyên medyayê yên berfireh guncaw e ku dixwazin stokê bi carekê paqij bikin (carekê tê kirîn ji bo bikaranîna bêsînor, bi gelemperî bêyî dema qedandinê).
• Mehane/Bêsînor: Ji bo malperên ku nûvekirinên berdewam ên wêneyan û optimîzasyoneke demdirêj û bi îstîqrar hewce dikin guncaw e.

Bingeha zanînê ya fermî ya ShortPixel herwiha berawirdkirina di navbera “pakêtên yekcarî li hember planên mehane yên bêsînor” de jî dinirxîne.Ravekirineke zelalPlana Mehane ya Bêsînor mehane (an salane) tê fatûrekirin, krediyên bêsînor û koteyeke sabit a CDN pêşkêş dike; krediyên yekcarî namînin, ku ev yek di dema pêwîst de kontrola bikaranînê zêdetir dide we.

Xala herî girîng: Krediyên ShortPixel çawa têne hesab kirin?

Belgeyên Fermî yên ShortPixel KB bi awayekî pir zelal got:

• Barkirina wêneyekî li WordPressê, çendîn pêşdîtinên piçûk çêdike;
• Her xweşbînkirina wêneyekî piçûk wekî krediyekê tê hesibandin.；
• Heke hûn hilbijêrin ku WebP an AVIF biafirînin,Her guhertoyeke WebP/AVIF a wêneyekî resen û pêşdîtina wê dê krediyeke zêde xerc bike.；
• Hûn dikarin ji bo kêmkirina xerckirina krediyê hin pêşdîtinan ji optimîzasyonê derxin.

Mînaka Krediyan：

Bifikirin ku hûn wêneyekî bar dikin, û tema/pêveka heşt pêşdîtinan çêdike:

• Optimîzasyona wêneya orîjînal + tenê pêşdîtin: 1 (wêneya orîjînal) + 8 (pêşdîtin) = 9 kredî
• Heke hilberandina WebP/AVIF jî pêwîst be: ji bo her yek ji 9 formatên jorîn guhertoyek nifşê-nû lê zêde bikin → paşê 9 krediyên din lê zêde bikin.
  Bi gotineke din, tiştê ku hûn dibe ku wekî “yek wêne” bihesibînin, di rastiyê de dikare hema hema “krediyên du-reqemî” xerc bike.

Ji ber vê yekê:“100 krediyên belaş” ne wekî “100 wêneyên belaş” e.

Xefkên Herî Berbelav ên ShortPixel

1. 100 krediyên belaş zû xilas dibin
   Sedema bingehîn: gelek pêşdîtin + krediyên zêde ji bo çêkirina WebP/AVIF pêwîst in.
   Pêşniyar：

• Pêşî hejmara biçûkneyzên li ser malperê binirxîne.
• Mezinahiyên nehewce yên wêneyên biçûk rakin (tenê ew mezinahî xweşbîn bikin ku bi rastî dê werin bikaranîn)
• Pêşî, berî ku bi komî bixebitînin, stratejiya pêçanê diyar bikin, da ku ji hewldanên dubarekirî yên ceribandin-û-xeletiyê yên ku çavkaniyan xerc dikin dûr bikevin.

2. Bi hevre plaginên din ên veguherandina formatê bar bike
   Heke hûn guhertina Plus WebP çalak bikin û di heman demê de fermanê bidin ShortPixel ku etîketên nifşê-nû biafirîne/bicîh bike, mantiq tebeqeyî dibe, ku ev yek çareserkirina pirsgirêkan dijwartir dike. Rêya B bi hêsanî dihêle ku ShortPixel vê yekê bi serê xwe bi rê ve bibe.
3. Wisa hesibandin ku tenê sazkirina wê garantî dike ku “frontend WebP/AVIF pêşkêş dike”.”
   Rûpela Pêveka ShortPixelEw dikare formatên WebP/AVIF veguherîne û wêneyên nifşê nû di nav rûpelên front-end de bi cih bike (mînak, bi rêya pêkanîna tagan).
   Lêbelê, piştî ku temam bibe jî, divê encam dîsa bên piştrastkirin.

---

3.2.2 Imagify: 20MB/mehê belaş; kûota li ser bingeha “mezinahiya wêneya resen + hejmara pêşdîtinan” tê kêmkirin; ji nû ve pêçandin dê bibe sedema kêmkirinên ducarî.

Sînorê belaş û danîn

Rûpela Bihayên Fermî ya ImagifyBi zelalî hatiye nivîsandin:Hesabên belaş xwedî kotayeke mehane ya 20MB ne.。
Rûpela wê ya pêvekê her wiha bi awayekî eşkere diyar dike ku ew dikare pelên WebP/AVIF pêçîne, mezinahiya wan biguherîne û veguherîne.

Kota çawa tên jêbirin?

Belgeyên Fermî yên Imagify “Bikaranîna Koterê Çawa Tê Hesibandin?” mekanîzmaya kêmkirinê bi awayekî zelal şirove dike:

• Hejmara pêşdîtinan dê bandorê li ser xerckirinê bike.Wek mînak, heke 10 mezinahiyên we yên miniaturê hebin, xweşbînkirina yek wêneyî dibe xweşbînkirina 11 wêneyan (wêneya orîjînal û 10 miniatur), ku hemû jî dibin sedema xerckirina kotayê.
• Parêzê li gorî mezinahiya pelê ya eslî kêm bike.Wek mînak, heke hûn wêneyekî 100KB'î ji Imagify re bişînin, dê 100KB ji kotaya we were jêbirin.
• Guhertina asta kompresyonê û ji nû ve optimîzekirin dê dîsa kotayê xerc bike.。
• Heman Mifteya APIyê dikare li ser gelek malperan were bikaranîn, lê sînor di navbera van malperan de tên parvekirin.

Ev nêzîkatiya bingehîn a têgihiştinê ya Imagify ye:
Ew bêtir wek pakêteke daneyê ye: çi bişînî, ewqas jê dibire; çiqas zêde miniatur (thumbnails) hebin, ewqas zêde jê dibire; barkirinên giran ên dubare dê bibin sedema jêbirinên dubare.

Mînakên kota Imagify yên hêsan-fêmkirin

Ferz bikin ku hûn wêneyek resen a 800KB bar dikin, û malper 8 pêşdîtinan çêdike.

• Dema ku hûn bi Imagify re optimîzasyonê dikin, hem wêneya resen û hem jî heşt pêşdîtin têne tevlîkirin (heke hûn “Optîmîze Bike Hemûyan” hilbijêrin). Ev tê wê wateyê ku ev yek operasyon dê kotayekê xerc bike ku nêzîkî mezinahiya giştî ya hevgirtî ya hemû van pelan e.
  Ji ber vê yekê hin malper dibînin ku kota wan a “20MB” zû diqede: ne ku Imagify ji karê xwe têr nake, lê belê wêneyên ku hûn bar dikin pir mezin in, hûn pir zêde miniaturayan çêdikin, û dibe ku hûn her weha bi awayekî dubare bi astên cuda yên pêçanê (compression) ceribandinan dikin.

Xefkên berbelav ên Imagify

1. 20MB ya belaş ji bo pêkanîna “paqijkirina temamî ya dîroka malperê” têr nake.”
   20MB bi giştî ji bo ceribandinê û nûvekirinên biçûk guncavtir e; heke pirtûkxaneya we ya medyayê jixwe mezin be, paqijkirina wê bi carekê bi îhtimaleke mezin dê pêdivî bi nûjenkirinê hebe.
2. Serrastkirina asta pêçanê ya dubare, dibe sedema xerckirina kota ya dubare.
   Imagify bi awayekî eşkere diyar dikeJi nû ve optimîzasyon dê dîsa kotayê xerc bike.
   Pêşniyaz e ku stratejî li ser vê rûpelê bi awayekî zelal were xêzkirin:

• Pêşî, bi bikaranîna hejmareke kêm a wêneyan, asta pêçanê û kalîteya dîtbarî diyar bikin.
• Stratejiyê berî ku bi koman bixebite, temam bike.
  Li seranserê databasê ji ceribandinên dubare yên bi ceribandin û şaşiyê dûr bikevin.

3. Parvekirina kilîtên APIyê li ser gelek malperan dibe sedem ku kotayên bi awayekî sirûştî kêm bibin.“
   Heke hûn heman Mifteya APIyê li ser gelek malperan bikar bînin, dê kotayên we bên parvekirin.
   Ji ber vê yekê, di senaryoyên tîm/gelek-cih de, baş e ku bi zelalî were diyarkirin ka kîjan cihan çavkaniyan parve dikin û kîjan serbixwe dixebitin, bi vî awayî pêşî li bêîdarîya budceyê tê girtin.

---

3.2.3 TinyPNG(Wêneyên Piçûk Kirin): Mehane 500 krediyên belaş; veguherandina bo WebP/AVIF “ji bo her mezinahiyê 1 krediyeke zêde” heqê xwe digire.”

Xerca belaş û rêbaza fatûrekirina wê

Rûpela pêveka TinyPNG ya WordPressê pir zelal hatiye nivîsandin:

• Her meh 500 kredî belaş
• Di “sazkirineke standard a WordPressê” de, ew dikare bi qasî were pêçan. Nêzîkî 100 wêne di mehê de
• Lêbelê, heke veguherandina AVIF an WebP çalak be:Ji bo her mezinahiya wêneyî dê heqek zêde were standin.Ji ber vê yekê, ew belkî tenê dikare were pêçan û veguherandin. Nêzîkî 50 wêne mehê(Li gorî çend mezinahiyên wêneyên piçûk ên we hene).

Di vê navberê de, Tinify (pêşvebera TinyPNG/TinyJPG) jî li ser rûpela xwe ragihandiye. Rûpela Bihayên APITêbînî: Qeyd bibin da ku mehane 500 kompresyonên belaş werbigirin. Ji vê mîqdarê zêdetir, li gorî hejmara kompresyonên serketî heqdest tê standin, bêyî ku abonetiyeke mecbûrî hewce be.

Ji bo kurtkirina TinyPNG di hevokekê de:
Ew li gorî krediyan tê hesabkirin; çi qas zêdetir mezinahiyên wêneyên piçûk (thumbnail) hebin û çi qas zêdetir formatên WebP/AVIF çalak bikin, krediyên we ew qas zûtir tên xerckirin.

Mînakeke hêsan a têgihiştinê ya krediyên TinyPNG

Bifikirin ku malpera we ji bo her wêneyekê heşt mezinahiyên pêşdîtinê hildiberîne:

• Tenê kompresyon: Wêneya orîjînal + 8 pêşdîtin → 9 krediyan hewce dike
• Heke veguherandina WebP/AVIF çalak be: Ji her mezinahiyê kêmkirineke krediyê ya zêde tê kirin → Ev dikare lêçûnê hema hema du qat bike.
  Ev tam li gorî danasîna rûpela pêvekê ye: piştî çalakkirina veguhertinê, kota belaş ji “mehê nêzîkî 100 wêne” diguhere bo “mehê 50 wêne”.

Xefkên hevpar ên TinyPNG

1. Li gorî texmînê, 500 kredî = 500 wêne.
   Na. Ew krediyan li gorî “mezinahiya wêneyê/guhertoyê” xerc dike. Rûpela pêvekê bi awayekî eşkere diyar dike: “Veguhertin ji bo her mezinahiya wêneyê 1 krediyeke zêde jê dibire”.
2. Pêveka tema/e-bazirganiyê pîvanên zêde hildiberîne, ku ev yek dibe sedema kêmbûneke berbiçav di kûota belaş de.
   Çiqas pîvan mezintir bin, ewqas kredî hêsantir tên zêdekirin û xerckirin.
3. Piştî ku min veguherîn aktîf kir, min dît ku sînorê krediyê ji nişka ve têrê nake.
   Ev ne xeletî ye; ev mekanîzmaya wê ya fatûreyê ye.
   Pêşniyarên Stratejîk:

• Heke asta belaş bi giranî ji bo pêçandinê û kêmkirina giraniyê tê bikaranîn, hûn dikarin di destpêkê de tenê li ser pêçandinê bisekinin. Piştî ku we piştrast kir ku avahiya malperê stabîl e û ku nifşê nû bi rastî pêwîst e, hûn dikarin wê demê dest bi veguhertinê bikin.

4. Pêşniyarên li ser Bingehê Kontekstê: Ji bo Cûreyên Cihêreng ên Malperan Çawa Têne Hilbijartin

Her çend hemû li ser WordPressê bixebitin jî, malperên naverokê, platformên e-bazirganiyê, portfolyo û malperên endamtiyê, her yek ji wan xalên zextê yên cuda yên têkildarî wêneyan pêşkêş dikin.

4.1 Malper/blogên naverok-navendî (ku di her gotarê de gelek wêne hene û bi frekansiyeke nûvekirinê ya navîn)

Pêşniyarên pêşîn:

1. Stratejiya Pîvanê (Gav 1)
2. Pêçan (Gav 2)
3. WebP (Gav 3)

Rêyeke guncavtir:

• Ji bo vebijarkeke bê-derdser: Yek ji sê alternatîfan hilbijêrin (ShortPixel / Imagify / TinyPNG)
• Vebijêrka belaş: Rêya A (Plus WebP + EWWW), lê tê şîret kirin ku meriv bi nirxandina rîskan di “moda parêzvanî (bêyî jêbirina wêneyên resen)” de dest pê bike.

Xefkên hevpar:

• Wêneyê sernavê yê gotarê pir mezin e, û stratejiya barkirina tenbelî ne guncaw e.Dê ekrana yekem hêdî bike.

4.2 Malperên E-bazirganiyê/Berheman (Gelek miniatur, gelek guhertoyên wêneyan, aramî ya herî girîng)

Pirsgirêkên herî berbelav ên di e-bazirganiyê de ne ji ber “encamên kompresyonê yên xirab” in, lê belê ji ber “pîvanên şaş piştî optimîzasyonê, nebûna miniaturayan, û têkçûna pêkhateyên front-endê di wergirtina wêneyan de” ne.

Pêşniyarên pêşîn:

1. Bi hişyarî tevbigerin: ji bo stratejiyên kompresyonê nêzîkatiyeke parêzvanî bipejirînin; tavilê ji kirina guhertina databasê ya tam dûr bikevin.
2. Nirxandina pîvanên wêneyên piçûk: Temayên e-bazirganiyê bi gelemperî zêdetir mezinahiyan çêdikin, ku ev yek xerckirina kotayê zêde dike (ev bi taybetî bi ShortPixel/TinyPNG re berbiçav e).
3. Berî berfirehkirinê, piştrastkirineke bi pîvaneke biçûk pêk bînin (pir girîng e).

Rêyeke guncavtir:

• Rêya B gelek caran kêmtir serêşî ye: ShortPixel/Imagify/TinyPNG hemû piştgiriya pêvajoya komî dikin. Mifte ew e ku mirov sîstema kotayê fêm bike û lêçûnan ji berê ve binirxîne.
• Rêya A jî gengaz e, lê divê mirov di derbarê reftara Plus WebP ya “serwerkirina IDyan/jêbirina wêneyên resen/guhertina URLyan” de zêdetir hişyar be: ev yek koçkirina sermayeyan pêk tîne, û ne şîretî ye ku mirov ji serî ve bi guhertineke giştî pêş ve biçe.

4.3 Malpera Portfoliyo/Wênekêşiyê (Hestiyar ji bo kalîteya wêneyan, mezinahiya pelan, standardên bilind ên dîtbarî)

Pêşniyarên pêşîn:

1. Stratejiya Pîvanê (Kontrolkirina Qada Nîşandanê)
2. Stratejiya pêçanê (Çêtir e mirov hinekî mezintir bihêle, ne ku hûrgulî winda bibin)
3. WebP/AVIF (ji bo senaryoyên wêneyên mezin feydeyên berbiçav pêşkêş dike, her çend kalîteya dîtbarî pêdivî bi piştrastkirinê hebe)

Rêyeke guncavtir:

• ImagifyVeqetandina kotayan li gorî “mezinahiya wêneya resen” malperan ji bo “kontrolkirina budceyê” hêsantir dike (ji ber ku hûn bi texmînî dizanin her wêneyek mezin dê çiqas cîh bigire), lê ji kompreskirina wan a dubare dûr bikevin.
• Pîksela KurtHeke hejmara mezinahiyên thumbnail sînordar be, xerckirina krediyan di bin kontrolê de dimîne; lêbelê, dema ku gelek mezinahî li gel sermayeyên nifşê nû tên çêkirin, bikaranîna krediyan bi awayekî berbiçav zêde dibe, ku ev yek plansaziya pêşwext pêwîst dike.

5. Berhevkirina Kontingent/Fatûreyê: Ravekirina ka gelo kontingentên belaş bes in

Kîjan ji aliyê lêçûnê ve sûdmendtir e, û dema belaş dê çiqas bidome?

5.1 Sê Modelên Daketina Xercê

• Pîksela Kurt(danasîn)Kredî li gorî hejmara wêneyên resen û miniaturan têne hesab kirin; hilberandina guhertoyên WebP/AVIF dê ji bo her formatekê kêmkirinên krediyê yên zêde çêbike.
• Imagify(Kota MB)Kêmkirinên kotayê li ser bingeha mezinahiya pelê ya eslî ne; çiqas zêdetir pêşdîtin hebin, ewqas kêmkirin zêde dibe; ji nû ve pêçandin dê bibe sedema kêmkirinên zêdetir.
• TinyPNG(danasîn): 500 kredî her meh; çalakkirina veguherandina WebP/AVIF dê ji bo her mezinahiya wêneyî krediyên zêde xerc bike.

5.2 Rêbazên Texmînkirina Lezgîn

Hûn dikarin wisa texmîn bikin:

1. Wêneyekî xwe yê “orîjînal” ê ku tu pir caran bar dikî hilbijêre û mezinahiya wê ya texmînî kontrol bike (mînak: 300KB / 1MB / 3MB)
2. Hejmara texmînî ya mezinahiyên thumbnailan ku malpera we hildiberîne texmîn bikin (mînak, 5 / 10 / 20)
3. Diyar bike ka were çêkirin WebP/AVIF (Belê/Na)

Paşê vê “hesabkirina zîhnî” ya jêrîn bi kar bîne da ku xerckirinê fêm bikî:

• Pîksela KurtJi bo her wêneyekî ≈ (1 + hejmara miniaturayan) kredî; Heke hûn WebP/AVIF jî çêdikin, ≈ du qatî wê hejmarê (ji ber ku guhertoyên nifşê-nû jî krediyan hewce dikin).
• ImagifyHer wêne bi qasî (mezinahiya wêneya resen + mezinahiya giştî ya hemû miniaturayan) ji kotayê dixwe; Guhertina asta kompresyonê û ji nû ve kompresekirin dê bibe sedema kêmkirinên zêdetir ên kotayê.
• TinyPNGBelaş: 500 kredî; heke malpera we ji bo her wêneyekê gelek mezinahiyên wêneyan çêbike û veguhertin çalak be, mîqdara belaş dê bi awayekî berbiçav kêm bibe (rûpela pêvekê texmîneke hêsan a “nêzîkî 100 wêne di mehê de” li hember “nêzîkî 50 wêne di mehê de” pêşkêş dike).

6. Eşkerekirina Rîskê

Rîska 1: Xwe ji hebûna gelek pêvekan ên ku heman fonksiyonê bi awayekî dubare pêk tînin dûr bixin.

Ev çavkaniya herî berbelav a karesatan e.“

• Rêya A:Zêde WebP an AVIF + EWWW(Berpirsiyariyan di navbera herduyan de dabeş bikin; heman veguhertin û radestkirinan di heman demê de pêk neynin, an jî tenê yek ji wan saz nekin.)
• Rêya B: ShortPixel / Imagify / TinyPNG Ji sêyan yekê hilbijêre.(Yekî ku berpirsiyarê kompresyonê û nifşê nû be hilbijêre)

Rîska 2: Fonksiyona “li ser nivîsandin / jêbirina wêneya orîjînal / guhertina URL” ya Plus WebP, koçkirina sermayeyan pêk tîne.

Careke din, divê were tekezkirin:Zêde WebP Di danasînê de bi awayekî eşkere tê gotin ku di dema hilberîna tam de, nasnameya wêneyê ya orîjînal dê were şopandin, pelê orîjînal were jêbirin, û URL-a naverokê were guhertin.
Ev tê wê wateyê ku ew ne “sererastkirineke biçûk e ku dikare her dem were betalkirin”, lê belê guhertineke di asta sermayeyê de ye.

Divê stratejiya pêşniyarkirî ev be:

• Testkirina destpêkê ya bi pîvana piçûk (bi dehan heta bi sedan babet)
• Piştrast bikin ku nîşandana front-end, pêşdîtin (thumbnails), û nûvekirinên cache hemû rast dixebitin.
• Pêvajoya databasa-temam li ber çavan bigirin.

Rîska 3: Bikaranîna rastîn a “beşê belaş” ê kompresyona ewrî, bi hejmara thumbnailan û vebijarkên nifşê nû yên hatine hilbijartin ve girêdayî ye.

• Pîksela KurtPêşdîtin û nifşê nû dê bandoreke berbiçav li ser krediyan bikin.
• TinyPNGAktîvkirina WebP/AVIF dê ji bo her mezinahiya wêneyan kêmkirinên krediyê yên zêde çêbike.
• ImagifyLi gorî mezinahiya wêneya resen kêm bike; çi qas bêtir miniatur hebin, ew qas kêmkirin zêdetir dibe. Zexmkirina zêde dê bibe sedema kêmkirinên dubare.

Rîska 4: “WebP/AVIF-a çêkirî” ne hevsengê “Radestkirina WebP/AVIF-a frontendê” ye.”

Gelek bikarhêner radigihînin ku ew hîs dikin malpera wan piştî veguherandinê leztir nebûye, û sedema bingehîn ev e ku frontend hîn jî pelên JPG/PNG hildiberîne (ji ber lihevnehatinên di her qonaxeke pêvajoyê de: keşkirin, ji nû ve nivîsandin, etîket, an jî danûstandina gerokê).

7. Piştî temamkirina peywirê, ez çawa dikarim piştrast bikim ka ew ketiye meriyetê?

Çar xalên verastkirinê yên pir rasterast:

1. Gava ku heman rûpel careke din tê nûkirin, gelo pêvajoya barkirinê bêtir stabîl û bileztir dibe?(Bandoriya hestkirî ya keşkirin û optimîzasyonê)
2. Gelo di pîvanên wêneyan de di navbera barkirina mobîl û sermaseyê de cudahiyeke berbiçav heye?(Bersivdar) çavkanî/pîvan Gelo ew bi bandor e
3. Li çend wêneyan bi awayekî bilez binêre: Gelo pel/çavkaniyên WebP an AVIF hene?Gelo malper bi rastî wê bi kar tîne? nifşê nû）
4. Li çend wêneyan ji nişka ve binêre: nêzîk bike da ku bibînî ka ew bi awayekî berbiçav mat in an nivîs nezelal xuya dike.(Gelo kalîteya kompresyonê zêde ye?)

Heke her çar pîvan pêk bên, ev nîşan dide ku rêya ku we hilbijartiye jixwe çalak e. Derbasî gava paşîn bibin. CDN “Qata Radestkirinê”Seyreke giştî dê were xurtkirin.

8. Pêşniyarên ji bo Çalakiyê

1. Pêşî rêya xwe hilbijêre:

• Ez dixwazim heta ku mimkun e belaş bihêlim.Zêde WebP an AVIF + EWWW (an jî tenê yek ji wan saz bike)
• Ji bo teserûfa çavkaniyên serverê û kêfxweşiya zêdetir a derûnî bi fatûreya li gorî bikaranînê.Yek ji van li jêr hilbijêre: ShortPixel / Imagify / TinyPNG

2. Testeke biçûk (bi dehan tişt) pêk bîne.
3. Berî ku bi komê dest pê bikî, piştrast be ku her tişt di rê de ye.
4. Ji bo zêdekirina aramiya radestkirinê, pêdivî bi başkirinên zêdetir heye:Xwendin Lezbûna CDN

Pirsên Pir Tên Pirsîn

Divê ez çend pêvekan saz bikim? Ez dikarim hemûyan saz bikim?

Biceribîne ku li ser yek rê bimîne.

• Rêya A: Plus WebP an AVIF + EWWW Image Optimizer (an jî tenê yek ji wan saz bike)
• Rêya B: Ji ShortPixel / Imagify / TinyPNG yekê hilbijêre.
  Hebûna gelek pêvekan ku di heman demê de di nav heman malperê de “compression/conversion to WebP/AVIF/guhertina URL/nivîsandina ji nû ve ya radestkirinê” pêk tînin, bi îhtimaleke mezin dê her ku diçe kaotîktir bibe û ji bo çareserkirina pirsgirêkan bibe ya herî zehmet.

2. Ma WordPress jixwe piştgiriyê nade WebP/AVIF? Gelo hîn jî pêdiviya min bi pêvekekê heye?

Pêwîst e ku mirov cudahiyê bike:
“Piştgiriya barkirin/bikaranînê” ≠ “Veguherîna otomatîk/radestkirina otomatîk”.
WordPress 6.5 dê bixweber pelên JPG/PNG yên kevnar bi komê neguherîne bo WebP/AVIF, û herwiha dê bixweber tevahiya herikîna kar a “li gorî şiyanên gerokê bi vegerên paşîn AVIF/WebP derxistinê” bi rê ve nebe. Ji bo nûjenkirina pirtûkxaneyên medyayê yên dîrokî, bi gelemperî pêdivî bi pêvekan an xizmetan heye da ku pêvajoyê temam bikin.

3. Di nav optimîzasyona wêneyan de, kîjan gav vegera veberhênanê ya herî bilind pêşkêş dike?

Bi gelemperî Pêşî, pîvanan rast eyar bike (srcset/sizes)。
Gelek malper hêdî dixebitin ne ji ber ku kompresyona wan kêm e, lê ji ber ku rûpel tenê 900px nîşan didin û bikarhêneran neçar dikin ku wêneya tevahî ya 3000px daxînin. Kompresyon kîlobaytan teserûf dike, lê pîvanên lihevnehatî dikarin bêyî sedemek baş çend qatan zêdetir daneyan winda bikin.

4. Ez çawa dikarim piştrast bikim ku wêneyê ku niha tê barkirin “yê piçûktir” e, ne ku her tim yê orîjînal tê daxistin?

Du diyardeyan çavdêrî bike:

• Dema ku rûpel li ser cîhazeke mobîl tê vekirin, pîvanên wêneyê ku hatiye daxistin bi awayekî berbiçav ji yên ser komputerê biçûktir in.
• Mezinahiya çavkaniyê ya heman wêneyî diguhere dema ku li ser cîhazên cuda tê barkirin.
  Heke wêneyên resen her tim tên daxistin, sedemek berbelav ew e ku temayê/avaker wêneyê wekî wêneyek paşxanê ya CSS an jî wekî derketineke xwerû bi kar tîne, û bi vî awayî derbasî ser şiyanên pir-mezinahî û fonksiyona srcset a pirtûkxaneya medyayê dibe.

5. Gelo “WebP/AVIF-a çêkirî” bi awayekî mecbûrî tê wateya ku frontend WebP/AVIF-ê hildiberîne?

Ne heman tişt e.
Berhemdan tenê temamkirina “qata pelan” e; ka gelo frontend bi rastî WebP/AVIF pêşkêş dike an na, bi faktorên wekî ji nû ve nivîsandinê, stratejiya etîketa wêneyan, lêdanên cache, û ka gelo danûstandina gerokê dikeve meriyetê ve girêdayî ye. Piştî ku we xilas kir, divê hûn “cureyên çavkaniyan ên çend wêneyan bi awayekî xefikî kontrol bikin”.

6. Rîska bi WebP an AVIF re tam çi ye? Gelo ez dikarim li seranserê pirtûkxaneyê veguherandineke yek-klîk bimeşînim?

Xala wê ya rîskê ne “pêçandin” e, lê belêGuhertina Asta Veguhestina Malan：

• Di dema hilberîna bi pîvana tam de, dibe ku nasnameya pelê wêneyê yê resen were sernivîsandin, pelê resen were jêbirin, û URLyên di nav naverokê de werin guhertin.
  Ji ber vê yekêNe şîret e ku meriv tevahiya databasê yekser biguherîne.Pêşî ceribandinên biçûk-pîvan (bi dehan heta bi sedan tomar) bikin û piştrast bibin ku paşvekêşan berdest in, berî ku li ser pêvajokirina databasa tevahî bifikirin.

7. Meriv çawa di navbera du modên Plus WebP de hilbijêre: Wêneyê resen biparêze li hemberî Wêneyê resen biguherîne û jê bibe?

Bi gotineke hêsan:

• Mod 1: Wêneyê resen diparêze + kopyayeke WebP/AVIF çêdike (zêdetir stabîl)Ji bo vegerên paşve guncaw e, lê cihê dîskê dê zêde bibe (wêneyê resen + formatê nû + pêşdîtinên bi gelek mezinahiyan).
• Mod 2: Wêneyê resen biguherîne û jê bibe (zêdetir êrîşkar)Berfirehkirina dîskê bi hêsanî pêkan nîne, lê dema ku hûn sermaye û referansan di heman demê de diguherînin, lêçûna çareserkirina pirsgirêkên lihevhatinê bi awayekî berbiçav zêdetir dibe.
  Çiqas malper tevlihevtir be (e-bazirganî/pir-plugîn/pir-mezinahî), ewqas zêdetir şîret tê kirin ku meriv bi nêzîkatiyeke aramtir dest pê bike.

8. Gelo kompresyona herêmî ya belaş a EWWW Image Optimizer bes e? Gelo dikare sererê bar bike?

EWWW bêtir wekî “amûreke kompresyonê ya herêmî” ye: ew CPU/IO dixwe.
Di dema optimîzasyona komî de zêdebûna barê kar tiştekî berbelav e. Ev nayê wê wateyê ku nêzîkatiya bikêr ne bes e, lê belê divê stratejî guncaw be: di komikan de, di demjimêrên ne-qerebalix de pêk bînin, û dema ku pêwîst be, vebijarka daxistinê an jî çareseriyên ewrî (cloud) hilbijêrin.
Heke hûn li çareseriyeke bê-derd digerin an jî bi sînordariyên çavkaniyên serverê re rû bi rû ne, Rêya B ji aliyê serverê ve bikêrhatîtir e.

9. 100 krediyên belaş ên mehane yên ShortPixel – çima wisa tê hîskirin ku ew piştî tenê çend wêneyan diqedin?

Ji ber ku Kredî ne “hejmara wêneyan” in.”Dê wekî pêşdîtin were nîşandan û ji bo nifşê din were mezinkirin:

• Wêneyê resen + her miniatur wek kredî tê hesibandin.
• Heke WebP/AVIF were çêkirin, her guhertoyeke pêwendîdar dê xerckirineke zêde ya krediyê çêbike.
  Ji ber vê yekê, dibe ku hûn bifikirin ku “1 wêne” bi rastî dikare nêzîkî “krediyên du-reqemî” bikar bîne. ShortPixel

10. Çima kota belaş a Imagify ya 201 TP234T/mehê ewqas zû diqede?

Imagify bêtir dişibe “pakêteke daneyan”:

• Li gorî peyama teMezinahiya pelê ya resenKotayê jê bibire
• Çiqas zêdetir pêşdîtin, ewqas zêdetir xerckirin.
• Guhertina asta kompresyonê ji bo ji nû ve optimîzekirinê dê dîsa kotayê xerc bike.
• Mifteyeke API'yê ya yekane li ser çend malperan tê parvekirin, û kote jî li gorî wê tên parvekirin.
  Ji ber vê yekê, peyama “20MB dê di demek nêzîk de biqede” pir caran ji ber wêneyên pir mezin, pir zêde miniatur (thumbnail), an jî ceribandin û şaşiyên dubare çêdibe.

11. TinyPNG mehê 500 krediyên belaş pêşkêş dike, nexwe çima pêvek dibêje ku ew tenê ji bo nêzîkî 100 wêneyan e di mehê de? Û çima piştî çalakkirina WebP/AVIF, ev hejmar dadikeve 50 wêneyan di mehê de?

Ji ber ku krediyên TinyPNG'yê jî bi “mezinahî/varîant”ê tên zêdekirin:

• Sazkirineke standard a WordPressê bi gelemperî mehane nêzîkî 100 wêneyan pêç dike.
• Veguherandina AVIF an WebP çalak bike:Ji bo her mezinahiya wêneyî dê heqek zêde were standin.Ji ber vê yekê, îhtîmal e ku tenê kompreskirin û veguherandina nêzîkî 50 wêneyan di mehê de mimkun be (li gorî hejmara mezinahiyên thumbnailan).
  Ji ber vê yekê, 500 kredî ne 500 wêne ne.

12. Li ser malpera min çend biçûk-wêne hene? Çima ew xwedî bandoreke ewqas girîng e?

Barkirina wêneyekî li WordPressê gelek pîvanan çêdike; temayan/pêvekan (bi taybetî yên e-bazirganiyê) dikarin pîvanên din jî lê zêde bikin.
Kredî/kotayên kompresyonê yên ewrî bi gelemperî wekî “wêneya orîjînal + wêneyê biçûkkirî yên hevgirtî” têne hesab kirin, ji ber vê yekê her ku hejmara wêneyên biçûkkirî zêdetir be, dema kuota belaş dê kêmtir bidome.

13. Gelo barkirina tenbel her tim tiştan lez dike? Çima hinek îdia dikin ku ew bi rastî tiştan hêdî dike?

Barbûna tenbel ji bo çavkaniyên li derveyî ekranê guncaw e.
Heke wêneya mezin a herî girîng a li ser ekrana yekem jî were paşxistin, dibe ku ev yek ezmûna barkirina destpêkê hêdî bike. Her çend barkirina tenbel a standard a WordPress 5.5 bi giştî qebûlkirî be jî, ji nêzîkatiyeke giştî dûr bikevin.

14. Heke ez Rêya A an B bigirim, kengî pêdiviya min bi CDN / Wêne CDN heye?

Pêçan, mezinahî û format bersiva pêdiviya ji bo “pelên piçûktir û guncavtir” didin.
CDN radestkirineke bileztir û pêbawertir misoger dike.。
Dema ku ji ber wergirtina wêneyan ji servereke çavkaniyê ya dûr derengiyeke berbiçav çêdibe, lê zêdekirina CDN ji bo her wêneyekê (mînak, Cloudflare Polish / Jetpack Site Accelerator) bi gelemperî dibe sedema serpêhatiyeke stabîltir, û naverokê ji bo xwendinê hêsantir dike. Lezgîhandina WordPress CDN。

15. Piştî ku min xilas kir, riya herî hêsan ji bo piştrastkirinê çi ye ku bi rastî jî xebitiye?

Rêbaza verastkirinê ya herî dem-teserûfkar:

• Gava ku heman rûpel careke din tê nûkirin, gelo pêvajoya barkirinê bêtir stabîl û bileztir dibe?
• Gelo di pîvanên wêneyan de di navbera barkirina mobîl û sermaseyê de cudahiyeke berbiçav heye (gelo srcset/sizes wekî ku tê xwestin dixebitin)?
• Li çend wêneyan bi awayekî bilez binêre: Gelo pel/çavkaniyên WebP an AVIF hene?
• Li çend wêneyan ji nişka ve binêre: nêzîk bike da ku bibînî ka ew bi awayekî berbiçav mat in an nivîs nezelal xuya dike.