أكبر رسم للمحتوى (LCP)

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

ما هو LCP

الانطباع الأول الذي يحصل عليه الأشخاص من موقعك هو مدى سرعة ظهوره في التحميل. يحاول LCP وضع رقم على ذلك. يقيس مقدار الوقت المستغرق لتحميل أكبر عنصر مرئي في منفذ العرض — الجزء من الصفحة الذي يمكنك رؤيته دون التمرير.

عادةً ما يكون “أكبر عنصر” أحد أمرين:

• صورة كبيرة — لافتة رئيسية، صورة منتج، صورة مميزة.
• كتلة نصية كبيرة — شائعة في صفحات المقالات التي لا تبدأ بصورة.

LCP هو اللحظة التي ينتهي فيها ذلك العنصر من العرض، ويُقاس من الوقت الذي بدأت فيه الصفحة التحميل لأول مرة. كلما انخفض الرقم، زادت سرعة شعور صفحتك.

النتيجة

تصنف Google LCP إلى ثلاث فئات:

• جيد: 2,5 ثانية أو أقل
• يحتاج إلى تحسين: 2,5 إلى 4 ثوانٍ
• ضعيف: أكثر من 4 ثوانٍ

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

لماذا قد يكون صعبًا

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

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

ما يجب فعله أولاً

ثلاثة مكاسب سريعة تعالج الأخطاء الأكثر شيوعًا:

1. لا تقم بالتحميل الكسول لصورتك الرئيسية. “التحميل الكسول” يخبر المتصفح بالانتظار قبل جلب الصورة. هذا رائع للمحتوى البعيد في أسفل الصفحة — ولكن إذا قمت بذلك لصورتك الرئيسية، فأنت تؤخر عمدًا أهم شيء على الشاشة. Evidence for this claim An LCP image should not be lazy-loaded, and reducing resource load delay is a primary LCP optimization. Scope: web.dev guidance for image-based LCP elements. Confidence: high · Verified: 2026-07-14 web.dev: Optimize LCP
2. أخبر المتصفح أن الصورة الرئيسية مهمة — هناك سمة (fetchpriority="high") تفعل ذلك بالضبط. ضعها على الصورة التي هي بالفعل مرشح LCP الخاص بك؛ وضعها على عدة صور يضعف الإشارة.
3. سرّع خادمك. إذا كان خادمك بطيئًا في الاستجابة، فلن يهم كثيرًا أي شيء آخر تفعله.

هل تريد النموذج العقلي الكامل — الأجزاء الفرعية الأربعة لـ LCP، وكيفية العثور على عنصر LCP الخاص بك، وأمور العرض والخطوط، ومدى أهمية ذلك فعليًا للترتيب؟ انتقل إلى علامة التبويب متقدم.

الخلاصة — LCP هو وقت عرض أكبر صورة أو كتلة نصية مرئية في منفذ العرض، بالنسبة إلى الوقت الذي بدأت فيه الصفحة التحميل. الجيد هو ≤ 2,5 ثانية عند المئين 75 من المستخدمين الحقيقيين (مقسمين حسب الجهاز)؛ 2,5–4 ثوانٍ يحتاج إلى عمل، وأكثر من 4 ثوانٍ ضعيف. وهو أحد مؤشرات الويب الأساسية الثلاثة وينقسم إلى أربعة أجزاء فرعية — TTFB، وتأخير تحميل الموارد، ومدة تحميل الموارد، وتأخير عرض العنصر — حيث يهيمن عادةً TTFB ومدة التحميل (إرشادات، وليس حصصًا ثابتة — شخّص صفحتك الخاصة). أفضل الإصلاحات: لا تقم أبدًا بالتحميل الكسول لصورة LCP، وأضف fetchpriority="high" على المرشح الفعلي، وقم بتحميله مسبقًا عندما لا يكون في HTML، وقم بإزالة CSS/JS الذي يعيق العرض، وأصلح TTFB. إنه مقياس ميداني — أدوات المختبر تقربه فقط — ويمكن أن يتغير عنصر LCP أثناء التحميل. تؤكد Google أن مؤشرات الويب الأساسية تغذي أنظمة الترتيب لكنها لا تنشر وزنًا دقيقًا لـ LCP أو تسميه عامل كسر التعادل؛ لا تزال أهمية المحتوى هي المهيمنة.

ما يقيسه LCP فعليًا

يُبلغ LCP عن وقت عرض أكبر صورة أو كتلة نصية مرئية في منفذ العرض، ويُقاس بالنسبة إلى الوقت الذي انتقل فيه المستخدم إلى الصفحة لأول مرة. تأطير Google الخاص: إنه أقرب وكيل موحد لـ متى يظهر المحتوى الرئيسي للمستخدم. وقد حل محل مقاييس أقدم وأكثر ضبابية مثل First Meaningful Paint و Speed Index.

بعض الأشياء التي تربك الناس فورًا:

• إنه ليس “وقت تحميل الصفحة”. يمكن للصفحة أن تجلب كل الموارد ومع ذلك تسجل LCP بطيئًا إذا كان عرض أكبر عنصر محظورًا. يتعلق LCP بهذا العنصر الواحد، وليس الصفحة بأكملها.
• إنه ليس نفس FCP. يبدأ First Contentful Paint عندما يظهر أي محتوى لأول مرة؛ ينتظر LCP العنصر الأكبر. يمكن أن يكون للصفحة FCP سريع (يُعرض شريط التنقل) وLCP بطيء (تظهر الصورة الرئيسية متأخرة).
• إنه مقياس ديناميكي. يرسل المتصفح مرشح LCP جديدًا في كل مرة يصبح فيها عنصر أكبر مرئيًا. آخر إدخال قبل تفاعل المستخدم (نقرة، تمرير، ضغطة مفتاح) أو تفريغ الصفحة هو القيمة التي تُحتسب — التفاعل غالبًا ما يغير ما هو مرئي، لذا يتوقف الإبلاغ هناك. المرشح الذي يُزال لاحقًا من DOM لا يمحو إدخاله الخاص — يظل العنصر المُبلَّغ عنه ما لم يُعرض عنصر أكبر قبل توقف الإبلاغ.

العتبات — ولماذا 2,5 ثانية

يُقيَّم عند المئين 75 من تحميلات الصفحات من مستخدمين حقيقيين، مقسمًا حسب نوع الجهاز. لذا يجب أن تكون ثلاثة من كل أربع زيارات أقل من 2,5 ثانية حتى يجتاز الموقع.

لماذا 2,5 تحديدًا؟ اعتمدت منهجية عتبات Google على شيئين: أبحاث الإدراك البشري التي تشير إلى حوالي 1–3 ثوانٍ كنطاق يبدو “فوريًا،” وبيانات CrUX عن إمكان تحقيق العتبات التي تُظهر أن 2,5 ثانية كانت قابلة للتحقيق باستمرار للمواقع المحسّنة جيدًا دون أن تكون سهلة بشكل تافه. الأهداف الأكثر صرامة مثل 1,5 ثانية أو 2,0 ثانية لم تكن قابلة للتحقيق باستمرار عبر عدد كافٍ من المواقع، لذا لم تنجح.

ما يُعتبر عنصر LCP

أنواع العناصر التي تُؤخذ في الاعتبار لـ LCP:

• عناصر <img>
• عناصر <image> داخل <svg>
• عناصر <video> (وقت تحميل صورة الملصق، أو الإطار الأول، أيهما أسبق)
• عنصر يحتوي على صورة خلفية محمّلة عبر دالة CSS url()
• عناصر على مستوى الكتلة تحتوي على عقد نصية أو عناصر نصية مضمّنة أخرى

الحجم المُبلَّغ عنه هو ما هو مرئي فعليًا في منفذ العرض — الأجزاء المقتطعة أو الممررة خارج الشاشة لا تُحتسب، وبالنسبة للصور فهو الحجم المرئي أو الحجم الجوهري، أيهما أصغر. الهوامش والحشوات والحدود تُتجاهل. عدد قليل من العناصر مستبعدة بواسطة الاستدلالات: أي شيء يحتوي على opacity: 0، والعناصر التي تغطي منفذ العرض بالكامل (تُعامل كخلفيات)، وصور العناصر النائبة منخفضة الإنتروبيا.

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

الأجزاء الفرعية الأربعة — الجزء الذي تتجاهله معظم المقالات

هذا هو الإطار الذي أبدأ به أي تشخيص لـ LCP. يقسم web.dev LCP إلى أربعة أجزاء فرعية متسلسلة:

1. الوقت حتى أول بايت (TTFB) — من عندما يبدأ المستخدم تحميل الصفحة إلى عندما يتلقى المتصفح أول بايت من HTML. الحصة النموذجية: ~40% من إجمالي LCP.
2. تأخير تحميل المورد — الفجوة بين TTFB وبدء المتصفح في تحميل مورد LCP. هذا هو وقت الاكتشاف. الحصة النموذجية: أقل من 10%.
3. مدة تحميل المورد — المدة التي يستغرقها مورد LCP نفسه للتنزيل. الحصة النموذجية: ~40%.
4. تأخير عرض العنصر — من عندما ينتهي المورد من التحميل إلى عندما يُعرض العنصر فعليًا. الحصة النموذجية: أقل من 10%.

المبدأ وراء الجدول: يجب أن تُقضى الغالبية العظمى من وقت LCP في تحميل مستند HTML ومورد LCP. أي فترة لا يتم فيها تحميل أي منهما هي فرصة للتحسين.

يوضح web.dev أن هذه النسب المئوية هي إرشادات، وليست قواعد صارمة — لا تحوّلها إلى أهداف زمنية مطلقة بالثواني، ولا تجبر كل صفحة على مطابقة التقسيم. إنها ذات معنى فقط بالنسبة لبعضها البعض، وإذا كان LCP لديك ضمن 2,5 ثانية باستمرار، فإن النسب النسبية لا تهم على الإطلاق. استخدم الجدول لتحديد أي مكوّن فرعي يستهلك حصة غير متناسبة في صفحتك، ثم أصلح ذلك المكوّن — لا تسعَ إلى تقسيم دقيق 40/10/40/10.

وإليك الجزء الذي يقلب الافتراض الشائع: اعتبارًا من فبراير 2025، تتوفر هذه المكونات الفرعية الأربعة في واجهة برمجة تطبيقات CrUX لصور LCP، وقد وجد تحليل فريق Chrome لبيانات أرشيف HTTP أن وقت تنزيل الصورة كان غالبًا أصغر جزء من وقت LCP. بعبارة أخرى، “فقط اضغط صوري” غالبًا ما يصلح المكوّن الخاطئ. غالبًا ما يكون TTFB وتأخير الاكتشاف رافعتين أكبر.

كيفية العثور على عنصر LCP الخاص بك

قبل تحسين أي شيء، اكتشف أي عنصر هو LCP الخاص بك وأي مكوّن فرعي هو عنق الزجاجة:

• PageSpeed Insights — قسم التشخيص يحدد عنصر LCP، وتبويب بيانات الحقل يعرض درجة المستخدمين الحقيقيين.
• Chrome DevTools — لوحة الأداء تحدد عقدة LCP على الخط الزمني.
• مكتبة web-vitals بلغة JavaScript — سجّل LCP (والعنصر) من مراقبة المستخدمين الحقيقيين الخاصة بك.

كيفية تحسين LCP

اربط كل إصلاح بالمكوّن الفرعي الذي يستهدفه:

إصلاح تأخير تحميل المورد (الاكتشاف). هذا هو الأعلى تأثيرًا والأكثر شيوعًا في التعطل.

• لا تقم أبدًا بالتحميل الكسول لصورة LCP الخاصة بك. loading="lazy" على عنصر LCP يضيف دائمًا تأخير تحميل غير ضروري. احتفظ بالتحميل الكسول للصور أسفل الطية.
• أضف fetchpriority="high" إلى صورة LCP المحتملة حتى يجلبها المتصفح مبكرًا بأولوية عالية.
• قم بتحميلها مسبقًا باستخدام <link rel="preload"> عندما لا تكون الصورة قابلة للاكتشاف في HTML الأولي — على سبيل المثال، عندما يتم تحميلها عبر CSS أو JavaScript. تحميل الصورة الرئيسية عبر JS هو نمط معاكس تمامًا لأنه يخفي عنوان URL عن ماسح التحميل المسبق في المتصفح.
• استضف الموارد الحرجة على نفس الأصل حتى لا يدفع المتصفح تكلفة إضافية لإعداد الاتصال.

التحميل المسبق وfetchpriority يحلان مشكلتين مختلفتين، لذا لا تلجأ إليهما معًا بدافع العادة. التحميل المسبق يكشف موردًا كان ماسح التحميل المسبق في المتصفح سيكتشفه متأخرًا (مثل صورة محملة عبر JS أو CSS)؛ fetchpriority يغير أولوية الجلب لمورد وجده المتصفح بالفعل. إذا كان الاكتشاف والأولوية صحيحين بالفعل — الصورة هي <img> عادي في HTML الأولي — فإن إضافة أي منهما قد لا يفعل شيئًا سوى طلبات إضافية. افحص تتبعًا، وطبق ما يناسب المشكلة الفعلية، وتأكد من أن رقم الحقل تحرك.

إصلاح تأخير عرض العنصر.

• قلل أو ضمّن CSS المعطل للعرض؛ وأجّل الأنماط غير الحرجة.
• تجنب البرامج النصية المتزامنة في <head>.
• فضّل العرض من جانب الخادم أو التوليد الثابت حتى يصل الترميز جاهزًا للرسم، وقسّم المهام الطويلة على الخيط الرئيسي.

تقليل مدة تحميل المورد.

• تنسيقات الصور الحديثة (WebP، AVIF)، وضغط معقول، وشبكة توصيل المحتوى (CDN).
• Cache-Control فعال. ولا تتجاهل تنافس الشبكة — التحميل الكسول للصور الأخرى أسفل الطية يمكن أن يحرر النطاق الترددي لتصل صورة LCP مبكرًا.

تقليل TTFB.

• قلل عمليات إعادة التوجيه، وتخلص من معلمات URL الفريدة غير الضرورية، وحسّن زمن استجابة الخادم. لاحظ أن LCP يشمل أي وقت إلغاء تحميل من الصفحة السابقة، وإعداد الاتصال، ووقت إعادة التوجيه — وكلها تُدرج في TTFB.

حالة خاصة: LCP النصي. عندما يكون أكبر عنصر نصًا، يكون المسار الحرج هو تحميل الخطوط، وليس وزن الصور. font-display: optional أو خطوط النظام تلغي تأخير العرض الناتج عن الخطوط؛ font-display: swap بدون تحميل مسبق لملف الخط يمكن أن يقدم هذا التأخير.

المختبر مقابل الميدان — هذا التمييز مهم

LCP هو في الأساس مقياس ميداني. تقيّمه Google على المستخدمين الحقيقيين عبر CrUX، ويظهر في تبويب الميدان في PageSpeed Insights وتقرير Core Web Vitals في Search Console. بيانات الميدان هذه هي ما يغذي التصنيفات.

أدوات المختبر — Lighthouse وChrome DevTools وWebPageTest — تقترب منه فقط تقريبًا تحت ظروف محاكاة، ولا تستخدم حتى نفس التقييم. يطبق Lighthouse عتبات سطح مكتب أكثر صرامة (جيد ≤ 1,2 ثانية) مقارنة بالمعيار الميداني (≤ 2,5 ثانية). لذا، فإن نتيجة Lighthouse الناجحة لا تضمن نتيجة CrUX ناجحة، والعكس صحيح. استخدم أدوات المختبر للتصحيح وإعادة الإنتاج؛ وثق ببيانات الميدان للحكم الفعلي.

هناك سبب ثانٍ لتباعد أرقام المختبر والميدان، يستحق المعرفة حتى لا يدفعك قراءة غريبة إلى مطاردة خطأ وهمي: واجهة برمجة التطبيقات الحالية LargestContentfulPaint (لا تزال مسودة عمل W3C) مقتصرة على تحميل مستند واحد. لا تعيد الضبط نفسها على استعادة ذاكرة التخزين المؤقت للخلف/الأمام (bfcache) أو التنقلات داخل المستند في تطبيقات SPA، والصفحات التي تبدأ خارج الشاشة — علامات التبويب في الخلفية، الصفحات المعالجة مسبقًا — يمكن أن تبلغ عن قيم مبالغ فيها لأن التوقيت يعمل من التحميل وليس من الوقت الذي أصبحت فيه الصفحة مرئية فعليًا. كما تتوقف خوارزمية الإبلاغ عند إدخال مستخدم مؤهل، لذا إذا تفاعل المستخدم قبل عرض المحتوى الرئيسي، فلن يلتقط LCP ذلك. لا يغير أي من هذا جدول العتبات أعلاه؛ يفسر لماذا يمكن أن يبدو رقم جلسة معينة خاطئًا عندما لا يكون التنقل الأساسي تحميلًا أولًا بسيطًا.

هل يؤثر LCP على التصنيفات؟

نعم، بمعنى أن Google تؤكد أن Core Web Vitals تغذي أنظمة التصنيف الخاصة بها وتوصي بتحقيق نتائج جيدة. لكن وثائق Search Central الحالية لا تنشر وزنًا دقيقًا لـ LCP ولا تصفه كعامل كسر تعادل — وصياغة Google الأصلية هي أن تجربة الصفحة “can contribute to success in Search”، أي «يمكن أن تسهم في النجاح في البحث»، للاستعلامات التي تقدم فيها صفحات متعددة بالفعل محتوى مشابهًا وذا صلة، وأن النتيجة الجيدة لا تضمن تعزيزًا في التصنيف. لا تزال أهمية المحتوى وجودته تهيمن. حسّن LCP لأن الصفحة ذات الإحساس الأسرع أفضل حقًا للمستخدمين (والتحويلات) — ليس لأن الآلية موثقة كعامل كسر تعادل في التصنيفات، لأنها ليست كذلك.

بعض الحقائق من البيانات: من بين Core Web Vitals، LCP هو المقياس الذي يجد المواقع صعوبة أكبر في تحسينه، وهو أصعب بشكل ملحوظ على الجوال منه على سطح المكتب — بسبب معالجات واتصالات أبطأ. على شبكات 3G وأبطأ، يمكن أن يبدو عتبة 2,5 ثانية شبه مستحيل تحقيقها.

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

LCP هو واحد من ثلاثة Core Web Vitals، إلى جانب Interaction to Next Paint وCumulative Layout Shift. الجزء الفرعي الأول منه، Time to First Byte، هو مقياس تشخيصي خاص به، وFirst Contentful Paint يقع بجواره مباشرة على الجدول الزمني للتحميل. سترى كل هذه في PageSpeed Insights وLighthouse وتقرير تجربة مستخدم Chrome (CrUX). كل منها هو غوص عميق خاص به في هذه المجموعة.

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

نظرة مكثفة على النسخة المتقدمة:

• LCP = وقت عرض أكبر صورة أو كتلة نصية مرئية، نسبة إلى وقت بدء تحميل الصفحة. وهو أقرب وكيل معياري لـ “متى يظهر المحتوى الرئيسي”.
• العتبات: جيد ≤ 2,5 ثانية، يحتاج تحسين 2,5–4 ثوانٍ، ضعيف > 4 ثوانٍ — عند المئين 75 من المستخدمين الحقيقيين، مقسمة حسب الجهاز. وهو أحد مؤشرات الويب الأساسية الثلاثة.
• ليس وقت تحميل الصفحة، وليس FCP. FCP = أول بكسل من أي محتوى؛ LCP = أكبر عنصر. LCP أيضًا ديناميكي — يمكن أن يتغير أكبر مرشح أثناء التحميل؛ آخر واحد قبل تفاعل المستخدم هو الذي يُحتسب.
• عناصر LCP: <img>، <image> داخل <svg>، ملصق <video>، CSS background-image: url()، أو عنصر نصي على مستوى الكتلة. حوالي 3 من كل 4 صفحات تحتوي على LCP صورة؛ والباقي نص (حيث الخطوط، وليس وزن الصورة، هي الرافعة).
• أربعة أجزاء فرعية: TTFB (~40%)، تأخير تحميل المورد (<10%)، مدة تحميل المورد (~40%)، تأخير عرض العنصر (<10%) — يسميها web.dev إرشادات، وليست حصصًا ثابتة؛ شخّص لكل صفحة بدلاً من مطاردة تقسيم دقيق. بيانات CrUX 2025: تنزيل الصورة غالبًا هو الجزء الأصغر — لذا “فقط ضغط الصور” غالبًا ما يصلح الشيء الخطأ.
• أفضل الإصلاحات: لا تقم أبدًا بالتحميل الكسول لصورة LCP؛ أضف fetchpriority="high" على المرشح الفعلي؛ قم بتحميله مسبقًا عندما لا يكون في HTML (التحميل المسبق وfetchpriority يحلان مشاكل مختلفة — لا تلجأ إليهما معًا بدافع العادة)؛ قلل من CSS/JS الذي يحجب العرض؛ قلل TTFB.
• ميداني، وليس مختبري. CrUX/Search Console تقود الترتيب؛ Lighthouse يقارب فقط ويستخدم عتبات سطح مكتب أكثر صرامة (≤ 1,2 ثانية). واجهة برمجة التطبيقات الحالية LargestContentfulPaint مقتصرة على تحميلات المستند ولا تعيد تعيين نفسها لاستعادة bfcache أو تنقلات SPA في نفس المستند.
• الترتيب: تؤكد Google أن أنظمة ترتيب CWV تغذي الترتيب لكنها لا تنشر وزنًا دقيقًا لـ LCP ولا تسميه عامل كسر التعادل؛ لا يزال ملاءمة المحتوى هو المسيطر. أصعب CWV في التحسين، وأصعب على الجوال.

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

إرشادات من المصدر الأساسي من فرق Chrome والبحث في Google.

web.dev (فريق Chrome)

• أكبر رسم للمحتوى (LCP) — التعريف الأساسي: ما يُعتبر عنصر LCP، وكيف يُحسب الحجم، ومتى يتوقف الإبلاغ، وواجهات برمجة التطبيقات للقياس.
• تحسين أكبر رسم للمحتوى — إطار الأجزاء الفرعية الأربعة ودليل التحسين الكامل.
• مؤشرات الويب الأساسية — أين يقع LCP بين مؤشرات الويب الأساسية الثلاثة.
• كيف حُددت عتبات مقاييس مؤشرات الويب الأساسية — البحث وبيانات قابلية التحقيق وراء علامة 2,5 ثانية.

Chrome للمطورين

• الأجزاء الفرعية لصورة LCP وRTT متاحة الآن في CrUX — إصدار بيانات الميدان لشهر فبراير 2025 للأجزاء الفرعية الأربعة (صور LCP فقط).
• أكبر رسم للمحتوى | Lighthouse — المقياس المختبري وتقييمه الخاص بالجهاز.

مركز بحث Google

• فهم مؤشرات الويب الأساسية ونتائج بحث Google — كيف تؤثر مؤشرات الويب الأساسية في البحث.

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

تصريحات رسمية من وثائق Google وفريقها. كل رابط هو رابط عميق يقفز إلى المقطع المقتبس.

web.dev — التعريف والسلوك (Philip Walton & Barry Pollard, Google)

• “LCP reports the render time of the largest image, text block, or video visible in the viewport, measured relative to when the user first navigated to the page.” (ترجمة) «يُبلغ LCP عن وقت عرض أكبر صورة أو كتلة نصية أو فيديو ظاهر في منفذ العرض، مُقاسًا بالنسبة إلى الوقت الذي انتقل فيه المستخدم إلى الصفحة لأول مرة.» الانتقال إلى الاقتباس
• حول ما يُقاس: “LCP doesn’t consider margins, paddings, or borders applied using CSS.” (ترجمة) «لا يأخذ LCP في الاعتبار الهوامش أو الحشوات أو الحدود المُطبَّقة باستخدام CSS.» الانتقال إلى الاقتباس
• حول موعد توقف الإبلاغ: “The browser will stop reporting new entries as soon as the user interacts with the page (via a tap, scroll, or keypress), as user interaction often changes what’s visible to the user.” (ترجمة) «سيتوقف المتصفح عن الإبلاغ عن الإدخالات الجديدة بمجرد تفاعل المستخدم مع الصفحة (عبر نقرة أو تمرير أو ضغطة مفتاح)، لأن تفاعل المستخدم غالبًا ما يغيّر ما هو مرئي للمستخدم.» الانتقال إلى الاقتباس
• حول ما يُدرج في التوقيت: “It is important to note that LCP includes any unload time from the previous page, connection set up time, redirect time, and other Time To First Byte (TTFB) delays.” (ترجمة) «من المهم ملاحظة أن LCP يتضمن أي وقت تفريغ من الصفحة السابقة، ووقت إعداد الاتصال، ووقت إعادة التوجيه، وتأخيرات أخرى لوقت أول بايت (TTFB).» الانتقال إلى الاقتباس

web.dev — التحسين (Philip Walton & Barry Pollard, Google)

• القاعدة الأكثر أهمية للتحميل الكسول: “Never lazy-load your LCP image, as that will always lead to unnecessary resource load delay.” (ترجمة) «لا تقم أبدًا بالتحميل الكسول لصورة LCP الخاصة بك، لأن ذلك سيؤدي دائمًا إلى تأخير غير ضروري في تحميل الموارد.» الانتقال إلى الاقتباس
• المبدأ الكامن وراء أهداف الأجزاء الفرعية: “The vast majority of the LCP time should be spent loading the HTML document and LCP source.” (ترجمة) «يجب قضاء الغالبية العظمى من وقت LCP في تحميل مستند HTML ومصدر LCP.» الانتقال إلى الاقتباس

Google Search Central — التصنيفات

• “We highly recommend site owners achieve good Core Web Vitals for success with Search and to ensure a great user experience generally.” (ترجمة) «نوصي بشدة أن يحقق مالكو المواقع مقاييس Core Web Vitals جيدة للنجاح في البحث ولضمان تجربة مستخدم رائعة بشكل عام.» (مُنقول من مستند Search Central Core Web Vitals؛ تحقق من الصفحة المباشرة قبل اعتباره نهائيًا.)

قائمة فحص إصلاح LCP

اعمل عليها تقريبًا من الأعلى إلى الأسفل — الاكتشاف وTTFB أولاً، لأنهما عادةً أكبر الروافع وأكثرها شيوعًا في التعطل.

• العثور على عنصر LCP الفعلي (تشخيصات PageSpeed Insights، لوحة الأداء في DevTools، أو مكتبة web-vitals) — لا تحسّن بشكل أعمى.
• فحص الأجزاء الفرعية الأربعة لمعرفة أي منها هو عنق الزجاجة قبل تغيير أي شيء.
• صورة LCP ليست loading="lazy" (التحميل الكسول ينتمي فقط أسفل الطية).
• صورة LCP تحتوي على fetchpriority="high".
• صورة LCP قابلة للاكتشاف في HTML الأولي — أو محمّلة مسبقًا (<link rel="preload">) إذا تم تحميلها عبر CSS/JS.
• عدم تحميل الصورة الرئيسية عبر JavaScript (يخفيها عن ماسح التحميل المسبق).
• تقليل/تضمين CSS المعطّل للعرض؛ تأجيل الأنماط غير الحرجة.
• لا توجد نصوص برمجية متزامنة في <head>؛ تقسيم المهام الطويلة.
• تنسيق صورة حديث (WebP/AVIF)، ضغط معقول، تقديم عبر CDN مع Cache-Control جيد.
• تحميل كسول للصور أسفل الطية حتى لا تتنافس على النطاق الترددي مع صورة LCP.
• معالجة TTFB: تقليل عمليات إعادة التوجيه، تحسين استجابة الخادم، إسقاط معلمات URL غير الضرورية.
• LCP نصي؟ استخدام font-display: optional أو خطوط النظام، وتحميل مسبق لأي ملف خط يتم تبديله.
• التحقق من بيانات ميدانية (CrUX / Search Console)، وليس فقط تشغيل مختبري في Lighthouse.

ورقة غش LCP

العتبات (المئين 75 من المستخدمين الحقيقيين، حسب الجهاز)

الأجزاء الفرعية الأربعة — ما هو كل منها والإصلاح

ما يمكن أن يكون عنصر LCP

• <img> · <image> داخل <svg> · ملصق <video> · CSS background-image: url() · نص على مستوى الكتلة

مستبعد بالاستدلال: opacity: 0، عناصر “الخلفية” بعرض إطار العرض الكامل، عناصر نائبة منخفضة الإنتروبيا.

حقائق سريعة

• LCP هو مقياس ميداني (CrUX / Search Console يقودان التصنيفات)؛ Lighthouse يقارب فقط ويستخدم حدًا صارمًا لسطح المكتب الجيد ≤ 1,2 ثانية.
• يمكن أن يتغير عنصر LCP أثناء التحميل؛ آخر مرشح قبل تفاعل المستخدم هو ما يُحتسب.
• حوالي 3 من كل 4 صفحات تحتوي على LCP صورة؛ الباقي نص (الخطوط هي الرافعة).
• وقت تنزيل الصورة غالبًا هو الأصغر بين الأجزاء الفرعية — الضغط ليس دائمًا الحل.
• LCP ≠ FCP؛ LCP ≠ إجمالي وقت تحميل الصفحة.

أدوات قياس وإصلاح LCP

بيانات ميدانية (ما تستخدمه التصنيفات)

• PageSpeed Insights — علامة التبويب الميدانية تعرض LCP الخاص بـ CrUX لمستخدميك الحقيقيين؛ التشخيصات تشير إلى عنصر LCP.
• Search Console — تقرير Core Web Vitals — حالة LCP عبر عناوين URL الخاصة بك، مجمعة، على بيانات المستخدم الحقيقي.
• تقرير تجربة مستخدم Chrome (CrUX) — مجموعة البيانات الميدانية الأساسية؛ اعتبارًا من فبراير 2025 يتضمن الأجزاء الفرعية الأربعة لـ LCP الصورة عبر API.
• مكتبة web-vitals JS — سجل LCP وعنصر LCP من مراقبة المستخدم الحقيقي الخاصة بك.

بيانات مخبرية (لتصحيح الأخطاء)

• Lighthouse — LCP مختبري سريع وقائمة فرص (تذكر: عتبات سطح المكتب أكثر صرامة من الميدانية).
• Chrome DevTools — لوحة الأداء — تحدد عقدة LCP والجدول الزمني الكامل للعرض.
• WebPageTest — عرض الشلال لتحديد أي جزء فرعي بطيء.

زواحف SEO

• Ahrefs Site Audit — يكشف مشكلات Core Web Vitals / الأداء عبر الموقع على نطاق واسع.

كيف تقيّم الأدوات نفسها

مثال حي للمقياس الذي تصفه هذه الصفحة — خدمات معروفة لسرعة الصفحة والمراقبة مرتبة حسب LCP المحمول الحقيقي لمستخدميها (بيانات ميدانية من تقرير تجربة مستخدم Chrome):

إصلاحات LCP التي تستهدف المشكلة الخاطئة

التحميل الكسول لصورة البطل

loading="lazy" يؤخر اكتشاف صورة فوق الطية التي من المحتمل أن تصبح LCP. قم بتحميلها بشكل فوري، وأعطِ المرشح المحتمل fetchpriority="high"، واحتفظ بالتحميل الكسول للصور أسفل الطية.

ضغط كل صورة قبل العثور على الاختناق

مدة تنزيل الصورة هي فقط واحدة من أربعة أجزاء فرعية لـ LCP وقد تكون الأصغر. حدد عنصر LCP وافحص TTFB، وتأخير التحميل، ومدة التحميل، وتأخير العرض قبل اختيار الإصلاح.

تحميل البطل عبر JavaScript

الصورة المحقونة عبر JS تخفي عنوان URL الخاص بها عن ماسح التحميل المسبق للمتصفح وتخلق تأخيرًا في تحميل الموارد. ضع الصورة في HTML الأولي أو قم بتحميلها مسبقًا عندما يجب أن تمتلكها CSS أو JS.

إعلان النجاح من تشغيل Lighthouse واحد

Lighthouse هو تشخيص مُتحكم فيه، بينما يأتي حكم CWV من Google من بيانات CrUX الميدانية. استخدم تشغيلات المختبر للتحقق من الآلية وانتظر بيانات المستخدمين الحقيقيين لمعرفة ما إذا كانت نتيجة p75 قد تحسنت.

يبدأ مورد LCP متأخرًا

الأعراض: تظهر فجوة طويلة بين TTFB وطلب مورد LCP. السبب المحتمل: التحميل الكسول، اكتشاف JS، صورة خلفية CSS، أو أولوية جلب منخفضة. الإصلاح: اجعل المورد قابلًا للاكتشاف في HTML الأولي، أزل التحميل الكسول، طبق fetchpriority="high"، أو قم بتحميله مسبقًا. تأكد من أن الطلب يتحرك مبكرًا في التتبع.

يكتمل تحميل المورد لكن LCP يظل متأخرًا

الأعراض: تنتهي مدة التحميل قبل حدث LCP بوقت طويل. السبب المحتمل: CSS يحجب العرض، JavaScript متزامن، مهمة طويلة، أو عرض خط لنص LCP. الإصلاح: قلل العمل المحجب واختبر استراتيجية الخط للنص؛ تأكد من أن تأخير عرض العنصر يتقلص.

LCP في المختبر جيد لكن LCP في الميدان ضعيف

الأعراض: ينجح Lighthouse بينما لا ينجح CrUX أو Search Console. السبب المحتمل: المستخدمون الحقيقيون لديهم أجهزة وشبكات وحالات تخزين مؤقت ومواقع وعناصر LCP مختلفة. الإصلاح: قسّم البيانات الميدانية، التقط تفاصيل عنصر/جزء فرعي من RUM، وأعد إنتاج الجزء البطيء بدلاً من ضبط ملف تعريف المختبر الافتراضي فقط.

يتغير عنصر LCP المُبلغ عنه بين التشغيلات

الأعراض: يحدد DevTools صورًا أو كتل نصية مختلفة. السبب المحتمل: نقاط توقف متجاوبة، تخصيص، تغييرات DOM متأخرة، أو مرشحون متنافسون. الإصلاح: اختبر منافذ العرض والحالات التمثيلية، ثم حسّن كل مرشح متكرر بدلاً من افتراض أن صورة رئيسية واحدة لسطح المكتب تمثل تجربة كل مستخدم.

اكتشاف صورة البطل: متأخر مقابل مبكر

تنفيذ متأخر مبسط يخفي الصورة خلف JavaScript:

<div id="hero"></div>
<script>
  document.querySelector('#hero').innerHTML = '<img src="hero.webp" alt="">';
</script>

يمكن للمتصفح اكتشاف هذا الإصدار وتحديد أولويته أثناء تحليل HTML:

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

صورة خلفية CSS: غير معلنة مقابل محملة مسبقًا

عندما يجب أن تبقى صورة LCP كخلفية CSS، اكشف عنها قبل أن ينتهي ملف الأنماط:

<link rel="preload" as="image" href="hero.webp" fetchpriority="high">

التحميل المسبق يساعد فقط عندما يتطابق عنوان URL وسمات الطلب مع المورد الفعلي.

قائمة بمرشحي LCP الأخيرين في Chrome DevTools

الصق هذا في وحدة تحكم Chrome DevTools، أعد تحميل الصفحة، وراقب كل مرشح يبلغ عنه المتصفح. المرشح الأخير قبل التفاعل هو المرشح ذو الصلة.

new PerformanceObserver((list) => {
  for (const entry of list.getEntries()) {
    console.table({
      lcp: Math.round(entry.startTime),
      element: entry.element?.tagName,
      url: entry.url || '',
      size: entry.size,
    });
  }
}).observe({ type: 'largest-contentful-paint', buffered: true });

العثور على صور كسولة محتملة فوق الطية

شغّل هذا في وحدة تحكم DevTools. يسرد الصور الكسولة التي تبدأ حافتها العلوية في منفذ العرض الحالي؛ تحقق من مرشح LCP الحقيقي قبل إزالة السمة.

[...document.querySelectorAll('img[loading="lazy"]')]
  .filter((img) => img.getBoundingClientRect().top < innerHeight)
  .map((img) => ({ src: img.currentSrc || img.src, top: img.getBoundingClientRect().top }));

استخراج سمات أولوية الصور في زاحف

استخدم XPath هذا في استخراج مخصص في Screaming Frog لإرجاع الصور المميزة كأولوية عالية:

//img[@fetchpriority='high']/@src

إثبات نجاح إصلاح LCP

اختبار ترتيب الاكتشاف

الاختبار للتشغيل: سجل تتبع أداء DevTools بعد تغيير صورة البطل. النتيجة المتوقعة: يبدأ طلب LCP مبكرًا ولا يتم تحميله كسولًا. تفسير الفشل: يبقى المورد مخفيًا أو منخفض الأولوية أو محجوبًا خلف اعتماد آخر. نافذة المراقبة: نتيجة مختبر فورية. مشغل التراجع: التغيير يؤخر موردًا حاسمًا آخر أو يجعل LCP في المختبر أسوأ باستمرار.

اختبار تأخير العرض

الاختبار المطلوب تنفيذه: مقارنة اكتمال مورد LCP وحدث LCP في تتبعات قبل/بعد مكافئة. النتيجة المتوقعة: يتقلص تأخير عرض العنصر دون تخطيط جديد أو تراجع بصري. تفسير الفشل: لا تزال CSS أو JavaScript أو الخطوط تمنع الرسم. نافذة المراقبة: فورية عبر منافذ العرض التمثيلية. مشغل التراجع: عرض مكسور، أو أنماط مفقودة، أو LCP متكرر أسوأ.

اختبار النتيجة الميدانية

الاختبار المطلوب تنفيذه: مراقبة CrUX على مستوى عنوان URL أو RUM من الطرف الأول p75 LCP بعد النشر. النتيجة المتوقعة: يتحرك p75 نحو عتبة “جيد” أو يبقى ضمنها دون تراجع في INP أو CLS. تفسير الفشل: لم تكن حالة المختبر تمثيلية أو أن جزءًا فرعيًا آخر يهيمن على الزيارات الحقيقية. نافذة المراقبة: يمكن أن يقود RUM؛ يحتاج CrUX إلى نافذته المتدحرجة البالغة 28 يومًا للتحول. مشغل التراجع: تراجع ميداني مستمر مرتبط بالإصدار.

مقاييس LCP الجديرة بالتتبع

p75 LCP الميداني

المقياس: LCP عند المئين 75 حسب عامل الشكل. ما يخبرك به: ما إذا كان المستخدمون الحقيقيون يحققون عتبة تحميل Core Web Vitals. كيفية سحبه: CrUX أو Search Console أو RUM من الطرف الأول. المعيار / النطاق الواقعي: “جيد” عند أو أقل من 2,5 ثانية؛ قسّم الجوال وسطح المكتب. الإيقاع: أسبوعيًا، مع تسجيل نافذة CrUX المتدحرجة.

توزيع الأجزاء الفرعية لـ LCP

المقياس: TTFB، وتأخير تحميل المورد، ومدة التحميل، وتأخير عرض العنصر لـ LCP. ما يخبرك به: أي مرحلة تمتلك الانتظار. كيفية سحبه: تتبعات مختبرية تمثيلية وأجزاء فرعية لصورة LCP من CrUX/RUM حيثما توفرت. المعيار / النطاق الواقعي: استخدم التقسيم التشخيصي التقريبي 40/10/40/10 من المقالة كدليل، وليس وعدًا عالميًا بالأداء. الإيقاع: بعد إصدارات القوالب وشهريًا للقوالب ذات الأولوية.

تغطية عناوين URL ذات LCP جيد

المقياس: مجموعات عناوين URL المهمة ذات LCP ميداني جيد. ما يخبرك به: ما إذا كان التحسين واسعًا أم مقتصرًا على صفحة عينة. كيفية سحبه: مجموعات CWV في Search Console بالإضافة إلى CrUX على مستوى عنوان URL للصفحات ذات الأولوية. المعيار / النطاق الواقعي: أنشئ خطًا أساسيًا حسب القالب؛ قد تفتقر عناوين URL منخفضة الحركة إلى بيانات ميدانية فردية. الإيقاع: أسبوعيًا.

اختبر نفسك: Largest Contentful Paint

خمسة أسئلة سريعة حول قياس LCP وتشخيصه. اختر إجابة لكل سؤال، ثم تحقق.

موارد تستحق وقتك

كتاباتي ذات الصلة

• ما أكبر رسم للمحتوى (LCP) وكيف تحسّنه — دليلي الكامل حول LCP على مدونة Ahrefs.
• ما مؤشرات الويب الأساسية (CWVs) وكيف تحسّنها — كيف يتناسب LCP مع INP وCLS، ولماذا هو الأصعب في الإصلاح.
• دليل المبتدئين إلى تحسين محركات البحث التقني — أين يقع أداء الصفحة في الصورة الأكبر.

رسمي (Google / Chrome)

• Largest Contentful Paint (LCP) وOptimize LCP — الزوج الأساسي.
• How CWV thresholds were defined — السبب وراء 2,5 ثانية.

من مصادر أخرى

• إصلاح Largest Contentful Paint لموقعك من خلال تحسين تحميل الصور — نظرة MDN الموجهة للمطورين، قوية في التعامل مع تنازع النطاق الترددي والنمط المعاكس للصور المعتمدة على JavaScript.
• الأداء — 2025 Web Almanac — الغوص السنوي العميق من HTTP Archive؛ مصدر لإحصائيات التبني حول fetchpriority، واستخدام preload، وتوزيع LCP بين الصور والنصوص، ومعدلات النجاح حسب الجهاز.
• Largest Contentful Paint (LCP) — توثيقات DebugBear تغطي تحليل مخطط الشلال لتحديد الأجزاء الفرعية، وتحذيرات JPEG التدريجي، وحالات الحافة المتعلقة بالإطارات المدمجة والتنقل الناعم.
• Largest Contentful Paint (LCP): ما هو، وكيف تقيسه وتحسّنه — corewebvitals.io؛ معايير RUM حقيقية، ودراسات حالة لتأثير الأعمال (Vodafone Italy)، ونتيجة fetchpriority من Google Flights.
• Largest Contentful Paint | MDN Web Docs — مرجع MDN لواجهة برمجة التطبيقات LargestContentfulPaint، وأنواع العناصر، وتوافق المتصفحات.

إحصائيات جديرة بالاستشهاد

• LCP هو أصعب Core Web Vital لتحقيقه. فهو يحتوي على أكبر عدد من المكونات، ولهذا يواجه المواقع صعوبة فيه أكثر من INP أو CLS. المصدر
• الجوال أصعب من سطح المكتب. المعالجات والاتصالات الأبطأ ترفع LCP، وعلى اتصالات 3G/البطيئة يكاد يكون من المستحيل الوصول إلى عتبة 2,5 ثانية. المصدر
• وقت تنزيل الصورة غالبًا ما يكون الجزء الأصغر من LCP. وجد تحليل Chrome لبيانات HTTP Archive أن مدة التنزيل غالبًا ليست هي عنق الزجاجة — بل عادةً ما تكون TTFB وتأخير الاكتشاف هما السبب. المصدر
• تغطية CrUX ضعيفة. في دراستنا لـ 42 مليون صفحة، كان لدى ~11,4% فقط بيانات ميدانية مرتبطة بـ CrUX — معظم الصفحات لا تحصل على حركة مرور كافية من مستخدمين حقيقيين ليتم قياسها. المصدر
• 62% من صفحات الجوال مقابل 74% من صفحات سطح المكتب تحقق LCP جيدًا (2025 Web Almanac). تعكس فجوة الجوال المعالجات الأبطأ واتصالات الشبكة. المصدر
• فقط 2,1% من صفحات الجوال تقوم بتحميل صورة LCP الخاصة بها مسبقًا، على الرغم من أن 76% لديها صورة كعنصر LCP — وهي فرصة تحسين كبيرة ضائعة (2025 Web Almanac). المصدر
• نمو اعتماد fetchpriority="high" من 0,03% من مواقع الجوال في 2022 إلى 17,3% في 2025، مدفوعًا إلى حد كبير بإضافته في نواة WordPress (2025 Web Almanac). شهد Google Flights تحسنًا في LCP بمقدار 700 مللي ثانية من هذه السمة الواحدة. المصدر

فيديوهات

• Google Search Central (يوتيوب) — شروحات Core Web Vitals وتجربة الصفحة، بما في ذلك جولات فريق Chrome حول تحسين LCP. القناة

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