वेबसाइट छवि अनुकूलन

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

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

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

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

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

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

• हमनी के लगे जे “मुफ्त सुविधा” उपलब्ध बा, ओकर इस्तेमाल करे के बदले हमनी समय आ पैसा बरबाद क के पहिया के फेर से आविष्कार कइनी।
• हम सोचनी कि WordPress अपने आप सभ पुरान इमेज के 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/image 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 के हिसाब से सर्वर पर भारी लोड डाल सकेला, जवना से रउआ के “रणनीति आ जोखिम” पर अउरी बारीकी से ध्यान देवे के पड़ी।”

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. Free 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), बाकिर हमनी सलाह देतानी कि पहिले जोखिम के आकलन खातिर “कंजर्वेटिव मोड (मूल छवियन के डिलीट मत करीं)” से शुरू करीं।

सामान्य फँस:

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

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. कुछ तस्वीरन पर एक नजर डालऽ: ज़ूम करके देखऽ कि ऊ साफ धुंधल बा कि ना, आउर टेक्स्ट धुंधल लागत बा कि ना।(का दबाव बहुत ज़्यादा बा?)

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

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 असल में फ्रंट-एंड पर सर्व होई कि ना, ई रीराइटिंग, `picture` टैग रणनीति, कैश हिट आ ब्राउज़र नेगोशिएशन के असरदार होखे जइसन कारक पर निर्भर करेला। जब रउआ काम पूरा कर लेब, त कुछ तस्वीरन के रिसोर्स टाइप जरूर स्पॉट-चेक करीं।

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 के मुफ्त 201 TP234T/महीना अलाउंस अतना जल्दी काहे खत्म हो जाला?

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 जोड़ला (जइसे Cloudflare Polish / Jetpack Site Accelerator) से आमतौर पर अनुभव अउरी स्थिर हो जाला आ सामग्री पढ़े में आसान हो जाला। वर्डप्रेस CDN एक्सेलेरेशन。

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

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

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