ويب سائيٽ تصويري بهتري

تصويرن جي بهترڪاري WordPress جي ڪارڪردگي ۾ سڀ کان وڌيڪ “اعليٰ موٽ” ڏيندڙ شين مان هڪ آهي: ساڳئي صفحي جي جوڙجڪ، ساڳيو ٿيم، رڳو جيڪڏهن تصويرن جي سائيز، ماپ، فارميٽ ۽ پهچائڻ جو طريقو صحيح هجي، ته لوڊ ٿيڻ جو تجربو اڪثر فوري طور تي بهتر ٿي وڃي ٿو.

پر تصويرن جي بھتري به ماڻهن کي سڀ کان آسانيءَ سان “وڌيڪ ڇيڙڇاڙ ڪري وڌيڪ افراتفري” ۾ وجهي ٿي، ان جو سبب هي ناهي ته ٽيڪنالاجي تمام ڏکي آهي، پر اهو آهي ته معلومات تمام ٽڪرن ٽڪرن ۾ آهي:
توهان ڪجهہ مضمون پڙهيا، ۽ ڄاڻيو ته “ڪمپريس ڪرڻ”، “WebP/AVIF”، “ليزي لوڊنگ” ضروري آهي. پوءِ جڏهن پلگ ان جو تعارف ڏسو ٿا ته اتي وري لکيل هوندو آهي “هر مهيني 100 ڪريڊٽ مفت”، “مفت 20MB”، “هر تصوير 1 ڪريڊٽ”، نتيجي ۾ جيترو وڌيڪ ڏسو ٿا اوترو ئي وڌيڪ مونجهارو وڌي وڃي ٿو — آخر مفت وارو حصو ڪافي آهي يا نه؟ فيس ڪيئن ڪٽي ويندي؟ ڇا اوهان “ساڳئي شيءِ” کي غلط سمجهي رهيا آهيو؟ ۽ سڀ کان اهم:تون ختم ڪرڻ کان پوءِ آخرڪار ڇا اهو واقعي اثرائتو ٿيو هو؟

هيءَ مضمون رڳو ٽي ڪم ڪري ٿو:

1. توهان کي هڪ قابل عمل ڏيوروڊ ميپپهريان ڇا ڪجي، پوءِ ڇا ڪجي
2. پنهنجو چونڊيل منصوبو چٽو بيان ڪريو (مفت/ادا ڪيل ۾ اصل فرق ڇا آهي، ۽ هر هڪ ڪنهن لاءِ مناسب آهي)
3. عام غلطيون اڳواٽ لکي ڇڏيون ٿا (ته جيئن ڪم مڪمل ٿيڻ کان پوءِ اوهان کي هر هنڌ ڳولي جاچ نه ڪرڻي پوي)

1. بنيادي سطح: WordPress پاڻ سان ڇا آڻي ٿو، ۽ ڇا نٿو آڻي

جيڪڏهن توهان پهرين اهو نه سمجهو ته WordPress جي ڪور اڳ ۾ ڇا ڪري چڪي آهي، ته آساني سان ٻه حالتون پيدا ٿي سگهن ٿيون:

• جيڪا “مفت صلاحيت” حاصل ٿيڻ گهرجي هئي، سا استعمال نه ٿي، الٽو وقت ۽ پئسو خرچ ڪري ساڳيو ڪم ٻيهر ڪيو ويو
• سمجهيو ته WordPress “پراڻيون سڀ تصويرون پاڻمرادو WebP/AVIF ۾ بدلائي ڇڏيندو”، پر پوءِ خبر پئي ته ائين ناهي ٿيندو

ورڊپريس ڪور ۾ اهي اهم صلاحيتون اڳ ئي شامل آهن:

• جوابداري تصويرون (srcset/sizes): WordPress 4.4 کان، ڪور تصويرن لاءِ آئوٽ پُٽ ڪندو srcset 与 sizes۽ اپلوڊ وقت ٺهيل مختلف سائيزن جون تصويرون استعمال ڪري، برائوزر کي اسڪرين جي حالتن موجب وڌيڪ مناسب وسيلا لوڊ ڪرڻ لاءِ چونڊ ڪرڻ ڏئي ٿو۔
• اصل سست لوڊنگ: WordPress 5.5 کان تصويرن لاءِ ڊفالٽ طور اصلي ليزي لوڊنگ فعال ڪري ٿو، HTML معيار استعمال ڪندي loading خاصيت جي عملداري۔
• ويب پي اپلوڊ جي حمايت ڪريو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 ڪمپريس ڪريو (KB گهٽ ڪريو، پر معيار کي “خراب” نه ڪريو)

ڪمپريشن جو بنيادي مقصد “جيترو ننڍو اوترو بهتر” ناهي، پر اهو آهي ته “ننگي اک سان لڳ ڀڳ ڪو فرق نظر نه اچي، پر سائيز نمايان گهٽجي وڃي”.

ضابطا هيٺيان آهن:

• تصوير/اصل تصوير (ماڻهو، مصنوعات، منظر): ترجيحي نقصان واري دٻاءُ (وڌ ۾ وڌ فائدو)
• انٽرفيس اسڪرين شاٽ/گهڻي لکت واريون تصويرون: ڪمپريشن وڌيڪ محتاط هجڻ گهرجي، متن کي ڌنڌلو ٿيڻ کان بچايو
• لوگو/آئڪن: SVG کي ترجيح ڏيو يا احتياط سان بي نقصان رکو (نقصاندہ ۾ ڪنارا آساني سان ڌنڌلا ٿي وڃن ٿا)

ڪهڙي حد تائين پهچڻ تي قابلِ قبول سمجهيو وڃي ٿو:

• اڪثر صفحن تي تصويرن جو سائيز واضح طور گهٽجي ويو آهي
• واضح شور، ڪنارن جي ڌندلاڻ، رنگن جا ٽٽا يا متن جي ڌندلاڻ نه هجي

---

2.3 WebP / AVIF (فارميٽ حڪمتِ عملي: ساڳي وضاحت سان ننڍو)

ورڊپريس هاڻي اپلوڊ جي حمايت ڪري ٿو WebP (5.8) ۽ AVIF (6.5)。
پر “ايندڙ نسل جي فارميٽ” کي حقيقت ۾ استعمال ڪرڻ لاءِ، عام طور تي ٻن ڳالهين کي حل ڪرڻو پوندو:

1. تاريخي ميڊيا لائبريري کي بيچ ۾ ڪيئن تبديل ڪجي(نه ته توهان رڳو “بعد ۾ اپلوڊ ڪيل نيون تصويرون” کي بهتر ڪيو آهي)
2. ڇا نقل ٺاھيو يا اصل تصوير مٽايو(هي خطري جو حدِ فاصل آهي؛ اڳتي هلي Plus WebP جي “مٽائي اصل تصوير حذف ڪريو” تي خاص ڌيان سان ڳالهائينداسين)

سفارش ڪيل لکڻ جو طريقو:

• WebP: عام طور تي ڊفالٽ پهرين پسند طور استعمال ٿيندو آهي (مطابقت وڌيڪ مستحڪم آهي)
• AVIF: وڌيڪ ڪمپريشن جي طرف، وڏين تصويرن/پهريون اسڪرين وڏين تصويرن/البم تصويرن لاءِ مناسب (پر وڌيڪانحصاري ماحول جي سپورٽ）

---

2.4 ليزي لوڊنگ کي صحيح نموني استعمال ڪريو (سڀني تي هڪجهڙو لاڳو نه ڪريو)

ورڊپريس 5.5 کان پوءِڊفالٽ ليزي لوڊنگتصوير۔
اها شروعاتي رينڊرنگ وقت بينڊوڊٿ جي استعمال کي گهٽائي سگهي ٿي:

• ليزي لوڊنگ “اسڪرين کان ٻاهر وارن وسيلن” لاءِ مناسب آهي”
• پهريئين اسڪرين جي سڀ کان اهم وڏي تصوير اڪثر دير سان لوڊ ڪرڻ لاءِ مناسب نه هوندي آهي

---

2.5 پهچائڻ جي سطح: CDN / تصوير CDN

ڪمپريشن، سائيز ۽ فارميٽ جو مقصد آهي “فائل کي ننڍي ۽ وڌيڪ مناسب بڻائڻ”.
پر جيڪڏهن تصويرون هميشه اصل سائيٽ تان پري کان حاصل ڪيون وڃن، ته نيٽ ورڪ جي دير اڃا به تجربو تي واضح اثر وجهندي. اهڙي وقت “ترسيل پرت” جو حل گهربل هوندو آهي（CDN/تصوير CDN）

ٻه عام رخ:

• ڪلاوڊ فليئر پولش：Cloudflare دستاويزاتPolish جي ڪمپريشن جا طريقا متعارف ڪرايا ويا آهن (بغير نقصان/نقصان سان/WebP)، ۽ پڻ ذڪر ڪيو ويو آهي ته استعمال ڪيو وڃي format=auto WebP/AVIF فارميٽ جي اجازت آهي۔
• Jetpack سائيٽ ايڪسليٽر：Jetpack دستاويزاتوضاحت ڪري ٿو ته اهو تصويرن کي بهتر بڻائيندو ۽ انهن کي جامد وسيلن سان گڏ پنهنجي نيٽ ورڪ ذريعي ورهائيندو.

تصويرن جي بهترڪاري سائيز ننڍو ۽ مناسب ڪري ٿيCDN ذميوار ترسيل وڌيڪ ويجهو ۽ وڌيڪ مستحڪم بڻائي ٿو

3. چونڊ: رڳو ٻه مکيه رستا اختيار ڪريو

تصويرن جي بهتري ۾ سڀ کان عام ناڪامي “پلگ ان نه لڳايو” ناهي، پر تمام گهڻا پلگ ان لڳائڻ سبب ورجائتي پروسيسنگ ٿيڻ آهي:
A پيو ڪمپريس ڪري، B به پيو ڪمپريس ڪري؛ A پيو WebP/AVIF ۾ بدلائي، B به پيو بدلائي؛ A پيو URL بدلائي، B وري ريرائيٽ ڪري—آخر ۾ توهان پاڻ به نٿا چئي سگهو ته سائيٽ ۾ هاڻي آخر ڇا پيو ٿئي۔

ضابطو:

صرف هڪ ئي رستو اختيار ڪريو: يا ته مڪمل طور مفت مقامي، يا ڪلائوڊ ڪمپريشن جي ٽن مان هڪ.

• رستو A (مڪمل طور مفت مقامي):Plus WebP يا AVIF + EWWW تصوير Optimizer(يا صرف هڪ چونڊيو)
• رستو B (ڪلائوڊ ڪمپريشن مان ٽن مان هڪ چونڊيو):شارٽ پڪسل / اميجيفاءِ / ٽائني پي اين جي

---

3.1 رستو A: مڪمل مفت مقامي (Plus WebP يا AVIF يا EWWW)

هن رستي جي خاصيت هيءَ آهي:

• توهان “ماهوار حد/في تصوير فيس” واري ٽئين ڌر جي ڪمپريشن سروس تي ڀاڙيندا ناهيو (البته ڪجهه خاصيتون اختياري سروس به ڏئي سگهن ٿيون)
• قيمت هي: بيچ پروسيسنگ شايد سرور CPU/IO تي وڌيڪ بار وجهي، توهان کي “حڪمتِ عملي ۽ خطري” تي وڌيڪ ڌيان ڏيڻ جي ضرورت آهي”

3.1.1 Plus WebP يا AVIFبنيادي ڳالهه “ٺاهڻ/مٽائڻ” آهي، اهو روايتي معنيٰ ۾ “ڪمپريس اوزار” ناهي”

• جڏهن سڀئي تصويرون تيار ڪيون وڃن:اصل تصوير فائل ID کي WebP/AVIF سان مٽايو ويندو، اصل فائل حذف ڪئي ويندي، ۽ مواد ۾ موجود URL پڻ مٽايا ويندا。
• پلگ ان WP-CLI ڪمانڊ فراهم ڪري ٿو، ۽ ياد ڏياري ٿو: جڏهن فائلون گهڻيون هجن ته WP-CLI وڌيڪ قابلِ اعتماد آهي۔

هن جو مطلب آهي: اهو “خاموشي سان توهان لاءِ هڪ WebP تيار ڪري ٿو” نه آهي، پر شايد هڪ ڀيرو آهياثاثن جي منتقلي(خاص طور تي جڏهن توهان “بدليو ۽ اصل تصوير حذف ڪريو” سان لاڳاپيل اختيار کي فعال ڪريو ٿا)۔

ٻن طريقن ۾ فرق

موڊ 1: اصل تصوير برقرار + WebP/AVIF نقلون ٺاھيو (وڌيڪ مستحڪم)

• فائدو: مطابقت جي مسئلن کي منهن ڏيڻ وقت واپس موٽڻ وڌيڪ آسان آهي
• قيمت: ڊسڪ جو استعمال وڌي ويندو (اصل تصوير + نئون فارميٽ + گهڻن سائيزن جا ٿمب نيل)

موڊ 2: بدلائي ۽ اصل تصوير حذف ڪريو (وڌيڪ جارحاڻو)

• فائدا: ڊسڪ ايتري تيزي سان ڦولجي نه سگهندي؛ سائيٽ اندر حوالا سڌو نئين فارميٽ ۾ تبديل ٿي ويندا
• خطرو: توهان “اثاثا تبديل + حوالا تبديل” ڪري رهيا آهيو، ته مطابقت جي مسئلن جي جاچ جي قيمت وڌيڪ ٿيندي (خاص طور جڏهن ڪجهه ٻاهريان سسٽم يا ٿيم منطق اصل فائل نالي/رستي/فارميٽ تي ڀاڙين ٿا)

Plus WebP يا AVIF جون عام خاميون

1. پوري لائبريري مٽائڻ کان پوءِ، ڪجهه صفحن جون تصويرون غيرمعمولي نموني ڏيکارجن ٿيون
   سبب عام طور تي “تصوير خراب آهي” نه هوندو آهي، پر URL جي مٽاسٽا، ڪيش، ٿمب نيل حڪمتِ عملي وغيره واري زنجير ۾ ڪو نه ڪو مرحلو صحيح نه مليو هوندو آهي۔
2. ٿمبنيلن جو تعداد جيترو وڌيڪ، تبديلي جو دائرو اوترو وڏو ٿيندو
   WordPress ۾ هڪ تصوير اپلوڊ ڪرڻ سان ڪيترن ئي سائيزن جون فائلون ٺهن ٿيون؛ ۽ ٿيم/پلگ ان وڌيڪ سائيزون به وڌائي سگهن ٿا. مڪمل متبادل جو مطلب آهي ته توهان شايد فائلن جي هڪ تمام وڏي مجموعي ۾ تبديلي ڪري رهيا آهيو۔
3. رڳو فارميٽ جي منتقلي ڪرڻ سان ضروري ناهي ته حجم سڀ کان گهٽ هجي
   WebP/AVIF عام طور ننڍا هوندا آهن، پر “سائيز حڪمتِ عملي” ۽ “ڪمپريشن حڪمتِ عملي” اڃا به تمام اهم آهن۔ Plus WebP کي “هڪ-ڪلڪ سان تيز” نه سمجهو۔

---

3.1.2 EWWW تصوير بهتر ڪندڙ: مفت مقامي ڪمپريشن جو نمائندو

EWWW پلگ ان صفحي جي پوزيشننگ تمام واضح آهي:

• اهو توهان جي سرور تي اوزارن جي هڪ سلسلي سان بهتر بڻائي سگهجي ٿو (jpegtran، optipng، pngout، pngquant، gifsicle، cwebp وغيره)
• جيڪڏهن توهان کي وڌيڪ دٻاءُ سان ڪمپريس ڪرڻ يا CPU وڌيڪ بچائڻ جي ضرورت آهي، ته CPU خرچ ڪندڙ پروسيسنگ ان جي سرور تي به آف لوڊ ڪري سگهجي ٿي (اختياري).

EWWW کي روٽ A ۾ ڪهڙو ڪردار نڀائڻ گهرجي؟

جيڪڏهن توهان 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 ShortPixelهر مهيني 100 مفت ڪريڊٽ، پر ٿمب نيل ۽ WebP/AVIF سبب ڪريڊٽ وڌيڪ خرچ ٿيندا

مفت/ادا ڪيل ڇا آهي

ShortPixel پلگ ان جو تعارف واضح طور تي لکي ٿو:

• هر مهيني 100 مفت credits
• اضافي لامحدود ماهوار ڪريڊٽس پڻ آهن ڏنل قيمتن جي معلومات پلگ ان صفحي تي موجود آهي
• هميشه لاءِ نه ختم ٿيندڙ هڪ دفعي ڪريڊٽ پيڪ پڻ موجود آهن (شروعاتي قيمت سان)

اشارو:

• مفت: هر مهيني ڪجهه ڪريڊٽ ڏنا ويندا، هلڪين سائيٽن يا جاچ لاءِ
• هڪ ڀيري وارو پيڪيج: انهن سائيٽن لاءِ مناسب، جن جي “ميڊيا لائبريري تمام وڏي هجي ۽ جيڪي هڪ ئي ڀيري سڄو اسٽاڪ صاف ڪرڻ چاهين” (هڪ ڀيرو خريد ڪريو ۽ مڪمل استعمال تائين هلندو، عام طور تي ميعاد ختم نه ٿيندي)
• ماهوار/لامحدود: انهن سائيٽن لاءِ مناسب جيڪي تصويرون مسلسل اپڊيٽ ڪن ٿيون ۽ ڊگهي مدي تائين مستحڪم بهتري گهرن ٿيون

ShortPixel جي سرڪاري KB به “هڪ دفعي وارو پيڪيج بمقابله لامحدود مهينو” ڏنو آهيواضح وضاحت: لامحدود مهيني وارو منصوبو مهيني (يا سالياني) بنياد تي فيس وٺي ٿو، لامحدود ڪريڊٽس فراهم ڪري ٿو، ۽ CDN جو مقرر ڪوٽا به شامل آهي؛ هڪ ڀيرو خريد ڪيل ڪريڊٽس جي مدي ختم نٿي ٿئي، تنهنڪري توهان انهن کي ضرورت موجب وڌيڪ ڪنٽرول سان استعمال ڪري سگهو ٿا۔

سڀ کان اهم: ShortPixel جا credits ڪيئن ڳڻيا وڃن ٿا؟

ShortPixel سرڪاري دستاويز KB بلڪل سڌيءَ طرح چيو:

• ورڊپريس ۾ هڪ تصوير اپلوڊ ڪرڻ سان ڪيترائي ٿمب نيل ٺهن ٿا؛
• هر ٿمب نيل جي بهتري تي هڪ ڪريڊٽ ڳڻيو ويندو；
• جيڪڏهن توهان WebP يا AVIF ٺاهڻ چونڊيو ٿاهر اصل تصوير ۽ ٿمبنيل جي WebP/AVIF ورزن لاءِ هڪ اضافي ڪريڊٽ خرچ ٿيندو；
• توهان ڪجهه ٿمب نيلز کي بهتر نه ڪرڻ لاءِ خارج ڪري سگهو ٿا ته جيئن ڪريڊٽس جي خرچ کي گهٽائي سگهجي۔

ڪريڊٽ مثال：

فرض ڪريو توهان 1 تصوير اپلوڊ ڪريو ٿا، موضوع/پلگ ان 8 ٿمب نيل ٺاهي ٿو:

• صرف اصل تصوير + ٿمب نيل بهتر ڪريو: 1 (اصل تصوير) + 8 (ٿمب نيل) = 9 ڪريڊٽس
• جيڪڏهن WebP/AVIF به ٺاهڻا آهن: مٿين 9 مان هر هڪ لاءِ هڪ وڌيڪ next-gen نسخو → پوءِ +9 ڪريڊٽس
  انهيءَ جو مطلب اهو آهي ته، توهان سمجهو ٿا ته “1 تصوير”، پر حقيقت ۾ شايد لڳ ڀڳ “2 انگن وارا ڪريڊٽس” خرچ ٿين.

تنهنڪري:“مفت 100 ڪريڊٽس” جو مطلب “مفت 100 تصويرون” نه آهي۔

ShortPixel جا سڀ کان عام مسئلا

1. مفت 100 ڪريڊٽ جلدي ختم ٿي ويندا
   بنيادي سبب: وڌيڪ ٿمب نيل + WebP/AVIF ٺاهڻ لاءِ اضافي ڪريڊٽس
   صلاح：

• پهرين سائيٽ جي ٿمب نيلن جي تعداد جو جائزو وٺو
• غير ضروري ٿمبنيل سائيزن کي خارج ڪريو (رڳو اهي سائيز بهتر ڪريو جيڪي واقعي استعمال ٿينديون)
• پهريان ڪمپريشن حڪمت عملي طئي ڪري پوءِ بيچ ۾ هلايو، جيئن بار بار آزمائش ۾ وسيلن جو ضايع نه ٿئي

2. ساڳئي وقت ٻيا فارميٽ بدلائڻ وارا پلگ ان به شامل ڪريو
   جيڪڏهن توهان Plus WebP متبادل به آن ڪيو آهي، ۽ ShortPixel کي next-gen ٽيگ ٺاهڻ/داخل ڪرڻ به ڏنو آهي، ته منطق گڏجي ويندو ۽ جاچ ڏکيو ٿي ويندو. رستو B ۾ ShortPixel کي اڪيلو ذميوار رکو.
3. سمجهيو ويو ته انسٽال ڪرڻ شرط “فرنٽ اينڊ WebP/AVIF ڪڍي رهيو آهي”
   ShortPixel پلگ ان صفحواهو ذڪر ڪيو ويو آهي ته هي WebP/AVIF ۾ تبديل ڪري سگهي ٿو، ۽ next-gen تصويرون فرنٽ اينڊ صفحن ۾ شامل ڪري سگهي ٿو (مثال طور ٽيگ ذريعي)
   پر ڪم مڪمل ٿيڻ بعد به اثر جي تصديق ڪرڻي پوندي۔

---

3.2.2 Imagifyمفت 20MB/مهينو؛ ڪوٽا “اصل تصوير جي سائيز + ٿمب نيلن جي تعداد” موجب ڪٽي ويندي، ٻيهر ڪمپريس ڪرڻ تي ٻيهر ڪٽوتي ٿيندي

مفت ڪوٽا ۽ جڳھه مقرر ڪرڻ

Imagify سرڪاري قيمت وارو صفحوتمام صاف لکيل آهي:مفت کاتي جي هر مهيني 20MB ڪوٽا。
ان جي پلگ ان صفحي تي به صاف لکيل آهي ته اهو ڪمپريس ڪري سگهي ٿو، سائيز تبديل ڪري سگهي ٿو، ۽ WebP/AVIF ۾ تبديل ڪري سگهي ٿو۔

ڪوٽا ڪيئن ڪٽجي؟

Imagify سرڪاري دستاويز “ڪوٽا جو استعمال ڪيئن ڳڻيو وڃي ٿو؟” بلنگ جي طريقيڪار کي تمام واضح نموني سان بيان ڪري ٿو:

• ٿمبنيلن جو تعداد خرچ تي اثر انداز ٿيندومثال طور جيڪڏهن توهان وٽ 10 ٿمب نيل سائيزون آهن، ته 1 تصوير جي بهترڪاري 11 تصويرن جي بهترڪاري بڻجي ويندي (اصل تصوير + 10 ٿمب نيل)، ۽ اهي سڀ ڪوٽا جي استعمال ۾ شامل ٿيندا.
• اصل فائل جي سائيز مطابق ڪوٽا ڪٽيومثال طور، جيڪڏهن توهان 100KB جي هڪ تصوير Imagify ڏانهن موڪليندا، ته توهان جي ڪوٽا مان 100KB ڪٽجي ويندو۔
• ڪمپريشن سطح تبديل ڪري ٻيهر بهتر ڪرڻ سان ڪوٽا ٻيهر خرچ ٿيندي。
• ساڳيو API Key ڪيترين ئي سائيٽن لاءِ استعمال ڪري سگهجي ٿو، پر ڪوٽا انهن سائيٽن جي وچ ۾ گڏيل هوندي.

هي ئي Imagify جي “بنيادي سمجھڻ جو طريقو” آهي:
اهو وڌيڪ ٽرئفڪ پيڪيج وانگر آهي: توهان جيترو موڪليندا، اوترو ئي ڪٽبو؛ ٿمب نيل جيترا وڌيڪ هوندا اوترو وڌيڪ ڪٽبو؛ جيڪڏهن توهان بار بار ٻيهر ڪمپريس ڪندا ته بار بار ڪٽبو.

Imagify ڪوٽا جو آسانيءَ سان سمجهي سگهجڻ وارو مثال

فرض ڪريو توهان 800KB جي هڪ اصل تصوير اپلوڊ ڪريو ٿا، ۽ سائيٽ 8 ٿمب نيل ٺاهي ٿي.

• Imagify جڏهن بهترائي ڪندو ته “اصل تصوير + 8 ٿمب نيل” سڀني کي شامل ڪندو (جيڪڏهن توهان سڀني کي بهتر ڪرڻ چونڊيو)، جنهن جو مطلب اهو آهي ته هن هڪ عمل ۾ لڳ ڀڳ “انهن سڀني فائلن جي اصل سائيز جي ڪل جمع” جيترو ڪوٽا خرچ ٿيندو۔
  اهو ئي سبب آهي جو ڪجهه سائيٽن کي لڳي ٿو ته “20MB جلدي ختم ٿي وڃي ٿو”: اهو Imagify ڪافي نه هئڻ سبب ناهي، پر ان ڪري جو توهان هر ڀيري اپلوڊ ٿيندڙ تصويرون تمام وڏيون هونديون آهن، ٿمبنيل تمام گهڻا هوندا آهن، ۽ ممڪن آهي ته توهان بار بار ڪمپريشن ليول به آزمائيندا رهندا آهيو.

Imagify جا سڀ کان عام نقصاڻڙا

1. مفت 20MB سڄي سائيٽ جي تاريخي ڊيٽا صاف ڪرڻ لاءِ ڪافي ناهي“
   20MB عام طور تي جاچ ۽ هلڪي اپڊيٽ لاءِ وڌيڪ مناسب هوندو آهي؛ جيڪڏهن توهان جي ميڊيا لائبريري اڳ ئي تمام وڏي آهي، ته هڪ ئي ڀيري مڪمل صاف ڪرڻ لاءِ گهڻو امڪان آهي ته اپگريڊ ڪرڻو پوندو۔
2. بار بار ڪمپريشن ليول بدلائڻ سبب ڪوٽا ٻيهر خرچ ٿئي ٿي
   Imagify واضح وضاحت ڪريوٻيهر بهتري آڻڻ سان ڪوٽا ٻيهر خرچ ٿيندي.
   مان توهان کي صلاح ڏيان ٿو ته هن صفحي تي ئي “حڪمتِ عملي” کي صاف صاف لکي ڇڏيو:

• پهرين ٿوريون تصويرون استعمال ڪري ڪمپريشن جي سطح ۽ ڏيک طئي ڪريو
• حڪمتِ عملي طئي ڪرڻ بعد پوءِ بيچ ۾ هلائو
  سڄي ڊيٽابيس تي بار بار آزمائش کان پاسو ڪريو

3. گھڻن سائيٽن جي گڏيل API ڪي سبب ڪوٽا اوچتو گهٽجي وڃي ٿي“
   جيڪڏهن توهان ساڳي API Key کي ڪيترين ئي سائيٽن تي استعمال ڪندا، ته ڪوٽو گڏيل ٿيندو.
   تنهن ڪري ٽيم/گهڻ-سائيٽ واري صورتحال ۾، بهتر آهي ته واضح ڪيو وڃي: ڪهڙيون سائيٽون گڏيل طور استعمال ٿين ٿيون، ۽ ڪهڙيون سائيٽون الڳ استعمال ٿين ٿيون، ته جيئن بجيٽ بي قابو نه ٿئي۔

---

3.2.3 TinyPNGٽائني ڪمپريس اميجز: مفت 500 ڪريڊٽ/مهينو؛ WebP/AVIF ۾ تبديل ڪرڻ تي “هر سائيز لاءِ اضافي 1 ڪريڊٽ ڪٽبو”

مفت حد ۽ ان جي بلنگ جو طريقو

TinyPNG جو WordPress پلگ ان صفحو تمام واضح نموني سان لکيل آهي:

• هر مهيني 500 ڪريڊٽ مفت
• “عام WordPress انسٽاليشن” ۾، لڳ ڀڳ دٻائي سگهجي ٿو لڳ ڀڳ 100 تصويرون/مهينو
• پر جيڪڏهن AVIF يا WebP تبديلي فعال ڪئي وڃي:هر تصوير جي سائيز لاءِ هڪ اضافي ڪريڊٽ خرچ ٿيندوتنهنڪري شايد رڳو دٻائي ۽ تبديل ڪري سگهجي ٿو تقريباً 50 تصويرون/مهينو(اهو ان تي دارومدار رکي ٿو ته اوهان وٽ ٿمب نيلن جا ڪيترا سائيز آهن)。

ساڳئي وقت، Tinify (TinyPNG/TinyJPG جو ڊولپر) پڻ پنهنجي ۾ API قيمت صفحوواضح لکو: رجسٽريشن سان هر مهيني 500 مفت ڪمپريشنون ملنديون؛ ان کان پوءِ صرف ڪامياب ڪمپريشنن جي تعداد موجب فيس ورتي ويندي، ڪا به جبري سبسڪرپشن ناهي۔

هڪ جملي ۾ TinyPNG جي ڪم ڪرڻ جي طريقي کي مختصر بيان ڪريو:
اهو ڪريڊٽس موجب ڳڻيو ويندو آهي؛ جيترا وڌيڪ ٿمب نيل سائيز ۽ جيترا وڌيڪ WebP/AVIF آن ڪندا، اوترا ئي ڪريڊٽس جلدي خرچ ٿيندا۔

سمجهڻ ۾ آسان TinyPNG ڪريڊٽس جو مثال

فرض ڪريو توهان جي سائيٽ هر تصوير لاءِ 8 ٿمب نيل سائيزون ٺاهي ٿي:

• صرف دٻايو: اصل تصوير + 8 ٿمب نيلز → 9 ڪريڊٽ گهربل آهن
• جيڪڏهن WebP/AVIF تبديل ڪرڻ فعال هجي: هر سائيز لاءِ هڪ ڀيرو وڌيڪ ڪريڊٽ ڪٽبو → شايد لڳ ڀڳ ٻيڻو ٿي وڃي
  هي بلڪل پلگ ان صفحي جي وضاحت سان ملي ٿو: تبديلي آن ڪرڻ بعد مفت حد لڳ ڀڳ “100 تصويرون/مهينو” کان “50 تصويرون/مهينو” ٿي وڃي ٿي۔

TinyPNG جا سڀ کان عام مسئلا

1. سمجهو ته 500 ڪريڊٽس = 500 تصويرون
   نه. اهو “تصوير جي سائيز/قسم” موجب خرچ ٿئي ٿو. پلگ ان واري صفحي تي اڳ ئي صاف لکيل آهي ته “تبديل ڪرڻ تي هر تصويري سائيز لاءِ اضافي 1 ڪريڊٽ ڪٽبو”.
2. ٿيم/اي ڪامرس پلگ ان تمام گهڻيون سائيزون ٺاهي ٿو، مفت ڪوٽو نمايان گهٽجي ٿو
   جيترا وڌيڪ سائيزون هونديون، اوترو ئي credits وڏا ٿي وڌيڪ خرچ ٿيندا۔
3. تبديل فعال ڪرڻ بعد لڳو ته حد اوچتو گهٽ هلي رهي آهي
   هي بگ ناهي، اهو ان جو بلنگ ميڪانيزم آهي۔
   حڪمتِ عملي جي صلاح:

• جيڪڏهن مفت مرحلو بنيادي طور تي ڪمپريس ڪري سائيز گهٽائڻ لاءِ آهي، ته پهرين رڳو ڪمپريس ڪريو. جڏهن توهان پڪ ڪريو ته سائيٽ جي جوڙجڪ مستحڪم آهي ۽ واقعي next-gen جي ضرورت آهي، تڏهن تبديلي آن ڪريو

4. منظرنامي موجب سفارش: مختلف قسمن جي سائيٽن لاءِ ڪيئن چونڊيو وڃي

ساڳيو WordPress هئڻ باوجود، مواد واري سائيٽ، اي ڪامرس، پورٽ فوليو ۽ ميمبرشپ سائيٽ جا “تصويرن جا دٻاءُ وارا نقطا” هڪجهڙا ناهن۔

4.1 مواد سائيٽ/بلاگ (مضمونن جون تصويرون وڌيڪ، اپڊيٽ جي تعدد وچولي)

ترجيحي صلاح:

1. سائيز حڪمتِ عملي (Step 1)
2. دٻاءُ (Step 2)
3. ويب پي (قدم 3)

وڌيڪ مناسب رستو:

• پريشاني کان بچڻ لاءِ: رستو B، ٽن مان هڪ چونڊيو (ShortPixel / Imagify / TinyPNG)
• مفت چاهيو ٿا: رستو A (Plus WebP + EWWW)، پر صلاح آهي ته خطري جو جائزو وٺڻ لاءِ پهرين “محتاط موڊ (اصل تصوير نه حذف ڪريو)” کان شروع ڪريو

عام غلطيون:

• مضمون صفحي جي مکيه تصوير تمام وڏي آهي، سست لوڊنگ جي حڪمت عملي مناسب ناهيپهريون اسڪرين سست ڪندو

4.2 اي ڪامرس/پراڊڪٽ سائيٽ (گهڻا ٿمب نيل، گهڻيون تصويري قسمون، استحڪام پهرين)

اي ڪامرس ۾ سڀ کان آساني سان مسئلو “ڪمپريشن جو اثر خراب هئڻ” وارو ناهي، بلڪه “بهتر ڪرڻ کان پوءِ ڪجھ سائيزون غلط ٿي وڃن، ٿمب نيل غائب هجن، يا فرنٽ اينڊ جا ڪمپوننٽ تصوير حاصل نه ڪري سگهن” وارو آهي۔

ترجيحي صلاح:

1. پهريان استحڪام: ڪمپريشن جي حڪمتِ عملي ٿوري محتاط رکو، ۽ شروعات ۾ ئي سڄي لائبريري جي متبادل نه ڪريو
2. ٿمب نيل سائيز جو جائزو: اي ڪامرس ٿيم عام طور وڌيڪ سائيزون ٺاهي ٿي، جنهن سان ڪوٽا جو استعمال وڌي ويندو آهي (ShortPixel/TinyPNG ۾ خاص طور تي واضح)
3. پهريان ننڍي پيماني تي تصديق ڪريو، پوءِ وڏي تعداد ۾ ڪريو（تمام اهم）

وڌيڪ مناسب رستو:

• رستو B اڪثر وڌيڪ بي فڪر هوندو آهي: ShortPixel/Imagify/TinyPNG سڀ بيچ ۾ ڪم ڪن ٿا، اهم ڳالهه اها آهي ته توهان ڪوٽا جي طريقيڪار کي سمجهو ۽ اڳواٽ خرچ جو اندازو لڳايو
• رستو A به ٺيڪ آهي، پر Plus WebP جي “ID مٽائڻ/اصل تصوير حذف ڪرڻ/URL بدلائڻ” واري عمل سان وڌيڪ احتياط ڪريو: هي اثاثن جي لڏپلاڻ آهي، تنهنڪري شروعات ۾ مڪمل طور تي مٽائڻ جي صلاح نه آهي۔

4.3 پورٽفوليو/فوٽوگرافي سائيٽ (اڪيلو تصوير جي معيار لاءِ حساس، تصويرون وڏيون، بصري اثر لاءِ اعليٰ گهرجون)

ترجيحي صلاح:

1. سائيز پاليسي (ڊسپلي علائقي جو ڪنٽرول)
2. دٻائڻ جي حڪمت عملي (ٿورو وڏو هجي، پر تفصيل خراب نه ٿين)
3. WebP/AVIF (وڏي تصويرن وارن منظرنامن ۾ فائدو تمام واضح آهي، پر ڏيک جي احساس جي تصديق ڪرڻي آهي)

وڌيڪ مناسب رستو:

• Imagify: “اصل تصوير جي سائيز” موجب ڪوٽا ڪٽي ويندي، اهڙي قسم جي سائيٽ تي “بجيٽ تي ڪنٽرول” وڌيڪ آسانيءَ سان ٿي سگهي ٿو (توهان کي خبر هوندي ته هر وڏي تصوير تي لڳ ڀڳ ڪيتري ڪٽوتي ٿيندي)، پر بار بار ٻيهر ڪمپريشن ڪرڻ کان بچڻ گهرجي۔
• ShortPixelجيڪڏهن ٿمب نيل جا سائز گهٽ هجن ته ڪريڊٽس به ڪافي واضح هوندا؛ پر جيڪڏهن توهان ڪيترائي سائز + ايندڙ نسل ٺاهيو ٿا ته ڪريڊٽس جو خرچ وڌي ويندو، تنهنڪري اڳواٽ رٿابندي ضروري آهي۔

5. حد/فيءَ جي ڀيٽ: ڇا “مفت” ڪافي آهي، واضح ڪريو

آخر ڪهڙو چونڊڻ وڌيڪ فائدي وارو آهي، ۽ مفت ۾ ڪيتري دير هلي سگهندو؟

5.1 ٽن قسمن جا چارجنگ ماڊل

• ShortPixel（credits）اصل تصوير + ٿمب نيلن جي تعداد موجب ڪريڊٽس ڳڻيا ويندا؛ WebP/AVIF ٺاهڻ تي هر لاڳاپيل ورزن لاءِ اضافي ڪريڊٽ ڪٽبو۔
• Imagify(MB ڪوٽا): “اصل فائل جي سائيز” موجب ڪوٽا ڪٽي ويندي؛ جيترا وڌيڪ ٿمبنيل هوندا اوترو وڌيڪ ڪٽبو؛ ٻيهر ڪمپريس ڪرڻ تي وري ڪٽ ٿيندي۔
• TinyPNG（credits）هر مهيني 500 ڪريڊٽ؛ WebP/AVIF تبديلي فعال ڪرڻ سان هر تصويري سائيز لاءِ اضافي ڪريڊٽ ڪٽبو

5.2 تڪڙو اندازو لڳائڻ جو طريقو

توهان هن طرح اندازو لڳائي سگهو ٿا:

1. ڪو به هڪ “توهان اڪثر اپلوڊ ڪندڙ اصل تصوير” چونڊيو، ۽ ان جو لڳ ڀڳ سائيز ڏسو (مثال: 300KB / 1MB / 3MB)
2. پنهنجي سائيٽ ۾ اندازي طور ڪيترا ٿمب نيل سائيز ٺهن ٿا (مثال: 5 / 10 / 20)
3. فيصلو ڪريو ته ڇا توهان WebP/AVIF ٺاهڻ چاهيو ٿا (ها/نه)

پوءِ هيٺين “ذهني حساب” سان خرچ کي سمجهو:

• ShortPixelهر تصوير ≈ (1 + ٿمب نيلن جو تعداد) ڪريڊٽ؛ جيڪڏهن WebP/AVIF ٺاھيو وڃي، ته ≈ ٻيڻو ٿي ويندو (ڇو ته next-gen نسخن لاءِ به ڪريڊٽ گهرجي)
• Imagify: هر تصوير ≈ (اصل تصوير جي سائيز + هر ٿمب نيل جي سائيز) ڪوٽا مان ڪٽبي؛ ڪمپريشن ليول تبديل ڪري ٻيهر ڪمپريس ڪرڻ سان ٻيهر ڪٽوتي ٿيندي
• TinyPNGمفت 500 ڪريڊٽ؛ جيڪڏهن توهان جي سائيٽ تي هر تصوير مان ڪيترائي سائيز ٺهن ۽ تبديلي فعال هجي، ته مفت تصويرن جو انگ واضح طور گهٽجي ويندو (پلگ ان صفحي تي “تقريباً 100 تصويرون/مهينو” ۽ “تقريباً 50 تصويرون/مهينو” جي سادي اميد ڏني وئي آهي)

6. خطري جي خبرداري

خطرو 1: ڪيترن ئي پلگ انز کي ساڳيو ڪم بار بار نه ڪرڻ ڏيو

هي سڀ کان عام “آفت جو ذريعو” آهي”

• رستو A：Plus WebP or AVIF + EWWWڪم ٻنهي ۾ ورهايو، ساڳئي قسم جي تبديلي ۽ ترسيل هڪ ئي وقت نه ڪريو، يا صرف انهن مان هڪ انسٽال ڪريو
• رستو B: ShortPixel / Imagify / TinyPNG ٽن مان هڪ چونڊيوهڪ چونڊيو جيڪو کمپريس ۽ next-gen لاءِ ذميوار هجي

خطرو 2: Plus WebP جو “ڪور ID / اصل تصوير ختم ڪريو / URL مٽايو” اثاثن جي منتقلي ۾ شامل آهي

ٻيهر زور ڀريو ٿو وڃي:پلس WebP وضاحت ۾ صاف لکيل آهي ته مڪمل جنريشن دوران اصل تصوير جي ID مٿان لکي ويندي، اصل فائل حذف ڪئي ويندي، ۽ مواد جو URL مٽايو ويندو۔
هن جو مطلب آهي ته اها “ڪنهن به وقت واپس وٺي سگهجندڙ ننڍي سيٽنگ” ناهي، پر اثاثي جي سطح تي هڪ دفعي تبديلي آهي۔

تجويز ڪيل حڪمتِ عملي هي هجڻ گهرجي:

• پهريان ننڍي پيماني تي آزمائش ڪريو (ڪجهہ ڏهڪن کان ڪجهہ سئن تصويرون)
• پڪ ڪريو ته فرنٽ ڊيسڪ ڊسپلي، ٿمب نيل ۽ ڪيش اپڊيٽ سڀ صحيح آهن
• وري سوچي پوري لائبريري تي عمل ڪريو

خطرو 3: ڪلائوڊ ڪمپريشن جي “مفت حد” جو اصل استعمال ٿمبنيلن جي تعداد ۽ next-gen جي چونڊ تي دارومدار رکي ٿو

• ShortPixelٿمبنيل ۽ ايندڙ نسل ڪريڊٽس تي نمايان اثر وجهندا
• TinyPNGWebP/AVIF کي فعال ڪرڻ سان هر تصويري سائيز لاءِ اضافي ڪريڊٽ ڪٽبا
• Imagify: اصل تصوير جي سائيز موجب ڪٽيو ويندو، ٿمبنيل جيترا وڌيڪ هوندا اوترو وڌيڪ ڪٽبو، ٻيهر دٻائڻ سان ورجائي ڪٽبو

خطرو 4: “WebP/AVIF ٺهيو” جو مطلب اھو ناھي ته “فرنٽ اينڊ WebP/AVIF پهچائي رهيو آهي”

گھڻن ماڻهن کي تبديلي ڪرڻ کان پوءِ لڳي ٿو ته رفتار “نه وڌي”، اصل سبب اهو آهي ته فرنٽ اينڊ اڃا به JPG/PNG ئي ڏئي رهيو آهي (ڪيش/ري رائيٽ/ٽيگ/برائوزر نيگوشيئيشن وغيره مان ڪنهن به ڪڙي جو صحيح نه هجڻ)

7. مڪمل ٿيڻ کان پوءِ ڪيئن تصديق ڪجي ته اهو اثرائتو ٿيو آهي يا نه

4 تمام سادا تصديق جا نقطا:

1. ساڳيو صفحو ٻيهر تازو ڪرڻ تي، لوڊنگ وڌيڪ مستحڪم ۽ تيز آهي ڇاڪيش ۽ بهترڪاري اثرائتي لڳي ٿي يا نه ٿو لڳي
2. ڇا موبائل ۽ ڊيسڪ ٽاپ تي لوڊ ٿيندڙ تصويرن جا ماپ واضح طور مختلف آهن؟جوابداري ڪندڙ srcset/sizes ڇا اهو اثر ڪري ٿو）
3. ڪجهه تصويرون چيڪ ڪريو: ڇا WebP يا AVIF فائلون/وسيلا ظاهر ٿين ٿاڇا سائيٽ واقعي استعمال ۾ آهي؟ next-gen）
4. ڪجهه تصويرون بي ترتيب چيڪ ڪريو: وڏو ڪري ڏسو ته ڇا واضح طور ڌندليون آهن، ۽ ڇا لکت ڌنڌلي لڳي ٿيڇا ڪمپريشن معيار تمام گهڻو آهي؟

جيڪڏهن هي چارئي شرطون پوريون ٿين ٿيون، ته ان جو مطلب آهي ته توهان جي چونڊيل رستو اڳ ئي هلڻ لڳو آهي. هاڻي اڳتي هليو ۽ پوءِ ڪريو “پهچائڻ واري سطح”مجموعي طور وڌيڪ مستحڪم ٿيندو۔

8. ڪارروائي جي صلاحون

1. پهريان رستو چونڊيو:

• جيترو ٿي سگهي مفت ڪريو：Plus 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. ڇا WordPress اڳ ۾ ئي WebP/AVIF جي سپورٽ نٿو ڪري؟ ڇا مون کي اڃا به پلگ ان جي ضرورت آهي؟

الڳ الڳ سڃاڻڻ ضروري آهي:
“اپلوڊ/استعمال جي حمايت ≠ خودڪار تبديلي/خودڪار فراهمي
WordPress 6.5 به پراڻن JPG/PNG فائلن کي پاڻمرادو وڏي تعداد ۾ WebP/AVIF ۾ تبديل نه ڪندو، ۽ نه ئي اهو پاڻمرادو توهان لاءِ “برائوزر جي صلاحيت موجب AVIF/WebP مهيا ڪري ۽ ضرورت پوڻ تي واپس اصل فارميٽ ڏانهن موٽي” واري مڪمل سلسلي کي تيار ڪندو. جيڪڏهن توهان چاهيو ٿا ته پراڻي ميڊيا لائبريري به ان سان گڏ هلي، ته عام طور پلگ اِن يا سروس جي مدد وٺڻي پوندي.

3. تصوير جي بهتري ۾، سڀ کان “وڏي نتيجي واري” قدم آخر ڪهڙو آهي؟

عام طور تي آهي پهريائين “سائيز” درست ڪريو (srcset/sizes)。
گهڻيون سائيٽون سست انهيءَ ڪري ناهن جو ڪمپريشن ناهي، پر انهيءَ ڪري جو صفحي تي رڳو 900px ڏيکاريو وڃي ٿو پر استعمال ڪندڙ کان 3000px جي اصل تصوير ڊائونلوڊ ڪرائي وڃي ٿي. ڪمپريشن سان KB بچي سگهن ٿا، پر “ماپ ٺيڪ نه هئڻ” سبب توهان بي سبب ڪيترائي ڀيرا وڌيڪ ڊيٽا ڊائونلوڊ ڪريو ٿا.

4. مان ڪيئن پڪ ڪريان ته هاڻي جيڪا لوڊ ٿي رهي آهي اها “ننڍي واري تصوير” آهي، نه ته هميشه اصل تصوير ئي ڊائونلوڊ ٿي رهي آهي؟

ٻه رجحان ڏسو:

• جڏهن صفحو موبائل تي کوليو وڃي ٿو، تڏهن ڊائون لوڊ ڪيل تصوير جو سائيز ڊيسڪ ٽاپ کان واضح طور ننڍو هوندو آهي
• ساڳي تصوير لاءِ مختلف ڊوائيسن تي لوڊ ٿيندڙ وسيلا جو ماپ مختلف هوندو آهي
  جيڪڏهن هميشه اصل تصوير ڊائونلوڊ ٿئي ٿي، ته عام سبب اهو هوندو آهي ته ٿيم يا بلڊر تصوير کي CSS پسمنظر يا ڪسٽم آئوٽ پُٽ طور استعمال ڪري ٿو، جنهن ڪري ميڊيا لائبريري جون گهڻ-ماپون ۽ srcset نظرانداز ٿي وڃن ٿا۔

5. ڇا “WebP/AVIF ٺهي ويو” جو مطلب آهي ته فرنٽ اينڊ تي ضرور WebP/AVIF ڏيکاري رهيو آهي؟

برابر ناهي.
تيار ڪرڻ فقط “فائيل ليئر” تي مڪمل ٿيو آهي؛ اڳئين پاسي واقعي WebP/AVIF پهچايو وڃي ٿو يا نه، اهو اڃا به rewrite، picture ٽيگ جي حڪمتِ عملي، ڪيش hit ٿيو آهي يا نه، ۽ برائوزر negotiation اثرائتو ٿيو آهي يا نه، انهن ڳالهين تي دارومدار رکي ٿو. ڪم مڪمل ڪرڻ کان پوءِ لازمي طور “ڪجهه تصويرن جي ريسورس ٽائپ جي جاچ” ڪريو.

6. Plus WebP يا AVIF آخر خطرو ڪٿي آهي؟ ڇا مان هڪ ڪلڪ سان سڄي لائبريري تي هلائي سگهان ٿو؟

ان جو خطري جو نقطو “دٻاءُ” نه، پر آهياثاثن جي منتقلي جي سطح جون تبديليون：

• مڪمل طور تي ٺاهڻ وقت اصل تصويري فائل ID مٿان لکيجي سگهي ٿي، اصل فائل ڊليٽ ٿي سگهي ٿي، ۽ مواد ۾ موجود URL تبديل ٿي سگهن ٿا۔
  تنهنڪريشروعات ۾ ئي پوري لائبريري کي تبديل ڪرڻ جي صلاح نه آهي: پهرين ننڍي حد ۾ جاچ ڪريو (ڏهڪن کان سوين تصويرون) + استعمال لائق بيڪ اپ هجي، پوءِ ئي پوري ڊيٽابيس تي پروسيس ڪرڻ تي غور ڪريو۔

7. Plus WebP جا ٻه طريقا ڪيئن چونڊجن: اصل تصوير برقرار رکو يا مٽائي اصل تصوير حذف ڪريو؟

آسان سمجهاڻي:

• موڊ 1: اصل تصوير برقرار + WebP/AVIF نقلون ٺاھيو (وڌيڪ مستحڪم): واپس موٽائڻ آسان ٿيندو، پر ڊسڪ جي جاءِ وڌندي (اصل تصوير + نئون فارميٽ + ڪيترن سائزن جا ٿمب نيل).
• موڊ 2: بدلائي ۽ اصل تصوير حذف ڪريو (وڌيڪ جارحاڻو): ڊسڪ آسانيءَ سان نه وڌندي، پر توهان “اثاثا تبديل ڪرڻ + حوالا تبديل ڪرڻ” ڪري رهيا آهيو، جنهن سان مطابقت جي مسئلن جي جاچ جي قيمت وڌيڪ ٿي وڃي ٿي۔
  جيئن سائيٽ وڌيڪ پيچيده هجي (اي ڪامرس/گهڻا پلگ ان/گهڻا سائيز)، اوترو وڌيڪ صلاح آهي ته وڌيڪ مستحڪم موڊ سان شروع ڪيو وڃي۔

8. ڇا EWWW Image Optimizer جي مفت مقامي ڪمپريشن ڪافي آهي؟ ڇا اهو سرور تي تمام گهڻو لوڊ وجهي ڇڏيندو؟

EWWW وڌيڪ “مقامي ڪمپريشن ورڪر” جهڙو آهي: اهو CPU/IO استعمال ڪندو آهي۔
عام حالتن ۾ بيچ آپٽمائيزيشن دوران لوڊ وڌي ويندو آهي، اهو ان جي “ناڪامي” نه ٿو ڏيکاري، پر اهو ته حڪمت عملي درست هجي: مرحلن ۾، گهٽ رش وارن وقتن ۾، ۽ ضرورت هجي ته آف لوڊ/ڪلائوڊ حل چونڊيو۔
جيڪڏهن توهان آساني چاهيو ٿا، يا سرور جا وسيلا گهٽ آهن، ته رستو B سرور تي وڌيڪ هلڪو پوي ٿو۔

9. ShortPixel جا 100 مفت ڪريڊٽس/مهينو، مون کي ڇو لڳي ٿو ته ڪجهه تصويرن سان ئي ختم ٿي وڃن ٿا؟

ڇاڪاڻ⁠ته ڪريڊٽس “تصويرن جي ڳڻپ” نه آهن”ٿمب نيل ۽ ايندڙ نسل سان وڏو ڪيو ويندو】

• اصل تصوير + هر ٿمب نيل پڻ ڪريڊٽ ۾ ڳڻيو ويندو آهي
• جيڪڏهن WebP/AVIF ٺاھيو وڃي، ته هر لاڳاپيل ورزن لاءِ وڌيڪ ڪريڊٽ خرچ ٿيندو
  تنهنڪري اوهان سمجهو ٿا ته “1 تصوير”، پر حقيقت ۾ شايد لڳ ڀڳ “2 عدد credits” خرچ ٿين. ShortPixel

10. Imagify جا مفت 20MB/مهينو، ڇو جلدي ختم ٿي وڃي ٿو؟

Imagify وڌيڪ “ٽريفڪ پيڪيج” جهڙو آهي:

• جيئن توهان موڪليو آهياصل فائل جي سائيزڪوٽا ڪٽيو
• وڌيڪ ٿمب نيل، وڌيڪ خرچ
• دٻاءَ جي سطح تبديل ڪري ٻيهر بهتر ڪرڻ سان ڪوٽا ٻيهر خرچ ٿيندي
• ساڳي API Key ڪيترين ئي سائيٽن ۾ گڏيل استعمال، ڪوٽا به گڏيل
  تنهنڪري “20MB جلدي ختم ٿي وڃي ٿو” اڪثر ڪري تصويرون تمام وڏيون هجڻ، ٿمب نيل تمام گهڻا هجڻ، يا بار بار آزمائش ۽ غلطي ڪرڻ سبب ٿيندو آهي۔

11. TinyPNG مفت 500 ڪريڊٽس/مهينو، پوءِ پلگ ان ڇو چوي ٿو ته لڳ ڀڳ رڳو 100 تصويرون/مهينو، ۽ WebP/AVIF کولڻ کان پوءِ 50 تصويرون/مهينو ڇو ٿي وڃن ٿيون؟

ڇو ته TinyPNG جا ڪريڊٽ به “سائيز/ويرينٽ” سبب وڌي وڃن ٿا៖

• عام ورڈپریس انسٽاليشن لڳ ڀڳ 100 تصويرون في مهينو ڪمپريس ڪري ٿي
• AVIF يا WebP جي تبديلي کي فعال ڪريو:هر تصوير جي سائيز لاءِ هڪ اضافي ڪريڊٽ خرچ ٿيندوتنهنڪري شايد رڳو لڳ ڀڳ 50 تصويرون/مهينو ڪمپريس ۽ تبديل ڪري سگهجن ٿيون (ٿمب نيل جي سائيز ۽ تعداد تي دارومدار رکي ٿو)
  تنهنڪري 500 ڪريڊٽس ≠ 500 تصويرون۔

12. آخر منهنجي سائيٽ ۾ ٿمب نيلن جو تعداد ڪيترو آهي؟ اهو ايترو وڏو اثر ڇو وجهي ٿو؟

ورڊپريس هڪ تصوير اپلوڊ ڪرڻ تي ڪيترن سائيزن ۾ ٺاهي ٿو؛ ٿيم/پلگ ان (خاص طور اي ڪامرس) وڌيڪ سائيزون به شامل ڪري سگهن ٿا۔
ڪلائوڊ ڪمپريشن جا ڪريڊٽس/ڪوٽا عام طور “اصل تصوير + ٿمب نيل گڏجي ڳڻيا ويندا آهن”، تنهن ڪري جيترا وڌيڪ ٿمب نيل هوندا، اوتري ئي مفت حد جلدي ختم ٿيندي۔

13. ڇا ليزي لوڊنگ ضرور تيز ڪري ٿي؟ ڪجهه ماڻهو ڇو چون ٿا ته ليزي لوڊنگ الٽو سست ٿي وڃي ٿي؟

ليزي لوڊنگ “اسڪرين کان ٻاهر وارن وسيلن” لاءِ مناسب آهي۔
جيڪڏهن پهرين اسڪرين تي سڀ کان اهم اها وڏي تصوير به دير سان لوڊ ڪئي وڃي، ته شايد پهرين اسڪرين جي تجربي کي سست ڪري ڇڏي. WordPress 5.5 کان ڊفالٽ ليزي لوڊنگ ٺيڪ آهي، پر “هڪ ئي قاعدو سڀني لاءِ” وارو طريقو نه اپنائو.

14. مان رستو A يا B وٺان، مون کي CDN / تصوير CDN ڪڏهن گهرجي؟

دٻاءُ، سائيز ۽ فارميٽ اهو مسئلو حل ڪن ٿا ته “فائل ننڍي ۽ وڌيڪ مناسب هجي”؛
CDN حل ڪري ٿو ته پهچ وڌيڪ ويجهو ۽ وڌيڪ مستحڪم ٿئي。
جڏهن تصويرون سورس سائيٽ تان ڊگهي فاصلي تي حاصل ڪرڻ سبب دير واضح طور وڌي وڃي، ته پوءِ CDN/تصوير CDN (مثال طور Cloudflare Polish / Jetpack Site Accelerator) شامل ڪرڻ سان مجموعي طور وڌيڪ استحڪام رهندو، پڙهڻ WordPress CDN تيز ڪرڻ。

15. مڪمل ٿيڻ کان پوءِ مان ڪهڙي سڀ کان سادي طريقي سان تصديق ڪريان ته اهو “واقعي اثرائتو ٿيو”؟

سڀ کان وقت بچائيندڙ تصديق جو طريقو:

• ساڳيو صفحو ٻيهر تازو ڪرڻ تي، لوڊنگ وڌيڪ مستحڪم ۽ تيز آهي ڇا
• ڇا موبائل ۽ ڊيسڪ ٽاپ تي لوڊ ٿيندڙ تصويرن جا سائز واضح طور مختلف آهن (ڇا srcset/sizes ڪم ڪري رهيا آهن)
• ڪجهه تصويرون چيڪ ڪريو: ڇا WebP يا AVIF فائلون/وسيلا ظاهر ٿين ٿا
• ڪجهه تصويرون بي ترتيب چيڪ ڪريو: وڏو ڪري ڏسو ته ڇا واضح طور ڌندليون آهن، ۽ ڇا لکت ڌنڌلي لڳي ٿي