أول عرض ذي محتوى (FCP)
ما الذي يقيسه FCP، وما نتيجته الجيدة، ولماذا ليس مؤشر أداء ويب أساسيًا، وكيف يختلف عن First Paint وLCP، وكيف تصلح بطئه.
اللغات
FCP هو الزمن من بدء تحميل الصفحة حتى أول عرض لنص أو صورة أو SVG أو canvas غير أبيض. النتيجة الجيدة ≤ 1,8 ثانية عند المئين 75 من المستخدمين الحقيقيين. ليس مؤشر أداء ويب أساسيًا؛ إشارات الترتيب هي LCP وINP وCLS. وهو مقياس تشخيصي للمختبر والميدان يسبق LCP ويفيد في كشف الموارد الحاجبة للعرض وTTFB البطيء. في Lighthouse 10 وزنه 10 %. أصلحه بإزالة CSS وJavaScript الحاجبين، وخفض TTFB، وتضمين CSS الحرج، واستخدام font-display: swap، والاتصال المسبق بالأصول المطلوبة.
الخلاصة — يحدث أول عرض ذي محتوى (FCP) عندما يرى الزائر أول جزء من الصفحة — نصًا أو صورة أو رسمًا — بدل شاشة بيضاء. كلما كان أسرع كان أفضل، وتُعد المدة الأقل من 1,8 ثانية جيدة. وهو فحص مفيد للسرعة، لكنه ليس من المقاييس التي يستخدمها Google للترتيب.
ما FCP فعليًا؟
عندما ينقر شخص رابط صفحتك، يظل أمام شاشة فارغة برهة بينما يجلب المتصفح الصفحة ويعالجها. أول عرض ذي محتوى هو اللحظة التي تتحول فيها الشاشة الفارغة إلى شيء حقيقي: عنوان أو شعار أو صورة أو أي عنصر يراه الزائر.
هذه هي الفكرة كلها. يجيب FCP: «كم يلزم حتى يرى المستخدم أن الصفحة حية وتعمل؟» تبدو الصفحة التي تعرض محتوى خلال نصف ثانية سريعة، أما بقاؤها فارغة ثلاث ثوان فيوحي بأنها معطلة ويدفع الناس إلى المغادرة.
Evidence for this claim FCP measures from navigation until the first text, image, SVG, or non-white canvas content is rendered. Scope: Current web.dev FCP definition and qualifying content types. Confidence: high · Verified: web.dev: First Contentful Paintما الذي يُعد «محتوى»؟
يُسجَّل FCP عندما يرسم المتصفح أيًا مما يلي على الشاشة:
- نص، مثل عنوان أو فقرة أو رابط تنقل
- صور، بما فيها صور الخلفية
- رسوم
<svg> - عنصر
<canvas>غير أبيض
لا يُحتسب لون خلفية عادي وحده؛ فذلك حدث أسبق مختلف يسمى First Paint. لا يحتسب FCP إلا عند ظهور محتوى حقيقي.
ما النتيجة الجيدة؟
نطاقات Google المقاسة لدى الزوار الحقيقيين:
| زمن FCP | التقييم |
|---|---|
| 1,8 ثانية أو أقل | جيد |
| 1,8–3,0 ثوانٍ | يحتاج إلى تحسين |
| أكثر من 3,0 ثوانٍ | ضعيف |
ستجد FCP في أدوات مثل PageSpeed Insights وLighthouse، ضمن التقارير نفسها التي تعرض مؤشرات أداء الويب الأساسية.
هل يؤثر FCP في ترتيبي على Google؟
لا، ليس مباشرة. المقاييس الثلاثة التي يستخدمها Google للترتيب هي LCP وINP وCLS، وليس FCP أحدها.
ومع ذلك يستحق المتابعة لأن أسباب بطئه — خادم بطيء وملفات CSS أو JavaScript كبيرة تحجب العرض — كثيرًا ما تضر LCP أيضًا، وهو إشارة ترتيب. قد يساعد إصلاح جذور مشكلة FCP في LCP، لكن ذلك ليس مضمونًا لأن لـLCP أسبابًا خاصة مثل حجم أكبر عنصر وأولوية تحميله. تعامل مع FCP كإنذار دخان، لا دليلًا على انتهاء الحريق.
إصلاحات سريعة
إذا كان FCP بطيئًا، فهذه أبرز الأسباب وما ينبغي فعله:
- ملفات تحجب العرض. قد تمنع CSS وJavaScript في
<head>المتصفح من الرسم حتى يكتمل تحميلها، وهذا السبب الأول. - خادم بطيء. لا يستطيع المتصفح الرسم قبل وصول البايتات؛ لذا يرفع زمن الاستجابة الطويل TTFB.
- خطوط تخفي النص. قد يبقى النص غير مرئي حتى ثلاث ثوان أثناء تحميل خط الويب؛ ويعرض
font-display: swapنصًا بديلًا فورًا.
هل تريد التفاصيل التقنية والفارق بين المختبر والميدان وسلسلة تشخيص FCP/LCP وقائمة الإصلاح الكاملة؟ انتقل إلى تبويب متقدم.
الخلاصة — يقيس FCP الزمن من بدء التنقل حتى عرض أي محتوى: نص أو صورة أو
<svg>أو<canvas>غير أبيض. وهو ليس مؤشر أداء ويب أساسيًا، بل مقياس تشخيصي إضافي في المختبر والميدان وجزء سابق من LCP. حدود الميدان عند المئين 75: جيد ≤ 1,8 ث، ويحتاج إلى تحسين ≤ 3,0 ث، وضعيف > 3,0 ث. في Lighthouse 10 يمثل 10 % من نتيجة الأداء. ولأن ساعته تبدأ مع التنقل فهي تشمل التحويلات وإنشاء الاتصال وTTFB؛ لذلك قد تختلف نتائج Lighthouse وCrUX. ابدأ الإصلاح بموارد CSS/JS الحاجبة للعرض، ثم TTFB، ثم الخطوط.
ما الذي يقيسه FCP بدقة؟
تعريف Google في مقال Philip Walton على web.dev هو الأساس: “First Contentful Paint (FCP) measures the time from when the user first navigated to the page to when any part of the page’s content is rendered on the screen.” (ترجمة) «يقيس FCP الزمن من أول انتقال للمستخدم إلى الصفحة حتى عرض أي جزء من محتواها على الشاشة». ويعني المحتوى: “text, images (including background images), <svg> elements, or non-white <canvas> elements.” (ترجمة) «النص والصور، بما فيها صور الخلفية، وعناصر <svg>، وعناصر <canvas> غير البيضاء».
الكلمة الحاسمة هي أي. لا يهتم FCP بما يُعرض؛ فشعار بعرض 40 بكسل يعادل صورة بطل كاملة. إنه إشارة «هل ظهر أي شيء بعد؟»، ولذلك هو مؤشر مبكر لا مقياس اكتمال.
Evidence for this claim FCP measures from navigation until the first text, image, SVG, or non-white canvas content is rendered. Scope: Current web.dev FCP definition and qualifying content types. Confidence: high · Verified: web.dev: First Contentful Paintتفصيل مهم: تبدأ ساعة FCP عند التنقل، فتشمل ما يسبق حتى تحليل HTML. تقول Google: “FCP includes any unload time from the previous page, connection set up time, redirect time, and Time To First Byte (TTFB) which can be significant when measured in the field.” (ترجمة) «يشمل FCP زمن تفريغ الصفحة السابقة وإعداد الاتصال والتحويل وTTFB، وقد تكون كبيرة في القياس الميداني». فإذا استغرق الخادم 1,5 ثانية فقد استهلك معظم ميزانية 1,8 ثانية قبل معالجة أول بايت.
FCP ليس مؤشر أداء ويب أساسيًا
FCP ليس مؤشر أداء ويب أساسيًا ولا يدخل ضمن إشارات ترتيب Google. المؤشرات الأساسية هي LCP وINP وCLS، ولا تذكر صفحة Google الخاصة بالترتيب FCP.
يصنفه Google ضمن «مؤشرات الويب الأخرى»، أي مقياس إضافي مفيد للتشخيص. وتقول web.dev: “the metrics Time to First Byte (TTFB) and First Contentful Paint (FCP) are both vital aspects of the loading experience, and are both useful in diagnosing issues with LCP (slow server response times or render-blocking resources, respectively).” (ترجمة) «يمثل TTFB وFCP جانبين مهمين من تجربة التحميل ويفيدان في تشخيص مشكلات LCP، أي بطء استجابة الخادم والموارد الحاجبة للعرض على الترتيب».
لذلك ينبغي عرض الأمر لأصحاب المصلحة بجانبيه:
- لا يؤثر FCP في الترتيب مباشرة. لا تحسّنه «لأجل SEO».
- FCP أداة تشخيص ممتازة لـLCP الذي يؤثر في الترتيب. تظهر الموارد الحاجبة للعرض أولًا في FCP.
FCP مقابل First Paint (FP)
كثيرًا ما يختلطان:
- FP يحدث عندما يرسم المتصفح أي شيء، حتى لون خلفية بلا محتوى.
- FCP يحدث فقط عند عرض محتوى مؤهل: نص أو صور، بما فيها الخلفية، أو
<svg>أو<canvas>غير أبيض. هذه قائمة محددة في المواصفة، لا قاعدة فضفاضة عن محتوى DOM.
لذلك FP ≤ FCP دائمًا. وغالبًا يتقاربان لأن رسم خلفية بلا محتوى نادر. وإذا ظهر فرق ملحوظ فغالبًا رُسمت خلفية تجميلية قبل المحتوى الحقيقي. تعيد Paint Timing API مدخلَي first-paint وfirst-contentful-paint، لكن FCP هو الأجدر بالتحليل؛ إذ نادرًا ما يقدم FP إجراءً مفيدًا.
FCP مقابل LCP
الزوج الآخر الذي يخلطه الناس:
- FCP: وقت عرض أي محتوى؛ قد يكون شعارًا صغيرًا أو رابط تنقل.
- LCP: وقت عرض أكبر عنصر في إطار العرض؛ يحدث عند FCP أو بعده.
تقول Google إن FCP يقيس عرض أي محتوى وLCP عرض المحتوى الرئيسي، أي أن LCP أكثر انتقائية. لكن لا يثبت أيهما أن المحتوى الرئيسي الحقيقي اكتمل أو أفاد الزائر. قد يكون FCP سريعًا عند 0,5 ثانية لشعار، وLCP بطيئًا عند 4 ثوانٍ لصورة البطل؛ والفارق تشخيص مفيد. وتقاربهما غالبًا علامة جيدة لأن أول عنصر معروض هو الأكبر أيضًا.
Evidence for this claim FCP answers when any eligible content first appears, while LCP tracks the largest eligible viewport candidate; neither metric proves the page's main content is complete or useful. Scope: field and lab Confidence: high · Verified: First Contentful Paint (FCP)وقد تبلغ واجهة المتصفح في حالات نادرة أن LCP أسبق من FCP بسبب قيود أمان توقيت الصور عبر الأصول. هذه شذوذ قياس، لا ترتيب حدث فعلي.
الحدود ولماذا تختلف نتائج المختبر والميدان
حدود الميدان (CrUX، المئين 75): جيد ≤ 1,8 ث · يحتاج إلى تحسين ≤ 3,0 ث · ضعيف > 3,0 ث. توصي Google بالقياس عند المئين 75 من عمليات التحميل، مع فصل الجوال وسطح المكتب.
Evidence for this claim A good FCP is 1.8 seconds or less at the 75th percentile; above 3 seconds is poor. Scope: Current web.dev FCP field thresholds. Confidence: high · Verified: web.dev: First Contentful Paintلكن Lighthouse لسطح المكتب يستخدم حدودًا أشد: أخضر نحو 0–0,9 ث، وبرتقالي 0,9–1,6 ث، وأحمر فوق 1,6 ث، لأن المختبر يشغل Chrome نظيفًا ومقيدًا على جهاز محاكى. وهذه الحدود والأوزان مرتبطة بإصدار Lighthouse. وتقول الوثائق إن نتيجة FCP تقارن زمن صفحتك بأزمنة مواقع حقيقية اعتمادًا على HTTP Archive.
هذا أكثر مصادر الالتباس شيوعًا:
حد «الجيد» 1,8 ثانية خاص بالميدان (CrUX عند المئين 75)، أما الخط الأخضر في Lighthouse لسطح المكتب فنحو 0,9 ثانية. إنهما مقياسان لمهمتين مختلفتين.
تختلف أرقام المختبر والميدان أساسًا لأنهما يعاينان مجموعات مختلفة، لا لأن أحدهما أصح دائمًا. Lighthouse جلسة نظيفة واحدة بشروط ثابتة؛ أما CrUX فيجمع أجهزة وشبكات وحالات ذاكرة تخزين وأنواع تنقل حقيقية، بما فيها استعادة bfcache والصفحات المعروضة مسبقًا التي تحتاج معالجة دورة حياة خاصة توفرها مكتبة web-vitals. غالبًا يكون رقم الميدان أعلى بسبب التحويلات وتفريغ الصفحة والاتصالات الباردة، لكنه ليس قانونًا. قارن الشروط المتشابهة، واستخدم الميدان للواقع وLighthouse للتشخيص.
موضع FCP في نتيجة Lighthouse
في Lighthouse 10 — الإصدار الحالي وقت الكتابة لا رقم دائم — يمثل FCP 10 % من نتيجة الأداء:
| المقياس | الوزن |
|---|---|
| TBT | 30 % |
| LCP | 25 % |
| CLS | 25 % |
| FCP | 10 % |
| Speed Index | 10 % |
نتيجة الأداء متوسط موزون لنتائج المقاييس، وتقول Google إن الأوزان تتغير مع البحث. ظل FCP عند 10 % من Lighthouse 8 إلى 10، لكن تحقق من إصدارك قبل اعتبار الرقم ثابتًا. لا تستطيع نتيجة FCP مثالية وحدها تحريك النتيجة إلا بقدر محدود؛ وقد يشير FCP السيئ إلى LCP سيئ لاشتراكهما في الأسباب، لكنه تداخل ينبغي فحصه لا ضمانًا.
أسباب بطء FCP
بالترتيب التقريبي للأولوية:
- موارد تحجب العرض: CSS وJavaScript المتزامن في
<head>يمنعان بناء CSSOM وشجرة العرض حتى التنزيل والتحليل. - TTFB مرتفع: لا يحدث FCP قبل وصول البايتات، وزمن الخادم داخل قياسه.
- سلاسل تحويل: كل تحويل رحلة شبكة كاملة قبل أول بايت.
- استراتيجية خطوط الويب: قد يخفي
font-display: blockأو غياب القاعدة النص حتى نحو 3 ثوانٍ.
كيفية إصلاحه
هذه قائمة مرتبة للأدوات الشائعة لا وصفة عالمية. افحص أثر صفحتك أو شريطها المصور أولًا لتعرف المورد أو المرحلة التي تؤخر مرشح FCP قبل تطبيق preconnect أو preload أو تغيير الخط بلا داع.
ابدأ بهذه، فهي الأكبر أثرًا:
- أزل CSS وJavaScript الحاجبين للعرض. ضمّن CSS الحرج أعلى الصفحة في
<head>، وحمّل الباقي لا تزامنيًا، وأضفasyncأوdeferللنصوص غير الحرجة. نقل وسم<link>لا يفيد؛ فلا يرسم المتصفح قبل تحميل CSS كله وتحليله. - اخفض TTFB. التخزين المؤقت وCDN وأصل أسرع تسرّع أول بايت وتخفض FCP مباشرة.
- أصلح تحميل الخط. استخدم
font-display: swapلعرض خط بديل فورًا أوfont-display: optionalلتخطي خط غير مخزن، وتجنبfont-display: blockللنص الحرج.
ثم رتّب البقية:
- استخدم preconnect للأصول المطلوبة عبر
<link rel="preconnect">؛ فقد يوفر الاتصال المبكر 100–500 مللي ثانية. - حمّل الطلبات الأساسية مسبقًا عبر
<link rel="preload">لخط حرج أو صورة LCP. - صغّر CSS وأزل CSS وJavaScript غير المستخدمين.
- تجنب التحويلات المتعددة والحمولات الضخمة، واستخدم سياسة تخزين فعالة، وتجنب DOM مفرط الحجم وقلل عمق الطلبات الحرجة.
سلسلة تشخيص FCP ← TTFB ← LCP
هذه طريقة استخدام FCP عمليًا: عامل مقاييس التحميل الثلاثة كسير عمل واحد:
- إذا كان FCP مرتفعًا، افحص موارد العرض الحاجبة في
<head>؛ فهي السبب الأشهر وأسرع مكسب. - افحص TTFB أيضًا؛ لأنه جزء من FCP وقد يرفعه قبل دخول موارد العرض. ينبغي أن يستجيب الخادم بسرعة تكفي لتحقيق FCP جيد عند المئين 75.
- غالبًا تمتد المشكلات نفسها إلى LCP، وهو إشارة ترتيب. لكن ذلك ليس ضمانًا؛ فلـLCP عوامل خاصة بحجم أكبر عنصر وأولويته ومسار تحميله. إصلاح FCP نقطة البداية لا النهاية.
هذه قيمة FCP لمتخصص SEO: قراءة مبكرة ورخيصة لصحة مسار التحميل قبل اكتمال قياس LCP الأكثر انتقائية.
ملخص الذكاء الاصطناعي
خلاصة موجزة للنسخة المتقدمة:
- FCP هو الزمن من بدء التنقل حتى عرض أي محتوى: نص أو صورة، بما فيها الخلفية، أو
<svg>أو<canvas>غير أبيض. - ليس مؤشر أداء ويب أساسيًا. إشارات الترتيب هي LCP وINP وCLS؛ وهو مقياس تشخيصي للمختبر والميدان لا عامل ترتيب مباشرًا.
- هو لبنة في LCP وقد يكشف موارد العرض الحاجبة وTTFB البطيء، لكن إصلاحه لا يضمن إصلاح LCP لأن للأخير عوامل خاصة.
- حدود الميدان: جيد ≤ 1,8 ث، يحتاج إلى تحسين ≤ 3,0 ث، ضعيف > 3,0 ث.
- المختبر لا يساوي الميدان. خط Lighthouse الأخضر نحو 0,9 ث أشد من حد الميدان 1,8 ث؛ قارن مجموعات متشابهة وراع bfcache والعرض المسبق.
- FP مقابل FCP: يرسم FP أي شيء، بينما يحتاج FCP إلى محتوى مؤهل؛ FP ≤ FCP.
- FCP مقابل LCP: الأول لأي مرشح مؤهل والثاني لأكبر مرشح؛ كلاهما وكيل لا إثبات اكتمال، وقد يكون FCP سريعًا وLCP بطيئًا.
- أوزان Lighthouse 10: TBT 30 %، وLCP 25 %، وCLS 25 %، وFCP 10 %، وSpeed Index 10 %؛ وقد تتغير بين الإصدارات.
- الإصلاحات: أزل CSS/JS الحاجبين، اخفض TTFB، أصلح الخطوط (
font-display: swap/optional)، ثم preconnect وpreload والتصغير والتخزين وضبط DOM.
الوثائق الرسمية
وثائق Google الأولية عن FCP.
web.dev (Google)
- First Contentful Paint (FCP) — التعريف وقائمة المحتوى وحد 1,8 ثانية والقياس.
- Web Vitals — موضع FCP كمؤشر مساعد لتشخيص LCP.
- Largest Contentful Paint (LCP) — الفرق والعلاقة بين FCP وLCP.
- Time to First Byte (TTFB) — لماذا يسبق TTFB مقياس FCP ويدخل فيه.
- User-centric performance metrics — تصنيف FCP مقياسًا مختبريًا وميدانيًا.
Lighthouse / Chrome Developers
- تدقيق First Contentful Paint — نطاقات سطح المكتب، ومنها الأخضر ≤ 0,9 ث، ومقارنة النتيجة ببيانات HTTP Archive.
- حساب نتيجة الأداء في Lighthouse — أوزان المقاييس، ومنها وزن FCP البالغ 10 % في Lighthouse 10.
Google Search Central
- مؤشرات أداء الويب الأساسية وبحث Google — تسرد LCP وINP وCLS ولا تتضمن FCP.
اقتباسات من المصدر
تصريحات مسجلة من وثائق Google، مع روابط عميقة إلى المواضع الأصلية.
web.dev: التعريف
- “First Contentful Paint (FCP) measures the time from when the user first navigated to the page to when any part of the page’s content is rendered on the screen.” (ترجمة) «يقيس FCP الزمن من أول انتقال للمستخدم إلى الصفحة حتى عرض أي جزء من محتواها على الشاشة». — Philip Walton، First Contentful Paint (FCP)، web.dev، محدّث في 6 ديسمبر 2023. الانتقال إلى الاقتباس
web.dev: الحد
- “sites should strive to have a First Contentful Paint of 1.8 seconds or less.” (ترجمة) «ينبغي للمواقع السعي إلى FCP قدره 1,8 ثانية أو أقل». — المصدر نفسه. الانتقال إلى الاقتباس
web.dev: ما يشمله FCP
- “FCP includes any unload time from the previous page, connection set up time, redirect time, and Time To First Byte (TTFB) which can be significant when measured in the field.” (ترجمة) «يشمل FCP زمن تفريغ الصفحة السابقة وإعداد الاتصال والتحويل وTTFB، وقد تكون كبيرة في الميدان». — المصدر نفسه.
web.dev: دور FCP بالنسبة إلى المؤشرات الأساسية
- “the metrics Time to First Byte (TTFB) and First Contentful Paint (FCP) are both vital aspects of the loading experience, and are both useful in diagnosing issues with LCP (slow server response times or render-blocking resources, respectively).” (ترجمة) «يمثل TTFB وFCP جانبين مهمين من تجربة التحميل ويفيدان في تشخيص مشكلات LCP، أي بطء استجابة الخادم والموارد الحاجبة للعرض على الترتيب». — Web Vitals، web.dev. الانتقال إلى الاقتباس
Lighthouse: طريقة حساب نتيجة FCP
- “Your FCP score is a comparison of your page’s FCP time and FCP times for real websites, based on data from the HTTP Archive.” (ترجمة) «تقارن نتيجة FCP زمن صفحتك بأزمنة FCP لمواقع حقيقية استنادًا إلى بيانات HTTP Archive». — First Contentful Paint audit، developer.chrome.com.
Lighthouse: آلية نتيجة الأداء
- “The Performance score is a weighted average of the metric scores.” (ترجمة) «نتيجة الأداء متوسط موزون لنتائج المقاييس».
- “The weightings have changed over time because the Lighthouse team is regularly doing research and gathering feedback to understand what has the biggest impact on user-perceived performance.” (ترجمة) «تغيرت الأوزان بمرور الوقت لأن فريق Lighthouse يواصل البحث وجمع الملاحظات لفهم أكبر أثر في الأداء الذي يدركه المستخدم».
#:~:text= ثابتًا، لذا تحقق منها في الصفحات الحية. أوزان Lighthouse خاصة بالإصدار 10. قائمة فرز بطء FCP
عندما يرتفع FCP، اتبع القائمة بالترتيب التقريبي لأكبر مكسب:
- افحص رقم الميدان لا Lighthouse وحده. اقرأ CrUX عند المئين 75 واستخدم Lighthouse للتشخيص.
- ابحث عن موارد تحجب العرض في
<head>؛ فهي السبب الأول. - ضمّن CSS الحرج وحمّل الباقي لا تزامنيًا.
- أضف
asyncأوdeferللنصوص غير الحرجة. - قس TTFB وأصلح الخادم أو التخزين أو CDN.
- أزل سلاسل التحويل.
- أصلح الخطوط: استخدم
font-display: swapأوoptionalولا تستخدمblockللنص الحرج. - استخدم preconnect وpreload بانتقائية.
- قلص الحمولة وDOM وعمق الطلبات.
- أعد فحص LCP وتحقق من تحركه؛ فهو المقياس المؤثر في الترتيب.
ورقة مرجعية سريعة لـFCP
حدود الميدان (CrUX، المئين 75)
| زمن FCP | التقييم |
|---|---|
| ≤ 1,8 ث | جيد |
| 1,8–3,0 ث | يحتاج إلى تحسين |
| > 3,0 ث | ضعيف |
تقييم Lighthouse لسطح المكتب (مختبر، أشد من الميدان)
| زمن FCP | اللون |
|---|---|
| 0–0,9 ث | أخضر، سريع |
| 0,9–1,6 ث | برتقالي، متوسط |
| أكثر من 1,6 ث | أحمر، بطيء |
أوزان نتيجة الأداء في Lighthouse 10، وهي مرتبطة بالإصدار
| المقياس | الوزن |
|---|---|
| TBT | 30 % |
| LCP | 25 % |
| CLS | 25 % |
| FCP | 10 % |
| Speed Index | 10 % |
فك الالتباس بين مقاييس التحميل الثلاثة
| المقياس | يحدث عندما | مؤشر أساسي؟ |
|---|---|---|
| FP | يرسم المتصفح أي شيء، حتى الخلفية | لا |
| FCP | يرسم أي محتوى حقيقي | لا، تشخيصي |
| LCP | يرسم أكبر عنصر مؤهل | نعم |
ترتيب الأحداث: FP ≤ FCP ≤ LCP.
ما يُعد محتوى لـFCP: نص · صور، بما فيها الخلفية · عناصر <svg> · عناصر <canvas> غير البيضاء.
حقائق سريعة
- تبدأ ساعة FCP عند التنقل وتشمل التحويل وإعداد الاتصال وTTFB.
- يمكن قياسه في المختبر والميدان.
font-display: استخدمswapأوoptionalوتجنبblockالذي قد يخفي النص نحو 3 ثوانٍ.- قد يوفر preconnect للأصول الخارجية 100–500 مللي ثانية.
أدوات قياس FCP
بيانات الميدان، أي المستخدمين الحقيقيين
- PageSpeed Insights — يعرض FCP الميداني من CrUX بجانب Lighthouse.
- CrUX — مجموعة بيانات المستخدمين الحقيقيين عبر API أو BigQuery.
- مكتبة web-vitals JavaScript — استخدم
onFCP(console.log)أو أرسل الناتج إلى التحليلات؛ وتعالج حالات bfcache وعلامات التبويب الخلفية.
بيانات المختبر المحاكاة
- Lighthouse في DevTools أو PageSpeed Insights أو CLI؛ استخدم تدقيق إزالة الموارد الحاجبة.
- لوحة Performance في Chrome DevTools — تعرض توقيت الرسم وما حجبه.
- WebPageTest — يتيح شريط صور بصريًا لمقارنة الرقم بما رآه المستخدم.
القياس مباشرة عبر Paint Timing API
new PerformanceObserver((entryList) => {
for (const entry of entryList.getEntriesByName('first-contentful-paint')) {
console.log('FCP candidate:', entry.startTime, entry);
}
}).observe({type: 'paint', buffered: true});أو استخدم مكتبة web-vitals، وهو الموصى به
import {onFCP} from 'web-vitals';
onFCP(console.log);لا تعالج API الخام ما تعالجه مكتبة web-vitals: تتجاهل FCP في علامات التبويب الخلفية، وتبلغ عن الاستعادة من bfcache مع معالجتها الصريحة، وتستخدم activationStart بدل بدء التنقل للصفحات المعروضة مسبقًا. ويبقى توقيت الرسم داخل iframe عبر أصل مختلف فجوة معروفة وقد يجعل FCP يبدو أسرع من الحقيقة.
أخطاء FCP التي تخفي عنق الزجاجة الحقيقي
- اعتبار FCP مؤشرًا أساسيًا. هو تشخيص مفيد، لكن LCP وINP وCLS هي المؤشرات الأساسية المستخدمة في أنظمة ترتيب Google.
- تحسين شعار صغير لأنه يصبح أول عرض. قد يتحسن الرقم مع بقاء المحتوى المفيد متأخرًا؛ افحص LCP وشريط الصور.
- البدء بضغط الصور بينما الصفحة فارغة. تكون العوائق المعتادة استجابة الخادم أو CSS الحاجب أو JavaScript المتزامن أو الخطوط؛ اتبع شلال الطلبات قبل تغيير أصول غير مرتبطة.
- مقارنة تشغيلات Lighthouse غير المتكافئة. تؤثر محاكاة الجهاز والشبكة وذاكرة التخزين وتفاوت التشغيل؛ قارن تشغيلات متكررة بالإعدادات نفسها وأكدها ببيانات الميدان.
ميزانية الشاشة الفارغة
قسّم FCP إلى ثلاثة أسئلة متتالية بدل معاملته كمشكلة واحدة:
- كم يستغرق وصول HTML؟ افحص TTFB؛ وإذا بطؤ فابدأ بالخادم والتخزين المؤقت والتحويلات وإعداد الاتصال.
- كم يستغرق تمكين العرض؟ افحص أوراق الأنماط والنصوص والخطوط الحاجبة وحدد ما يمنع أول محتوى مؤهل.
- هل أول محتوى مفيد؟ قارن FCP بشريط الصور وLCP؛ فقد يحسن عنصر رمزي مبكر الرقم من دون تحسين التجربة.
يبقي هذا الإطار الإصلاحات مرتبة: التسليم أولًا، ثم العرض، ثم الفائدة. أعد تشغيل ملف المختبر نفسه بعد كل تغيير لتعرف أي مرحلة تحركت.
اختبر نفسك: First Contentful Paint
خمسة أسئلة سريعة عن قياس FCP وتشخيصه. اختر إجابة لكل سؤال ثم تحقق.
مصادر تستحق وقتك
Google / web.dev
- First Contentful Paint (FCP) — المرجع الأساسي للتعريف والحدود والقياس والتحسين.
- Web Vitals — علاقة FCP بالمؤشرات الأساسية.
- Largest Contentful Paint (LCP) — المقياس الذي يساعد FCP في تشخيصه.
- Time to First Byte (TTFB) — مقياس استجابة الخادم داخل FCP.
Lighthouse
- تدقيق First Contentful Paint — حدود سطح المكتب وطريقة الحساب.
- حساب نتيجة الأداء في Lighthouse — أوزان المقاييس، ومنها FCP عند 10 %.
كتاباتي ذات الصلة
- دليل المبتدئين إلى Technical SEO — موضع سرعة الصفحة في الصورة الأكبر.
- مؤشرات أداء الويب الأساسية: ماهيتها وكيفية تحسينها — مقاييس إشارات الترتيب التي يغذيها FCP.
من مصادر المجال
- First Contentful Paint (FCP) — تعريف Google وحدوده وقياسه وتحسينه.
- Web Vitals — موضع FCP كمؤشر ويب آخر.
- تدقيق First Contentful Paint — حدود Lighthouse وطريقة الحساب.
- Time to First Byte (TTFB) — لماذا يسبق TTFB مقياس FCP.
- إزالة الموارد الحاجبة للعرض — السبب الأول لبطء FCP: CSS وJavaScript المتزامن في <head>.
- إبقاء النص ظاهرًا أثناء تحميل خط الويب — قيم font-display ولماذا يؤخر
blockالعرض بينما يبقيswapأوoptionalالنص ظاهرًا. - First Contentful Paint — دليل عملي مع توضيح الميدان والمختبر.
إحصاءات تستحق الاستشهاد
- FCP جيد = ≤ 1,8 ث عند المئين 75؛ ويحتاج إلى تحسين حتى 3,0 ث ثم يصبح ضعيفًا. المصدر
- Lighthouse لسطح المكتب أشد: نحو 0–0,9 ث هو الأخضر. المصدر
- FCP يمثل 10 % من نتيجة Lighthouse 10 إلى جانب TBT 30 % وLCP 25 % وCLS 25 % وSpeed Index 10 %. المصدر
- قد يوفر preconnect 100–500 مللي ثانية بإنشاء الاتصالات مبكرًا. المصدر
سجل التغييرات
تم التحديث في 11 أغسطس 2026.
ملخص تحريري وتفاصيل التغيير المسجلة.تفاصيل التغيير
-
تفاصيل التغيير متاحة حاليًا باللغة الإنجليزية.
-
تفاصيل التغيير متاحة حاليًا باللغة الإنجليزية.
المقارنة الكاملة غير متاحة — لم تُؤرشف لقطة سابقة لهذه المراجعة.
تم التحديث في 11 أغسطس 2026.
ملخص تحريري وتفاصيل التغيير المسجلة.تفاصيل التغيير
-
تفاصيل التغيير متاحة حاليًا باللغة الإنجليزية.
-
تفاصيل التغيير متاحة حاليًا باللغة الإنجليزية.
-
تفاصيل التغيير متاحة حاليًا باللغة الإنجليزية.
المقارنة الكاملة غير متاحة — لم تُؤرشف لقطة سابقة لهذه المراجعة.
تم التحديث في 17 يوليو 2026.
ملخص تحريري وتفاصيل التغيير المسجلة.تفاصيل التغيير
-
تفاصيل التغيير متاحة حاليًا باللغة الإنجليزية.
المقارنة الكاملة غير متاحة — لم تُؤرشف لقطة سابقة لهذه المراجعة.