التحميل الكسول

كيف يؤدي التحميل الكسول للصور وإطارات iframe إلى تحسين Core Web Vitals، وخاصية التحميل، ومخاطر تحسين محركات البحث للتحميل الكسول للمحتوى الموجود أعلى الصفحة، وكيف يعرض Googlebot المحتوى المؤجل.

نُشر أول مرة: 2 يوليو 2026 · آخر تحديث: 13 أغسطس 2026 · Advanced
اللغات

يؤجل التحميل الكسول الصور وإطارات iframe غير الظاهرة حتى تقترب من منطقة العرض عند التمرير، فيقلل وزن الصفحة الأولي ويساعد Core Web Vitals. والطريقة الأصلية هي استخدام السمة loading="lazy" على عنصري <img> و<iframe> من دون JavaScript. أما الخطأ الكبير فهو تحميل الصورة الرئيسية أو صورة LCP تحميلًا كسولًا، لأن ذلك يؤخر أكبر رسم للمحتوى المرئي. لا يمرر Googlebot الصفحة أو ينقرها، لذلك قد لا يرى ما تحجبه أحداث التمرير أو النقر. والتحمّل الكسول ليس عامل ترتيب مباشرًا؛ بل يأتي أثره عبر Core Web Vitals وقابلية الزحف. تحقق في أداة فحص عنوان URL في Search Console مما يصيَّر فعليًا: يجب أن تظهر عناوين URL للصور في سمة src داخل HTML المصيَّر.

الخلاصة — التحميل الكسول يؤجل الصور وعناصر iframe خارج الشاشة حتى تقترب من منفذ العرض، مما يقلل الوزن الأولي للصفحة (يساعد في LCP) وعمل الخيط الرئيسي عند بدء التشغيل (يساعد في INP). خاصية loading="lazy" الأصلية على <img>/<iframe> حلت محل معظم مكتبات JavaScript؛ فقط lazy و eager هما القيمتان المفيدتان (auto مهملة). الأخطاء الضارة: التحميل الكسول لصورة LCP/فوق الجزء المرئي (يؤخر المقياس الذي تسعى إليه بالضبط)، وحجب المحتوى خلف التمرير/النقر — وهو ما لا يفعله Googlebot أبدًا لأنه لا يتفاعل مع الصفحة. إنه ليس عامل ترتيب مباشر؛ التأثير يمر عبر Core Web Vitals وقابلية الزحف. تحقق في أداة فحص عناوين URL في Search Console من أن عناوين URL للصور موجودة في خاصية src في HTML المعروض.

ما يفعله التحميل الكسول فعليًا

الفكرة بسيطة: قم بتحميل الموارد فقط عندما تحتاجها، بدلاً من تحميل كل شيء دفعة واحدة. في صفحة غنية بالوسائط، تنزيل كل صورة وعنصر تضمين مسبقًا يُبقي المتصفح مشغولاً بجلب أشياء قد لا يمرر الزائر إليها أبدًا — مما يهدر النطاق الترددي والذاكرة والبطارية دون فائدة. تأجيل العناصر خارج الشاشة يسمح لمحتوى الجزء المرئي بالظهور بشكل أسرع. أدلى Martin Splitt بهذه النقطة بالضبط في حلقة Search Off the Record بعنوان “Lazy loading demystified”: الهدف هو تجنب العمل الذي لا ينتج شيئًا، لأن الصور غير الحرجة التي يمكن للصفحة الاستغناء عنها تُبقي المتصفح مشغولاً فقط.

يرتبط هذا بـ Core Web Vitals التي يسعى معظم الناس لتحقيقها. قلة البايتات المتنافسة على الشبكة في البداية تعني أن عنصر Largest Contentful Paint يمكن أن يظهر بشكل أسرع. بالنسبة للإطارات المضمنة (iframes) — الإعلانات، وأدوات الوسائط الاجتماعية، وأقسام التعليقات، والخرائط — فإن تأجيلها يقلل أيضًا من عمل الخيط الرئيسي أثناء بدء التشغيل، وهو تحسّن في Interaction to Next Paint وليس مجرد تحسّن في LCP. إرشادات web.dev الخاصة بجوجل تصف الإطارات المضمنة المحملة بتكاسل كتحسين لـ INP أثناء تحميل الصفحة.

التحميل الكسول الأصلي مقابل التحميل الكسول المعتمد على جافا سكريبت

قبل بضع سنوات، اكتسبت المتصفحات سمة loading أصلية للصور والإطارات المضمنة، حتى تتمكن من تسليم المهمة بأكملها للمتصفح بدلاً من إعداد واجهة برمجة تطبيقات جافا سكريبت. في دليلي لتحسين محركات البحث في جافا سكريبت على Ahrefs أذكر نفس الملاحظة: منذ أن كتبت هذا المقال لأول مرة، انتقل التحميل الكسول في الغالب من كونه مدفوعًا بجافا سكريبت إلى التعامل معه بواسطة المتصفحات. ستظل تصادف إعدادات مدفوعة بجافا سكريبت، وبالنسبة للصور فهي عادةً ما تكون جيدة — الشيء الذي أتحقق منه هو ما إذا كان المحتوى الفعلي (وليس الصور فقط) يتم تحميله بتكاسل، لأن هذه الإعدادات هي التي تسببت في عدم التقاط المحتوى بشكل صحيح.

النسخة الأصلية:

<!-- Below-the-fold image: defer it -->
<img src="gallery-07.jpg" loading="lazy" width="800" height="600" alt="…">

<!-- Off-screen embed: defer it -->
<iframe src="https://www.youtube.com/embed/…" loading="lazy" title="…"></iframe>

حدد دائمًا width/height صريحًا (أو نسبة عرض إلى ارتفاع) على الصور الكسولة حتى يحجز المتصفح المساحة قبل تحميل الصورة — هذا هو أكبر خطر لتحول التخطيط مع الصور المؤجلة. الأبعاد المحجوزة ليست ضمانًا مطلقًا لـ CLS، ومع ذلك: إذا تغير التخطيط المحيط أو القص المتجاوب بعد تحميل الصورة، فقد ترى تحولًا، لذا تأكد من خلال تتبع حقيقي لتحول التخطيط بدلاً من افتراض أن الأبعاد الثابتة وحدها تحل الأمر.

التحميل الكسول والإطارات المضمنة يحتاجان إلى تمييز إضافي: loading="lazy" على <iframe> يؤجل فقط متى يحدث جلب وإنشاء التضمين. لا يحدد title الخاص به، أو سلوك التركيز، أو sandbox، أو سياسة allow/الأذونات، أو referrerpolicy، أو معالجة الموافقة، أو الأبعاد نيابة عنك — تلك لا تزال بحاجة إلى اهتمام خاص بها، ويمكن للتضمين أن يستمر في القيام بالعمل (البرامج النصية، وحدات البكسل للتتبع، التخطيط) بمجرد أن يصبح مؤهلاً للتحميل. ولا تفترض أن “أسفل الطية” يتصرف بنفس الطريقة في كل مكان: محتوى display: none، وشرائح العرض خارج الشاشة، والعناصر المحولة، وحاويات التمرير المتداخلة يمكن أن تتقاطع مع منفذ العرض بشكل مختلف عن عنصر عادي أسفل الطية، لذا اختبر التخطيط الفعلي وعناصر التحكم في التنقل بدلاً من افتراض التكافؤ.

قيم سمة loading

قيمتان فقط مهمتان اليوم:

  • loading="lazy" — قم بتأجيل المورد حتى يصبح قريبًا من منفذ العرض.
  • loading="eager" — قم بتحميله فورًا، السلوك الافتراضي. استخدمه لتكون صريحًا بشأن الصور الموجودة أعلى الطية.
Evidence for this claim The native loading attribute supports lazy loading for images and iframes without a JavaScript lazy-loading library. Scope: Browser-level lazy loading behavior; browser heuristics decide the fetch distance. Confidence: high · Verified: web.dev: Browser-level image lazy loading

قد ترى loading="auto" في المقالات الأقدم — إنها مهملة في Chrome، لذا لا تلجأ إليها. لا حاجة لذلك؛ حذف السمة يمنحك بالفعل السلوك الافتراضي (eager).

ما مدى قرب “القريب”؟ loading="lazy" هو تلميح، وليس ضمانًا يتحكم فيه المؤلف — تترك المواصفات قرار القرب الفعلي من منفذ العرض للمتصفح. يحاول Chromium جلب مورد كسول مبكرًا بما يكفي ليكون جاهزًا بحلول الوقت الذي تمرر إليه، و تختلف مسافة التشغيل حسب المتصفح وسرعة الاتصال ونوع المورد؛ إنها ليست قيمة بكسل ثابتة يمكنك الاعتماد عليها أو إعادة إنتاجها عبر المتصفحات أو الإصدارات. لا تنشر — أو تثق في — رقمًا محددًا “يتم تحميله N بكسل قبل منفذ العرض”؛ تعامل مع نافذة القرب من منفذ العرض على أنها محددة بالتنفيذ وأكد السلوك الفعلي باستخدام تتبع الشبكة على المتصفح/الاتصال الذي تهتم به بدلاً من افتراض ثابت.

يعمل التحميل الكسول الأصلي أيضًا بشكل جيد مع الصور المتجاوبة: فهو ينطبق على اختيار src وsrcset/sizes العادي، لذا لا تفقد سلوك الصورة المتجاوبة بإضافة loading="lazy". إذا قمت بدلاً من ذلك بإخفاء عنوان URL الحقيقي فقط في سمة data-* ليقوم سكربت بتبديله لاحقًا، فإن التحميل يعتمد الآن على ذلك السكربت — اختبر HTML المعروض وما يحدث إذا فشل السكربت (المزيد حول هذا في تبويبي السكربتات و استكشاف الأخطاء وإصلاحها).

Evidence for this claim Native lazy loading works with ordinary src and responsive srcset/sizes selection; hiding the real URL only in data-* attributes makes loading dependent on script and should be tested in rendered HTML and under script failure. Scope: responsive image fetching and layout Confidence: high · Verified: HTML Standard: img

الخطأ الأول: التحميل الكسول لصورة LCP / الصورة فوق الطية

هذا هو الفشل الذي أراه كثيرًا، وتتفق عليه جميع المصادر. إذا قمت بالتحميل الكسول لصورة الرئيسية — أو أي صورة من المحتمل أن تكون عنصر LCP — فأنت تخبر المتصفح بأن ينتظر أهم بكسل واحد لسرعة الإدراك. لا يمكن للمتصفح أيضًا تحميل صورة كسولًا حتى يعرف مكان الصورة على الصفحة، لذا تميل الصور الكسولة فوق الطية إلى التحميل ببطء أكثر من الصور المحمّلة فورًا. وهذا يؤخر مباشرةً Largest Contentful Paint، المقياس الذي يقول Google أنه يجب حله خلال أول 2,5 ثانية من التحميل.

Do not lazy-load the observed or likely LCP image; confirm the actual request and paint timing in a trace. المصدر: Lazy Loading

The eager path discovers the likely LCP image in HTML and starts its request promptly. The lazy path waits for browser loading heuristics before request start. The comparison uses no fixed timing values and notes that actual LCP must be measured.

© Patrick Stox LLC · CC BY 4.0 ·

وضع Splitt الجانب الآخر بوضوح في حلقة SOTR: إذا كنت لا تستخدم التحميل الكسول حيث يجب، فمن المحتمل أن يؤثر ذلك سلبًا على بعض جوانب Core Web Vitals — على الأرجح LCP. لذا فهو يقطع في كلا الاتجاهين. القاعدة:

  • مرشح LCP محتمل أو ملاحظ → تحميل متحمس (احذف loading="lazy"، أو اضبط eager). فكر في fetchpriority="high" على صورة LCP.
  • تحت الطية → loading="lazy".

ليست كل صورة فوق الطية هي مرشح LCP — حدد الصورة الفعلية (سيكشف تتبع الأداء أو PageSpeed Insights عنها) وتحقق من توقيت طلبها بدلاً من معاملة كل صورة في الشاشة الأولى بالمثل. وهذه تلميحات منفصلة، وليست إعدادًا واحدًا: loading="eager" (أو حذف loading) يعني فقط أن المتصفح لن يؤجل اكتشاف المورد — لا يرفع أولوية الجلب بحد ذاته. fetchpriority هو تلميح استشاري منفصل فوق ذلك. تكديس <link rel="preload"> مع loading="lazy" على نفس المورد يرسل للمتصفح نية متضاربة، لذا تحقق من شلال الشبكة الفعلي بدلاً من افتراض أن المجموعة تفعل ما تتوقعه.

النمط المعاكس الشامل هو تشغيل التحميل الكسول لـ كل صورة على مستوى الموقع — وهو إعداد افتراضي شائع في أنظمة إدارة المحتوى. كما لاحظ Splitt، إذا تم تحميل كل صورة بشكل كسول، فإن الصور التي تكون (أو يجب أن تكون) مرئية فورًا يتم تحميلها كسولًا أيضًا، وهذا بالضبط الحالة التي تريد تجنبها.

كيف يعرض Googlebot المحتوى المحمّل كسولًا

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

Evidence for this claim Google Search does not scroll or click to trigger lazy-loaded content, so implementations should not depend on user interaction and should expose resource URLs in rendered HTML. Scope: Google Search guidance for JavaScript-driven lazy loading. Confidence: high · Verified: Google Search Central: Lazy-load content

لهذا السبب فإن كيفية تنفيذك مهمة. يسرد مستند Google ثلاثة تطبيقات يعتبرها آمنة: التحميل الكسول المدمج في المتصفح للصور والإطارات المضمنة، وواجهة برمجة تطبيقات IntersectionObserver (مع polyfill)، أو مكتبة JavaScript تقوم بتحميل البيانات عند دخولها إلى منفذ العرض. كل الثلاثة تعتمد على تقاطع منفذ العرض — وليس حدث تمرير أو نقر لن يطلقه Googlebot أبدًا.

النمط عالي الخطورة هو مكتبة تحميل كسول مخصصة أو تابعة لجهة خارجية. إذا أخطأت المكتبة ولم يصل عنوان URL للصورة إلى خاصية src، فلن يلتقطها Google ببساطة — وصف سبلت هذا النمط من الفشل بالضبط في حلقة SOTR. لا يوجد شيء لفهرسته إذا لم يكن عنوان URL موجودًا. هذا هو نفس الشيء الذي أذكره في دليلي لتحسين محركات البحث في JavaScript: التحميل الكسول للصور عادةً ما يكون جيدًا، لكن المحتوى المُحمَّل كسولًا هو حيث تظهر مشاكل الفهرسة، والحل هو التحقق مما يعرضه Google فعليًا.

التمرير اللانهائي مشكلة مختلفة

لا تخلط بين التحميل الكسول الأساسي للصور/الإطارات المضمنة وبين التمرير اللانهائي أو التحميل المقسم إلى صفحات. تأجيل الصور شيء واحد؛ تحميل أجزاء جديدة من المحتوى أثناء تمرير المستخدم شيء آخر، ويتطلب بنية خاصة به. إرشادات Google: أعطِ كل جزء عنوان URL فريدًا ودائمًا، وحافظ على استقرار المحتوى لكل عنوان URL (استخدم أرقام صفحات مطلقة مثل ?page=12، وليس قيمًا نسبية مثل ?date=yesterday)، وحدّث عنوان URL المعروض باستخدام History API مع كل جزء يصبح المحتوى المرئي الأساسي بحيث يمكن تحديثه ومشاركته وربطه. تخطَّ ذلك وقد لا يتم الزحف إلى المحتوى الأعمق خلف التمرير اللانهائي أو فهرسته بشكل موثوق.

كيفية اختباره

مسار التحقق هو نفسه في مستند Google وفي منهجيتي الخاصة: استخدم أداة فحص عناوين URL في Search Console وانظر إلى HTML المعروض. إذا ظهرت عناوين URL للصور (أو الفيديو) في خاصية src على عناصر <img>/<video> في ذلك HTML المعروض، فإن إعدادك يعمل. يقول Google هذا صراحةً — Check the rendered HTML to make sure your content is in it. إذا كان عنوان URL مفقودًا من src، فهذه مشكلتك، وعادةً ما يشير إلى مشغل تمرير/نقر أو مكتبة معطلة.

بالنسبة لشبكة منتجات مُحمَّلة كسولًا، تجاوز فحص الوجود هذا. شغّل مصفوفة اختبار تحسين محركات البحث للتمرير اللانهائي مع منافذ عرض قياسية وطويلة، وتنقلًا جديدًا وتغيير حجم بعد التحميل، وتشغيلات بدون إجراء ومع تمرير تدريجي، وعدد روابط المنتجات الفريدة، وفحص شجرة إمكانية الوصول. تغيير حجم صفحة مهيأة ليس مكافئًا للتنقل بحجم منفذ العرض النهائي لأن المراقبين والحسابات الدفعية قد تُسجَّل فقط أثناء بدء التشغيل. Evidence for this claim Google Search does not scroll or click to trigger lazy-loaded content, so implementations should not depend on user interaction and should expose resource URLs in rendered HTML. Scope: Google Search guidance for JavaScript-driven lazy loading. Confidence: high · Verified: Google Search Central: Lazy-load content

يمكنك أيضًا الاعتماد على أدوات أداء الويب: PageSpeed Insights يشير إلى الصور خارج الشاشة التي يجب عليك تأجيلها. في دليلي لـ PageSpeed Insights في Ahrefs أذكر أن تدقيق “تأجيل العناصر خارج الشاشة” يخبرك بتحميل الصور كسولًا — طريقة مفيدة لربط التشخيص الذي تشغّله بالفعل بالإصلاح.

صدق إشارات الترتيب

كن واضحًا بشأن ما هو التحميل الكسول وما ليس كذلك. استخدامه ليس عامل ترتيب مباشرًا، وعدم استخدامه ليس عقوبة. العلاقة بالترتيب غير مباشرة: تمر عبر Core Web Vitals (بشكل أساسي LCP، وأحيانًا INP للإطارات المضمنة) وعبر قابلية الزحف، إذا كان التنفيذ السيئ يخفي المحتوى. وصف سبلت تأثير الترتيب عبر Core Web Vitals بأنه عامل صغير جدًا في معظم الحالات. لذا حسّن التحميل الكسول لتجربة تحميل المستخدمين وللفهرسة النظيفة — وليس لأنك تتوقع قفزة في الترتيب من الخاصية نفسها.

أين يتناسب هذا

التحميل الكسول هو رافعة واحدة في مجموعة أدوات أداء الويب الأوسع. يقترن بـ تلميحات الموارد (التحميل المسبق/الربط المسبق للموارد التي تريدها مبكرًا)، واستراتيجية تحميل الخطوط، والتخزين المؤقت، وشبكة توصيل المحتوى (CDN) — ويُقيَّم في النهاية عبر Core Web Vitals. احصل على تقسيم فوق الطية/تحت الطية بشكل صحيح وستكون واحدة من أرخص المكاسب المتاحة.

Add an expert note

Pin an expert quote

New person? Create their unclaimed profile at /admin/experts/ → Pin a quote first.