WordPress छवि अनुकूलन

इमेज ऑप्टिमाइजेशन वर्डप्रेस के प्रदर्शन में सबसे अधिक लाभदायक पहलुअन में से एक बा: एके पेज स्ट्रक्चर आ एके थीम के साथ, बस इमेज फाइल साइज, आयाम, फॉर्मेट आ डिलीवरी तरीका सही से सेट कइला से अक्सर लोडिंग स्पीड में तुरंत सुधार हो जाला।

हालाँकि, इमेज ऑप्टिमाइजेशन ओह क्षेत्र ह जहाँ सबसे आसान बा कि सब कुछ गड़बड़ हो जाए; कारण ई नइखे कि तकनीक बहुत मुश्किल बा, बल्कि जानकारी बहुत बिखराइल बा:
रउआ कई गो लेख पढ़नी, जान गइनी कि “कंप्रेसन” “WebP/AVIF” “लेज़ी लोड” चाहीं, फेर प्लगइन के परिचय देखनी त उ कहलस “हर महीना 100 क्रेडिट मुफ्त” “मुफ्त 20MB” “हर तस्वीर पर 1 क्रेडिट”, एसे देखत-देखत अउरी उलझन बढ़ गइल—आखिर मुफ्त वाला काफी बा कि ना? पैसा कइसे कटेला? कहीं रउआ “एके चीज” के मतलब गलत त ना समझनी? आ सबसे जरूरी बात:का ई सचमुच काम कइल जब तू पूरा कर लेहलू?

ई लेख बस तीन गो काम करेला:

1. एगो व्यावहारिक सुझाव बा।रास्ता के नक्शा(पहिले का करीं, फेर का करीं)
2. कृपया आप जे विकल्प पर विचार करत बानी, ओकरा के विस्तार से समझाईं (मुफ्त आ सशुल्क संस्करण में असल में का अंतर बा आ ई दुनो में से केकरा खातिर बढ़िया बा)
3. एहिजा सबसे आम फंदा बा जेकरा से सावधान रहे के चाहीं (ताकि काम पूरा होखे के बाद रउआ समाधान खोजे में समय ना गँवावे के पड़े)

1. बुनियादी बातें: वर्डप्रेस में का-का मिलेला, आ का-का ना मिलेला

अगर रउआ पहिले से ना समझब कि वर्डप्रेस कोर पहिले से का कर चुकल बा, त दू गो बात होखे के संभावना बा:

• हमनी के लगे जे “मुफ्त सुविधा” उपलब्ध बा, ओकर इस्तेमाल करे के बदले हमनी समय आ पैसा बरबाद क के पहिया के फेर से आविष्कार कइनी।
• हम सोचनी कि वर्डप्रेस अपने आप सभ पुरान इमेज के WebP/AVIF में बदल दी, बाकिर पता चलल कि ई ना कर रहल बा।

WordPress कोर में पहले से ही ई मुख्य फीचर शामिल बा:

• रेस्पॉन्सिव इमेजेज (srcset/sizes)WordPress 4.4 से आगे से, कोर छवियन के आउटपुट करी। srcset 与 sizes... आ अपलोड के दौरान बनल बहु-आकार वाली छवियन के इस्तेमाल करेला, ताकि ब्राउज़र स्क्रीन के हालत के हिसाब से सबसे उपयुक्त संसाधन चुनके लोड कर सके।
• नेटिव लेज़ी लोडिंगWordPress 5.5 से आगे, HTML मानकन के इस्तेमाल करत, छवियन खातिर नेटिव लेज़ी लोडिंग डिफ़ॉल्ट रूप से सक्षम बा। loading संपत्ति के क्रियान्वयन।
• WebP अपलोड के समर्थन करेलाWordPress 5.8 से आगे, रउआ WebP फाइलन के ठीक ओही तरीका से अपलोड आ इस्तेमाल कर सकेनी, जइसन कि JPEG आ PNG (बशर्ते रउआ के होस्टिंग वातावरण WebP के सपोर्ट करे)।
• AVIF अपलोड के समर्थन करेलाWordPress 6.5 से आगे, AVIF फाइलन के JPEG आ PNG फाइलन नियर अपलोड कइल जा सकेला आ इस्तेमाल कइल जा सकेला (होस्ट वातावरण के समर्थन पर निर्भर बा).

कृपया ध्यान दीं, हालांकि:
“अपलोड करे/उपयोग करे खातिर समर्थन” ≠ “स्वचालित रूपांतरण/स्वचालित वितरण”
दूसर शब्दन में: भले ही रउआ पहिले से WP 6.5 पर बानी, रउआ के मीडिया लाइब्रेरी में मौजूद JPG/PNG फाइल अपने आप WebP/AVIF में ना बदल जइहें; ना ही रउआ के ब्राउज़र के क्षमता के आधार पर AVIF/WebP आउटपुट करे आ जे ब्राउज़र सपोर्ट ना करे ओकरा खातिर मूल इमेज पर वापस जाए के पूरा फंक्शनलिटी अपने आप मिल जाई—एह खातिर आमतौर पर एगो प्लगइन या सर्विस के जरूरत पड़े ला।

2. रोडमैप: इमेज ऑप्टिमाइजेशन खातिर 5-चरणीय गाइड

का करीं, काहे करीं, पास का होला, आउर आम गलती का-का बा।

2.1 पहिले “आयाम” सही से तय करीं (सबसे आसानी से अनदेखा होखे वाला, बाकिर जे सबसे बेसी फायदा देला)

कई वेबसाइट धीमा बाड़े, ई एह से ना कि उनका ऑप्टिमाइज ना कइल गइल बा, बल्किडिस्प्ले क्षेत्र से बहुत बड़हन एगो छवि डाउनलोड कइनी।：
उदाहरण खातिर, अगर एगो पेज असल में खाली 900px चौड़ा बा, लेकिन रउआ विजिटर्स से असली 3000px के इमेज डाउनलोड करावत बानी, त ब्राउज़र बस ओकरा डाउनलोड करी आ फेर दिखावे खातिर छोट कर दी। ई बैंडविड्थ बर्बाद करेला, डीकोडिंग के समय बढ़ा देला आ सामग्री के पहिला स्क्रीन पर देखाए में देरी करेला।

WordPress 4.4 आ ओकरा बाद खातिरप्रतिक्रियाशील छवि तंत्र（srcset/sizes) ठीक एह समस्या के समाधान खातिर डिजाइन कइल गइल रहे।

पास का होला:

• जब पेज मोबाइल डिवाइस पर देखावल जाला, तब डाउनलोड कइल तस्वीर डेस्कटॉप के तुलना में साफ-साफ छोट देखाई देवे के चाहीं।
• ओही इमेज के फाइल साइज डिवाइस पर निर्भर करेला (हमेशा ओरिजिनल इमेज डाउनलोड करे के बजाय)

सबसे आम फंदा:

• कुछ थीम या बिल्डर इमेज के CSS बैकग्राउंड इमेज के रूप में ट्रीट करे लें या उनकर कस्टम तरीका से रेंडर करे लें, जेसे बाईपास हो सकेला। srcset, जवना से बड़का इमेज लोड होत रहेला
• अगर रउआ बाहरी इमेज होस्टिंग सेवा या तिसरका पक्ष के इमेज ब्लॉक इस्तेमाल करेलें, त रउआ मीडिया लाइब्रेरी द्वारा बनावल बहु-आकार प्रणाली के बाईपास कर सकेनी।

---

2.2 संपीड़न (गुणवत्ता से समझौता कइले बिना फाइल के साइज घटावल)

कंप्रेशन के असल मतलब ई नइखे कि “छोटका बढ़िया बा”, बल्कि ई बा कि “फरक नंगी आँख से मुश्किल से दिखेला, तबो फाइल साइज काफी घट जाला”।

नियम निम्नलिखित बा:

• फोटोग्राफ/असल जिंदगी के शॉट्स (पोर्ट्रेट, प्रोडक्ट, लैंडस्केप)हानि वाला संपीड़न के प्राथमिकता दीं (अधिकतम लाभ)
• बहुत सारा टेक्स्ट वाला स्क्रीनशॉट/तस्वीरटेक्स्ट धुंधला ना दिखे खातिर अधिक रूढ़िवादी संपीड़न लागू करीं।
• लोगो/आइकनSVG के प्राथमिकता दीं या बिना डेटा हानि के कम्प्रेशन के सावधानी से इस्तेमाल करीं (डेटा हानि वाला कम्प्रेशन आसानी से किनारा धुंधला कर देला)

पास का होला:

• अधिकांश पेज छवियन के फाइल साइज काफी घटा दिहल गइल बा।
• कोई ध्यान देने लायक शोर, धुंधला किनारा, रंग में पट्टी या धुंधला पाठ ना होखे

---

2.3 WebP / AVIF (फ़ॉर्मेट नीति: ओही स्तर के स्पष्टता खातिर छोट फाइल साइज़)

WordPress अब फाइल अपलोड के समर्थन करेला। WebP (5.8) आ AVIF (6.5)。
हालाँकि, “अगली पीढ़ी के फॉर्मेट” के व्यावहारिक इस्तेमाल में लावे खातिर, आमतौर पर दू गो समस्या के समाधान करे के जरूरत होला:

1. ऐतिहासिक मीडिया लाइब्रेरी के बैच में कइसे कन्वर्ट करीं(नाहीं त, रउआ खाली भविष्य में अपलोड होखे वाली नया इमेज के ही ऑप्टिमाइज करब)
2. का हम कॉपी बनाईं या असली तस्वीर बदल दीं?(ई एगो महत्वपूर्ण बिंदु बा; हमनी बाद में Plus WebP के “मूल के बदल के हटा देवे” फीचर पर ध्यान देब.)

सुझावल तरीका:

• WebP: आमतौर पर डिफ़ॉल्ट विकल्प (अधिक भरोसेमंद संगतता देला)
• AVIF: एगो अउरी उन्नत कंप्रेशन फॉर्मेट, जे बड़हन छवियन, पहिला स्क्रीन पर बड़हन छवियन, आ गैलरी छवियन खातिर उपयुक्त बा (बाकिर अधिकपर्यावरणीय सहायता पर निर्भर）

---

2.4 लेज़ी लोडिंग के सही से इस्तेमाल करीं (एकही साइज़ सब पर फिट करे वाला तरीका मत अपनाईं)

WordPress 5.5 से आगेडिफ़ॉल्ट सुस्त लोडिंगछवि।
ई शुरुआती रेंडरिंग के दौरान बैंडविड्थ के इस्तेमाल घटावेला:

• लेज़ी लोडिंग “ऑफ-स्क्रीन संसाधन” खातिर उपयुक्त बा।”
• पन्ना के ऊपर वाला बड़का चित्र (जे अक्सर पहिला स्क्रीन पर सबसे महत्वपूर्ण चित्र होला) आमतौर पर डिफ़र्ड लोडिंग खातिर उपयुक्त ना होला।

---

2.5 डिलीवरी स्तर: CDN / तस्वीर CDN

कंप्रेशन, फाइल साइज आ फॉर्मेट, सभे के मकसद बा कि फाइलन के छोट आ अधिक उपयुक्त बनावल जाव।
बाकिर अगर तस्वीर हमेशा स्रोत साइट से दूर से लावल जात रहे, त नेटवर्क देरी अबहियो अनुभव पर साफ असर डाली। एह घरी “डिलीवरी लेयर” के समाधान चाहीं (CDN/तस्वीर CDN)।

दू गो आम तरीका:

• क्लाउडफ्लेयर पॉलिश：क्लाउडफ्लेयर दस्तावेज़ई अनुभाग पोलिश में उपलब्ध संपीड़न विधियन (नो-हानि, हानि आ WebP) के परिचय देला, आ इनकर इस्तेमाल के उल्लेख करेला format=auto WebP आ AVIF फॉर्मेट मानल गइल बा।
• जेटपैक साइट एक्सेलेरेटर：जेटपैक दस्तावेजएकर मतलब बा कि ई इमेजन के ऑप्टिमाइज करी आ स्टैटिक रिसोर्सन के साथे-साथ अपना नेटवर्क से वितरित करी।

छवि अनुकूलन ई सुनिश्चित करेला कि छवियन के आकार घटावल जाला आ सही से पुनःआकारित कइल जाला।CDN डिलीवरी खातिर अउरी नज़दीक अउरी भरोसेमंद

3. मार्ग चयन: केवल दू गो मुख्य मार्ग हीं अपनाईं।

इमेज ऑप्टिमाइजेशन में सबसे आम फंदा “प्लगइन ना लगा पावल” ना ह, बल्कि बहुत सारा प्लगइन लगा देवे से होखेला, जे डुप्लिकेट प्रोसेसिंग के कारण बन जाला:
A कंप्रैस कर रहल बा, B भी कंप्रैस कर रहल बा; A WebP/AVIF में कन्वर्ट कर रहल बा, B भी ओही काम कर रहल बा; A URLs बदल रहल बा, B URLs के रीराइट कर रहल बा—अंत में, रउआ खुदो समझ ना पावत बानी कि साइट पर असल में का हो रहल बा।

नियम:

एक तरीका पर टिकल रहीं: या त पूरा तरह से मुफ्त लोकल स्टोरेज, या तीन क्लाउड कंप्रेशन विकल्पन में से एक।

• रूट A (पूरी तरह से मुफ्त स्थानीय):साथहीं WebP भा AVIF + EWWW Image Optimizer(या बस एक चुन लीं)
• विकल्प B (तीन क्लाउड संपीड़न विधियन में से एक चुन लीं):शॉर्टपिक्सल / इमेजाइफ़ाई / टिनिपिंजी

---

3.1 विकल्प A: पूरा मुफ्त लोकल होस्टिंग (साथ में WebP या AVIF या EWWW)

एह मार्ग के मुख्य विशेषताएँ बा:

• रउआ ओह तिसरका पक्ष के कम्प्रेशन सेवा पर भरोसा ना करीं जे मासिक कोटा या प्रति फाइल आधार पर चार्ज करेला (हालाँकि कुछ फीचर वैकल्पिक सेवा के रूप में उपलब्ध हो सकेला)
• कीमत बा: बैच प्रोसेसिंग सर्वर CPU/IO पर जादे लोड डाल सकsता, एह से रउआ के रणनीति आ जोखिम पर अउरी ध्यान देवे के पड़ी“

3.1.1 साथे WebP भा AVIFमूल अवधारणा “जनरेशन/रिप्लेसमेंट” बा; ई पारंपरिक मायने में “कंप्रेशन टूल” ना ह।”

• जब पूरा छवियन के सेट बनावल जाला:मूल इमेज फाइल के आईडी WebP/AVIF फाइल से ओवरराइट हो जाई, मूल फाइल डिलीट हो जाई, आ सामग्री में मौजूद सभ URL भी बदल दीहल जाई।。
• ई प्लगइन WP-CLI कमांड देला आ सलाह देला कि जब बड़हन संख्या में फाइलन से निपटे के होखे त WP-CLI ज्यादा भरोसेमंद बा।

एकर मतलब बा: ई खाली चुपचाप तोहरे खातिर एगो WebP फाइल ना बनावेला, बल्कि ई हो सकेलासंपत्ति हस्तांतरण(खास करके अगर रउआ “मूल के बदलीं आ हटाईं” विकल्प सक्षम कइले बानी)

दूनो मोड में अंतर

विकल्प 1: मूल छवि के रखल जाव + WebP/AVIF कॉपी बनावल जाव (अधिक भरोसेमंद)

• फायदा: अगर अनुकूलता में दिक्कत होखे त वापस ले आवे में आसान होला।
• नुकसान: डिस्क के इस्तेमाल बढ़ जाई (मूल इमेज + नया फॉर्मेट + कई थंबनेल साइज)

विधि 2: मूल छवि के बदलल आ हटावल (अधिक कट्टर)

• फायदा: डिस्क जल्दी से भर नाई; आंतरिक लिंक अपने आप नया फॉर्मेट में बदल जालन।
• जोखिम: अगर रउआ संपत्ति आ उनका संदर्भ दुनो में बदलाव करब, त अनुकूलता संबंधी समस्या के निवारण अउरी महँगा पड़ी (खासकर जहाँ बाहरी सिस्टम या थीम लॉजिक मूल फाइल नाम, पथ या फॉर्मेट पर निर्भर होखे)।

WebP या AVIF से जुड़ल आम दिक्कतें

1. पूरा लाइब्रेरी बदलला के बाद, कुछ पन्ना पर तस्वीरें गलत ढंग से दिख रहल बाड़ी स।
   अक्सर कारण ई ना होला कि “छवि टूटल” बा, बल्कि कहीं ना कहीं चेन में कुछ गड़बड़ हो गइल बा—जइसे URL बदलल, कैशिंग, या थंबनेल नीति।
2. जितना अधिक थंबनेल होइहें, बदलाव के दायरा ओतने बड़ होई।
   WordPress में इमेज अपलोड करे पर कई गो साइज बन जाला; थीम आ प्लगइन अउरी साइज जोड़ सकेला। पूरा बदली के मतलब बा कि रउआ बहुत बड़हन फाइलन के सेट में बदलाव कर सकत बानी।
3. सिर्फ फॉर्मेट कन्वर्जन करे से जरूरी नइखे कि फाइल के साइज सबसे छोट हो जाई।
   WebP आ AVIF फाइल आमतौर पर छोट होला, बाकिर “आयाम निर्धारण रणनीति” आ “संपीड़न रणनीति” बहुते जरूरी बा। Plus WebP के तेज लोडिंग समय खातिर “वन-क्लिक समाधान” मत मानल जाव।

---

3.1.2 ईव्वव इमेज ऑप्टिमाइज़रमुफ्त स्थानीय संपीड़न के एगो प्रमुख प्रदाता

EWWW प्लगइन पेज के एकदम साफ मकसद बा:

• ई रउरा सर्वर पर मौजूद छवियन के कई गो टूल (jpegtran, optipng, pngout, pngquant, gifsicle, cwebp आदि) के इस्तेमाल से ऑप्टिमाइज कर सकेला।
• अगर रउआ के अउरी ज्यादा संपीड़न या CPU के बचत के जरूरत बा, त CPU खपत वाला प्रोसेसिंग ओहकर सर्वर पर ऑफलोड भी क सकतानी (वैकल्पिक)।

रूट A में EWWW के का भूमिका होखे के चाहीं?

अगर रउआ “फॉर्मेट माइग्रेशन/रिप्लेसमेंट रणनीति” खातिर Plus WebP के इस्तेमाल करेलें, त EWWW एह काम खातिर बढ़िया बा:

• दबाव आ मात्रा के अनुकूलन(खास करके JPG आ PNG फाइल जइसन कच्चा एसेट्स के अनुकूलन)
• ऐतिहासिक मीडिया लाइब्रेरी के बैच अनुकूलन(URL बदलल के बजाय मात्रा में कमी के लक्ष्य)

EWWW के एगो आम फंदा

1. बैच ऑप्टिमाइजेशन के दौरान सर्वर लोड बढ़ जाला।
   काहेकि लोकल कंप्रेशन सीधे CPU/IO खा जाला। उपाय ई नइखे कि “मत इस्तेमाल करीं”, बल्कि “बैच में, कम लोड वाला समय में, आ जरूरत पड़े त ऑफलोड/क्लाउड विकल्प चुनल जाव”।
2. “WebP बन गइल बा” के मतलब ई जरूरी नइखे कि फ्रंट-एंड असल में WebP परोसत बा।
   कई प्लगइन्स ई गलतफहमी में काम करेलन कि जनरेशन एगो चीज बा, जबकि डिलीवरी रणनीतियन (जइसे कि फिर से लिखल, `picture` टैग आ कैश एक्सपायरी) बिलकुल अलग बा।
3. दूसरा प्लगइन के फंक्शनैलिटी के नकल करेला
   अगर रउआ विकल्प A चुनत बानी, त ShortPixel, Imagify या TinyPNG जइसन अतिरिक्त क्लाउड कंप्रेशन सेवा के इस्तेमाल से बचे के कोशिश करीं; अगर रउआ विकल्प B चुनत बानी, त Plus WebP में रिप्लेसमेंट लॉजिक के सक्षम मत करीं। मूल सिद्धांत बा:एकही रास्ता पर टिकल रहीं।

---

3.2 विकल्प B: तीन क्लाउड कम्प्रेशन सेवा (ShortPixel / Imagify / TinyPNG) में से एक चुन लीं

ई प्लान ओह लोग खातिर बढ़िया बा जे सर्वर के संसाधन बचावे के चाहेलें, बैच प्रोसेसिंग में झंझट-मुक्त तरीका पसंद करेलें, आ उपयोग-आधारित या पे-एज़-यू-गो बिलिंग से सहज बाड़ें।
हालाँकि, क्लाउड कम्प्रेशन के बारे में सबसे आम गलतफहमी ई बा:मुफ्त भत्ता खाली “मुफ्त शीट्स” के मामला ना ह।थंबनेल के साइज़ के संख्या, WebP/AVIF फॉर्मेट बनल बा कि ना, आ इमेज बार-बार कंप्रेस होखल बा कि ना, ई सब रिसोर्स के इस्तेमाल पर गहिर असर डाले ला।

नीचे हमनी समझाईब: मुफ्त आ सशुल्क विकल्प में का अंतर बा, क्रेडिट कइसे कटल जाला, सबसे आम फंदा से कइसे बचे, आ ई सेवा खातिर कौन-कौन वेबसाइट सबसे बढ़िया बा।

---

3.2.1 शॉर्टपिक्सल: हर महीना 100 मुफ्त क्रेडिट, लेकिन थंबनेल आ WebP/AVIF के बड़ा कइल से ई क्रेडिट खतम हो जाई

मुफ्त आ पेड विकल्पन के का मामला बा?

ShortPixel प्लगइन के विवरण में साफ-साफ कहल गइल बा:

• हर महीना 100 मुफ्त क्रेडिट
• एकरे अलावा “अतिरिक्त असीमित मासिक क्रेडिट” भी बा (कीमत के विवरण प्लगइन पेज पर दिहल बा)
• हमनी “एक बेर वाला क्रेडिट पैक जे कबो खत्म ना होखे” भी ऑफर करिला (साथे शुरुआती दाम के जानकारी)

नोट:

• मुफ्त: हर महीना कुछ निश्चित क्रेडिट हल्का-फुल्का वेबसाइट पर इस्तेमाल करे या टेस्ट करे खातिर दिहल जाला।
• एक बेर वाला पैकेज: बड़हन मीडिया लाइब्रेरी वाला साइट खातिर उपयुक्त बा, जे एक साथे आपन इन्वेंटरी खाली करे के चाहेला (एक बेर खरीदला पर जब तक पूरा ना हो जाई वैध बा; आमतौर पर एकर समाप्ति तारीख ना होला)
• मासिक/अनलिमिटेड: ओह साइटन खातिर ठीक बा जेकरा नियमित इमेज अपडेट आ लंबा समय ले स्थिर ऑप्टिमाइजेशन के जरूरत बा।

ShortPixel के आधिकारिक ज्ञान आधार “एक बेर के लाइसेंस बनाम असीमित मासिक” पर भी मार्गदर्शन देला।एक स्पष्ट व्याख्या: असीमित मासिक योजना में महीना-के हिसाब से (या सालाना) भुगतान होला, एह में असीमित क्रेडिट्स मिलेला, आ एक तय CDN कोटा साथे आवेला; एकमुश्त क्रेडिट्स के मियाद खत्म नइखे होत, एहसे रउआ जरूरत अनुसार ओकरा के अउरी नियंत्रित ढंग से इस्तेमाल कर सकत बानी।

सबसे जरूरी बात: ShortPixel क्रेडिट्स के हिसाब कइसे लगावल जाला?

ShortPixel आधिकारिक दस्तावेज केबी एकदम साफ-साफ कह दिहलन:

• जब रउआ वर्डप्रेस पर एगो इमेज अपलोड करेलीं, त ई कई गो थंबनेल बनावेला;
• हर थंबनेल के ऑप्टिमाइज करे पर एक क्रेडिट गिनेला।；
• अगर रउआ WebP भा AVIF बनावे के चुनत बानी,मूल छवि के हर WebP/AVIF संस्करण आ ओकर थंबनेल एगो अतिरिक्त क्रेडिट के रूप में गिनल जाई।；
• रउआ क्रेडिट के इस्तेमाल कम करे खातिर कुछ थंबनेल के ऑप्टिमाइजेशन से बाहर रख सकतानी।

क्रेडिट्स उदाहरण：

मान लीं कि रउआ एक गो इमेज अपलोड करेलें, आ थीम भा प्लगइन आठ गो थंबनेल बनावेला:

• केवल मूल छवि आ थंबनेल के ऑप्टिमाइज करीं: 1 (मूल छवि) + 8 (थंबनेल) = 9 क्रेडिट
• अगर रउआ भी WebP/AVIF जनरेट करे के चाहत बानी: ऊपर बतावल 9 में से हर एक में अगिला पीढ़ी के वर्शन जोड़ऽ → साथे 9 क्रेडिट
  दूसर शब्दन में, रउआ सोच सकतानी कि ई “एक इमेज” बा, बाकिर असल में एकर कीमत लगभग “दहाई अंक वाला क्रेडिट” हो सकेला।

एह से:“100 फ्री क्रेडिट्स” के मतलब “100 फ्री इमेजेज” ना होला।

ShortPixel के सबसे आम समस्याएँ

1. मुफ्त 100 क्रेडिट जल्दीए खत्म हो जइहें
   कारण: थंबनेल के बड़हन संख्या + WebP/AVIF फाइल बनावे खातिर अतिरिक्त क्रेडिट।
   सिफारिश：

• पहिले, साइट के थंबनेल के संख्या के आकलन करीं।
• अनावश्यक थंबनेल साइज हटा दीं (केवल ओही साइज के अनुकूलित करीं जे वाकई में इस्तेमाल होखी)
• पहिले एगो कंप्रेशन रणनीति तय करीं, फेर प्रक्रिया के बैच में चलाईं ताकि ट्रायल आ एरर में समय बर्बाद ना होखे।

2. अन्य फॉर्मैट रूपांतरण प्लगइन्स के साथे इस्तेमाल करीं
   अगर रउआ Plus WebP रिप्लेसमेंट सक्षम करब आ ShortPixel से नेक्स्ट-जेन टैग बनवाके लगावेब, त लॉजिक ओवरलैप हो जाई, जवना से समस्या निवारण अउरी मुश्किल हो जाई। ऑप्शन B में, ShortPixel ई काम अपने आप संभाल लेला।
3. हम मान लिहनी कि एक बेर ई इंस्टॉल हो जाई, त फ्रंटएंड अपने आप WebP/AVIF फाइल बना दी।“
   ShortPixel प्लगइन पेजई WebP आ AVIF फाइलन के कन्वर्ट कर सकेला, आ अगिला पीढ़ी के इमेज के फ्रंट-एंड पेज में शामिल कर सकेला (उदाहरण खातिर टैग के माध्यम से)।
   हालाँकि, रउआ के काम ख़त्म होखे के बादो नतीजा जरूर देखे के पड़ी।

---

3.2.2 इमैजिफाईमुफ्त 20MB/महीना; कोटा “मूल चित्र आकार + थंबनेल संख्या” के हिसाब से कटेला, दोबारा कंप्रेस करे पर फेर कटेला

मुफ्त भत्ता आ ठिकाना

इमेजिफाय आधिकारिक मूल्य निर्धारण पृष्ठई बिलकुल साफ-साफ कहल गइल बा:मुफ्त खाता खातिर हर महीना 20MB कोटा。
एकर प्लगइन पेज पर ई भी लिखल बा कि ई कंप्रैस, रिसाइज आ WebP/AVIF में कन्वर्ट कर सकेला।

कोटा कइसे कटल जाला?

इमैजिफाई आधिकारिक दस्तावेज “कोटा उपयोग के गणना कइसे होला?” बिलिंग के तरीका बहुत साफ-साफ समझावेला:

• थंबनेल के संख्या संसाधन के उपयोग पर असर डालेला।उदाहरण खातिर, अगर रउरा लगे 10 गो थंबनेल साइज बा, त एके गो इमेज के ऑप्टिमाइज करे पर कुल 11 गो इमेज (मूल इमेज आ 10 गो थंबनेल) ऑप्टिमाइज हो जइहें, जे सभ रउरा कोटा में गिनल जइहें।
• मूल फ़ाइल साइज़ के आधार पर कोटा घटाईंउदाहरण खातिर, अगर रउआ Imagify पर 100KB के इमेज अपलोड करब, त रउआ के कोटा से 100KB कट जाई।
• कम्प्रेशन स्तर बदले आ फेर से ऑप्टिमाइज करे पर क्वोटा फेर से खपत होई।。
• एक API की कई गो साइट पर इस्तेमाल कइल जा सकेला, बाकिर कोटा सभमें बाँटल जाला।

ई इमैजिफाई के “मुख्य तरीका” बा:
ई एक तरह के डेटा पैकेज बा: जेतना अधिक तू अपलोड करब, ओतना अधिक ई कटिहें; जेतना अधिक थंबनेल तू अपलोड करब, ओतना अधिक ई कटिहें; आ अगर तू एके सामग्री के बार-बार अपलोड करब, त हर बेर ई शुल्क कटिहें।

Imagify कोटा के समझ में आसान उदाहरण

मान लीं कि रउआ 800 KB के एगो असली फोटो अपलोड करत बानी, आ साइट 8 गो थंबनेल बनावेला।

• जब इमेजिफाय से ऑप्टिमाइज कइल जाला, तब “मूल इमेज आ 8 थंबनेल” दुनो शामिल हो जालन (अगर रउआ “सब ऑप्टिमाइज” चुनत बानी), जेकर मतलब बा कि ई ऑपरेशन लगभग इन सब फाइलन के कुल साइज के बराबर कोटा इस्तेमाल करी।
  एही से कुछ साइट सभ के लागेला कि “20MB जल्दी खतम हो जात बा”: बात Imagify के कम पड़े के नइखे, बलुक रउआ हर बेर अपलोड कइल तस्वीर बहुत बड़ होला, थंबनेल बहुत जादे बनत बा, आ हो सकेला कि रउआ बार-बार कंप्रेशन लेवलो बदल-बदल के ट्राइ करत होखीं।

Imagify के सबसे आम फँस।

1. मुफ्त 20MB पूरा साइट इतिहास साफ करे खातिर पर्याप्त नइखे“
   20MB आमतौर पर परीक्षण आ हल्का अपडेट खातिर जादे उपयुक्त बा; अगर तोहार मीडिया लाइब्रेरी पहिले से बहुत बड़ा बा, त एके बेर पूरा लाइब्रेरी साफ करे पर बहुत संभव बा कि अपग्रेड करे के पड़ी।
2. बार-बार कम्प्रेशन स्तर समायोजित करे से कोटा बार-बार खत्म हो जाला।
   इमैजिफाई: एगो साफ-साफ समझाइशफिर से अनुकूलन फेर से कोटा खतम कर दी।
   हमनी के सलाह बा कि रउआ एह पेज पर “रणनीति” साफ-साफ लिख दीं:

• संकुचन स्तर आ दृश्य गुणवत्ता तय करे खातिर पहिले कुछ कम छवियन के इस्तेमाल करीं।
• एक बेर रणनीति पक्का हो जाए, तब एकरा के बैच में चला दीं।
  पूरा डेटाबेस में ट्रायल आ एरर से बचीं

3. एकही API की कई गो साइट पर शेयर करे से कोटा रहस्यमयी ढंग से घट जाला।“
   अगर रउआ एके API की कई गो साइट पर इस्तेमाल करब, त कोटा साझा हो जाई।
   एह से, टीम या बहु-साइट परिदृश्य में ई सबसे बढ़िया होला कि साफ-साफ बतावल जाव कि कौन-कौन साइट संसाधन साझा करेली आ कौन-कौन साइट स्वतंत्र रूप से चलेली, ताकि बजट के अधिक खर्च से बचा जा सके।

---

3.2.3 छोट पीएनजी(छोट कंप्रेशन इमेजेज): प्रति महीना 500 मुफ्त क्रेडिट; WebP/AVIF में बदलला पर हर साइज पर 1 क्रेडिट अतिरिक्त चार्ज लागेला“

मुफ्त भत्ते आ उनका हिसाब-किताब

TinyPNG WordPress प्लगइन के पेज बहुत साफ-साफ लिखल बा:

• हर महीना 500 क्रेडिट मुफ्त
• एक “मानक वर्डप्रेस इंस्टॉलेशन” में, रउआ शायद संपीड़ित कर सकेनी। लगभग हर महीना 100 तस्वीरें
• हालाँकि, अगर AVIF या WebP रूपांतरण सक्षम बा:प्रत्येक छवि के आकार खातिर एक अतिरिक्त क्रेडिट लागत बा।, त हम सोचत बानी कि एकमात्र विकल्प बा कि एकरा के कंप्रेस आ कन्वर्ट कर दीं लगभग 50 तस्वीरें प्रति महीना(ई बात पर निर्भर बा कि रउरा लगे कतना थंबनेल साइज बा.)

इसी बीच, टिनिफाई (TinyPNG आ TinyJPG के डेवलपर) भी एपीआई प्राइसिंग पेजकृपया ध्यान दीं: प्रति महीना 500 मुफ्त कम्प्रेशन खातिर साइन अप करीं; एक बेर ई सीमा पार हो जाए, तब रउरा से सफल कम्प्रेशन के गिनती के हिसाब से शुल्क लियाई, आ कवनो अनिवार्य सब्सक्रिप्शन के जरूरत ना होई।

एक ही वाक्य में TinyPNG कइसे काम करेला, एकर सारांश:
ई क्रेडिट में गिनल जाला; जेतना अधिक थंबनेल साइज रउरा लगेला आ जेतना अधिक रउरा WebP/AVIF सक्षम करेलीं, ओतने जल्दी रउरा क्रेडिट खतम हो जाई।

TinyPNG क्रेडिट्स के एक आसान से समझ में आवे वाला उदाहरण

मान लीं कि रउरा साइट हर इमेज खातिर आठ गो थंबनेल साइज बनावेला:

• केवल संपीड़न: मूल छवि + 8 थंबनेल → 9 क्रेडिट्स जरूरी बा
• अगर WebP/AVIF कन्वर्जन सक्षम बा: हर साइज पर एगो अतिरिक्त क्रेडिट कट जाई → ई कुल लागत लगभग दोगुना कर सकेला
  ई प्लगइन पेज पर दिहल विवरण से मेल खाला: एक बेर रूपांतरण सक्षम हो जाए, त मुफ्त कोटा लगभग “100 प्रति महीना” से बदल के “50 प्रति महीना” हो जाला।

TinyPNG के सबसे आम फँस।

1. हम सोचनी कि 500 क्रेडिट्स के मतलब 500 तस्वीरन ह।
   ना। ई “इमेज साइज/वेरिएंट” के आधार पर चार्ज होला। प्लगइन पेज पर साफ लिखल बा कि “कन्वर्जन पर हर इमेज साइज खातिर अतिरिक्त 1 क्रेडिट लागत बा”।
2. थीम/ई-कॉमर्स प्लगइन बहुत सारा इमेज साइज बना रहल बा, आ मुफ्त कोटा काफी घट गइल बा।
   जितना अधिक आयाम होइहें, क्रेडिट्स खतम होखे में ओतना आसान हो जाई।
3. कन्वर्जन सक्रिय करे के बाद, हमके पता चलल कि हमार क्रेडिट लिमिट अचानक खतम हो गइल।
   ई कोई बग नइखे; ई बिलिंग सिस्टम के काम करे के तरीका ह।
   रणनीति सिफारिशें:

• अगर फ्री फेज मुख्य रूप से कंप्रेशन आ वजन घटावे खातिर बा, त रउआ बस कंप्रेशन लागू करके शुरुआत कर सकत बानी। एक बेर जब रउआ ई पक्का कर लेब कि साइट के संरचना स्थिर बा आ रउआ के सचमुच नेक्स्ट-जेन के जरूरत बा, तब रउआ रूपांतरण शुरू कर सकत बानी।

4. परिदृश्य के हिसाब से सिफारिश: अलग-अलग प्रकार के वेबसाइट खातिर कइसे चुनल जाव

हालाँकि सभे वर्डप्रेस इस्तेमाल करेलन, लेकिन कंटेंट साइट, ई-कॉमर्स साइट, पोर्टफोलियो आ मेंबरशिप साइट में इमेज से जुड़ल समस्या अलग-अलग होला।

4.1 सामग्री साइट/ब्लॉग (जवना में ढेर सारा तस्वीर आ लेख होखेला, आ जेकर अपडेट आवृत्ति मध्यम बा)

प्राथमिकता सिफारिशें:

1. आयाम निर्धारण रणनीति (चरण 1)
2. दबाव (चरण 2)
3. WebP (चरण 3)

एक अधिक उपयुक्त मार्ग:

• अगर रउआ बिना झंझट वाला विकल्प चाहत बानी: त Option B में से कवनो एक चुन लीं (ShortPixel / Imagify / TinyPNG)
• अगर रउआ मुफ्त विकल्प चाहत बानी: रूट A (Plus WebP + EWWW), बाकिर हमनी सलाह देतानी कि पहिले जोखिम के आकलन खातिर “Conservative Mode (मूल छवियन के मिटाईं मत)” से शुरू करीं।

सामान्य फंदा:

• लेख पेज पर हेडर इमेज बहुत बड़ बा, आ लेज़ी लोडिंग रणनीति ठीक से लागू ना भइल बा।ई पहिला स्क्रीन के धीमा कर दी।

4.2 ई-कॉमर्स/उत्पाद वेबसाइट (जवना में कई गो थंबनेल आ छवि के विभिन्न रूप होला; स्थिरता सर्वोपरि बा)

ई-कॉमर्स में सबसे आम समस्या ई ना होला कि “कंप्रेशन क्वालिटी खराब बा”, बल्कि ई होला कि “ऑप्टिमाइजेशन के बाद कुछ आयाम गलत हो जालन, थंबनेल गायब बाड़ें, या फ्रंट-एंड कंपोनेंट्स इमेज ना खींच पावत बाड़ें”।

प्राथमिकता सिफारिशें:

1. सावधानी से शुरुआत करीं: एगो अधिक रूढ़िवादी संपीड़न रणनीति अपनाईं; पूरा डेटाबेस के तुरतिए बदल मत करीं।
2. थंबनेल के साइज़ के आकलन: ई-कॉमर्स थीम आमतौर पर अधिक साइज़ बनावेलन, जेकर चलते डेटा के इस्तेमाल काफी बढ़ जाला (ई खास करके ShortPixel आ TinyPNG में साफ देखाई देला)।
3. पहिले छोट पैमाना पर परीक्षण करीं, फेर बड़का दर्शक तक फैलाईं (ई एकदम जरूरी बा)

एक अधिक उपयुक्त मार्ग:

• Option B आमतौर पर झंझट-मुक्त विकल्प होला: ShortPixel, Imagify आ TinyPNG सभ बैच प्रोसेसिंग के समर्थन करेला; मुख्य बात ई बा कि कोटा सिस्टम के समझल जाव आ लागत के पहिले से आकलन कइल जाव।
• विकल्प A भी स्वीकार्य बा, लेकिन रउआ के Plus WebP के “ID ओवरराइट करे, मूल इमेज मिटावे आ URLs बदले” के व्यवहार में अउरी सावधानी बरते के चाहीं: चूंकि ई एगो संपत्ति स्थानांतरण ह, एह से तुरत पूरा प्रतिस्थापन करे के सलाह नइखे दीहल जा रहल।

4.3 पोर्टफोलियो/फोटोग्राफी वेबसाइट (जहाँ छवि के गुणवत्ता अति महत्वपूर्ण बा, फाइल बड़हन बा, आ दृश्यात्मक आकर्षण सर्वोपरि बा)

प्राथमिकता सिफारिशें:

1. आयाम निर्धारण रणनीति (प्रदर्शन क्षेत्र नियंत्रण)
2. संपीड़न रणनीति (विवरण खोवे से बेहतर बा कि फाइल थोड़ा बड़का होखे)
3. WebP/AVIF (बड़हन छवियन खातिर फायदा साफ बा, बाकिर दृश्य गुणवत्ता के जांच करे के जरूरत बा)

एक अधिक उपयुक्त मार्ग:

• इमैजिफाई: चूंकि कोटा “मूल इमेज साइज” के आधार पर कटल जाला, एह तरह के साइट से खर्चा पर काबू रखल आसान हो जाला (रउआ मोटा-मोटी जानत बानी कि हर बड़का इमेज पर कतना खर्चा आई), बाकिर रउआ के बार-बार फेर से कंप्रेस करे से बचे के चाहीं।
• शॉर्टपिक्सलअगर थंबनेल के बहुत ज़्यादा साइज़ ना होखे, त क्रेडिट्स के इस्तेमाल काफी सीधा-सादा होला; बाकिर अगर रउआ ढेर सारा साइज़ आ अगिला पीढ़ी के वर्शन बनाइब, त क्रेडिट्स के खपत काफी बढ़ जाई, एह से रउआ के पहिले से योजना बनावे के पड़ी।

5. कोटा बनाम बिलिंग: ई मुफ्त कोटा पर्याप्त बा कि ना, एकर पूरा जांच।

कवन एक पैसा के हिसाब से बढ़िया फायदा देला, आ मुफ्त वर्जन कतना दिन ले चली?

5.1 तीन बिलिंग मॉडल

• शॉर्टपिक्सल(श्रेय)क्रेडिट्स असली इमेज आ थंबनेल के गिनती पर आधारित बा; हर संबद्ध वर्शन खातिर WebP/AVIF फाइल बनावे पर अतिरिक्त क्रेडिट चार्ज लागेला।
• इमैजिफाई(MB कोटा)क्वोटა “मूल फ़ाइल साइज़” के आधार पर घटावल जाला; जेतना ज़्यादा थंबनेल होई, ओतना ज़्यादा क्वोटა इस्तेमाल होई; दोबारा कंप्रेशन से अउरी क्वोटა घटी।
• छोट पीएनजी(श्रेय): हर महीना 500 क्रेडिट; WebP/AVIF कन्वर्जन सक्षम करे पर प्रति इमेज साइज अतिरिक्त शुल्क लागी।

5.2 त्वरित अनुमान विधि

रउआ एकरा के निम्नलिखित तरीका से अनुमान लगा सकत बानी:

1. कवनो एक आम अपलोड कइल मूल फोटो चुनि के देखीं, ओकरा साइज़ लगभग कतना बा (जइसे 300KB / 1MB / 3MB)
2. ई एह बात पर निर्भर करेला कि रउरा साइट आमतौर पर कतना थंबनेल साइज बनावेला (जइसे 5, 10 या 20)
3. निर्णय करीं कि रउआ WebP/AVIF जनरेट करे चाहत बानी कि ना (हाँ/ना)

फिर खपत समझे खातिर नीचे दिहल “मानसिक गणित” के इस्तेमाल करीं:

• शॉर्टपिक्सलप्रत्येक इमेज खातिर लगभग (1 + थंबनेल के संख्या) क्रेडिट; अगर WebP/AVIF जनरेट होखे त लगभग ओकर दोगुना (काहे कि अगिला पीढ़ी के वर्शन खातिर भी क्रेडिट चाहीं)
• इमैजिफाईप्रत्येक छवि खातिर कोटा लगभग (मूल छवि के आकार + सभ थंबनेल के कुल आकार) होला; कंप्रेशन स्तर बदले आ छवि के फेर से कंप्रेशन करे पर कोटा में अउरी कटौती होई।
• छोट पीएनजी500 मुफ्त क्रेडिट; अगर रउरा साइट पर हर इमेज खातिर बहुते साइज बनत बा आ इमेज कन्वर्जन चालू बा, त मुफ्त इमेज के संख्या काफी घट जाई (प्लगइन पेज पर मोटा-मोटी अंदाजा दिहल गइल बा कि “लगभग 100 प्रति महीना” आ “लगभग 50 प्रति महीना”)

6. जोखिम प्रकटीकरण

जोखिम 1: एके काम खातिर कई गो प्लगइन इस्तेमाल करे से बचीं

ई सबसे आम “आपदा के स्रोत” बा।”

• मार्ग A:साथहीं WebP भा AVIF + EWWW(काम दुनो में बाँट दीं; एके बेर में कन्वर्जन आ डिलीवरी दुनो मत करीं, ना त बस एके इंस्टॉल करीं)
• विकल्प B: ShortPixel / Imagify / TinyPNG तीन में से एक चुन लीं(कंप्रेशन आ अगिला पीढ़ी के संभाले खातिर एक चुन लीं)

जोखिम 2: साथे-साथ WebP के “ओवरराइट आईडी / मूल छवि मिटाईं / URL बदलीं” फीचर संपत्ति के माइग्रेशन के रूप में गिनल जाला।

फेर से दोहरावे खातिर:अउरी WebP विवरण में साफ-साफ कहल गइल बा कि पूरा जेनरेशन के दौरान, मूल इमेज आईडी ओवरराइट हो जाई, मूल फाइल डिलीट हो जाई, आ सामग्री के URL बदल दिहल जाई।
एकर मतलब ई बा कि ई कौनो “छोट बदलाव ना ह जेकरा के कबो भी पलट दिहल जा सके”, बल्कि ई संपत्ति के स्तर पर एगो बदलाव ह।

सुझावल रणनीति एह तरह होखे के चाहीं:

• छोट पैमाना के टेस्ट से शुरू करीं (कुछ दर्जन से कुछ सौ तक)
• पक्का करीं कि फ्रंट-एंड डिस्प्ले, थंबनेल आ कैश अपडेट सब ठीक से काम कर रहल बा।
• पूरा डेटाबेस के प्रोसेस करे पर विचार करीं

जोखिम 3: क्लाउड कम्प्रेशन खातिर “मुफ्त अलाउंस” के असली खपत थंबनेल के संख्या आ अगली पीढ़ी के विकल्पन के चुनाव पर निर्भर करेला।

• शॉर्टपिक्सलथंबनेल आ अगली पीढ़ी के फीचर क्रेडिट्स पर महत्वपूर्ण प्रभाव डालीं।
• छोट पीएनजीWebP/AVIF सक्षम करे से हर इमेज साइज पर अतिरिक्त क्रेडिट कटौती होई।
• इमैजिफाईमूल छवि के साइज पर चार्ज आधारित बा; जेतना अधिक थंबनेल होई, चार्ज ओतने अधिक होई; बार-बार डाउनलोड पर अतिरिक्त चार्ज लागेला।

जोखिम 4: “WebP/AVIF बन गइल बा” के मतलब ई नइखे कि “फ्रंट एंड WebP/AVIF परोसत बा”

बहुते लोग महसूस करेलन कि कन्वर्जन के बाद उनकर साइट अबहीं तक तेज ना भइल बा; असली कारण ई बा कि फ्रंट-एंड अबहियों JPG/PNG फाइल परोसेला (कैशिंग, रीराइटिंग, टैग्स, या ब्राउज़र नेगोशिएशन में से कवनो के मेल ना खाए के चलते).

7. काम पूरा होखे के बाद हम कइसे देखब कि ई असर कइल बा?

4 बहुत ही सरल जांच बिंदु:

1. जब एके पेज के दुसरका बेर रिफ्रेश कइल जाला, त लोडिंग प्रक्रिया का अधिक स्थिर आ तेज हो जाला?(कैशिंग आ ऑप्टिमाइजेशन के असर कतना ध्यान खींचे लायक बा?)
2. का मोबाइल डिवाइस आ डेस्कटॉप कंप्यूटर पर लोड भइल छवियन के साइज में साफ-साफ अंतर बा?(प्रतिक्रियाशील स्रोतसेट/आकार (का ई काम करेला)
3. कुछ इमेज बेतरतीब से जांचीं: का कवनो WebP या AVIF फाइल/संसाधन बा?(का साइट सचमुच इस्तेमाल कर रहल बा अगिला पीढ़ी）
4. कुछ तस्वीरन पर एक नजर डालऽ: ज़ूम करके देखऽ कि का ऊ साफ-साफ धुंधल बा या लिखल धुंधल लागत बा(का दबाव बहुत ज़्यादा बा?)

अगर ई चारों बात लागू होखे, त एकर मतलब बा कि रूट जवन तू चुनले बाड़ऽ, ऊ पहिले से ही चालू बा। अब अगिला पर बढ़ीं। डिलीवरी स्तर“...ई कुल मिलाके अउरी स्थिर होई।

8. कार्रवाई खातिर सिफारिशें

1. पहिले, एगो रस्ता चुन लीं:

• हम चाहत बानी कि ई जेतना हो सके मुफ्त रहे।: साथे WebP भा AVIF + EWWW (भा इनमे से बस एके इंस्टॉल करीं)
• सर्वर संसाधन पर बचत करे के चाहत बानी? उपयोग के हिसाब से भुगतान करे में जादे झंझट-मुक्त बा।ShortPixel, Imagify या TinyPNG में से एक चुन लीं।

2. छोट पैमाना पर परीक्षण से शुरू करीं (कुछ दर्जन)
3. बैच में प्रोसेस करे से पहिले देख लीं कि सब कुछ ठीक से बा।
4. डिलीवरी के विश्वसनीयता में अउरी सुधार के जरूरत बा:पढ़ाई CDN तेज करी

अक्सर पूछल जाए वाला सवाल

1. हमके कतना प्लगइन इंस्टॉल करे के चाहीं? का हम सभके इंस्टॉल कर सकेनी?

एकही रास्ता पर चले के कोशिश करीं।

• विकल्प A: Plus WebP या AVIF + EWWW Image Optimizer (या इनमे से सिर्फ एक इंस्टॉल करीं)
• विकल्प B: ShortPixel, Imagify या TinyPNG में से एक चुन लीं।
  एके साइट पर कई गो प्लगइन एके साथ चलाके “कंप्रेसन, WebP भा AVIF में कन्वर्जन, URL में बदलाव आ डिलीवरी रीराइटिंग” करे के तरीका सबसे पक्का गड़बड़ी पैदा करे वाला बा आ एकरा के ठीक करे में सबसे मुश्किल होला।

2. का वर्डप्रेस पहिले से WebP/AVIF के सपोर्ट ना करेला? का हमरा अबहियों प्लगइन के जरूरत बा?

ई बात के बीच अंतर करना जरूरी बा:
“अपलोड करे/उपयोग करे खातिर समर्थन” ≠ “स्वचालित रूपांतरण/स्वचालित वितरण”
WordPress 6.5 मौजूदा JPG/PNG फाइलन के थोक में अपने आप WebP/AVIF में कन्वर्ट ना करी, ना ही ब्राउज़र के क्षमता के हिसाब से AVIF/WebP सर्व करे आ फेर मूल फॉर्मेट पर वापस जाए के पूरा प्रक्रिया अपने आप संभाली। अपने मौजूदा मीडिया लाइब्रेरी के भी अपडेट होखे खातिर, आमतौर पर रउआ के खाली जगह पूरा करे खातिर एगो प्लगइन या सेवा के इस्तेमाल करे के पड़ी।

3. जब इमेज ऑप्टिमाइजेशन के बात आवेला, त कौन कदम असल में सबसे जियादा रिटर्न ऑन इन्वेस्टमेंट देला?

आम तौर पर पहिले माप सही से सेट करीं (srcset/sizes)。
कई वेबसाइट धीमा होखेलन, ई एह से ना कि उनका कंप्रेस ना कइल गइल बा, बल्कि ई कि ऊ लोग खाली 900px चौड़ा पेज देखावेलन जबकि यूजर लोग के असली 3000px वाला इमेज डाउनलोड करे पर मजबूर कर देलन। कंप्रेस से कुछ किलोबाइट बच सकेला, लेकिन “गलत डाइमेंशन” से बिना कवनो जरूरत के कई गुना ज्यादा डेटा डाउनलोड करे के पड़े ला।

4. हम कइसे पक्का कर सकीं कि हर बेर असली इमेज के बजाय “छोट वर्जन” लोड हो रहल बा?

दू गो घटना पर विचार करीं:

• जब मोबाइल डिवाइस पर देखल जाला, त डाउनलोड कइल तस्वीर डेस्कटॉप के तुलना में साफ-साफ छोट लागेली।
• ओही इमेज के फाइल साइज ओह डिवाइस पर निर्भर करेला जवना पर ई लोड होखेला।
  अगर इमेज हमेशा असली साइज में डाउनलोड होखेला, त अक्सर ई एह से होला कि थीम या पेज बिल्डर इमेज के CSS बैकग्राउंड इमेज या कस्टम आउटपुट मान लेला, जवना से मीडिया लाइब्रेरी के कई गो आयाम आ `srcset` एट्रिब्यूट के सपोर्ट बाईपास हो जाला।

5. का “WebP/AVIF generated” के मतलब जरूरी बा कि फ्रंट एंड WebP/AVIF आउटपुट कर रहल बा?

बराबर नइखे
जनरेशन खाली “फाइल लेवल” पर पूरा होला; WebP/AVIF असल में फ्रंट-एंड पर सर्व होई कि ना, ई रीराइटिंग, `tag` पॉलिसी, कैश हिट्स आ ब्राउज़र नेगोशिएशन के असरदार होखे जइसन कारक पर निर्भर करेला। जब रउआ काम पूरा कर लेब, त कुछ तस्वीरन के रिसोर्स टाइप जरूर स्पॉट-चेक करीं।

6. WebP या AVIF से जुड़ल असली खतरा का बा? का हम पूरा डेटाबेस पर एक-क्लिक चेक चला सकेनी?

जोखिम “कंप्रेशन” में ना बा, बल्किसंपत्ति प्रवासन स्तरन में बदलाव：

• जब पूरा सेट बनावल जाला, तब मूल इमेज फाइल के आईडी ओवरराइट हो सकेला, मूल फाइल डिलीट हो सकेला, आ सामग्री में मौजूद URLs बदलल जा सकेला।
  तऽहमनी पूरा डेटाबेस के तुरत बदले के सलाह ना देतानी।छोट पैमाना पर टेस्ट से शुरू करीं (कुछ दर्जन से कुछ सौ रिकॉर्ड) आ पूरा डेटाबेस पर आगे बढ़े से पहिले सुनिश्चित करीं कि रउरा लगे काम करे वाला बैकअप बा।

7. Plus WebP में दू गो मोड में से रउआ कइसे चुनब: मूल इमेज रखल जाव या बदल के मूल इमेज मिटा दिहल जाव?

सरल शब्दन में:

• विकल्प 1: मूल छवि के रखल जाव + WebP/AVIF कॉपी बनावल जाव (अधिक भरोसेमंद): पलट के पहिले जइसन करे में आसान बा, बाकिर ई ज्यादा डिस्क जगह लेवेला (मूल इमेज + नया फॉर्मेट + कई थंबनेल साइज).
• विधि 2: मूल छवि के बदलल आ हटावल (अधिक कट्टर)डिस्क फइलल के प्रवृत्ति नइखे, बाकिर अगर रउआ एसेट्स आ रेफरेंस में बदलाव करब त अनुकूलता संबंधी समस्या के समाधान करे में जादे खर्चा हो जाई।
  साइट जेतना जटिल होई (ई-कॉमर्स, कई गो प्लगइन, कई गो साइज), ओतना हमनी के सलाह बा कि एगो अधिक स्थिर तरीका से शुरुआत करीं।

8. का EWWW Image Optimizer द्वारा दिहल जा रहल मुफ्त लोकल कम्प्रेशन पर्याप्त बा? का ई सर्वर पर ओवरलोड करी?

EWWW जादे “लोकल काम करे वाला कंप्रेस मजदूर” जइसन बा: ई CPU/IO खा जाला।
बैच ऑप्टिमाइजेशन के दौरान लोड बढ़ना आम बात बा; एकर मतलब ई नइखे कि सिस्टम “फेल” हो रहल बा, बल्कि ई बतावेला कि तरीका सही होखे के चाहीं: काम के बैच में ऑफ-पीक घंटन में करीं, आ जहाँ जरूरी होखे, ऑफलोडिंग या क्लाउड समाधान चुनीं।
अगर रउआ बिना झंझट के समाधान खोजत बानी, या रउआ के सर्वर संसाधन सीमित बा, त विकल्प B सर्वर खातिर ज्यादा कुशल बा।

9. ShortPixel हर महीना 100 मुफ्त क्रेडिट देला, त फेर हमके काहे लागत बा कि ई बस कुछे तस्वीरन में ही खतम हो गइल?

काहे कि “Credits” से 'तस्वीरन के संख्या' के मतलब ना होला।”थंबनेल आ अगिला पीढ़ी से बढ़ावल जाई:

• मूल छवि + हर थंबनेल खातिर श्रेय
• अगर WebP/AVIF फाइल बनल जालें, त हर संबंधित वर्जन पर क्रेडिट में अतिरिक्त खर्चा लागी।
  जेकरा के रउआ “एक इमेज” समझत बानी, ऊ असल में लगभग “दहाई अंक के क्रेडिट” खर्च कर सकेला। ShortPixel

10. Imagify के मुफ्त 20MB/महीना, काहे जल्दी खतम हो जाला?

Imagify अधिकतर “डेटा बंडल” जइसन बा:

• रउरा संदेश के अनुसारमूल फ़ाइल आकारकोटा से घटाईं
• जितना अधिक थंबनेल होइहें, उतना अधिक संसाधन खपत होई।
• कंप्रेशन लेवल बदले आ फेर से ऑप्टिमाइज करे से कोटा फेर से खपत हो जाई।
• एकही API की कई गो साइट पर इस्तेमाल कइल जा सकेला, जवना में कोटा साझा होला।
  एह से “20MB जल्दी खतम हो जाला” अक्सर एह से होला कि तस्वीर बहुत बड़ी होखे, थंबनेल बहुत जादे होखे, या बार-बार कोशिश करके गलती कइल गइल होखे।

11. TinyPNG हर महीना 500 मुफ्त क्रेडिट देला, त फेर ई प्लगइन काहे कहता कि हर महीना बस करीब 100 इमेज मिलेला, आ WebP/AVIF चालू करे के बाद ई काहे घट के हर महीना 50 इमेज हो जाला?

ई एह से बा कि TinyPNG क्रेडिट्स भी “Dimensions/Variants” के तहत बढ़ा दिहल गइल बा:

• एक मानक वर्डप्रेस इंस्टॉलेशन आमतौर पर हर महीना लगभग 100 तस्वीरें संपीड़ित करेला।
• AVIF या WebP रूपांतरण सक्षम करीं:प्रत्येक छवि के आकार खातिर एक अतिरिक्त क्रेडिट लागत बा।, एह से हम शायद महीना में करीब 50 गो तस्वीर ही कम्प्रेस आ कन्वर्ट कर सकेनी (थंबनेल साइजन के गिनती पर निर्भर करत)।
  त 500 क्रेडिट्स ≠ 500 तस्वीरें

12. हमनी के साइट पर कतना थंबनेल बा? ई लोगन पर अतना गहिर असर काहे होला?

WordPress में इमेज अपलोड करे पर कई गो साइज बन जाला; थीम आ प्लगइन (खास करके ई-कॉमर्स वाला) अउरी साइज बना सकेला।
क्लाउड कम्प्रेशन में, क्रेडिट या कोटा आमतौर पर “मूल छवियाँ और थंबनेल्स मिलाकर” के आधार पर हिसाब लगावल जाला, एह से जेतना अधिक थंबनेल्स होइहें, तोहार मुफ्त कोटा ओतने जल्दी खत्म हो जाई।

13. का लेज़ी लोडिंग हमेशा चीज़न के तेज कर देला? कुछ लोग काहे कहेलन कि लेज़ी लोडिंग असल में चीज़न के धीमा कर देला?

लेज़ी लोडिंग “ऑफ-स्क्रीन संसाधन” खातिर उपयुक्त बा।
अगर पहिला स्क्रीन पर सबसे महत्वपूर्ण बड़का इमेज भी देरी से लोड होखे, त ई शुरुआती लोडिंग अनुभव के धीमा कर सकेला। जबकि WordPress 5.5 आ ओकरा बाद के डिफ़ॉल्ट लेज़ी लोडिंग ठीक बा, रउआ एकरा के हर जगह लागू ना करे के चाहीं।

14. हम रूट A या B से जाईं, त CDN / फोटो CDN कब चाहीं?

कंप्रेशन, फाइल साइज आ फॉर्मेट फाइलन के छोट आ अधिक उपयुक्त बनावे के समस्या के समाधान करेलन।
CDN से डिलीवरी अउरी नजदीक आ भरोसेमंद हो जाला。
जब तस्वीर के स्रोत साइट से दूर से खींचल जाए के कारण देरी साफ नजर आवे, त ओकरा पर CDN/तस्वीर CDN (जइसे Cloudflare Polish / Jetpack Site Accelerator) अउरी जोड़ देला त कुल मिलाके जादे स्थिर रही, पढ़े खातिर WordPress CDN तेज करी。

15. जब हम काम पूरा कर लेब, त ई सचमुच काम कर रहल बा कि ना, ई जांचे के सबसे आसान तरीका का बा?

सत्यापित करे के सबसे तेज तरीका:

• जब एके पेज के दुसरका बेर रिफ्रेश कइल जाला, त लोडिंग प्रक्रिया का अधिक स्थिर आ तेज हो जाला?
• का मोबाइल आ डेस्कटॉप वर्शन में इमेज के साइज में साफ-साफ अंतर देखाई देला (का srcset/sizes जइसन चाहल गइल बा, ओइसहीं काम कर रहल बा)?
• कुछ इमेज बेतरतीब से जांचीं: का कवनो WebP या AVIF फाइल/संसाधन बा?
• कुछ तस्वीरन पर एक नजर डालऽ: ज़ूम करके देखऽ कि का ऊ साफ-साफ धुंधल बा या लिखल धुंधल लागत बा