التحميل الكسول
كيف يؤدي التحميل الكسول للصور وإطارات iframe إلى تحسين Core Web Vitals، وخاصية التحميل، ومخاطر تحسين محركات البحث للتحميل الكسول للمحتوى الموجود أعلى الصفحة، وكيف يعرض Googlebot المحتوى المؤجل.
اللغات
يؤجل التحميل الكسول الصور وإطارات iframe غير الظاهرة حتى تقترب من منطقة العرض عند التمرير، فيقلل وزن الصفحة الأولي ويساعد Core Web Vitals. والطريقة الأصلية هي استخدام السمة loading="lazy" على عنصري <img> و<iframe> من دون JavaScript. أما الخطأ الكبير فهو تحميل الصورة الرئيسية أو صورة LCP تحميلًا كسولًا، لأن ذلك يؤخر أكبر رسم للمحتوى المرئي. لا يمرر Googlebot الصفحة أو ينقرها، لذلك قد لا يرى ما تحجبه أحداث التمرير أو النقر. والتحمّل الكسول ليس عامل ترتيب مباشرًا؛ بل يأتي أثره عبر Core Web Vitals وقابلية الزحف. تحقق في أداة فحص عنوان URL في Search Console مما يصيَّر فعليًا: يجب أن تظهر عناوين URL للصور في سمة src داخل HTML المصيَّر.
الخلاصة — التحميل الكسول يخبر المتصفح بتأجيل تحميل الصور وعناصر التضمين حتى تكون على وشك التمرير إليها، مما يجعل الصفحة تُحمَّل بشكل أسرع في البداية. الطريقة السهلة بدون كود هي إضافة
loading="lazy"إلى<img>أو<iframe>. القاعدة الوحيدة التي يجب تذكرها: لا تقم بالتحميل الكسول للصورة الكبيرة في أعلى الصفحة — فهذا يجعل الصفحة تبدو أبطأ، وليس أسرع.
ما هو التحميل الكسول
عادةً، عندما يفتح المتصفح صفحة، يحاول تنزيل كل شيء فيها — كل صورة، وكل خريطة أو فيديو مضمّن — فورًا. في صفحة طويلة تحتوي على الكثير من الصور، يكون ذلك قدرًا كبيرًا من التنزيل لأشياء قد لا تمرر للوصول إليها أبدًا.
التحميل الكسول يحل هذه المشكلة. فهو يؤجل تحميل الصور وعناصر التضمين خارج الشاشة حتى تكون على وشك تمريرها إلى العرض. تعرض الصفحة ما في الأعلى بسرعة، ويتم تحميل الباقي أثناء التمرير. بيانات أقل في البداية تعني انطباعًا أوليًا أسرع، بالإضافة إلى توفير في النطاق الترددي والبطارية — وهو ما يهم أكثر على الهواتف.
الطريقة السهلة: خاصية loading
كنت تحتاج سابقًا إلى مكتبة JavaScript للقيام بذلك. لم يعد الأمر كذلك. المتصفحات الحديثة لديها هذه الميزة مدمجة. كل ما عليك فعله هو إضافة خاصية واحدة:
<img src="photo.jpg" loading="lazy" alt="…">هذا كل شيء. تعمل على <img> و <iframe> (فكر في فيديوهات YouTube المضمّنة، خرائط Google، أدوات التواصل الاجتماعي) في جميع المتصفحات الرئيسية، بدون JavaScript.
الخطأ الوحيد الذي يجب تجنبه
لا تقم بالتحميل الكسول للصورة الكبيرة في أعلى الصفحة — الصورة الرئيسية، الشيء الذي يراه الناس أولاً. التحميل الكسول يخبر المتصفح “هذا يمكن أن ينتظر”، لذا فإن الصورة العلوية ذات التحميل الكسول تُحمَّل لاحقًا مما ينبغي، وتشعر الصفحة بأنها أبطأ. إرشادات Google الخاصة هي تخطي التحميل الكسول لأي شيء يكون مرئيًا فورًا عند فتح الصفحة.
النسخة المختصرة: قم بالتحميل الكسول للأشياء الموجودة أسفل الجزء المرئي، وقم بتحميل الأشياء الموجودة فوق الجزء المرئي بشكل طبيعي.
هل يضر تحسين محركات البحث؟
بحد ذاته، لا. يمكن لـ Google فهرسة الصور والمحتوى ذي التحميل الكسول بشكل جيد عندما يتم ذلك بالطريقة العادية. تبدأ المشكلة فقط عندما تخفي الصفحة المحتوى خلف التمرير أو النقر — لأن محركات البحث لا تمرر أو تنقر. إذا كانت صورك تستخدم فقط loading="lazy"، فأنت بخير. تريد التفاصيل حول كيفية رؤية Google لهذا بالفعل، وكيفية التحقق منه؟ انتقل إلى علامة التبويب متقدم.
الخلاصة — التحميل الكسول يؤجل الصور وعناصر 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"— قم بتحميله فورًا، السلوك الافتراضي. استخدمه لتكون صريحًا بشأن الصور الموجودة أعلى الطية.
قد ترى loading="auto" في المقالات الأقدم — إنها مهملة في Chrome، لذا
لا تلجأ إليها. لا حاجة لذلك؛ حذف السمة يمنحك بالفعل
السلوك الافتراضي (eager).
ما مدى قرب “القريب”؟ loading="lazy" هو تلميح، وليس ضمانًا يتحكم فيه المؤلف —
تترك المواصفات قرار القرب الفعلي من منفذ العرض للمتصفح. يحاول Chromium جلب
مورد كسول مبكرًا بما يكفي ليكون جاهزًا بحلول الوقت الذي تمرر إليه، و
تختلف مسافة التشغيل حسب المتصفح وسرعة الاتصال ونوع المورد؛ إنها ليست
قيمة بكسل ثابتة يمكنك الاعتماد عليها أو إعادة إنتاجها عبر المتصفحات أو الإصدارات. لا تنشر
— أو تثق في — رقمًا محددًا “يتم تحميله N بكسل قبل منفذ العرض”؛ تعامل مع
نافذة القرب من منفذ العرض على أنها محددة بالتنفيذ وأكد السلوك الفعلي باستخدام
تتبع الشبكة على المتصفح/الاتصال الذي تهتم به بدلاً من افتراض ثابت.
يعمل التحميل الكسول الأصلي أيضًا بشكل جيد مع الصور المتجاوبة: فهو ينطبق على اختيار
src وsrcset/sizes العادي، لذا لا تفقد سلوك الصورة المتجاوبة بإضافة
loading="lazy". إذا قمت بدلاً من ذلك بإخفاء عنوان URL الحقيقي فقط في سمة data-*
ليقوم سكربت بتبديله لاحقًا، فإن التحميل يعتمد الآن على ذلك السكربت — اختبر
HTML المعروض وما يحدث إذا فشل السكربت (المزيد حول هذا في تبويبي السكربتات و
استكشاف الأخطاء وإصلاحها).
الخطأ الأول: التحميل الكسول لصورة LCP / الصورة فوق الطية
هذا هو الفشل الذي أراه كثيرًا، وتتفق عليه جميع المصادر. إذا قمت بالتحميل الكسول لصورة الرئيسية — أو أي صورة من المحتمل أن تكون عنصر LCP — فأنت تخبر المتصفح بأن ينتظر أهم بكسل واحد لسرعة الإدراك. لا يمكن للمتصفح أيضًا تحميل صورة كسولًا حتى يعرف مكان الصورة على الصفحة، لذا تميل الصور الكسولة فوق الطية إلى التحميل ببطء أكثر من الصور المحمّلة فورًا. وهذا يؤخر مباشرةً Largest Contentful Paint، المقياس الذي يقول Google أنه يجب حله خلال أول 2,5 ثانية من التحميل.
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. احصل على تقسيم فوق الطية/تحت الطية بشكل صحيح وستكون واحدة من أرخص المكاسب المتاحة.
ملخص الذكاء الاصطناعي
نظرة مختصرة على النسخة المتقدمة:
- التحميل الكسول يؤجل الصور وعناصر iframe خارج الشاشة حتى تقترب من منفذ العرض —
مما يقلل الوزن الأولي للصفحة والعمل عند بدء التشغيل. الطريقة الأصلية بدون JavaScript هي
loading="lazy"على<img>و<iframe>؛ وقد حلت إلى حد كبير محل مكتبات JavaScript. إنها تلميح من المتصفح، وليست مسافة أو توقيتًا مضمونًا — نقطة التشغيل تختلف حسب المتصفح والاتصال ونوع المورد، لذا لا تعتمد على رقم بكسل ثابت. - القيم: فقط
lazyوeagerمهمة.autoمهملة في Chrome. - العلاقة بـ Core Web Vitals: تقليل البايتات الأولية يساعد LCP؛ تأجيل iframes يقلل
العمل على الخيط الرئيسي عند بدء التشغيل، مما يساعد INP. عيّن
width/heightحتى لا تسبب الصور المؤجلة CLS — على الرغم من أن الأبعاد المحجوزة وحدها لا تضمن عدم وجود إزاحة إذا استمر التخطيط المحيط في التغيير. - الخطأ الأول: تحميل كسول لصورة LCP المحتملة/المرصودة، وليس فقط أي صورة
فوق الطية. إنه يؤخر Largest Contentful Paint، الذي تقول Google إنه يجب أن
يُحل خلال 2,5 ثانية.
eager/حذفloadingيؤثر فقط على الاكتشاف — لا يرفع أولوية الجلب بحد ذاته؛fetchpriorityتلميح منفصل، وتكديسpreloadمعloading="lazy"على نفس المورد يتعارض. التحميل الكسول الشامل عبر الموقع هو النمط المعاكس الشائع في أنظمة إدارة المحتوى. - iframes لها عقدها الخاص:
loading="lazy"يؤجل فقط توقيت الجلب/الإنشاء — العنوان، وsandbox، وسياسة الأذونات، وسياسة الإحالة، والموافقة، و الأبعاد لا تزال بحاجة إلى ضبط مستقل، والتخطيطات المخفية/الدوارة/المحولة يمكن أن تتقاطع مع منفذ العرض بشكل مختلف عن عنصر عادي أسفل الطية. - Googlebot لا يمرر أو ينقر. أي محتوى محجوب خلف أحداث التمرير/النقر قد لا يُرى. طرق Google الآمنة — التحميل الكسول الأصلي، أو IntersectionObserver، أو مكتبة JavaScript جيدة السلوك — كلها تعتمد على تقاطع منفذ العرض.
- أعلى مخاطرة: مكتبات التحميل الكسول المخصصة/التابعة لجهات خارجية. إذا لم يصل الرابط أبدًا إلى
src، فلن يفهرس Google الصورة (وفقًا لمارتن سبلت). - التمرير اللانهائي مختلف: يحتاج عناوين URL فريدة مقسمة إلى صفحات + History API.
- تحقق في Search Console URL Inspection ← HTML المعروض ← عناوين URL للصور موجودة في
سمة
src. - ليس عامل ترتيب مباشر. التأثير غير مباشر، عبر Core Web Vitals و قابلية الزحف، ووصف سبلت تأثير ترتيب Core-Web-Vitals بالصغير.
الوثائق الرسمية
إرشادات من المصادر الأساسية من محركات البحث وموقع Google’s web.dev.
Google — Search Central
- إصلاح محتوى موقع الويب المُحمَّل كسولًا — الوثيقة الحاسمة: طرق التنفيذ الآمنة، وقاعدة “Google لا يتفاعل مع صفحتك”، ومتطلبات التمرير اللانهائي/التحميل المقسم إلى صفحات، وكيفية التحقق في HTML المعروض.
- فهم أساسيات JavaScript SEO — يوصي بالتحميل الكسول للصور كأفضل ممارسة لعرض النطاق الترددي/الأداء ويربط بالدليل المخصص.
- Core Web Vitals — لماذا التحميل الكسول لعنصر LCP هو إضعاف ذاتي (هدف LCP هو 2,5 ثانية).
Google — web.dev (تعلّم الأداء)
- تحميل الصور وعناصر
<iframe>كسولًا — متى تؤجل، وفائدة INP من iframes الكسولة. - التحميل الكسول للصور على مستوى المتصفح للويب — السمة الأصلية، ولماذا لا تحمّل الصور داخل منفذ العرض/LCP كسولًا.
- حان الوقت لتحميل iframes خارج الشاشة كسولًا! — الحالة الخاصة بـ iframe (الإعلانات، الأدوات، الخرائط).
- التحميل الكسول على مستوى المتصفح لأنظمة إدارة المحتوى — إرشادات لمنصات أنظمة إدارة المحتوى.
Google — بودكاست
- Search Off the Record — الحلقة 98، “Lazy loading demystified” (21 أغسطس 2025) — جون مولر ومارتن سبلت حول التحميل الكسول، والعرض، والفهرسة، وCore Web Vitals. مفهرس أيضًا على صفحة Search Off the Record الخاصة بجوجل.
مرجع المطور (ليس خاصًا بتحسين محركات البحث، لكنه موثوق بشأن واجهة برمجة التطبيقات)
- MDN — التحميل الكسول (دليل الأداء)
- MDN — HTMLImageElement: خاصية التحميل
- caniuse — التحميل الكسول عبر السمة للصور والإطارات المضمنة
Bing / Microsoft
- لا تنشر Bing مستندًا مخصصًا للتحميل الكسول. تغطي إرشادات مشرفي المواقع العامة الخاصة بها الزحف ومعالجة JavaScript بشكل واسع. يعرض Bingbot باستخدام متصفح بدون واجهة رسومية قائم على Chromium، ومثل Googlebot، لا يقوم بالتمرير أو النقر — لذا فإن نفس نهج
loading="lazy"الأصلي / IntersectionObserver الذي يرضي Google يجب أن يرضي Bing. هذه النقطة الأخيرة هي استنتاج من سلوك العرض العام لـ Bingbot، وليست بيانًا موثقًا من Bing حول التحميل الكسول — تعامل معها وفقًا لذلك.
اقتباسات من المصدر
بيانات مسجلة من الوثائق الرسمية لجوجل. كل رابط هو رابط عميق يقفز إلى المقطع المقتبس في الصفحة المصدر.
Google — Search Central، “إصلاح محتوى موقع الويب المحمّل كسولًا”
- “Deferring loading of non-critical or non-visible content, also commonly known as ‘lazy-loading’, is a common performance and UX best practice.” (ترجمة) «تأجيل تحميل المحتوى غير الحرج أو غير المرئي، المعروف أيضًا باسم ‘التحميل الكسول’، هو ممارسة شائعة لأفضل أداء وتجربة مستخدم.» الانتقال إلى الاقتباس
- “However, if not implemented correctly, this technique can inadvertently hide content from Google. This document explains how to make sure Google can crawl and index lazy-loaded content.” (ترجمة) «ومع ذلك، إذا لم يتم تنفيذ هذه التقنية بشكل صحيح، فقد تخفي المحتوى عن Google عن غير قصد. يشرح هذا المستند كيفية التأكد من أن Google يمكنها الزحف إلى المحتوى المحمّل كسولًا وفهرسته.» الانتقال إلى الاقتباس
- “The methods mentioned don’t rely on user actions, such as scrolling or clicking, to load content, which is important as Google Search does not interact with your page.” (ترجمة) «الطرق المذكورة لا تعتمد على إجراءات المستخدم، مثل التمرير أو النقر، لتحميل المحتوى، وهو أمر مهم لأن بحث Google لا يتفاعل مع صفحتك.» الانتقال إلى الاقتباس
- “Don’t add lazy-loading to content that is likely to be immediately visible when a user opens a page. That might cause content to take longer to load and show up in the browser, which will be very noticeable to the user.” (ترجمة) «لا تضف التحميل الكسول إلى المحتوى الذي من المحتمل أن يكون مرئيًا فورًا عند فتح المستخدم للصفحة. قد يتسبب ذلك في استغراق المحتوى وقتًا أطول للتحميل والظهور في المتصفح، وهو ما سيكون ملحوظًا جدًا للمستخدم.» الانتقال إلى الاقتباس
- “Give each chunk its own persistent, unique URL.” — حول التمرير اللانهائي / التحميل المرقّم. (ترجمة) «امنح كل جزء عنوان URL خاصًا به ودائمًا وفريدًا.» الانتقال إلى الاقتباس
قائمة التحقق من التحميل الكسول
قم بتشغيل هذا قبل نشر تغيير التحميل الكسول:
- صورة hero / LCP ليست محمّلة بتكاسل (lazy-loaded) — تُحمَّل بسرعة (احذف
loading="lazy")، ويفضَّل معfetchpriority="high". - يتم تطبيق
loading="lazy"على الصور وعناصر iframe الموجودة أسفل الجزء المرئي من الصفحة. - الصور المحمّلة بتكاسل لها
width/heightصريح (أوaspect-ratio) حتى لا تسبب إزاحة في التخطيط (CLS) عند تحميلها. - لا يوجد محتوى محجوب خلف حدث تمرير أو نقرة — لن يُطلق Googlebot هذه الأحداث. استخدم التحميل الكسول الأصلي أو IntersectionObserver بدلاً من ذلك.
- لا تستخدم القيمة المهجورة
loading="auto"— فقطlazy/eager. - iframes خارج الشاشة (تضمينات، إعلانات، خرائط، أدوات) تستخدم
loading="lazy"لتقليل عمل الخيط الرئيسي عند بدء التشغيل. - iframes المحمّلة بتكاسل لا تزال تحتوي على
titleوsandboxوallow/سياسة الأذونات وreferrerpolicyوأبعاد صريحة —loading="lazy"يؤجل توقيت الجلب فقط، وليس تلك السمات. - تم التحقق في Search Console URL Inspection → rendered HTML من أن عناوين URL للصور/الفيديو
تظهر في سمة
src. - إذا كنت تستخدم مكتبة تحميل بطيء تابعة لجهة خارجية، تأكد من أن
srcلا تزال مملوءة في HTML المعروض. - بالنسبة للتمرير اللانهائي، كل جزء له عنوان URL فريد ودائم ومرقّم، وتحدّث History API عنوان URL المعروض.
- تمت معالجة علامات “defer offscreen images” في PageSpeed Insights.
أنماط التحميل الكسول المضادة (خرافات وأخطاء)
كل من هذه عبارة عن اعتقاد أو عادة شائعة، ولماذا هي خاطئة، وما يجب فعله بدلاً منها.
“التحميل الكسول جيد دائمًا، لذا طبّقه على كل صورة.” لماذا هو خاطئ: التحميل الكسول الشامل على مستوى الموقع يشمل الصورة الرئيسية/LCP أيضًا، مما يؤخر Largest Contentful Paint — عكس مكسب السرعة الذي تريده. افعل بدلاً من ذلك: حمّل بتكاسل فقط ما هو أسفل الجزء المرئي؛ وحمّل الصور فوق الجزء المرئي بسرعة.
“Google لا يفهرس المحتوى المحمّل بتكاسل على الإطلاق.” لماذا هو خاطئ: يزحف Google ويفهرس المحتوى المحمّل بتكاسل جيدًا عندما يتم ذلك باستخدام التحميل الكسول الأصلي أو IntersectionObserver أو مكتبة جيدة السلوك. الخطر خاص بالإعدادات المحجوبة بالتمرير/النقر أو المعطوبة — وفقًا لصياغة Google نفسها، المشكلة هي عندما لا يكون “منفذًا بشكل صحيح.” افعل بدلاً من ذلك: استخدم طريقة تقاطع منفذ العرض وتحقق في HTML المعروض.
“loading='auto' هو افتراضي جيد.”
لماذا هو خاطئ: auto مهجور في Chrome؛ التوصية به نصيحة قديمة.
افعل بدلاً من ذلك: استخدم lazy للموارد خارج الشاشة، وeager (أو لا شيء) للباقي.
“التحميل الكسول والتمرير اللانهائي هما نفس الإصلاح.” لماذا هو خاطئ: إنهما مختلفان. التمرير اللانهائي يحتاج أيضًا إلى عناوين URL مرقّمة فريدة وتحديثات History API، أو قد لا يتم الزحف إلى المحتوى الأعمق بشكل موثوق. افعل بدلاً من ذلك: تعامل مع التحميل المرقّم/اللانهائي كبنية خاصة به مع عناوين URL لكل جزء.
“loading='lazy' يعمل على أي عنصر.”
لماذا هو خاطئ: محدد لـ <img> و<iframe>. الدعم للعناصر الأخرى
ليس جزءًا من المواصفات الأساسية بنفس الطريقة.
افعل بدلاً من ذلك: استخدم السمة على الصور وعناصر iframe؛ وتعامل مع الوسائط الأخرى بتقنية
مناسبة (للفيديو، صورة ملصق تحمّل الفيديو عند دخول منفذ العرض).
“التحميل الكسول يضر بـ SEO.” لماذا هو خاطئ: التحميل الكسول نفسه ليس عقوبة. التأثير المرتبط بالترتيب يمر عبر Core Web Vitals وهو صغير؛ التنفيذ السيئ هو ما يضر، وليس التقنية. افعل بدلاً من ذلك: نفذه بشكل صحيح، واستبعد صورة LCP، وتحقق مما يُعرض.
ورقة الغش للتحميل البطيء
سمة loading
| القيمة | ماذا تفعل | متى تستخدم |
|---|---|---|
loading="lazy" | تؤجل المورد حتى يقترب من منفذ العرض | الصور وعناصر iframe أسفل الجزء المرئي |
loading="eager" | تحميل فوري (الافتراضي) | صور فوق الجزء المرئي / LCP (أو احذفها فقط) |
loading="auto" | مهجور في Chrome — لا تستخدمه | — |
أي العناصر تدعمها
<img>— نعم<iframe>— نعم- عناصر أخرى (فيديو/صوت) — ليست جزءًا من المواصفات الأساسية بنفس الطريقة؛ استخدم نمط صورة ملصق + تحميل عند العرض للفيديو.
فوق الطية مقابل أسفلها
- فوق الطية / من المحتمل أن يكون LCP → eager (أبدًا lazy). أضف
fetchpriority="high"إلى صورة LCP. - أسفل الطية → lazy.
تأثير Core Web Vitals
- تأجيل الصور خارج الشاشة → يساعد LCP (بايتات أقل تتنافس في البداية).
- تأجيل iframes خارج الشاشة → يساعد INP (عمل أقل على الخيط الرئيسي عند بدء التشغيل).
- غياب
width/heightعلى الصور الكسولة → قد يضر CLS (انزياح التخطيط عند التحميل).
قواعد يهتم بها Googlebot
- Googlebot لا يمرر أو ينقر — لا محتوى مقيد بالتمرير أو النقر.
- طرق آمنة:
loading="lazy"الأصلي، IntersectionObserver، مكتبة JS جيدة السلوك. - تحقق: URL Inspection → HTML المعروض → عنوان URL للصورة في سمة
src. - التمرير اللانهائي ≠ تحميل كسول للصور — يتطلب عناوين URL فريدة مرقمة + History API.
قبل / بعد
إصلاحات ملموسة، مصاغة بالطريقة التي ستواجهها في تدقيق.
1. الصورة الرئيسية محمّلة بشكل كسول (تأخير LCP)
قبل:
<img src="hero.jpg" loading="lazy" alt="Product hero">بعد:
<img src="hero.jpg" fetchpriority="high" alt="Product hero">السبب: الصورة الرئيسية هي عنصر LCP. تحميله بشكل فوري (وتحديد أولوية الجلب) يسمح له بالظهور أسرع. تحميله الكسول يفعل العكس.
2. تحميل كسول شامل على مستوى الموقع من إعداد افتراضي في CMS
قبل: كل <img> في القالب يحمل loading="lazy"، بما في ذلك شعار الرأس
وصورة مميزة أعلى الصفحة.
بعد: القالب يحمّل الصور فوق الطية بشكل فوري ويطبق فقط
loading="lazy" على الصور المعروضة أسفل منفذ العرض الأولي.
السبب: التحميل الكسول الشامل يلتقط الصور المرئية فورًا، مما يؤخر ما يراه
المستخدم (وLCP) أولاً.
3. تحميل تضمين خارج الشاشة عند تحميل الصفحة
قبل:
<iframe src="https://maps.google.com/…" title="Store map"></iframe>بعد:
<iframe src="https://maps.google.com/…" loading="lazy" title="Store map"></iframe>السبب: الخريطة أسفل الطية. تأجيلها يزيل تكلفة بدء التشغيل ويساعد INP، لأن التضمينات تقوم بعمل على الخيط الرئيسي أثناء تحميل الصفحة.
4. تحميل كسول مخصص بـ JS يترك src فارغًا لـ Googlebot
قبل: مكتبة تخزن عنوان URL الحقيقي في data-src وتستبدله في src عند حدث تمرير
— وهو ما لا يطلقه Googlebot أبدًا، لذا يُظهر HTML المعروض src فارغًا/بديلًا.
بعد: استخدم loading="lazy" الأصلي (عنوان URL حقيقي في src من البداية)، أو مكتبة
قائمة على IntersectionObserver، ثم تأكد في URL Inspection أن عنوان URL موجود
في src المعروض.
السبب: إذا لم يكن عنوان URL في src في HTML المعروض، لا يمكن لـ Google التقاط الصورة.
ابحث عن الصور التي يجب (أو لا يجب) تحميلها بشكل كسول
مقتطف Console في DevTools يمكنك لصقه على أي صفحة لتدقيق سمة loading.
يسرد الصور مع قيمة loading الخاصة بها وما إذا كانت حاليًا في
منفذ العرض — حتى تتمكن من اكتشاف صورة فوق الطية مميزة بـ lazy، أو صورة أسفل الطية
ليست كذلك.
Chrome DevTools Console
// Audit loading attributes vs. viewport position
[...document.images].forEach(img => {
const r = img.getBoundingClientRect();
const inView = r.top < innerHeight && r.bottom > 0;
const loading = img.getAttribute('loading') || '(none/eager)';
// Flag the two mistakes: in-view + lazy, or off-view + not lazy
const flag =
(inView && loading === 'lazy') ? '⚠ above-the-fold but LAZY' :
(!inView && loading !== 'lazy') ? '· off-screen, not lazy' : '';
console.log(loading.padEnd(14), inView ? 'in-view ' : 'off-view', flag, img.currentSrc || img.src);
});ابحث في مصدرك عن أنماط تحميل كسول محفوفة بالمخاطر
تحقق من قوالبك/مخرجات البناء بحثًا عن القيمة المهملة auto وعن
تحميل كسول بنمط data-src عبر JS (الذي قد يترك src فارغًا لـ Googlebot).
macOS / Linux (bash)
# Deprecated loading="auto"
grep -rn 'loading="auto"' ./src
# JS-driven lazy load leaving real URL in data-src (verify these render into src)
grep -rn 'data-src=' ./srcWindows (PowerShell)
# Deprecated loading="auto"
Get-ChildItem -Recurse .\src | Select-String -Pattern 'loading="auto"'
# JS-driven lazy load using data-src
Get-ChildItem -Recurse .\src | Select-String -Pattern 'data-src='تذكر: data-src ليس مشكلة تلقائيًا — إنه تذكير لتأكيد أن عنوان URL الحقيقي
ينتهي في src المعروض، وهو ما تتحقق منه في Search Console URL Inspection.
الصورة الرئيسية تبدأ لاحقًا بعد تفعيل التحميل الكسول
العرض: يتباطأ LCP ويبدأ طلب الصورة الرئيسية متأخرًا في مخطط الشلال.
السبب المحتمل: قاعدة عامة في CMS أضافت loading="lazy" إلى صورة فوق الطية أو
صورة LCP.
الإصلاح والتأكيد: أزل سمة التحميل الكسول من تلك الصورة، وأضف اختياريًا
fetchpriority="high"، وتأكد من أن طلبها يبدأ مبكرًا في تتبع مطابق.
صورة كسولة تظهر لكنها تُزيح الصفحة
العَرَض: تقفز المحتويات عندما تدخل صورة مؤجلة إلى منطقة العرض.
السبب المحتمل: الصورة لا تحتوي على أبعاد صريحة أو نسبة أبعاد محجوزة.
الإصلاح والتأكيد: أضف سمتي width و height أو احجز نفس نسبة الأبعاد في CSS. أعد التحميل مع تفعيل مناطق تغيّر التخطيط وتحقق من أن الصورة لم تعد تُزيح المحتوى المحيط.
جوجل لا يرى المحتوى المؤجل
العَرَض: يفتقد الفحص المصيَّر عنوان URL للصورة أو محتوى لا يظهر إلا بعد تمرير بشري.
السبب المحتمل: معالج تمرير/نقر لا يعمل أبدًا مع Googlebot، أو مكتبة تحميل كسول تترك عنوان URL الحقيقي في data-src بدلاً من src المصيَّر.
الإصلاح والتأكيد: استخدم التحميل الكسول الأصلي أو تنفيذًا قائمًا على IntersectionObserver، ثم افحص HTML المصيَّر وتأكد من وجود عنوان URL النهائي والمحتوى دون تفاعل.
تضمين خارج الشاشة لا يزال يُحمَّل فورًا
العَرَض: يظهر iframe أسفل الجزء المرئي في مخطط الطلبات الأولي رغم تغيير التحميل الكسول.
السبب المحتمل: السمة غائبة عن iframe المنشور، أو غلاف ينشئ iframe مبكرًا، أو التضمين قريب بما يكفي من منطقة العرض لحد تحميل المتصفح.
الإصلاح والتأكيد: افحص DOM المباشر وبادئ الطلب، واختبر على صفحة طويلة مع ذاكرة تخزين مؤقت باردة، وتحقق من تأجيل الطلب حتى حد قرب منطقة العرض في المتصفح.
أدوات للتنفيذ والإثبات
- لوحتا Elements و Network في Chrome DevTools: تأكد من سمة
loadingالمنشورة، وحدد أي سكربت أنشأ iframe، وقارن أوقات بدء الطلبات قبل التغيير وبعده. - لوحة Performance في Chrome DevTools: سجّل تحميلًا وتحقق من أن تأجيل تضمين يقلل عمل الخيط الرئيسي عند بدء التشغيل دون تأخير صورة LCP.
- PageSpeed Insights: استخدم تشخيص الصورة خارج الشاشة كقائمة بداية، ثم افصل المرشحات الحقيقية أسفل الجزء المرئي عن الصورة الرئيسية أو المحتوى الفوري الآخر.
- فحص عنوان URL في Search Console: افحص HTML المصيَّر وتحقق من أن عناوين URL للصور المؤجلة تنتهي في
srcوأن المحتوى المُحمَّل كسولًا موجود دون تمرير أو نقرة. - منطقة عرض المتصفح وشريط اللقطات: اختبر أكثر من حجم لمنطقة العرض. صورة أسفل الجزء المرئي على سطح المكتب قد تكون فوق الجزء المرئي على جهاز أصغر أو مختلف الشكل.
تأجيل الصور أسفل الجزء المرئي
الاختبار المطلوب تنفيذه: سجّل تتبع شبكة بتحميل بارد قبل وبعد إضافة التحميل الكسول الأصلي لصورة بعيدة أسفل منطقة العرض الأولية.
النتيجة المتوقعة: يكون طلب الصورة غائبًا عن مخطط الطلبات الحر الأولي ويبدأ مع اقتراب منطقة العرض منه.
تفسير الفشل: الترميز المنشور يفتقد السمة، أو JavaScript ينشئ الصورة أو يجلبها مبكرًا، أو صورة الاختبار ضمن حد قرب منطقة العرض في المتصفح.
نافذة المراقبة: تحقق فورًا بعد النشر عبر أحجام مناطق عرض تمثيلية للجوال وسطح المكتب.
مُحفِّز التراجع: تراجع إذا تم تأجيل صورة مرئية عند التحميل الأولي أو إذا فشلت الصورة بانتظام في الظهور قبل وصول المستخدم إليها.
استثناء صورة LCP
الاختبار المطلوب تنفيذه: قارن تتبعات الأداء المطابقة ومخططات طلبات الصفحة لصورة LCP بعد إزالة التحميل الكسول الشامل.
النتيجة المتوقعة: تُحمَّل صورة LCP مبكرًا، ويبدأ طلبها في وقت أبكر، ولا يتراجع LCP.
تفسير الفشل: قالب أو طبقة تحسين أخرى تعيد إضافة السمة، أو الاكتشاف ما زال متأخرًا بسبب CSS أو JavaScript أو الترميز.
نافذة المراقبة: تحقق من تشغيلات المختبر المتكررة فورًا، ثم راقب LCP الميداني خلال نافذة التقارير التالية.
مُحفِّز التراجع: تراجع عن النشر المحيط إذا أخر التغيير موارد حرجة أخرى بما يكفي للتسبب في تراجع LCP قابل للتكرار.
رؤية المحتوى المصيَّر
الاختبار المطلوب تنفيذه: استخدم URL Inspection لعرض HTML المصيَّر دون التفاعل مع الصفحة وابحث عن عنوان URL للصورة المؤجلة والمحتوى المرتبط بها.
النتيجة المتوقعة: يظهر عنوان URL النهائي في src، ويكون المحتوى المهم موجودًا في HTML المصيَّر.
تفسير الفشل: يعتمد التنفيذ على حدث تمرير/نقر أو فشل البرنامج النصي للتحميل البطيء أثناء العرض.
نافذة المراقبة: اختبر كل قالب متأثر بعد الإصدار وبعد تغيير مكتبة التحميل الكسول أو خط أنابيب الصور في نظام إدارة المحتوى.
مشغل التراجع: تراجع إذا اختفى المحتوى القابل للفهرسة أو عناوين URL للصور من المخرجات المصيَّرة.
اختبر نفسك: التحميل الكسول
خمسة أسئلة سريعة حول تأجيل الصور وعناصر iframe دون الإضرار بـ Core Web Vitals أو الفهرسة. اختر إجابة لكل سؤال، ثم تحقق.
موارد تستحق وقتك
كتاباتي ذات الصلة
- JavaScript SEO Issues & Best Practices — حيث أغطي التحول من التحميل الكسول المعتمد على JavaScript إلى التحميل الكسول الأصلي في المتصفح، ولماذا يشكل المحتوى المُحمَّل ببطء (وليس الصور فقط) خطرًا على الفهرسة.
- دليل Google PageSpeed Insights لمتخصصي تحسين محركات البحث والمطورين — يربط تدقيق “تأجيل الصور خارج الشاشة” بالتحميل الكسول، بالإضافة إلى بقية تقرير PSI.
- دليل المبتدئين إلى تحسين محركات البحث التقني — حيث يتناسب الأداء والعرض في الصورة الأكبر.
من جميع أنحاء الصناعة
- إصلاح محتوى المواقع المحمّل كسولًا (Google Search Central) — المستند النهائي للتنفيذ والاختبار.
- التحميل الكسول للصور على مستوى المتصفح للويب (web.dev) — السمة الأصلية وتحذير LCP، مباشرة من فريق الأداء في Google.
- حان وقت التحميل الكسول لإطارات iframe خارج الشاشة (web.dev) — حالة iframe وفائدتها في بدء التشغيل وINP.
- إزالة الغموض عن التحميل الكسول — Search Off the Record، الحلقة 98 (Google) — حلقة Mueller وSplitt الكاملة حول التحميل الكسول والعرض والفهرسة وCore Web Vitals.
- شرح التحميل الكسول: سرّع موقعك وتجربة المستخدم (Search Engine Land) — دليل صناعي شامل مع ملاحظات خاصة بأنظمة إدارة المحتوى.
- التحميل الكسول: دليل الأداء (MDN) — عرض مرجع المطور لواجهة برمجة التطبيقات.
- مقدمة في التحميل الكسول لنجاح قابلية الزحف والفهرسة (Oncrawl) — زاوية الزحف/الفهرسة بعمق.
سجل التغييرات
تم التحديث في 13 أغسطس 2026.
ملخص تحريري وتفاصيل التغيير المسجلة.تفاصيل التغيير
-
تفاصيل التغيير متاحة حاليًا باللغة الإنجليزية.
-
تفاصيل التغيير متاحة حاليًا باللغة الإنجليزية.
المقارنة الكاملة غير متاحة — لم تُؤرشف لقطة سابقة لهذه المراجعة.
تم التحديث في 9 أغسطس 2026.
ملخص تحريري وتفاصيل التغيير المسجلة.تفاصيل التغيير
-
تفاصيل التغيير متاحة حاليًا باللغة الإنجليزية.
المقارنة الكاملة غير متاحة — لم تُؤرشف لقطة سابقة لهذه المراجعة.
تم التحديث في 29 يوليو 2026.
ملخص تحريري وتفاصيل التغيير المسجلة.تفاصيل التغيير
-
تفاصيل التغيير متاحة حاليًا باللغة الإنجليزية.
المقارنة الكاملة غير متاحة — لم تُؤرشف لقطة سابقة لهذه المراجعة.
تم التحديث في 18 يوليو 2026.
ملخص تحريري وتفاصيل التغيير المسجلة.تفاصيل التغيير
-
تفاصيل التغيير متاحة حاليًا باللغة الإنجليزية.
-
تفاصيل التغيير متاحة حاليًا باللغة الإنجليزية.
-
تفاصيل التغيير متاحة حاليًا باللغة الإنجليزية.
-
تفاصيل التغيير متاحة حاليًا باللغة الإنجليزية.
المقارنة الكاملة غير متاحة — لم تُؤرشف لقطة سابقة لهذه المراجعة.
تم التحديث في 17 يوليو 2026.
ملخص تحريري وتفاصيل التغيير المسجلة.تفاصيل التغيير
-
تفاصيل التغيير متاحة حاليًا باللغة الإنجليزية.
المقارنة الكاملة غير متاحة — لم تُؤرشف لقطة سابقة لهذه المراجعة.