تحسين الصور هو من أكثر الحوايج اللي كيعطيو أكبر مردودية فالأداء ديال WordPress: نفس بنية الصفحة، ونفس القالب، غير إلا تصلحات حجم الصور، المقاسات، الصيغة، وطريقة التقديم، غالباً تجربة التحميل كتحسن فوراً.
ولكن تحسين الصور هو أيضًا أكثر ما يمكن يخلّي الأمور “كتولي عشوائية”، والسبب ماشي هو أن التقنية صعيبة بزاف، ولكن حيث المعلومات متفرقة بزاف:
قريتي شي مقالات، وعرفتي خاص “الضغط” و“WebP/AVIF” و“التحميل الكسول”، ومن بعد ملي كتشوف شرح الإضافة كيلقاو كيقولو “100 credits مجاناً كل شهر” و“20MB مجاناً” و“1 credit لكل صورة”، وفي اللخر كتبدا كتخلط عليك الأمور أكثر: واش المجاني كافي ولا لا؟ كيفاش كيتحسب الاقتطاع؟ واش يمكن فهمتي “نفس الحاجة” غلط؟ والأهم:من بعد ما كتكمّل، واش بصح كيولّي خدام؟
هاد المقال كيدير غير ثلاثة ديال الحوايج:
- نعطيك أمر قابل للتنفيذخارطة الطريقشنو نديرو اللول وشنو من بعد
- وضح الخطة اللي بغيتي تختار مزيان شنو الفرق بين المجاني والخالص ولمن كتلائم كل وحدة
- كتبنا لك هنا أكثر المشاكل الشائعة باش ما تبقاش تقلب وتقصي من بعد ما تسالي
1. المستوى الأساسي: شنو كييجي مع WordPress وشنو ما كييجيش معاه
إلى ما فهمتيش شنو دار WordPress Core من اللول، ساهل يوقعو جوج ديال الحالات:
- ضيّع ميزة مجانية كانت متاحة، وبدّلها بوقت وفلوس فإعادة اختراع العجلة
- كنت كنظن باللي WordPress غادي يحوّل الصور القديمة تلقائياً لـ WebP/AVIF، ولكن لقيت باللي ما كيديرهاش
WordPress فيه هاد القدرات الأساسية مدموجة من الأصل:
- صور متجاوبة (srcset/sizes)من ووردبريس 4.4 فصاعدًا، النواة غادي تخرّج للصور
srcsetوsizesوكيستافد من الصور بعدة أحجام اللي كيتصاوبو وقت الرفع، باش يختار المتصفح الموارد الأنسب للتحميل حسب ظروف الشاشة. - التحميل البطيء الأصليبدءًا من WordPress 5.5، تم تفعيل التحميل الكسول الأصلي للصور بشكل افتراضي، باستخدام معيار HTML
loadingتنفيذ السمة. - كيدعم رفع WebPابتداءً من WordPress 5.8، يمكن رفع واستخدام WebP مثل JPEG/PNG، إذا كانت بيئة الاستضافة تدعم WebP.
- يدعم رفع AVIFمن ووردبريس 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 (استراتيجية الصيغة: نفس الوضوح بحجم أصغر)
WordPress كيدعم دابا الرفع WebP (5.8) وAVIF (6.5)。
ولكن باش تستعملو بالفعل “الصيغة ديال الجيل الجاي”، خاص عادة تحل جوج حوايج:
- كيفاش نحوّل مكتبة الوسائط التاريخية دفعة وحدةإلا غادي تحسّن غير الصور الجديدة اللي غادي ترفع من بعد
- واش تنشئ نسخة ولا تبدّل الصورة الأصلية(هادي هي النقطة الفاصلة ديال المخاطر؛ ومن بعد غادي نهضرو بالتركيز على “Plus WebP” ديال "الاستبدال وحذف الصورة الأصلية")
الصياغة الموصى بها:
- WebP: عادة كيتختار افتراضياً فالأول (التوافق ديالو أكثر استقراراً)
- AVIF: توجه أحدث فالضغط، مناسب للتصاور الكبار/تصاور الواجهة الأولى/تصاور الألبوم (ولكن أكثريتطلب دعم البيئة)
2.4 خاصك تستعمل التحميل الكسول بالطريقة الصحيحة (ماشي بشكل عشوائي)
بداية من WordPress 5.5التحميل الكسول الافتراضيتصويرة.
كيقدر ينقص من استهلاك عرض النطاق فالرندر الأولي:
- التحميل الكسول مناسب للموارد خارج الشاشة“
- الصورة الكبيرة والأهم فالشاشة الأولى غالباً ما كتناسبش يتأخر تحميلها
2.5 طبقة التسليم: CDN / الصورة CDN
الضغط، الحجم، والصيغة كايحلّو مشكل ديال “الملف كيولي أصغر وأنسب”.
ولكن إذا كانت الصور تُحمَّل دائمًا من الموقع الأصلي من مسافة بعيدة، فسيظل تأخر الشبكة يؤثر بوضوح على التجربة. هنا كنحتاجو حل من طبقة التسليم (CDN/الصور CDN).
جوج ديال الاتجاهات النموذجية
- تحسين Cloudflare:وثائق 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 Image Optimizerأو اختار غير واحد منهم
- المسار B (اختار واحد من 3 ديال ضغط السحابة):ShortPixel / Imagify / TinyPNG
3.1 المسار A: محلّي كامل ومجاني (Plus WebP أو AVIF أو EWWW)
الميزة ديال هاد المسار هي:
- ما كتعتمدش على خدمات ضغط من طرف ثالث من نوع “حصّة شهرية/الدفع لكل صورة” طبعاً بعض الميزات ممكن حتى توفّر خدمات اختيارية
- الثمن هو: المعالجة الدفعية قد تستهلك أكثر من الخادم CPU/IO، وخاصك تركّز أكثر على “الاستراتيجية والمخاطر”
3.1.1 Plus WebP أو AVIFالأساس هو “الإنشاء/الاستبدال”، وماشي “أداة ضغط” بالمعنى التقليدي”

- مني كيتولدو جميع الصور:سيتم استبدال معرّف ملف الصورة الأصلي بـ WebP/AVIF، وسيتم حذف الملف الأصلي واستبدال الروابط داخل المحتوى أيضًا。
- البلوغين كيوفر أوامر WP-CLI، وكينبّه: إلا كانو الملفات بزاف فـ WP-CLI أكثر موثوقية.
هاد الشي كيعني: راه ماشي “كيعاونك فالسكات ويولّد ليك ملف WebP”، بل يقدر يكون مرة وحدةنقل الأصول(خصوصاً إلا فعّلتي خيارات “استبدال وحذف الصورة الأصلية” ذات الصلة).
الفرق بين الوضعين
النمط 1: الاحتفاظ بالصورة الأصلية + إنشاء نسخة WebP/AVIF (أكثر استقرارا)
- الميزة: إلى لقيتي مشاكل فالتوافق، ساهل ترجع للإصدار السابق
- الثمن: غادي يطلع استهلاك الديسك (الصورة الأصلية + الصيغة الجديدة + صور مصغرة بمقاسات متعددة)
الوضع 2: بدّل وحيد الصورة الأصلية (أكثر جرأة)
- المزايا: الديسك ما غاديش يعمر بهاد السرعة؛ الإحالات داخل الموقع غادي يتحولو مباشرة للصيغة الجديدة
- مخاطر: إذا غيّرت الأصول والمراجع، غادي ترتفع تكلفة تتبّع مشاكل التوافق، خصوصاً إلا كانت بعض الأنظمة الخارجية أو منطق القالب كيعتمد على اسم الملف أو المسار أو الصيغة الأصلية
الاقتراحات
قبل ما تختار “بدّل وحيد الصورة الأصلية”، جرّب الأول على نطاق صغير + تأكد كاين باكاب صالح؛ ما تبدلش من اللول فالمكتبة كاملة.
أشهر مشاكل Plus WebP أو AVIF
- من بعد الاستبدال الكامل للمكتبة، بعض الصور فالصفحات كيبانو بشكل غير عادي
السبب غالباً ماشي هو “الصورة خاسرة”، ولكن تبديل URL، الكاش، وسياسة الصور المصغرة وغيرها من المراحل فهاد السلسلة ما توافقش فيها شي حلقة. - كلما زاد عدد الصور المصغرة، كبر نطاق التغييرات
رفع صورة في ووردبريس كيولّد بزاف ديال المقاسات؛ والثيمات والإضافات يقدرو يزيدو مقاسات أخرى. الاستبدال الكامل كيعني باللي ممكن تبدّل مجموعة كبيرة بزاف ديال الملفات. - غير تحويل فالصيغة، ما كيعنيش بالضرورة أن الحجم غادي يكون الأصغر
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
لاحظ
بلوس WebP وإي دبليو دبليو دبليو : يمكن تحويلها كلها إلى AVIF أو WebP
من الأفضل تثبّت غير واحد منهم، وإلا ممكن يوقع تعارض
المشاكل الشائعة ديال EWWW
- أثناء التحسين الجماعي، يرتفع ضغط الخادم
حيت الضغط المحلي كياكل CPU/IO. الحل ماشي هو “ما تستعملوش”، ولكن “على دفعات، فالأوقات الخاوية، وعند الحاجة اختار التفريغ/حلول سحابية” - “كونو تولّد WebP ما كيعنيش بالضرورة باللي الواجهة الأمامية كتعرض WebP
كاينين بزاف ديال الإضافات عندهم هاد الفهم الخاطئ: التوليد حاجة، واستراتيجية التقديم (إعادة الكتابة، وسم picture، إصابة الكاش وغيرها) حاجة أخرى. - كيعاود يدير نفس الخدمة بحال إضافات خرين
إلى خديتي المسار A، حاول ما تزيدش تكدّس معاه ضغط سحابي بحال ShortPixel/Imagify/TinyPNG؛ وإلى خديتي المسار B، ما تبقاش تفعل منطق الاستبدال ديال Plus WebP. المبدأ الأساسي:شد طريق واحد حتى للآخر.
3.2 المسار B: ضغط سحابي واحد من ثلاثة (ShortPixel / Imagify / TinyPNG)
هاد المسار مناسب للي بغاو يوفرو موارد السيرفر، ويبغاو يديرو الدفعات براحة، وكيقبلو الأداء حسب الحصة أو حسب الاستعمال
ولكن أكثر نقطة كتخلق سوء الفهم فـضغط السحابة هي:الحصة المجانية ماشي غير عدد مجاني بسيطعدد أحجام الصور المصغرة، وتوليد WebP/AVIF من عدمه، وتكرار إعادة الضغط، كلها كتأثر بزاف على الاستهلاك.
غادي نفسرو لتحت: آش منو مجاني وآش منو بالمقابل، كيفاش كيتخصم الرصيد، شنوما أكثر الأخطاء اللي ساهل تطيح فيها، وشنو الأنواع ديال المواقع اللي كيناسبها।
3.2.1 ShortPixel100 كريدي مجاني/شهر، ولكن الكريدي كيتستهلك أكثر بسبب الصور المصغرة وWebP/AVIF

شنو الفرق بين مجاني ومدفوع
تعريف إضافة ShortPixel كاتب بوضوح:
- 100 كريدي مجاني كل شهر
- كاين حتى credits شهرية غير محدودة إضافية (صفحة الإضافة فيها معلومات الثمن المناسبة)
- كنوفّرو حتى باقات ديال كريديت للاستعمال مرة وحدة وما كيسالوش الصلاحية مع عرض الثمن الابتدائي
ملاحظة:
- مجاني: كنعطيو كل شهر واحد العدد محدد من credits، للمواقع الخفيفة ولا للتجربة
- باك ديال مرة وحدة: مناسب للمواقع اللي عندها “مكتبة وسائط كبيرة وبغات تصفّي المخزون دفعة وحدة” (كتشريه مرة وحدة وكيبقى حتى تساليه، وعادة ما كيساليش الأجل ديالو)
- شهري/غير محدود: مناسب للمواقع اللي كتحدّث الصور باستمرار وكتحتاج تحسين طويل الأمد ومستقر
الـKB الرسمي ديال ShortPixel حتى هو عطى على “الباقة لمرة وحدة مقابل الشهرية غير المحدودة”شرح واضح: Unlimited Monthly kaytkhalles b chhar (wlla b 3am), kay3ti credits بلا حدود ومعاه حصة ثابتة ديال CDN؛ l-credits li كتتشرا مرة وحدة ma kaytsalawch, باش t9dar تستعملهم على قد الحاجة بشكل أكثر تحكمًا.
الاقتراحات
- تصْفية مخزون الموقع القديم: إعطاء الأولوية للباك ديال المرة الواحدة
- تحديث مستمر: كيناسب أكثر الشهري/غير محدود (إلى ما بغيتيش تحسب credits استعمل غير محدود)
الأهم: كيفاش كيتحسبو كريدي ديال ShortPixel؟
الوثائق الرسمية ديال ShortPixel KB شرحها بوضوح كبير:
- ووردبريس كينشئ بزاف دالصور المصغرة ملي كتطلع صورة وحدة؛
- كل صورة مصغّرة كتتحسب فيها كريدي واحد ديال التحسين;
- إلى اخترتي توليد WebP ولا AVIF،كل نسخة WebP/AVIF من الصورة الأصلية والصورة المصغّرة كتستهلك كريدي إضافي;
- يمكن ليك تستثني شي صور مصغرة من التحسين باش تنقص من استهلاك الاعتمادات.
إلا حمّلتي صورة وحدة، القالب/الإضافة غادي ينشّأو 8 ديال الصور المصغرة:
- غادي يتم تحسين الصورة الأصلية + الصور المصغرة فقط: 1 (الصورة الأصلية) + 8 (الصور المصغرة) = 9 كريديت
- إلى بغيتو تولّدو حتى WebP/AVIF: هاد 9 اللي فوق، كل واحد منهم كيزيد نسخة next-gen → +9 credits أخرى
يعني، كتظن باللي “تصويرة وحدة”، ولكن فالحقيقة يقدر يتستهلك قرّيب لـ“عدد من رقمين ديال الكريدي”.
إذن:“100 credits مجانًا” ماشي هي “100 صورة مجانًا”.
أشهر أخطاء ShortPixel
- مجانا 100 كريدي كيساليو بسرعة
السبب الجذري: بزاف ديال الصور المصغرة + توليد WebP/AVIF كيستهلك كريديتات إضافية
الاقتراحات:
- تقييم عدد الصور المصغرة ديال الموقع أولاً
- استبعد أحجام الصور المصغرة غير الضرورية (حسّن غير الأحجام اللي غادي يتستعملو بصح)
- حدّد استراتيجية الضغط أولاً ثم شغّل الدفعات لتفادي تكرار التجربة والخطأ واستهلاك الموارد
- وفي نفس الوقت تضيف إضافات أخرى لتحويل الصيغة
إذا فعّلتي تبديل Plus WebP وخليتي ShortPixel يْوَلّد/يدخل وسوم الجيل الجديد، غادي يتراكب المنطق ويصعّب التشخيص. الخيار B خلي ShortPixel هو اللي يتكلف بوحدو. - كاتعتقد بلي غير مني تركّبات كيولي الواجهة الأمامية كاتخرّج WebP/AVIF ديما“
صفحة إضافة ShortPixelكيذكر أنه كيقدر يحوّل WebP/AVIF، وكيقدر يزيد صور الجيل الجديد لصفحات الواجهة الأمامية (مثلاً عبر الوسوم).
ولكن من بعد ما تكمل، خاصك تبقى تتحقق من النتيجة.
3.2.2 Imagifyمجاني 20MB فالشهر؛ كيتخصم الكوطا حسب الحجم الأصلي ديال الصورة + عدد الصور المصغرة، وإعادة الضغط كتعاد كتنقص من الكوطا

الرصيد المجاني والموقع
صفحة الأسعار الرسمية ديال Imagifyمكتوب بوضوح كبير:حساب مجاني بحصة شهرية 20MB。
صفحة الإضافة ديالو حتى هي كتوّضح بالواضح باللي كتقدر تضغط الصور، تبدّل الحجم ديالها، وكتحوّلها لـ WebP/AVIF
كيفاش كيتخصم الكوطا؟
الوثائق الرسمية لـ Imagify “كيفاش كيتحسب استعمال الكوطة؟” كيشرح آلية الاقتطاع بوضوح كبير:
- عدد الصور المصغرة كيأثر على الاستهلاكمثلاً إلى كان عندك 10 ديال أحجام الصور المصغرة، فتحسين صورة وحدة غادي يولي تحسين 11 صورة (الصورة الأصلية + 10 ديال الصور المصغرة)، وهاد الشي كامل غادي يساهم فاستنزاف الحصة.
- خصم الحصة حسب الحجم الأصلي للملف: مثلا إلا صيفطّي صورة ديال 100KB لـ Imagify، غادي يتحيد 100KB من الحصة ديالك.
- بدّل مستوى الضغط وأعد التحسين، غادي يتستهلك الكوطا مرة أخرى。
- نفس مفتاح API يقدر يتستعمل فعدة مواقع، ولكن الحصة غادي تتشارك بين هاد المواقع.
هاد الشي هو “الطريقة الأساسية للفهم” ديال Imagify:
كاتبان ليه أكثر بباك ديال النت: كدّيه شحال، كيتخصم شحال؛ كلما كثروا الصور المصغرة كيزيد يخصم؛ إلا عاودتي الضغط بقوة كيتعاود يخصم.
مثال سهل الفهم لحصة Imagify
إيلا فرضنا بلي طلّعتي صورة أصلية حجمها 800KB، الموقع غادي ينشئ 8 صور مصغّرة.
- منين كيدير Imagify التحسين، كيدخل حتى “الصورة الأصلية + 8 ديال الصور المصغرة” كاملين (إلى ختاريتي تحسين الكل)، وهاد الشي كيعني بلي هاد العملية غادي تستهلك تقريباً من الحصة قد المجموع ديال الحجم الأصلي ديال هاد الملفات كاملين.
هاد الشي علاش بعض المواقع كيحسو أن “20MB” كيسالي بسرعة: ماشي حيت Imagify ماكافيش، ولكن حيت كل مرة كترفع صور كبار بزاف، وكاينين بزاف ديال الصور المصغرة، وممكن حتى كتعاود تجرب مستويات الضغط مراراً.
أكثر الأخطاء الشائعة في Imagify
- مجاني 20MB لا يكفي لإنجاز تنظيف كامل سجل الموقع“
20MB فعادةً كيكون أنسب للاختبار والتحديثات الخفيفة؛ إلا كانت مكتبة الوسائط ديالك من الأصل كبيرة، فمن المحتمل بزاف أن التنظيف الكامل دفعة وحدة يحتاج ترقية. - تكرار تعديل مستوى الضغط يؤدي إلى استهلاك الحصة أكثر من مرة
Imagify شرح بوضوحإعادة التحسين غادي تستهلك الحصة مرة أخرى.
كنصحك تكتب “الاستراتيجية” بوضوح فهاد الصفحة:
- جرّب أولاً بعدد قليل من الصور لتحديد مستوى الضغط والجودة البصرية
- من بعد ما تتحدد الاستراتيجية شغّل دفعة وحدة
تجنّب تكرار المحاولات والخطأ على قاعدة البيانات كاملة
- مشاركة مفتاح API بين عدة مواقع كتخلي الحصة كتنقص بلا سبب واضح“
إلى استعملتي نفس مفتاح API فكثر من موقع، الحصة غادي تكون مشتركة.
لذلك في سيناريوهات الفريق/تعدد المواقع، من الأفضل توضيح: أي المواقع مشتركة وأيها تُستخدم بشكل منفصل، لتفادي خروج الميزانية عن السيطرة.
3.2.3 TinyPNGTiny Compress Images: مجاني 500 كريديت/شهر؛ التحويل إلى WebP/AVIF كيخصم 1 كريديت إضافي لكل حجم“

الحصة المجانية وطريقة احتساب التكلفة
صفحة إضافة TinyPNG ديال WordPress مكتوبة بوضوح كبير:
- 500 كريدي فالشهر مجاناً
- في “تثبيت ووردبريس العادي”، يمكن تقليصه تقريبًا حوالي 100 صورة/الشهر
- ولكن إلى تفعّل التحويل إلى AVIF أو WebP:كل حجم صورة كيستهلك كريدي إضافيلذلك يمكن فقط ضغطه وتحويله تقريبا حوالي 50 صورة/الشهر(على حسب شحال من قياسات ديال الصور المصغرة عندك).
وفي الوقت نفسه، Tinify (مطوّرو TinyPNG/TinyJPG) أيضًا في صفحة أسعار APIوضّح: غير بالتسجيل كتحصل على 500 عملية ضغط مجانية كل شهر؛ ومن بعد كيتحسب عليك غير على عدد عمليات الضغط الناجحة، وما كاين حتى اشتراك إجباري.
لخّص طريقة الفهم ديال TinyPNG ف جملة وحدة:
كيتحسب بـ credits؛ كلما كثرات مقاسات الصور المصغرة وكلما فعلتي WebP/AVIF أكثر، كيتستهلكو credits بسرعة أكثر
أمثلة على أرصدة TinyPNG سهلة الفهم
إفترض بلي الموقع ديالك كينتج لكل صورة 8 مقاسات ديال الصور المصغّرة:
- غير الضغط فقط: الصورة الأصلية + 8 صور مصغرة → كيتطلب 9 كريديت
- إلا فعّلت تحويل WebP/AVIF: كل مقاس كيتخصم ليه كريدي إضافي → يقدر يقرب يتضاعف
هادشي كيوافق الشرح فصفحة الإضافة: منين كتفعّل التحويل كتهبط الحصة المجانية تقريباً من 100 صورة فالشهر لـ50 صورة فالشهر.
أشهر مشاكل TinyPNG
- أو 500 كريدي = 500 صورة
لا. كيستهلك حسب حجم/نسخة الصورة. صفحة الإضافة راه وضحات باللي التحويل كيخصم 1 كريدي إضافي لكل حجم صورة - الثيم/إضافة التجارة الإلكترونية كتنشئ مقاسات بزاف، والحصة المجانية نقصات بشكل واضح
كلما كثرات المقاسات، كيتضاعف استهلاك الكريديت بسهولة. - منين كتفعّل التحويل كيبان باللي الرصيد كيسالي بسرعة
هادشي ماشي bug، هادي هي طريقة الفوترة ديالو.
نصيحة استراتيجية:
- إلا كانت المرحلة المجانية كتستعمل أساسًا غير للضغط وتقليل الحجم، تقدر دابا غير تضغط، ومنين تتأكد أن هيكلة الموقع مستقرة وبالصح محتاج next-gen، فعّل التحويل من بعد
4. توصيات حسب السيناريو: كيفاش تختار حسب نوع الموقع المختلفة
حتى إلا كان WordPress هو هو، “نقاط الضغط ديال الصور” فمواقع المحتوى، والمتاجر الإلكترونية، ومعارض الأعمال، ومواقع العضوية ماشي هي نفسها.
4.1 موقع محتوى/بلوغ (مقالات بصور كثيرة وتحديث متوسط)
اقتراح ديال الأولوية:
- استراتيجية المقاس (الخطوة 1)
- ضغط (المرحلة 2)
- WebP (الخطوة 3)
طريق أنسب:
- بغيتي حل ساهل: اختار واحد من 3 (ShortPixel / Imagify / TinyPNG)
- بغيتيها ببلاش: الخطة A (Plus WebP + EWWW)، ولكن كننصحك تبدا الأول بـ“الوضع المحافظ (ما كيمسحش الصور الأصلية)” باش تقيّم المخاطر
الحفرة النموذجية:
- الصورة الرئيسية ديال المقال كبيرة بزاف، واستراتيجية التحميل الكسول ماشي مناسبةكيبطّأ التحميل الأولي
4.2 متجر إلكتروني/موقع منتوجات (مصغرات بزاف، تنويعات الصور بزاف، الاستقرار أولاً)
فالتجارة الإلكترونية، أكثر المشاكل ما كتكونش هي “الجودة ديال الضغط ماشي مزيانة”، بل “من بعد التحسين كيبانو بعض المقاسات غلط، المصغرات ناقصة، ومكونات الواجهة ما كتلقاش الصور”.
اقتراح ديال الأولوية:
- الأول خاصنا نثبّتو: خليه فسياسة الضغط محافظة شوية، وما تبدلوش المخزن كامل من اللول
- قيّم مقاس الصور المصغّرة: قوالب المتاجر الإلكترونية كتولّد عادةً مقاسات أكثر، وهاد الشي كيزيد فالاستهلاك ديال الحصة خصوصاً مع ShortPixel/TinyPNG
- تحقق أولاً على نطاق صغير ثم نفّذ بالجملة مهم بزاف
طريق أنسب:
- المسار B غالباً كيريّح البال أكثر: ShortPixel وImagify وTinyPNG كاملين كيدعمو المعالجة بالجملة، والمهم هو تفهم نظام الحصص وتقيّم التكلفة مسبقاً
- المسار A ممكن أيضًا، لكن خاص التعامل بحذر أكثر مع سلوك Plus WebP ديال تبديل المعرف/حذف الصورة الأصلية/استبدال الرابط: هاد الشي كيدخل فترحيل الأصول، وما كينصحش به من البداية بشكل شامل
4.3 موقع معرض الأعمال/التصوير الفوتوغرافي (حساس لجودة الصورة الفردية، الصور كبيرة، ويتطلب مستوى عالٍ من الجودة البصرية)
اقتراح ديال الأولوية:
- إستراتيجية المقاس التحكم في منطقة العرض
- سياسة الضغط (خليه أكبر شوية وما تفسدش التفاصيل)
- WebP/AVIF (فالصورة الكبيرة الفايدة باينة بزاف، ولكن خاص التحقق من الجودة البصرية)
طريق أنسب:
- Imagify: كيتحسب من الحصة حسب “الحجم الأصلي ديال الصورة”، وهاد النوع ديال المواقع أسهل باش يدير “ميزانية متحكم فيها” (كتكون عارف تقريباً شحال كتقتطع كل صورة كبيرة)، ولكن خاصك تتفادى إعادة الضغط مرات كثيرة.
- ShortPixelإيلا كانو مقاسات الصور المصغرة قليلين، فالاعتمادات كتكون واضحة؛ ولكن إلا ولّدتي بزاف ديال المقاسات مع next-gen، غادي يكبر استهلاك الاعتمادات وخصك تخطط من قبل
5. مقارنة السقف والتسعير: وضّح واش المجاني كافي ولا لا
شنو هو لي أوفر، وشحال غتبقى المجانية صامدة؟
5.1 جوج ديال نماذج الاقتطاع
- ShortPixelالرصيدكيتحسبو الكريديتات حسب الصورة الأصلية + عدد الصور المصغرة؛ وإنشاء WebP/AVIF كيقتاطع كريديت إضافي على كل نسخة مقابلة.
- Imagifyالحصة ديال MB: كيتخصم من الكوطا على حساب “الحجم الأصلي ديال الملف”؛ كلما كثروا المصغرات كيزيد الخصم؛ وإلى تعاود الضغط كيتخصم مرة أخرى.
- TinyPNGالرصيد500 credits فالشهر؛ تفعيل التحويل لـ WebP/AVIF كيخصم credit إضافي على كل حجم ديال الصورة
5.2 طريقة سريعة للتقدير
تقدر تقدرها بهاد الطريقة:
- جيب شي صورة أصلية من اللي كتطلعها غالباً، وشوف تقريباً شحال الحجم ديالها (مثلاً 300KB / 1MB / 3MB)
- شحال تقريباً من قياس ديال الصور المصغرة غادي يتولد فالموقع ديالك بحال 5 / 10 / 20
- حدد ما إذا كنت تريد إنشاء WebP/AVIF (نعم/لا)
ومن بعد استوعب الاستهلاك بهاد “الحساب الذهني”:
- ShortPixelلكل صورة ≈ (1 + عدد الصور المصغّرة) credits؛ وإذا تولّد WebP/AVIF فالتكلفة كتتقارب كتتضاعف (حيت نسخة next-gen حتى هي كتحتاج credit)
- Imagify: كل تصويرة ≈ (الحجم ديال الصورة الأصلية + الحجم ديال كل الصور المصغرة) كيتحسب من الكوطا؛ إلا بدّلتي مستوى الضغط وعاودتي الضغط غادي يتحسب مرة أخرى
- TinyPNGمجاني 500 رصيد؛ إذا كان موقعك كينتج بزاف ديال المقاسات لكل صورة ومفعّل التحويل، العدد المجاني ديال الصور غادي ينقص بوضوح (فصفحة الإضافة كاين توقع واضح: حوالي 100 صورة/الشهر و حوالي 50 صورة/الشهر)
6. تنبيه بالمخاطر
الخطر 1: ما تخليش بزاف ديال الإضافات يعاودو يديرو نفس الحاجة
هاد هو أكثر “مصدر الكوارث” شيوعًا”
- المسار APlus WebP أو AVIF + EWWWقسمو الخدمة بيناتهم، ما تديروش بجوج نفس النوع ديال التحويل والتسليم فآن واحد، ولا ركّبو غير واحد منهم
- المسار B: ShortPixel / Imagify / TinyPNG واحد من ثلاثةاختار واحد مسؤول على الضغط و next-gen
الخطر 2: “تغطية المعرّف / حذف الصورة الأصلية / استبدال الرابط” ديال Plus WebP كيدخل فترحيل الأصول
كنعاودو نأكدو:بلوس WebP الوصف كايقول بوضوح بلّي ملي كيتدار التوليد الكامل كيتبدّل ID ديال الصورة الأصلية، وكيتحيد الملف الأصلي، وكيتعوّض رابط المحتوى.
هاد الشي كيعني باللي ماشي “إعداد صغير اللي تقدر ترجعو فأي وقت”، بل تغيير على مستوى الأصل مرة وحدة.
الستراتيجية المقترحة خاصها تكون:
- جرّب أولاً على نطاق صغير (من عشرات الصور إلى بضع مئات)
- تأكد من أن عرض الواجهة، الصور المصغرة، وتحديث التخزين المؤقت كاينين بشكل عادي
- إعادة النظر في معالجة كامل المكتبة
الخطر 3: الاستهلاك الحقيقي للحصة المجانية ديال الضغط السحابي كيعتمد على عدد الصور المصغرة واختيار الجيل التالي
- ShortPixelالصور المصغرة وnext-gen غادي يأثرو بزاف على الرصيد
- TinyPNGتفعيل WebP/AVIF كيخصم كريدي إضافي لكل حجم صورة
- Imagify: كيتخصم على حسب الحجم الأصلي ديال الصورة، وكلما كثر عدد الصور المصغرة كيزيد الخصم، والضغط بقوة كيعاود يخصم
الخطر 4: “إنشاء WebP/AVIF” لا يعني أن الواجهة كتسلّم WebP/AVIF“
كثير من الناس من بعد ما يديرو التحويل كيبان ليهم باللي ما ولاتش أسرع، والسبب الرئيسي هو أن الواجهة الأمامية ما زالت كاتخرج JPG/PNG (الكاش/إعادة الكتابة/الوسوم/تفاوض المتصفح وغيرها ممكن شي حلقة ما خداماش مزيان)
7. من بعد ما تسالي، كيفاش تتأكد واش خدام ولا لا
4 نقط ديال التحقق بسيطين بزاف:
- إعادة تحميل الصفحة للمرة الثانية، واش كيولي التحميل أكثر استقرارًا وأسرعالإحساس بفعالية التخزين المؤقت والتحسينات
- واش حجم الصور اللي كتتحمل فالهاتف وفي الحاسوب مختلف بوضوحمتجاوب
srcset/sizesواش خدامة؟ - فحص بعض الصور: واش كاين ملفات/موارد WebP ولا AVIFواش الموقع فعلاً كيتستعمل الجيل القادم)
- شيك على شي تصاور عشوائياً: كبّر وشوف واش كاين تشويش باين ولا النص مغبّشواش الجودة ديال الضغط زايدة بزاف
إيلا هاد الأربع شروط كاملين متوفرين، فهذا كيعني باللي المسار اللي ختاريتي بدا خدام. من بعد سير دير طبقة التسليم“، غادي يكون كولشي أكثر استقرار.
8. التوصيات العملية
- اختار المسار أولاً:
- بغيت يكون مجاني قدر الإمكان: Plus WebP ولا AVIF + EWWW (ولا غير ثبّت واحد منهم)
- بغيتي تقتاصد فموارد السيرفر وتخلص حسب الاستهلاك براحة بالاختار واحد من ShortPixel / Imagify / TinyPNG الثلاثة
- جرّب أولاً على نطاق صغير (بضعة عشرات من الصور)
- تأكد ما كاين حتى مشكل ومن بعد دير بالجملة
- خاصنا نزيدو نحسنو استقرار التسليم:اقرأ CDN تسريع
المشاكل الشائعة
1. واش خاصني بالضبط نثبّت شحال من إضافة؟ واش نقدر نثبّتهم كاملين؟
حاول تمشي غير فطريق واحد قد ما تقدر.
- المسار A: Plus WebP أو AVIF + EWWW Image Optimizer (أو نصّب غير واحد منهم)
- المسار B: اختار واحد من ShortPixel / Imagify / TinyPNG
إلى خدمتي نفس الموقع كييديرو بزاف دالإضافات فآن واحد الضغط والتحويل لـ WebP أو AVIF وتبديل الروابط وإعادة كتابة التسليم كيزيدو يعقدو الأمور وكيصعب التتبع ديال المشاكل
2. ووردبريس ما كيدعمش بالفعل WebP/AVIF؟ واش مازال محتاج إضافة؟
خاصّك تفرّق بيناتهم:
“يدعم الرفع/الاستخدام ≠ التحويل التلقائي/التسليم التلقائي
حتى WordPress 6.5 ما غاديش يحوّل تلقائياً الصور القديمة JPG/PNG بشكل جماعي لـ WebP/AVIF، وما غاديش حتى يوفّر ليك تلقائياً السلسلة الكاملة ديال “إخراج AVIF/WebP حسب دعم المتصفح مع الرجوع للصيغة الأصلية”. إلا بغيتي حتى مكتبة الوسائط القديمة تواكب هاد الشي، غالباً خاصك إضافة أو خدمة تكمل هاد الجانب.
3. فاش كنديرو تحسين الصور، شنو هي الخطوة اللي كتعطي أكبر مردود؟
عادةً صلّح المقاس اللول (srcset/sizes)。
بزاف ديال المواقع ماشي بطيئة حيث ما داروش الضغط، ولكن حيث الصفحة كتبرز غير بـ 900px وكيخليو المستخدم يحمّل الصورة الأصلية ديال 3000px. الضغط يقدر يوفّر KB، ولكن إلا كان “القياس ما مناسبش” غادي تهبط بلا فايدة بيانات أكثر بعدة مرات.
4. كيفاش نأكد دابا باللي اللي كيتشارجا واش هي “النسخة الأصغر”، وماشي ديما كيتحمّل الأصل؟
شوفو جوج ديال الظواهر:
- عند فتح الصفحة من الهاتف، يكون حجم الصور المُنزَّلة أصغر بكثير من سطح المكتب
- نفس الصورة كيتحمّلو ليها أحجام موارد مختلفة حسب الجهاز
إلى كانت الصورة الأصلية كتتهبط ديما، فالسبب الغالب هو أن القالب/البيلدر كيعامل الصورة كخلفية CSS ولا بإخراج مخصص، وكيخلي مكتبة الوسائط وتعدد المقاسات وsrcset خارج الخدمة
واش “تم إنشاء WebP/AVIF” كتعني بالضرورة أن الواجهة الأمامية كتعرض WebP/AVIF؟
ما كيساويش.
التوليد غير كمّل غير فـ“طبقة الملفات”؛ واش الواجهة فعلاً كتسلّم WebP/AVIF كيبقى متعلق بإعادة الكتابة، واستراتيجية وسم picture، واش الكاش تْصاب، وواش تفاوض المتصفح خدام، وغير ذلك. منين تسالي خاصك ضروري “تدير فحص عشوائي لشي شوية ديال التصاور ديال نوع الموارد”.
6. فين كاين الخطر بالضبط فـ Plus WebP ولا AVIF؟ واش نقدر نشغّلهم على كامل المكتبة بكليك وحدة؟
مخاطرها ليست في “الضغط”، بل فيتعديلات على مستوى ترحيل الأصول:
- فاش كيدار التوليد الكامل، ممكن يتغطّى على ID ديال ملف الصورة الأصلي، ويتحيد الملف الأصلي، ويتبدلو روابط URL فالمحتوى.
لذلكما كننصحوش تبدّل الكل فقاعدة البيانات دفعة وحدة: جرّب الأول على نطاق صغير (شي عشرات حتى لمئات ديال الصور) + يكون عندك باكوب صالح، ومن بعد فكّر تعالج قاعدة البيانات كاملة.
7. كيفاش تختار بين جوج دالأنماط ديال Plus WebP: الاحتفاظ بالصورة الأصلية ولا الاستبدال والحذف ديال الصورة الأصلية؟
ببساطة:
- النمط 1: الاحتفاظ بالصورة الأصلية + إنشاء نسخة WebP/AVIF (أكثر استقرارا): ساهل فالرجوع لورا، ولكن الديسك غادي يعمر (الصورة الأصلية + الصيغة الجديدة + صور مصغرة بعدة أحجام).
- الوضع 2: بدّل وحيد الصورة الأصلية (أكثر جرأة): الديسك ما كيتنفخش بسهولة، ولكن ملي كتبدل الأصول + كتبدل المراجع، كترتافع تكلفة تشخيص مشاكل التوافق.
كلما كان الموقع أعقد (تجارة إلكترونية/إضافات كثيرة/مقاسات متعددة)، كان من الأفضل البدء بوضع أكثر استقرارًا
8. واش EWWW Image Optimizer المجاني فالضغط المحلي كافي؟ واش يقدر يطيّح السيرفر؟
EWWW كيشبه أكثر لواحد خدام محلي ديال الضغط: كياكل CPU/IO
فالغالب كيرتافع الحمل فالتحديث بالجملة، وهادشي ما كيعنيش باللي ما صالحش، غير خاص الاستراتيجية تكون صحيحة: على دفعات، فوقت الخفيف، وعند الحاجة اختار حل التفريغ/السحابة
إلى كنت باغي راحة البال، أو موارد السيرفر محدودة، فالمسار B كيوفر أكثر فموارد السيرفر.
علاش كنحسّ أن 100 كريدي مجانيين فالشهر ديال ShortPixel كيمشيو غير مع شي غير تصاور قليلة؟
بسبب الرصيد ماشي “عدد الصور”سيتم تكبيرها بواسطة الصورة المصغرة وnext-gen
- الصورة الأصلية + كل صورة مصغّرة كتتحسب كرصيد
- إلا تولّد WebP/AVIF، كل نسخة مقابلة غادي تستهلك حتى هي credit زيادة
يعني كتظنّ بلي “تصويرة وحدة”، ولكن فالحقيقة كتستهلك تقريباً “كريدي بزوج ديال الأرقام”. ShortPixel
علاش الباقة المجانية ديال Imagify ديال 20MB فالشهر كتسال بسرعة؟
Imagify كيشبه كثر لـ“باك دالأنترنيت”:
- بحال اللي رسلتيهالحجم الأصلي للملفخصم الحصة
- كلما زادت الصور المصغرة، زاد الاستهلاك
- عاود حسّن بعد تغيير مستوى الضغط، وغادي يستهلك الحصة مرة أخرى
- نفس مفتاح API مشترك بين عدة مواقع، والحصة مشتركة
لهذا “20MB كيكمّل بسرعة” غالباً كيكون بسبب الصور الكبيرة بزاف، أو كثرة الصور المصغّرة، أو كثرة المحاولات والتجارب المتكررة.
11. TinyPNG مجاني 500 رصيد/شهر، علاش البلاغين كايقول تقريباً غير 100 صورة/شهر، وملي كاتفعّل WebP/AVIF كايولي 50 صورة/شهر؟
حيت حتى الرصيد ديال TinyPNG كيتزاد بسبب “الحجم/النسخ المتغيرة”
- تثبيت ووردبريس العادي يضغط تقريباً حوالي 100 صورة في الشهر
- فعّل التحويل لـ AVIF ولا WebP:كل حجم صورة كيستهلك كريدي إضافيلذلك يمكن فقط ضغط وتحويل حوالي 50 صورة شهريًا تقريبًا (حسب عدد أحجام الصور المصغرة)
يعني 500 كريدي ماشي = 500 تصاور۔
12. شحال كاينين بالضبط ديال الصور المصغرة فالموقع ديالي؟ وعلاش كاتأثر بهاد الشكل الكبير؟
مني كترفع تصويرة فـ WordPress كيتصاوبو منها عدة قياسات؛ والثيمات/الإضافات، خصوصاً ديال التجارة الإلكترونية، يقدرو يزيدو قياسات أخرى.
الكريدي ديال الضغط السحابي ولا الحصص كيتحسبو غالبًا بـ“الصورة الأصلية + الصورة المصغرة مع بعض”، لذلك كلما كثر عدد الصور المصغرة كتسال الحصة المجانية بسرعة أكثر
13. واش التحميل الكسول كيقدر ديما يسرّع؟ علاش كاينين اللي كيقولو باللي التحميل الكسول بالعكس كيولّي أبطأ؟
التحميل الكسول مناسب لـ“الموارد اللي خارج الشاشة”.
إلا حتى الصورة الكبيرة والأهم فالشاشة اللولة تأخر تحميلها، يقدر هادشي يبطّأ تجربة الظهور الأول ديال الصفحة. من ووردبريس 5.5 ولات خاصية التحميل الكسول مفعلة افتراضياً، ما فيها باس، ولكن ما خاصّاش تطبّقها بطريقة موحّدة على كلشي.
14. إلا درت المسار A ولا B، إمتى كنحتاج CDN / الصورة CDN؟
الضغط، القياس، والصيغة كايحلو مشكل “الملف كيولي أصغر وأنسب”؛
CDN كتحلّ التوصيل أقرب وبثبات أكبر。
إلى كان جلب الصور من السيرفر الأصلي عن بُعد كيخلي التأخير باين بوضوح، من بعد زيد CDN/تصويرة CDN (بحال Cloudflare Polish / Jetpack Site Accelerator) باش يولي الأداء العام أكثر استقراراً وتجربة القراءة أحسن تسريع WordPress CDN。
15. من بعد ما نكمّل، شنو أسهل طريقة نتحقق بها باللي “خدام بصح”؟
أسرع طريقة للتحقق:
- إعادة تحميل الصفحة للمرة الثانية، واش كيولي التحميل أكثر استقرارًا وأسرع
- واش قياس الصورة اللي كيتحمّل فالتلفون والديسكتوب باين مختلف بوضوح (واش srcset/sizes خدامين)
- فحص بعض الصور: واش كاين ملفات/موارد WebP ولا AVIF
- شيك على شي تصاور عشوائياً: كبّر وشوف واش كاين تشويش باين ولا النص مغبّش