تحسين الصور

الخلاصة — يعني تحسين الصور تصغير ملفاتها كي تحمل الصفحات بسرعة من دون إفساد مظهرها. استخدم صيغة حديثة مثل WebP واضغط الملف ولا تقدم صورة أكبر بكثير من حجم عرضها على الشاشة. وأكثر قاعدة يخالفها الناس: يجب أن تحمل الصورة الكبيرة في أعلى الصفحة فورًا؛ فلا تطبق عليها التحميل الكسول أبدًا. لا يرفع ذلك ترتيبك بطريقة سحرية، ولا يضمن اجتياز اختبار السرعة؛ بل يجعل الصفحة أسرع، والسرعة هي المقصودة، لذلك تحقق من نتائجك الفعلية قبل التغيير وبعده.

ما الذي يفعله تحسين الصور فعلًا؟

تكون الصور في الغالب أثقل عناصر صفحة الويب. وتقول وثائق Google إنها “often the largest contributor to overall page size, which can make pages slow and expensive to load.” (الترجمة العربية) «غالبًا ما تكون أكبر مساهم في الحجم الإجمالي للصفحة، ما قد يجعل تحميل الصفحات بطيئًا ومكلفًا». لذلك يدور التحسين أساسًا حول تقليل البايتات التي يتعين على الزائر تنزيلها كي تظهر الصفحة بسرعة.

والمفاجأة هي أن الصيغة نفسها لا تمنح دفعة في الترتيب. لن يؤدي تحويل ملفات JPEG إلى WebP وحده إلى رفع مواقعك. لكنه يصغّر الملفات، فيسرّع الصفحة، والسرعة هي الفائدة. هذا المقال شقيق لدليل Image SEO الأوسع؛ يغطي الدليل الآخر alt وأسماء الملفات وبحث الصور، بينما يقدم هذا المقال خطوات جعل الصور سريعة التحميل.

الأمور القليلة التي تهم

• استخدم صيغة حديثة. تصغّر WebP وAVIF الملفات كثيرًا مقارنة بصيغتي JPEG وPNG القديمتين من دون تدهور ظاهر. وتعد WebP الخيار الافتراضي الآمن حاليًا.
• اضغط الملف. قد يكون ملف WebP كبيرًا أيضًا. مرر الصور عبر أداة ضغط وابحث عن النقطة التي يصغر عندها الملف مع بقاء مظهره جيدًا.
• لا تقدم صورة عملاقة في مساحة صغيرة. إذا عُرضت الصورة بعرض 500 بكسل فقط، فلا حاجة إلى ملف عرضه 3 000 بكسل؛ فهذا تنزيل مهدور.
• طبّق التحميل الكسول على الصور الواقعة أسفل الصفحة. تخبر إضافة loading="lazy" المتصفح أن ينتظر حتى يقترب المستخدم من الصورة قبل تحميلها، وهو مناسب للصور الواقعة خارج إطار العرض الأولي.
• لا تطبق التحميل الكسول على الصورة الكبيرة في الأعلى. أكبر صورة يراها المستخدم عند تحميل الصفحة هي غالبًا ما تقيس Google سرعة الصفحة على أساسه، ولذلك يجب أن تحمل فورًا.

الخطأ الذي يقع فيه معظم الناس

يطبقون التحميل الكسول على كل شيء، حتى صورة الواجهة في الأعلى. يبدو ذلك ذكيًا، أي «حمّل عناصر أقل»، لكنه يعكس المطلوب؛ فالصورة العليا هي غالبًا العنصر الذي يُقاس عليه أداء الصفحة، وتأخيرها يجعل النتيجة أسوأ. حمّلها مبكرًا وأخبر المتصفح بأنها مهمة. تشرح علامة التبويب المتقدمة الطريقة بدقة.

إذا أردت النسخة الدقيقة، بما فيها اقتباسات Google وصيغة المفاضلة بين WebP وAVIF وحساب الأبعاد وحيلة fetchpriority، فانتقل إلى علامة التبويب المتقدمة.

الخلاصة — تحسين الصور ممارسة تخص سرعة الصفحة وCore Web Vitals، وليس رافعة ترتيب مباشرة. يقلل اختيار الصيغة، مثل WebP أو AVIF، عدد البايتات لكنه لا يمنح دفعة SEO؛ وقد أكد Mueller ذلك بثلاث صيغ منفصلة. ووازن أيضًا بين الشفافية والحركة ودعم المتصفحات الحالي، لا نسبة الضغط فقط. أهم قاعدة هي: لا تطبق التحميل الكسول على صورة LCP، التي تكون عادة صورة الواجهة، لأن ذلك يؤخر المقياس نفسه الذي تحاول تحسينه. استخدم لها loading="eager" مع fetchpriority="high"، مع العلم أن تلميحات الأولوية تساعد فقط عندما تكون المشكلة في اكتشاف المورد أو توقيت جلبه، لا في كل مشكلات LCP. وخصص loading="lazy" للصور الواقعة خارج إطار العرض الأولي، لا أسفل خط بكسلات ثابت يسمى «الجزء المرئي». لا توجد جودة ضغط واحدة صحيحة دائمًا؛ اختبر كل نوع من الصور. وتساوي الأبعاد الصحيحة حجم حاوية العرض مضروبًا في نسبة بكسلات الجهاز، كما تتغير الحاوية مع التصميم المتجاوب؛ لذلك قدم نطاق srcset وsizes، لأن قيمة sizes الخاطئة قد تنزّل صورة أكبر من اللازم بصمت، مع بديل داخل <picture>. الصور أكثر عناصر LCP شيوعًا على الويب، ولهذا يُدرج المقال أيضًا ضمن أداء الويب؛ لكن لا يضمن شيء هنا اجتياز Core Web Vitals أو تغير الترتيب أو زيادة الزيارات، لذا قِس قبل التغيير وبعده.

ما الهدف من تحسين الصور؟ ابدأ بتصحيح الخرافة

لنصحح أكبر خرافة أولًا: صيغة الصورة رافعة للسرعة، وليست رافعة للترتيب. لا يمنحك التحويل إلى WebP أو AVIF زيادة في الترتيب؛ بل يمنحك ملفات أصغر تؤدي إلى صفحة أسرع، ما يؤثر في Core Web Vitals، وهذا هو الجزء الذي تستخدمه أنظمة البحث. العلاقة حقيقية لكنها غير مباشرة، والخطأ الذي تقع فيه معظم أدلة المنافسين هو اختزالها في قول «الصيغ الحديثة ترتب أفضل».

توضح وثائق Google سبب أهمية الصور للسرعة: فهي “often the largest contributor to overall page size, which can make pages slow and expensive to load,” (الترجمة العربية) «غالبًا ما تكون أكبر مساهم في الحجم الإجمالي للصفحة، ما قد يجعل تحميل الصفحات بطيئًا ومكلفًا»، وتنصح بأن “apply the latest image optimization and responsive image techniques to provide a high quality and fast user experience” (الترجمة العربية) «تطبق أحدث تقنيات تحسين الصور والصور المتجاوبة لتقديم تجربة مستخدم عالية الجودة وسريعة» (Google Search Central — الصور). لاحظ أن التأطير يتعلق بسرعة تجربة المستخدم، لا بمكافأة ترتيب تمنحها صيغة الملف.

أما شرح ماهية Image SEO وسبب أهميته عمومًا، بما يشمل alt وأسماء الملفات وخرائط مواقع الصور والبيانات المنظمة والترتيب في بحث الصور، فهو مهمة دليل Image SEO الرئيسي. وهذا المقال هو المرجع العملي للكيفية: الصيغ والضغط والأبعاد واستراتيجية التحميل.

ابدأ بالقاعدة التي يخالفها الجميع: لا تطبق التحميل الكسول على صورة LCP

إذا خرجت بفكرة واحدة من هذه الصفحة فلتكن هذه. عنصر Largest Contentful Paint (LCP)، أي أكبر عنصر يُرسم في إطار العرض عند التحميل، يكون وفق web.dev “either an image or a web font,” (الترجمة العربية) «إما صورة أو خط ويب» (تحسين LCP), ويكون صورة في معظم الصفحات: صورة الواجهة أو الصورة البارزة أو صورة المنتج. ويصوغ web.dev القاعدة بوضوح شديد:

“Never lazy-load your LCP image, as that will always lead to unnecessary resource load delay, and will have a negative impact on LCP.” (الترجمة العربية) «لا تطبق التحميل الكسول أبدًا على صورة LCP؛ لأن ذلك يؤدي دائمًا إلى تأخير غير ضروري في تحميل المورد ويؤثر سلبًا في LCP».

هذه هي الدقة التي تغفلها نصائح «استخدم التحميل الكسول» العامة. فالتحميل الكسول ممتاز للصور الواقعة خارج إطار العرض الأولي. أما تطبيقه على صورة LCP فيؤخر المقياس نفسه الذي تحاول تحسينه. وتقول إرشادات web.dev للتحميل الكسول الشيء نفسه من الاتجاه الآخر: “Don’t lazy-load images that are likely to be in-viewport when the page loads, especially LCP images” (الترجمة العربية) «لا تطبق التحميل الكسول على الصور المرجح ظهورها داخل إطار العرض عند تحميل الصفحة، وخصوصًا صور LCP» (التحميل الكسول على مستوى المتصفح).

قدمت الحجة نفسها في مقالي عن LCP على Ahrefs: أكبر عنصر “is usually going to be a featured image or maybe the <h1> tag,” (الترجمة العربية) «يكون عادة صورة بارزة أو ربما وسم <h1>»، ومن ذلك تتبع الحلول. فـ*“If you don’t need the image, the most impactful solution is to simply get rid of it. If you must have the image, I suggest optimizing the size and quality to keep it as small as possible.”* (الترجمة العربية) «إذا لم تكن بحاجة إلى الصورة، فأكثر الحلول أثرًا هو حذفها ببساطة. وإذا كان لا بد منها، فأقترح تحسين حجمها وجودتها لإبقائها صغيرة قدر الإمكان». وينبغي أن “lazy load any images that you don’t need immediately” (الترجمة العربية) «تطبق التحميل الكسول على أي صور لا تحتاج إليها فورًا»، لكن الوجه الآخر قاعدة مشددة لسبب وجيه: “Do not lazy load images above the fold!” (الترجمة العربية) «لا تطبق التحميل الكسول على الصور الواقعة في إطار العرض الأولي».

استخدم fetchpriority="high" لصورة LCP

عدم تطبيق التحميل الكسول على صورة الواجهة ضروري لكنه غير كافٍ. ولكي تحمل صورة LCP في أبكر وقت ممكن، أعط المتصفح تلميحًا إلى أولويتها. يقول web.dev:

“You can hint to the browser as to which resources are most important using the fetchpriority attribute… It’s a good idea to set fetchpriority=\"high\" on an <img> element if you think it’s likely to be your page’s LCP element.” (الترجمة العربية) «يمكنك إرشاد المتصفح إلى أهم الموارد باستخدام سمة fetchpriority… ومن الجيد ضبط fetchpriority="high" في عنصر <img> إذا رجحت أنه عنصر LCP في صفحتك».

<img src="/hero.webp" alt="…" fetchpriority="high" width="1200" height="675">

أصف fetchpriority="high" بالطريقة نفسها في مقالي عن LCP: إذ “can be used on <img> or <link> tags and tells browsers to get the image early” (الترجمة العربية) «يمكن استخدامه في وسمي <img> أو <link> ويطلب من المتصفحات جلب الصورة مبكرًا». وأقرنه أيضًا بـEarly Hints، أي استجابة 103، بوصفها طريقة مكملة لبدء الجلب حتى قبل وصول HTML الرئيسي. لذلك وصفة LCP هي: التحميل المبكر مع fetchpriority="high"، وإضافة Early Hints إن كانت بنيتك تدعمها. ويمكن لبقية الصور الواقعة خارج إطار العرض الأولي استخدام التحميل الكسول.

تعامل مع fetchpriority والتحميل المسبق بوصفهما أداتين لمشكلة محددة، لا حلًا مضمونًا. فهما يساعدان عندما تُكتشف صورة LCP أو تُجلب متأخرة، لكنهما لا يعالجان بطء استجابة الخادم أو موردًا يحجب العرض قبل الصورة أو ملفًا كبيرًا فعلًا. حدد عنق الزجاجة الحقيقي أولًا؛ إذ يقسم PageSpeed Insights أو Lighthouse زمن LCP إلى أجزائه الفرعية، ولا تفترض أن تلميح الأولوية وحده سيغير النتيجة.

loading="lazy" الأصلي: مجاني وبسيط وصحيح خارج إطار العرض الأولي

يعد التحميل الكسول الأصلي أسهل مكسب في الأداء لكل صورة لا تقع ضمن إطار العرض الأولي. يقول web.dev: “You can use the loading attribute to lazy-load images without the need to write custom lazy-loading code or use a separate JavaScript library.” (الترجمة العربية) «يمكنك استخدام سمة loading لتطبيق التحميل الكسول على الصور من دون كتابة شيفرة مخصصة أو استخدام مكتبة JavaScript منفصلة».

<img src="/below-the-fold.webp" alt="…" loading="lazy" width="800" height="600">

يحافظ أمران على سلامة التطبيق:

• استند إلى إطار العرض الأولي، لا إلى خط ثابت يسمى «الجزء المرئي». فهذا الحد ليس عددًا ثابتًا من البكسلات؛ بل يتغير مع حجم إطار العرض والتخطيط. والاختبار الحقيقي هو احتمال ظهور الصورة عند الرسم الأول للصفحة. كل صورة مرجح ظهورها، وخصوصًا صورة LCP، تستخدم loading="eager"، وهو الافتراضي، ولا تستخدم lazy.
• فضّل السمة الأصلية على حلول JavaScript الملتوية. قد لا تفهرس الزواحف الصور إذا أخفت أدوات JavaScript عنوان URL الحقيقي في data-src ولم تعرض src مطلقًا. يحافظ loading="lazy" الأصلي، أو تطبيق نظيف لـIntersectionObserver، على ظهور src للزواحف. ويشرح دليل Image SEO الرئيسي هذه الدقة المتعلقة بالفهرسة كاملة.

الصيغ الحديثة: WebP مقابل AVIF مقابل JPEG وPNG

تظهر أهمية تصحيح الخرافات أكثر ما تظهر في الصيغ، لذلك ينبغي توضيح ما تمنحه كل صيغة بدقة: بايتات أقل، لا ترتيبًا أعلى.

• WebP — “often has better compression than JPEG, PNG, or GIF, offering both lossy and lossless compression” (الترجمة العربية) «غالبًا ما توفر ضغطًا أفضل من JPEG أو PNG أو GIF، وتتيح الضغط المنقوص وغير المنقوص» (web.dev — أداء الصور). تكون أصغر من JPEG بنحو 25–35% مع دعم شبه شامل في المتصفحات، ولذلك تعد الخيار الافتراضي الآمن للصور الفوتوغرافية حاليًا.
• AVIF — “supports both lossy and lossless compression, and tests have shown greater than 50% savings when compared to JPEG in some cases.” (الترجمة العربية) «تدعم الضغط المنقوص وغير المنقوص، وقد أظهرت الاختبارات توفيرًا يتجاوز 50% مقارنة بـJPEG في بعض الحالات». تقدم أفضل ضغط، لكن دعمها أقل شمولًا قليلًا؛ لذلك استخدم معها بديل WebP أو JPEG.
• JPEG — البديل واسع الدعم للصور الفوتوغرافية.
• PNG — مناسب عندما تحتاج إلى الشفافية أو رسومات ذات حواف حادة.
• SVG — للشعارات والأيقونات؛ صيغة متجهة تتدرج بلا حدود وملفاتها صغيرة.

يعتمد اختيار الصيغة أيضًا على وظيفة الصورة، لا على أقصى ضغط فقط. فالشفافية والحركة ومدى ثبات دعم المتصفح أو الأداة لهذه المجموعة من الخصائص عوامل مهمة إلى جانب مقدار التوفير في الحجم. تحقق من الدعم الحالي للميزة المحددة التي تحتاج إليها، وخصوصًا الصور المتحركة، قبل اعتماد صيغة واحدة افتراضية.

يدعم بحث Google صيغ “BMP, GIF, JPEG, PNG, WebP, SVG, and AVIF” (الترجمة العربية) «BMP وGIF وJPEG وPNG وWebP وSVG وAVIF» المشار إليها في src لعنصر <img>. قدم الصيغة الحديثة مع بديل سلس باستخدام <picture>:

<picture>
  <source srcset="/photo.avif" type="image/avif">
  <source srcset="/photo.webp" type="image/webp">
  <img src="/photo.jpg" alt="…" width="1200" height="800" loading="lazy">
</picture>

يمثل <img src> في الأسفل شبكة الأمان؛ إذ تعود إليه المتصفحات والزواحف الأقدم، وهو عنوان URL الذي تفهرسه Google فعلًا.

هل تؤثر الصيغة في الترتيب؟ لا، وقد قال Mueller ذلك بثلاث طرق

هذه أهم خرافة ينبغي تصحيحها في الموضوع كله. تتفق ثلاث تصريحات منفصلة لـJohn Mueller، صدرت في أوقات مختلفة، على خلاصة واحدة: تؤثر الصيغة في آليات الزحف والفهرسة ووزن الصفحة، لكنها لا تؤثر مباشرة في الترتيب:

1. لا تمنح AVIF دفعة SEO. بعدما أضافت Google دعم AVIF الأصلي، أكد Mueller عدم وجود “SEO boost” (الترجمة العربية) «دفعة SEO» لاستخدام AVIF بدل الصيغ الأخرى المدعومة (تغطية SE Roundtable).
2. WebP «مقبولة». “WebP images are fine for Image Search” (الترجمة العربية) «صور WebP مناسبة لبحث الصور»؛ أي مناسبة، لا «أفضل» (تغطية SE Roundtable).
3. مشكلات فهرسة WebP ليست خاصة بالصيغة. عندما ظهرت ملفات WebP في GSC بالحالة “Crawled – currently not indexed” (الترجمة العربية) «تم الزحف إليها، وهي غير مفهرسة حاليًا»، أوضح Mueller أن ملفات الصور لا تُفهرس كصفحات HTML، ولم يعتقد أن الظاهرة تقتصر على WebP (تغطية SEJ).

الضغط والجودة: لا يوجد إعداد واحد «صحيح» دائمًا

أكثر النصائح السيئة شيوعًا في أدلة الصور هي عبارة واحدة مثل «اضغط إلى 80%». ويوضح web.dev أنه لا يوجد رقم سحري من هذا النوع:

“When compressing, there isn’t a universal setting suitable for all cases. The recommended approach would be to experiment with different compression levels until you find a good compromise between image quality and file size.” (الترجمة العربية) «عند الضغط، لا يوجد إعداد عام مناسب لجميع الحالات. والمنهج الموصى به هو تجربة مستويات ضغط مختلفة حتى تجد توازنًا جيدًا بين جودة الصورة وحجم الملف».

عمليًا: اختبر كل نوع من الصور على حدة. تتحمل الصور الفوتوغرافية الضغط المنقوص القوي جيدًا، بينما تظهر العيوب سريعًا في الرسومات والشعارات ولقطات الشاشة التي تحتوي نصًا، وغالبًا تحتاج إلى ضغط غير منقوص أو إعداد جودة أعلى. بدل الوثوق بمنزلق واحد، صدّر الصورة نفسها بمستويين أو ثلاثة من الجودة وافحصها بحجم العرض؛ وأصغر نسخة لا تستطيع تمييزها بصريًا عن الأصل هي الإجابة المناسبة. هذه آلية عمل حقيقية، لا مجرد «مررها عبر TinyPNG وتمنَّ الأفضل».

الأبعاد الصحيحة: حجم الحاوية × نسبة بكسلات الجهاز

ليست القاعدة «صغّرها فحسب»، بل طابق حجم العرض مع نسبة بكسلات الجهاز (DPR). يقول web.dev:

“An image displayed in a 500 pixel by 500 pixel container would be optimally sized at 500 pixels by 500 pixels.” (الترجمة العربية) «يكون الحجم الأمثل لصورة معروضة في حاوية أبعادها 500 بكسل × 500 بكسل هو 500 بكسل × 500 بكسل».

“If the device has a DPR of 2 and the image is displayed in a 500 pixel by 500 pixel container, then a square 1000 pixel image… is now the optimal size.” (الترجمة العربية) «إذا كانت نسبة بكسلات الجهاز 2 وعُرضت الصورة في حاوية 500 × 500 بكسل، تصبح صورة مربعة أبعادها 1000 بكسل هي الحجم الأمثل».

إذًا تحتاج حاوية 500×500 على شاشة بنسبة 2×، مثل شاشات Retina، إلى مصدر 1 000×1 000. وإذا تجاوزته هُدرت البايتات من دون مكسب مرئي، وإذا نقصت عنه بدت الصورة ضبابية على الشاشات عالية DPR. ولهذا تقدم نطاقًا من الأحجام وتدع المتصفح يختار باستخدام srcset وsizes:

<img
  src="/photo-800.webp"
  srcset="/photo-400.webp 400w, /photo-800.webp 800w, /photo-1600.webp 1600w"
  sizes="(max-width: 600px) 100vw, 500px"
  alt="…" width="800" height="600" loading="lazy">

يقرأ المتصفح عرض الحاوية من sizes ونسبة DPR لديه، ثم يختار المرشح المناسب من srcset؛ وهذه هي النسخة المتجاوبة من حساب DPR أعلاه. وتوصي Google باستخدام <picture> أو srcset للصور المتجاوبة، وتقول: “always specify a fallback URL using the src attribute.” (الترجمة العربية) «حدد دائمًا عنوان URL بديلًا باستخدام سمة src».

لن يحذرك شيء إذا أخطأت في sizes. فإذا لم تطابق القيمة التي تعلنها العرض الفعلي للصورة، وهو خطأ شائع بعد تغيير التخطيط أو CSS، فلن يعرف المتصفح ذلك وسيختار مرشحًا بناء على الرقم غير الدقيق الذي أعطيته، ما يعني عادة تنزيل ملف أكبر من حاجة التخطيط. وهذا يبطل عمل الصيغة والضغط أعلاه بصمت. والطريقة الموثوقة لاكتشافه هي فتح لوحة Network في DevTools والعثور على طلب الصورة ومقارنة أبعاد الملف المقدم بالعرض الفعلي للحاوية.

مثال 500×500 أعلاه توضيحي، لا رقم ثابتًا ينبغي تطبيقه على الموقع كله. فقد تُعرض صورة الواجهة نفسها بعرض مختلف على الهاتف وسطح المكتب، ولذلك يتحرك «حجم الحاوية» مع التخطيط المتجاوب بدل بقائه ثابتًا. وهذا هو سبب تقديم نطاق srcset بدل تصدير حجم «مثالي» واحد والاكتفاء به.

لماذا يرتبط كل ذلك بـCore Web Vitals؟

الخيط الذي يصل كل التقنيات السابقة هو LCP. الصور أكثر عناصر LCP شيوعًا على الويب، وLCP أحد مقاييس Core Web Vitals الثلاثة. وهدف Google هو أن “LCP should occur within 2.5 seconds” (الترجمة العربية) «يحدث LCP خلال 2,5 ثانية» عند المئين الخامس والسبعين لتحميلات الصفحة على الهاتف وسطح المكتب (web.dev — Web Vitals). وتقول إن Core Web Vitals “apply to all web pages, should be measured by all site owners, and will be surfaced across all Google tools.” (الترجمة العربية) «تنطبق على جميع صفحات الويب، وينبغي لكل مالكي المواقع قياسها، وستظهر في جميع أدوات Google».

لذلك لا يمثل تحسين الصور عامل ترتيب منفصلًا؛ بل هو مساهم في إشارة تجربة الصفحة، أي Core Web Vitals، التي تستخدمها أنظمة الترتيب. وهذا هو التأطير الدقيق، وهو سبب وجود المقال في مجموعتي Image SEO وأداء الويب. وللتعمق في المقياس نفسه، راجع Core Web Vitals وLCP ضمن أداء الويب.

ويجب قول تحذير إضافي بوضوح: لا يضمن أي إصلاح في هذه الصفحة نتيجة بعينها. فبايتات الصور مجرد مكوّن محتمل من LCP؛ ويشمل تقسيم web.dev لأجزاء LCP زمن استجابة الخادم والموارد التي تحجب العرض قبل الصورة، وهي أمور لا تمسها الصيغة أو الضغط. كما أن أبعاد الصور مجرد مدخل واحد في CLS، وليست ضمانًا لنتيجة محددة. قد يساعد تصغير صورة الواجهة بدرجة قابلة للقياس، أو لا يفعل شيئًا، أو يحرك الرقم قليلًا إذا كان عنق الزجاجة الحقيقي في مكان آخر. كذلك لا يضمن تحسين الصور وحده اجتياز Core Web Vitals أو تغير الترتيب أو زيادة الزيارات أو التحويلات أو الاستشهاد في بحث الذكاء الاصطناعي؛ فكل ذلك يعتمد على ما هو أكثر من بايتات الصور. تعامل مع كل إصلاح بوصفه فرضية لا نتيجة محسومة: قِس LCP وCLS قبل التغيير وبعده في المختبر والميدان، ودع البيانات، لا افتراض نجاح التحسين، تخبرك بما تغير.

أخطاء شائعة في التنفيذ

• لا تفهرس Google صور خلفية CSS. يستبدل المطورون أحيانًا <img> بـbackground-image لتسهيل التخطيط. وتقول Google إنها “can find images in the src attribute of <img> element (even when it’s a child of other elements, such as the <picture> element)” (الترجمة العربية) «تستطيع العثور على الصور في سمة src لعنصر <img> حتى عندما يكون تابعًا لعناصر أخرى مثل <picture>»، لكنها “doesn’t index CSS images.” (الترجمة العربية) «لا تفهرس صور CSS». فإذا أردت ظهور الصورة في بحث الصور، فأبقها في <img>.
• لا تعِد تسمية الملفات المنشورة بالجملة ضمن «تحديث» للأداء أو SEO. قال Mueller إن أنظمة Google تحتاج “a lot of time” (الترجمة العربية) «وقتًا طويلًا» لمعالجة الصور المعاد تسميتها، وإن الأثر ضئيل إذا كان السياق جيدًا أصلًا؛ ويشرح دليل Image SEO الرئيسي ذلك كاملًا.
• لا تهمل width وheight. حدد دائمًا width وheight الأصليين، أو استخدم aspect-ratio في CSS، كي يحجز المتصفح المساحة قبل تحميل الصورة. يقلل ذلك تغير التخطيط الناتج عن الصور، لكنه مجرد مدخل في CLS وليس ضمانًا لنتيجة محددة.

وصفة سريعة

• صورة الواجهة أو LCP: صيغة حديثة وحجم مناسب وloading="eager" وfetchpriority="high".
• كل ما يقع خارج إطار العرض الأولي: loading="lazy".
• قدم WebP أو AVIF داخل <picture> مع بديل src.
• طابق الحجم مع الحاوية × DPR، وقدم نطاق srcset مع sizes.
• اضغط حسب نوع الصورة؛ اختبر مستويين أو ثلاثة من الجودة ولا تثق بمنزلق واحد.
• حدد width وheight دائمًا.

ولبقية موضوع Image SEO، بما فيه alt وأسماء الملفات وخرائط مواقع الصور والبيانات المنظمة والترتيب في بحث الصور، ارجع إلى دليل Image SEO الرئيسي.

ملخص الذكاء الاصطناعي

خلاصة مكثفة للنسخة المتقدمة:

• تحسين الصور يعني السرعة، لا رفع الترتيب مباشرة. يقلل اختيار WebP أو AVIF البايتات، فتسرع الصفحة وتتحسن Core Web Vitals. ولا تمنح الصيغة نفسها دفعة ترتيب مباشرة؛ وقد أكد Mueller ذلك بثلاث طرق: لا “SEO boost” لـAVIF، وWebP “fine”، ومشكلات فهرسة WebP ليست خاصة بالصيغة.
• القاعدة الأولى: لا تطبق التحميل الكسول على صورة LCP. الصورة المرجح ظهورها عند الرسم الأول، وهي عادة صورة الواجهة، تحدد LCP؛ وتأخيرها يؤخر المقياس نفسه. استخدم loading="eager" وfetchpriority="high"، مع إمكانية Early Hints، لكن تلميحات الأولوية تعالج فقط تأخر الاكتشاف أو الجلب، لا كل مشكلات LCP.
• loading="lazy" الأصلي مجاني وصحيح للصور خارج إطار العرض الأولي، لا تحت خط بكسلات ثابت. وتجنب أدوات JavaScript التي تخفي URL في data-src.
• الصيغ: WebP خيار افتراضي آمن وأصغر من JPEG بنحو 25–35%، وقد توفر AVIF أكثر من 50% في بعض الاختبارات مع بديل. ويعتمد الاختيار أيضًا على الشفافية والحركة ودعم المتصفح أو الأداة. استخدم <picture> مع بديل <img src> تفهرسه Google.
• الضغط: لا توجد جودة واحدة صحيحة دائمًا؛ اختبر كل نوع من الصور، فالصور الفوتوغرافية تتحمل ضغطًا قويًا، بينما تظهر العيوب سريعًا في النصوص والرسومات.
• الأبعاد: الحجم الصحيح هو حجم الحاوية المعروضة × نسبة بكسلات الجهاز؛ فحاوية خمسمئة بكسل عند DPR قدره 2 تحتاج مصدرًا 1 000 بكسل. ولأن عرض الحاوية يتغير مع التصميم المتجاوب، قدم نطاقًا عبر srcset وsizes. وقد تؤدي قيمة sizes الخاطئة إلى تنزيل مرشح أكبر من اللازم بصمت.
• سبب الأهمية: الصور أكثر عناصر LCP شيوعًا، والهدف أن يحدث LCP خلال 2,5 ثانية عند المئين 75. لكن لـLCP أجزاء أخرى، مثل استجابة الخادم والموارد التي تحجب العرض، لا تصلحها بايتات الصور وحدها.
• لا ضمانات: لا يضمن التحسين اجتياز Core Web Vitals أو تغير الترتيب أو زيادة الزيارات أو التحويلات أو الاستشهاد في بحث الذكاء الاصطناعي. قِس LCP وCLS قبل التغيير وبعده في المختبر والميدان.
• أخطاء التنفيذ: لا تفهرس Google background-image في CSS؛ ولا تعِد تسمية الملفات بالجملة؛ وحدد width وheight دائمًا لتقليل تغير التخطيط من دون الادعاء بضمان نتيجة CLS.

الوثائق الرسمية

وثائق من المصادر الأولية لمحركات البحث وفريق Chrome.

Google / web.dev

• أداء الصور — الصيغ وعدم وجود إعداد ضغط عام وحساب أبعاد DPR.
• التحميل الكسول للصور على مستوى المتصفح — آلية loading="lazy" الأصلي واستثناء الصور الواقعة في إطار العرض أو صور LCP.
• تحسين LCP — fetchpriority، وكون مورد LCP صورة أو خطًا، وقاعدة عدم تطبيق التحميل الكسول على صورة LCP.
• Fetch Priority API — شرح fetchpriority="high" لصور LCP.
• Web Vitals — تعريفات Core Web Vitals وعتبة LCP البالغة ≤ 2,5 ثانية عند المئين 75.
• أفضل ممارسات Google للصور — الصيغ المدعومة وفهرسة <img> و<picture> دون خلفيات CSS والصور المتجاوبة وضرورة بديل src.

Bing / Microsoft

• لا تنشر Bing دليلًا تقنيًا خاصًا بتحسين الصور بمستوى تفصيل دليل Google؛ وتظهر الإرشادات ذات الصلة ضمن إرشادات Bing لمشرفي المواقع، التي تتعامل مع سرعة الصفحة، ومنها وزن الصور، بوصفها اعتبارًا. أذكر هذه الفجوة بصراحة بدل اختلاق «اقتباس» من Bing.
• Bing Visual Search — البحث المرئي على مستوى العناصر، وهو متعلق باكتشاف الصور ومنفصل عن آثار الصيغة والضغط في سرعة الصفحة.

اقتباسات من المصادر

تصريحات موثقة من فريق Chrome في Google وممثلي البحث. وعندما تعرض الصفحة النص، ينقلك الرابط مباشرة إلى موضع الاقتباس.

web.dev، فريق Google Chrome — قواعد LCP

• “Never lazy-load your LCP image, as that will always lead to unnecessary resource load delay, and will have a negative impact on LCP.” (الترجمة العربية) «لا تطبق التحميل الكسول أبدًا على صورة LCP؛ لأن ذلك يؤدي دائمًا إلى تأخير غير ضروري في تحميل المورد ويؤثر سلبًا في LCP». الاقتباس
• “Don’t lazy-load images that are likely to be in-viewport when the page loads, especially LCP images.” (الترجمة العربية) «لا تطبق التحميل الكسول على الصور المرجح ظهورها داخل إطار العرض عند تحميل الصفحة، وخصوصًا صور LCP». الاقتباس
• “It’s a good idea to set fetchpriority=\"high\" on an <img> element if you think it’s likely to be your page’s LCP element.” (الترجمة العربية) «من الجيد ضبط أولوية الجلب على المستوى المرتفع في عنصر الصورة إذا رجحت أنه عنصر LCP في صفحتك». — web.dev، تحسين LCP.

web.dev، فريق Google Chrome — الصيغ والضغط والأبعاد

• “WebP often has better compression than JPEG, PNG, or GIF, offering both lossy and lossless compression.” (الترجمة العربية) «غالبًا ما توفر WebP ضغطًا أفضل من JPEG أو PNG أو GIF، وتتيح الضغط المنقوص وغير المنقوص». الاقتباس
• “AVIF supports both lossy and lossless compression, and tests have shown greater than 50% savings when compared to JPEG in some cases.” (الترجمة العربية) «تدعم AVIF الضغط المنقوص وغير المنقوص، وقد أظهرت الاختبارات توفيرًا يتجاوز 50% مقارنة بـJPEG في بعض الحالات». — web.dev، أداء الصور.
• “When compressing, there isn’t a universal setting suitable for all cases. The recommended approach would be to experiment with different compression levels until you find a good compromise between image quality and file size.” (الترجمة العربية) «لا يصلح إعداد ضغط واحد لكل الحالات؛ والمنهج الموصى به هو تجربة درجات متعددة حتى تحقق موازنة مناسبة بين جودة الصورة وحجم ملفها». — web.dev، أداء الصور.
• “An image displayed in a 500 pixel by 500 pixel container would be optimally sized at 500 pixels by 500 pixels.” (الترجمة العربية) «يكون الحجم الأمثل لصورة معروضة في حاوية 500 × 500 بكسل هو 500 × 500 بكسل». … “If the device has a DPR of 2 … then a square 1000 pixel image … is now the optimal size.” (الترجمة العربية) «إذا كانت نسبة بكسلات الجهاز 2، تصبح صورة مربعة أبعادها 1000 بكسل هي الحجم الأمثل». — web.dev، أداء الصور.

Google Search Central — سبب أهمية الصور للسرعة

• “images are often the largest contributor to overall page size, which can make pages slow and expensive to load.” (الترجمة العربية) «غالبًا ما تكون الصور أكبر مساهم في الحجم الإجمالي للصفحة، ما قد يجعل تحميل الصفحات بطيئًا ومكلفًا». الاقتباس

web.dev — Core Web Vitals

• “Core Web Vitals are the subset of Web Vitals that apply to all web pages, should be measured by all site owners, and will be surfaced across all Google tools.” (الترجمة العربية) «Core Web Vitals هي مجموعة Web Vitals الفرعية التي تنطبق على جميع صفحات الويب، وينبغي لكل مالكي المواقع قياسها، وستظهر في جميع أدوات Google». الاقتباس

John Mueller من Google — الصيغة ليست رافعة ترتيب

• عن AVIF: لا توجد “SEO boost” (الترجمة العربية) «دفعة SEO» لاستخدام ملفات AVIF. التغطية
• عن WebP: “WebP images are fine for Image Search.” (الترجمة العربية) «صور WebP مناسبة لبحث الصور». التغطية

قائمة تدقيق تحسين الصور

نفذ هذه الجولة في كل صفحة حساسة للأداء:

• حددت صورة LCP، وهي عادة صورة الواجهة أو الصورة البارزة أو أول صورة منتج.
• صورة LCP لا تستخدم التحميل الكسول؛ بل تستخدم loading="eager"، وهو الافتراضي.
• تحمل صورة LCP السمة fetchpriority="high"، مع النظر في Early Hints إذا كانت بنيتك تدعمها.
• كل صورة خارج إطار العرض الأولي تستخدم loading="lazy".
• تقدم صيغة حديثة، WebP افتراضيًا وAVIF حيث تدعم، مع بديل src داخل <picture>.
• حجم كل صورة يطابق حاويتها × نسبة بكسلات الجهاز؛ فلا تقدم ملفًا عرضه 3 000 بكسل في مساحة خمسمئة بكسل.
• تستخدم srcset وsizes عندما تُعرض الصور بعروض مختلفة.
• اختبرت الضغط حسب نوع الصورة بمقارنة مستويين أو ثلاثة من الجودة عند حجم العرض، لا بإعداد شامل واحد.
• حددت width وheight الأصليين، أو aspect-ratio في CSS، لكل صورة لتقليل تغير التخطيط، من دون الادعاء بضمان نتيجة CLS.
• لا توجد صورة محتوى داخل background-image في CSS فقط، لأن Google لا تفهرسها.
• يستخدم التحميل الكسول السمة الأصلية، أو IntersectionObserver نظيفًا، لا حل JavaScript يخفي URL في data-src.
• تحققت من LCP في بيانات الميدان عبر CrUX أو PageSpeed Insights، مستهدفًا ≤ 2,5 ثانية عند المئين 75.

ورقة مرجعية لتحسين الصور

الأدوات: وظيفة كل منها وأفضل ممارسة

حقائق سريعة

• الصيغة رافعة سرعة لا ترتيب؛ لا “SEO boost” لـAVIF وWebP “fine”.
• WebP أصغر من JPEG بنحو 25–35%، وقد تكون AVIF أصغر بأكثر من 50% في الاختبارات.
• أهم قاعدة: لا تطبق التحميل الكسول على صورة LCP.
• هدف LCP: ≤ 2,5 ثانية عند المئين 75 على الهاتف وسطح المكتب.
• الصيغ المدعومة: BMP وGIF وJPEG وPNG وWebP وSVG وAVIF.
• الحجم الصحيح = حجم الحاوية المعروضة × نسبة بكسلات الجهاز.

الخطأ الذي يفسد نتيجة LCP

تطبيق التحميل الكسول على صورة الواجهة هو أعلى الأخطاء كلفة في هذا المقال، ويستحق التنبيه إليه منفردًا قبل بقية الأخطاء.

• الخطأ: إضافة loading="lazy"، أو أداة JavaScript للتحميل الكسول، إلى أكبر صورة في إطار العرض الأولي، وهي عادة صورة الواجهة أو الصورة البارزة أو أول صورة منتج. سبب الخطأ: تكون هذه الصورة في الغالب عنصر LCP، ويقول web.dev بوضوح إن تحميلها الكسول “will always lead to unnecessary resource load delay, and will have a negative impact on LCP.” (الترجمة العربية) «سيؤدي دائمًا إلى تأخير غير ضروري في تحميل المورد ويؤثر سلبًا في LCP». وهكذا تؤخر المقياس نفسه الذي تحاول تحسينه. البديل: استخدم لصورة LCP loading="eager"، وهو الافتراضي، مع fetchpriority="high"، وخصص loading="lazy" للصور الواقعة خارج إطار العرض الأولي.

الثقة في إعداد ضغط شامل واحد

• الخطأ: تمرير كل الصور عبر الإعداد نفسه، مثل «اضغط إلى 80%»، بصرف النظر عن محتواها. سبب الخطأ: يقول web.dev صراحة “there isn’t a universal setting suitable for all cases” (الترجمة العربية) «لا يوجد إعداد عام مناسب لجميع الحالات». فالإعداد المناسب للصور الفوتوغرافية قد يفرط في ضغط الشعارات ولقطات الشاشة والرسومات كثيرة النص حتى تظهر عيوب مرئية. البديل: صدّر الصورة نفسها بمستويين أو ثلاثة من الجودة وقارنها بحجم العرض الفعلي؛ واختر أصغر نسخة لا تستطيع تمييزها عن الأصل، لكل نوع من الصور.

تحديد الحجم انطلاقًا من الملف المتاح لا من الحاوية

• الخطأ: تقديم الدقة الموجودة في الملف الأصلي، أو حجم ثابت واحد لكل التخطيطات، بدل مطابقة الصورة لمساحة عرضها الفعلية. سبب الخطأ: وفق حساب web.dev، يساوي الحجم الصحيح حجم الحاوية المعروضة × نسبة بكسلات الجهاز؛ فحاوية 500×500 عند DPR قدره 2 تحتاج مصدرًا 1 000×1 000، لا 500×500 ولا 3 000×3 000. والحجم الأكبر يهدر البايتات بلا مكسب مرئي، والأصغر يبدو ضبابيًا على الشاشات عالية DPR. البديل: قدم نطاق srcset مع sizes كي يختار المتصفح المرشح المناسب للحاوية والجهاز.

إخفاء صور المحتوى الحقيقية خلف CSS

• الخطأ: استبدال <img> بـbackground-image لتسهيل التخطيط. سبب الخطأ: تقول Google إنها “doesn’t index CSS images” (الترجمة العربية) «لا تفهرس صور CSS». فصورة المحتوى الموجودة بوصفها background-image فقط لا تظهر لبحث الصور مهما كان تحسينها جيدًا. البديل: أبق صور المحتوى داخل <img>، أو بوصفها بديل <img> داخل <picture>، وخصص خلفيات CSS للزخارف فقط.

حذف width وheight بهدف «تقليل الشيفرة»

• الخطأ: حذف width وheight الأصليين، أو aspect-ratio في CSS، من وسوم <img>. سبب الخطأ: لا يستطيع المتصفح حجز مساحة التخطيط قبل تحميل الصورة، فتقفز الصفحة مع وصول كل صورة، ما يضر CLS، وهو مقياس Core Web Vital المصاحب لـLCP. البديل: حدد width وheight، أو aspect-ratio، لكل صورة دائمًا، حتى الصور المحسنة أيضًا من حيث الصيغة والحجم.

النماذج الذهنية

1. لا تطبق التحميل الكسول على صورة LCP. هذه أعلى قاعدة قيمة في الموضوع كله. فأكبر عنصر في إطار العرض الأولي، وهو عادة صورة، يحدد زمن LCP. ولا يوفر تحميله الكسول شيئًا؛ بل يؤخر المقياس الذي تحسنه. يمكن تطبيق loading="lazy" على الصور الأخرى الواقعة خارج إطار العرض الأولي، لكن لا يطبق على صورة LCP.

2. لا يوجد إعداد ضغط عام. تعامل مع سؤال «إلى أي جودة أضغط؟» بوصفه سؤالًا خاصًا بكل صورة، لا سياسة للموقع كله. تتحمل الصور الفوتوغرافية ضغطًا منقوصًا قويًا، بخلاف الرسومات كثيرة النص ولقطات الشاشة. وآلية العمل مقارنة نسختين أو ثلاث عند حجم العرض، لا ضبط منزلق واحد ثم نسيانه.

3. الحجم الصحيح = حجم الحاوية × نسبة بكسلات الجهاز. ليست قاعدة «الأصغر أفضل»، بل المطابقة هي المطلوبة. تساوي أبعاد المصدر المثلى حجم العرض الفعلي مضروبًا في نسبة بكسلات الجهاز؛ فحاوية 500×500 عند DPR قدره 2 تحتاج مصدرًا 1 000×1 000. وينبغي لهذه المعادلة أن تحدد حجم تصدير كل صورة، وهي سبب تقديم نطاق عبر srcset بدل ملف ثابت واحد.

4. الصيغة رافعة للسرعة لا للترتيب. رتب العلاقة بدقة: اختيار الصيغة يؤدي إلى ملفات أصغر، ثم صفحة أسرع، ثم Core Web Vitals أفضل، وهي إشارة تستخدمها أنظمة الترتيب. أما القفز مباشرة إلى قول «الصيغ الحديثة ترتب أفضل» فهو أكثر أخطاء أدلة المنافسين شيوعًا؛ وقد قال Mueller ثلاث مرات إن الصيغة نفسها لا تمنح دفعة SEO مباشرة.

مؤشرات الأداء الدائمة لسرعة الصفحة المرتبطة بالصور

هذه الأرقام المستمرة تخبرك هل يصل أثر تحسين الصور فعلًا، بعيدًا عن صورة واحدة تغير حجمها أو صيغتها هذا الأسبوع.

اختبر معلوماتك: تحسين الصور

خمسة أسئلة سريعة عن الصيغ والضغط والأبعاد واستراتيجية التحميل. اختر إجابة لكل سؤال ثم تحقق.

سجل التغييرات