Core Web Vitals ثلاثة مؤشّرات وضعتها Google لقياس تجربة المستخدم الحقيقية على الصفحة: LCP يقيس سرعة ظهور أكبر عنصر مرئي (الهدف أقل من 2.5 ثانية)، وINP يقيس سرعة استجابة الصفحة لتفاعلات المستخدم (الهدف أقل من 200 مللي ثانية)، وCLS يقيس ثبات التخطيط ومقدار «قفز» العناصر (الهدف أقل من 0.1). تُقاس هذه المؤشّرات على بيانات الميدان (مستخدمون حقيقيون عبر تقرير تجربة Chrome) لا على المختبر وحده، وهي ما يعتمده محرّك البحث ضمن إشارات تجربة الصفحة. لتمرير الثلاثة تحتاج أن يكون 75% من زياراتك ضمن النطاق «الجيّد» لكل مؤشّر. هذا الدليل يشرح كل مؤشّر بعمق: ما يقيسه، عتباته، أسبابه السيّئة وحلولها، وكيف تقيسه وتشخّصه خطوة بخطوة.
هذا المرجع شامل ويصلح لأي منصّة — ووردبريس، متجر مخصّص، تطبيق حديث، أو صفحة ثابتة — لأن مبادئ هذه المؤشّرات واحدة وإن اختلفت أدوات التنفيذ. سنفصّل كل مؤشّر على حدة مع جداول عتبات وأسباب وحلول، ثم نختم بالقياس والتشخيص والأخطاء الشائعة.
ما هي Core Web Vitals وما أهدافها؟
Core Web Vitals (يُختصر CWV، ويُترجم «مؤشّرات الويب الأساسية») مجموعة فرعية من مقاييس تجربة الصفحة التي تعتبرها Google جوهرية لكل المواقع. الفكرة أن سرعة الصفحة الإجمالية رقم مجرّد لا يصف ما يشعر به الزائر فعلًا، بينما هذه المؤشّرات الثلاثة تقيس أبعادًا ملموسة من التجربة: هل ظهر المحتوى بسرعة؟ هل استجابت الصفحة لمسي؟ هل ثبتت العناصر دون قفز؟
المؤشّرات الثلاثة الحالية:
- LCP (Largest Contentful Paint): الزمن حتى يُرسم أكبر عنصر مرئي داخل إطار الشاشة — يقيس سرعة التحميل المُدركة.
- INP (Interaction to Next Paint): الزمن من تفاعل المستخدم حتى يرى استجابة مرئية على الشاشة — يقيس الاستجابية (Responsiveness).
- CLS (Cumulative Layout Shift): مجموع تزحزحات التخطيط غير المتوقّعة أثناء عمر الصفحة — يقيس الثبات البصري.
كل مؤشّر له ثلاثة نطاقات: جيّد (يجتاز)، يحتاج تحسينًا، وضعيف. والشرط الرسمي لاعتبار الصفحة «جيّدة» في مؤشّر ما هو أن يقع المئين 75 (p75) من زياراتها ضمن النطاق الجيّد — أي أن ثلاثة أرباع التجارب على الأقل سريعة، لا المتوسّط فقط.
| المؤشّر | ماذا يقيس | البُعد | الوحدة | متى يُحسَب |
|---|---|---|---|---|
| LCP | سرعة ظهور أكبر عنصر مرئي | التحميل المُدرك | ثانية (s) | أثناء تحميل الصفحة |
| INP | سرعة الاستجابة للتفاعل | الاستجابية | مللي ثانية (ms) | عبر كامل الجلسة |
| CLS | ثبات التخطيط البصري | الاستقرار البصري | رقم بلا وحدة | طوال عمر الصفحة |
النقطة الجوهرية التي تخلط على كثيرين: هذه المؤشّرات تُقاس ميدانيًا على بيانات مستخدمين حقيقيين، لا على نتيجة مختبر واحدة. قد يعطيك المختبر نتيجة ممتازة بينما يعاني زوّارك على أجهزة وشبكات أبطأ — وما يعتمده محرّك البحث ويُحكم به على صفحتك هو الميدان.
يجدر التنبيه أيضًا إلى أن Core Web Vitals مجموعة متطوّرة لا ثابتة؛ غيّرت Google مكوّناتها أكثر من مرّة لتعكس فهمًا أدقّ للتجربة. فقد كان المؤشّر الثالث للاستجابية هو FID (تأخّر أول إدخال) حتى استُبدل بـINP في مارس 2024 لأنه أصدق تعبيرًا عن استجابية الصفحة على امتداد الجلسة. لذا تابع التحديثات، لكن المبادئ الأساسية — سرعة الظهور، وسرعة الاستجابة، وثبات التخطيط — تبقى ثابتة مهما تغيّرت تفاصيل القياس. وتذكّر أن هذه المؤشّرات تقيس الصفحة كما يراها الزائر، لا صحّة الخادم وحدها؛ فقد يكون خادمك سريعًا بينما صفحة بعينها تفشل بسبب صورة ثقيلة أو سكربت إعلاني، والعكس صحيح.
لماذا تهمّ هذه المؤشّرات؟ السرعة مقابل الارتداد
Core Web Vitals ليست تمرينًا تقنيًا بل ترجمة رقمية لتجربة تؤثّر مباشرة في سلوك الزائر وفي ترتيب البحث. الزائر — خاصّة على الجوال — لا يصبر على صفحة بطيئة أو تقفز عناصرها تحت إصبعه؛ يضغط زرّ الرجوع ويغادر، وهو ما يُعرف بـ«الارتداد». كلّما تأخّر ظهور المحتوى (LCP سيّئ) أو تأخّرت الاستجابة للنقر (INP سيّئ) أو قفزت الأزرار لحظة الضغط (CLS سيّئ)، ارتفع احتمال المغادرة وانخفض التحويل.
| المحور | أثر تردّي CWV | المؤشّر الأكثر تأثيرًا |
|---|---|---|
| معدّل الارتداد | يرتفع كلّما تأخّر المحتوى أو قفز | LCP وCLS |
| إكمال المهمّة/التحويل | ينخفض مع بطء الاستجابة والقفز | INP وCLS |
| ترتيب البحث | إشارة سلبية ضمن تجربة الصفحة | الثلاثة |
| رضا الزائر | يتراجع مع كل احتكاك مُدرك | الثلاثة |
Google تستخدم Core Web Vitals ضمن إشارات تجربة الصفحة في الترتيب. ليست العامل الأقوى — المحتوى وملاءمته يبقيان الأساس — لكنها مُرجّحة بين صفحتين متقاربتين في الجودة، وتجاوزها شرط لجزء من ميزات نتائج البحث. الأهمّ أنها تقيس ما يلمسه الزائر فعلًا، فتحسينها يحسّن التجربة والأعمال معًا. لرؤية أوسع لتسريع الموقع كاملًا راجع الدليل الشامل لتسريع موقعك.
ما هو LCP وكيف تحسّنه؟
LCP (Largest Contentful Paint — «رسم أكبر محتوى») هو الزمن من بدء تحميل الصفحة حتى يُرسَم أكبر عنصر محتوى مرئي داخل إطار الشاشة (Viewport). هذا العنصر غالبًا الصورة الرئيسية (Hero)، أو كتلة عنوان كبيرة، أو فيديو أو خلفية. المؤشّر يجيب عن سؤال الزائر الأول: «متى رأيت المحتوى الأساسي للصفحة؟»
عتبات LCP
| النطاق | القيمة | الحُكم |
|---|---|---|
| جيّد | أقل من 2.5s (≤ 2.5 ثانية) | يجتاز |
| يحتاج تحسينًا | 2.5s – 4s | على الحدّ |
| ضعيف | أكثر من 4s (> 4 ثوانٍ) | يفشل |
أسباب LCP السيّئ وحلولها
LCP يتألّف عمليًا من أربع مراحل: زمن استجابة الخادم (TTFB)، ثم تأخّر تحميل المورد، ثم زمن تحميل المورد نفسه، ثم تأخّر رسمه. المعالجة تكون بمطاردة المرحلة الأبطأ:
| السبب | كيف يظهر | الحلّ |
|---|---|---|
| TTFB مرتفع (خادم بطيء/بلا كاش) | تأخّر قبل أي بايت | استضافة أقوى + كاش صفحة — دليل الكاش |
| صورة LCP ثقيلة أو بصيغة قديمة | أكبر عنصر بطيء التحميل | AVIF/WebP + أبعاد صحيحة + ضغط |
| مورد LCP يُكتشَف متأخّرًا | المتصفّح يجده بعد تحليل كثير | preload + fetchpriority="high" |
| موارد حاجبة للرسم (CSS/JS) | الرسم ينتظر تحميل الأصول | Critical CSS + تأجيل JS غير الحرج |
| صورة LCP كسولة التحميل | أهمّ عنصر يُؤجَّل | أزل loading="lazy" عن عنصر LCP |
| خطّ يؤخّر النص (إن كان LCP نصًّا) | النص لا يظهر حتى يجهز الخطّ | font-display: swap + preload للخطّ |
لفهم LCP عمليًا، تخيّل صفحة مقال نموذجية: المتصفّح يطلب الصفحة، ينتظر ردّ الخادم (TTFB)، ثم يبدأ تحليل HTML، يكتشف أثناءه الصورة الرئيسية فيطلبها، ينتظر تحميلها، ثم يرسمها. أي تأخّر في أيٍّ من هذه الحلقات يُضاف إلى LCP النهائي. لذا لا يكفي «ضغط الصورة» إن كان الخادم بطيئًا أصلًا، ولا يكفي خادم سريع إن كانت الصورة بحجم عدّة ميغابايت بصيغة قديمة. عالج الحلقة الأبطأ أوّلًا: قِس كل مرحلة في WebPageTest أو DevTools واعرف أين يضيع الجزء الأكبر من الزمن قبل أن تحسّن.
أقوى مكسبين عادةً: خفض TTFB (استضافة + كاش) وتحميل صورة LCP مسبقًا. مثال على تحميل مسبق لصورة LCP مع رفع أولويتها:
<link rel="preload" as="image" href="/hero.avif" fetchpriority="high" />
نصيحة خبير: لا تجعل أبدًا الصورة الرئيسية (عنصر LCP المتوقّع) كسولة التحميل (lazy). التحميل الكسول ممتاز للصور أسفل الطيّة، لكنه كارثي إذا طُبّق على أهمّ عنصر فوقها. حدّد عنصر LCP فعليًا في DevTools أوّلًا، ثم عامِله بأولوية قصوى. لتفاصيل تحسين الصور والخطوط على ووردبريس تحديدًا راجع دليل تسريع ووردبريس.
جاهز لإطلاق موقعك على استضافة سريعة؟
خطط استضافة wpressly على أقراص NVMe مع SSL مجاني ودعم عربي — اختر الخطة المناسبة لحجمك وانطلق اليوم.
اكتشف خطط الاستضافةما هو INP وكيف تحسّنه؟
INP (Interaction to Next Paint — «من التفاعل إلى الرسم التالي») يقيس زمن استجابة الصفحة لتفاعلات المستخدم عبر كامل الجلسة. عند كل نقرة أو ضغطة لوحة مفاتيح أو لمسة، يحسب المتصفّح الزمن من بدء التفاعل حتى يُرسَم أقرب تحديث مرئي على الشاشة، ثم يبلّغ عن قيمة تمثّل أسوأ التفاعلات (تقريبًا) خلال الزيارة. INP حلّ محلّ FID القديم في 2024، وهو أدقّ منه لأنه يقيس كامل دورة التفاعل لا تأخّر أول استجابة فقط.
عتبات INP
| النطاق | القيمة | الحُكم |
|---|---|---|
| جيّد | أقل من 200ms (≤ 200 مللي ثانية) | يجتاز |
| يحتاج تحسينًا | 200ms – 500ms | على الحدّ |
| ضعيف | أكثر من 500ms (> 500 مللي ثانية) | يفشل |
أسباب INP السيّئ وحلولها
INP بطيء يعني أن الخيط الرئيسي (Main Thread) مشغول بتنفيذ JavaScript فلا يجد وقتًا للاستجابة لتفاعل المستخدم ورسم النتيجة. الأسباب تدور حول ثِقل JavaScript:
| السبب | كيف يظهر | الحلّ |
|---|---|---|
| مهامّ JS طويلة تحجب الخيط | تجمّد لحظي بعد النقر | تقسيم المهامّ الطويلة (Yield/chunking) |
| سكربتات طرف ثالث ثقيلة | تأخّر يزداد مع كل ودجت | تأجيلها أو تحميلها عند التفاعل |
| معالِجات أحداث مكلفة | كل نقرة تشغّل حسابًا ثقيلًا | تبسيطها + تأجيل العمل غير العاجل |
| كود JS كبير غير مستخدم | حِمل تنفيذ زائد | تقسيم الكود (Code splitting) + إزالة غير المستخدم |
| إعادة تخطيط/رسم مفرطة | تحديث DOM ضخم لحظة التفاعل | تجميع تغييرات DOM وتقليلها |
| Hydration ثقيلة (تطبيقات JS) | الصفحة تظهر لكن لا تستجيب | تأجيل/تقسيم الترطيب وتقليل الكود |
لفهم INP بدقّة، تذكّر أن المتصفّح ينفّذ معظم JavaScript على خيط واحد هو الخيط الرئيسي نفسه الذي يرسم الواجهة ويستجيب لنقراتك. فإذا انشغل هذا الخيط بمهمّة حسابية طويلة، فكل نقرة تنتظر دورها حتى تنتهي تلك المهمّة، ولو شعر الزائر بأن الصفحة «تجمّدت» لجزء من الثانية. INP يلتقط بالضبط هذا التأخّر التراكمي لأسوأ التفاعلات، وهو لذلك المؤشّر الأصعب تحسينًا في التطبيقات الغنيّة بالـJavaScript. كذلك يدخل في حساب INP ثلاثة أزمنة: تأخّر الإدخال (انتظار فراغ الخيط)، ثم زمن المعالجة (تنفيذ معالِج الحدث)، ثم تأخّر العرض (حتى يُرسم التحديث) — وتحسين أيٍّ منها يخفض الرقم.
القاعدة العملية: قسّم أي مهمّة طويلة (أكثر من ~50 مللي ثانية) إلى أجزاء أصغر، وأعطِ المتصفّح فرصة للاستجابة بينها. مثال مبسّط لإفساح المجال للخيط الرئيسي بين دفعات عمل:
async function processChunks(items) {
for (const item of items) {
handle(item);
// أعطِ المتصفّح فرصة للاستجابة للتفاعلات
await new Promise((r) => setTimeout(r, 0));
}
}
نصيحة خبير: أكبر مصدر لتردّي INP في الممارسة هو سكربتات الطرف الثالث (تتبّع، إعلانات، ودجت دردشة) لأنك لا تتحكّم بأدائها وتعمل على الخيط نفسه. حمّلها بكسل (async/defer)، وأخّر ودجت الدردشة الثقيلة حتى يتفاعل المستخدم معها فعلًا لا عند بداية التحميل. INP تحديدًا يتأثّر بقوّة بضعف معالج الجوال، فاختبره دائمًا على جهاز متوسّط لا على حاسوبك القويّ.
ما هو CLS وكيف تحسّنه؟
CLS (Cumulative Layout Shift — «التزحزح التراكمي للتخطيط») يقيس مقدار «قفز» عناصر الصفحة وتزحزحها بشكل غير متوقّع أثناء عمرها. عندما تقرأ نصًّا فيقفز فجأة لأسفل بسبب تحميل صورة أو إعلان فوقه، أو تهمّ بالضغط على زرّ فيتزحزح فتنقر غيره — هذا ما يقيسه CLS. القيمة رقم بلا وحدة يجمع حاصل ضرب «نسبة المساحة المتأثّرة» في «مسافة الإزاحة» لكل تزحزح غير متوقّع.
عتبات CLS
| النطاق | القيمة | الحُكم |
|---|---|---|
| جيّد | أقل من 0.1 (≤ 0.1) | يجتاز |
| يحتاج تحسينًا | 0.1 – 0.25 | على الحدّ |
| ضعيف | أكثر من 0.25 (> 0.25) | يفشل |
أسباب CLS السيّئ وحلولها
CLS يحدث كلّما حجز عنصرٌ مساحته بعد أن رسم المتصفّح ما حوله، فيدفع المحتوى المجاور:
| السبب | كيف يظهر | الحلّ |
|---|---|---|
| صور/فيديو بلا أبعاد محجوزة | المحتوى يقفز عند تحميل الصورة | حدّد width وheight أو aspect-ratio |
| إعلانات/iframes بلا مساحة محجوزة | فراغ يُملأ فجأة فيدفع ما تحته | احجز حاوية بأبعاد ثابتة مسبقًا |
| محتوى يُحقن ديناميكيًا فوق المرئي | بانر/إشعار يُدسّ أعلى الصفحة | احجز مكانه أو ضعه دون إزاحة الموجود |
| خطوط ويب تبدّل المقاسات (FOUT) | النص يعيد التدفّق عند تبديل الخطّ | اضبط الخطّ البديل بمقاسات متقاربة |
| إضافة عناصر بـ transitions خاطئة | حركة تغيّر تدفّق التخطيط | استخدم transform لا خصائص التخطيط |
من المهمّ فهم أن CLS لا يعاقب كل حركة، بل التزحزح غير المتوقّع فقط — أي الذي يحدث دون أن يطلبه المستخدم. حركةٌ يطلبها الزائر بنفسه (فتح قائمة منسدلة، توسيع قسم «اقرأ المزيد») لا تُحتسَب إن وقعت خلال نصف ثانية من تفاعله، لأنها متوقّعة ومرغوبة. ما يضرّ هو القفز المفاجئ: نصّ يُدفع لأسفل لأن صورة فوقه حُمّلت متأخّرة، أو زرّ يتزحزح لحظة الضغط فينقر الزائر إعلانًا بالخطأ. هذه التجربة محبِطة وقد تكون مضلّلة، ولذلك تأخذها Google بجدّية ضمن إشارات التجربة.
الحلّ الجوهري لمعظم حالات CLS بسيط: احجز المساحة مسبقًا. أبسط مثال — حدّد أبعاد كل صورة دائمًا:
<img src="/cover.avif" width="1200" height="630" alt="غلاف المقال" />
تحديد width وheight يتيح للمتصفّح حساب نسبة الأبعاد وحجز المكان قبل تحميل الصورة، فلا يقفز شيء عند وصولها. للإعلانات والـiframes، أحِط كلًّا بحاوية ذات ارتفاع ثابت محجوز. ولتبديل الخطوط، استخدم size-adjust ومقاييس خطّ احتياطي متقاربة لتقليل إعادة التدفّق.
نصيحة خبير: انتبه إلى تزحزحات تحدث بعد التحميل الأول — كثير من فرق العمل تختبر اللحظة الأولى فقط وتنسى البانرات والإشعارات التي تُحقن لاحقًا أو الإعلانات التي تتحدّث أثناء التصفّح. CLS تراكمي طوال عمر الصفحة، فاختبر بالتمرير والتفاعل لا عند اللحظة صفر فقط. وتذكّر استثناءً مهمًّا: التزحزح الناتج عن تفاعل المستخدم خلال نصف ثانية لا يُحتسَب (يُعتبر متوقّعًا)، لذا التوسّعات التي يطلبها المستخدم بنفسه آمنة.
مخبري أم ميداني؟ (Lab vs Field / CrUX)
هذا أهمّ تمييز في موضوع Core Web Vitals، وسوء فهمه سبب أغلب الحيرة («لماذا نتيجتي 100 لكن الصفحة لم تجتز؟»). هناك نوعان من البيانات:
- بيانات المختبر (Lab): قياس في بيئة مضبوطة واحدة، بجهاز وشبكة محدّدين، في لحظة واحدة. مصدرها أدوات مثل Lighthouse وWebPageTest. مفيدة للتشخيص والتجربة المتكرّرة لأنها قابلة للإعادة.
- بيانات الميدان (Field / RUM): قياس من زيارات مستخدمين حقيقيين بأجهزة وشبكات وظروف متنوّعة، مجمّعة عبر مدّة. مصدرها الرسمي تقرير تجربة Chrome (CrUX) الذي يجمع بيانات مستخدمي Chrome الحقيقيين.
| البُعد | بيانات المختبر (Lab) | بيانات الميدان (Field / CrUX) |
|---|---|---|
| المصدر | أداة في بيئة مضبوطة | مستخدمون حقيقيون عبر CrUX |
| INP | لا يُقاس مباشرة (يُقدَّر بـ TBT) | يُقاس فعليًا من التفاعلات |
| الجهاز/الشبكة | ثابتة محدّدة | متنوّعة كما الواقع |
| الأفضل لـ | التشخيص والتجربة | الحُكم الرسمي والترتيب |
| التحديث | فوري عند كل اختبار | متأخّر (نافذة 28 يومًا متحرّكة) |
| ما يعتمده Google | لا | نعم |
نقطتان حاسمتان: أوّلًا، INP لا يُقاس في المختبر مباشرة لأنه يحتاج تفاعلات بشرية حقيقية؛ يقرّب المختبر منه عبر مقياس TBT (Total Blocking Time)، لكن الحُكم الفعلي ميداني. ثانيًا، بيانات CrUX تمثّل نافذة 28 يومًا متحرّكة، فأي تحسين تطبّقه اليوم لن ينعكس كاملًا في الميدان إلا بعد أسابيع مع دخول زيارات جديدة. لا تُحبَط إن لم تتغيّر أرقام الميدان فورًا — أكّد بالمختبر أن الإصلاح يعمل، ثم انتظر تراكم بيانات الميدان.
القاعدة: شخّص بالمختبر، احكم بالميدان. استخدم Lighthouse وDevTools لتعرف سبب المشكلة وتجرّب الحلول بسرعة، لكن تابع نجاحك الحقيقي في بيانات CrUX عبر PageSpeed Insights وSearch Console.
كيف تقيس Core Web Vitals؟ الأدوات
لا تحسّن ما لا تقيسه، ولا تكتفِ بأداة واحدة. كل أداة تخدم غرضًا: بعضها للحُكم الرسمي وبعضها للتشخيص العميق:
| الأداة | نوع البيانات | الأفضل لـ | ملاحظة |
|---|---|---|---|
| PageSpeed Insights | ميدان (CrUX) + مختبر | الحُكم الرسمي + نظرة سريعة | يعرض p75 الحقيقي إن توفّر |
| Search Console (تقرير CWV) | ميدان (CrUX) | متابعة المجموعات عبر الموقع كاملًا | يصنّف الصفحات جيّد/يحتاج/ضعيف |
| Chrome DevTools (Performance) | مختبر مباشر | تشخيص INP وCLS أثناء التصفّح | يحدّد عنصر LCP والمهامّ الطويلة |
| Lighthouse | مختبر | تدقيق محلّي بتوصيات مرتّبة | INP مُقدَّر بـ TBT لا مقاس |
| WebPageTest | مختبر متقدّم | تحليل عميق متعدّد المواقع | film strip + waterfall مفصّل |
| إضافة Web Vitals | ميدان (جهازك) | قراءة المؤشّرات الثلاثة فوريًا أثناء التصفّح | مفيدة للفحص السريع |
من أين تبدأ القياس؟
ابدأ بـ Search Console لترى أي مجموعات صفحات تفشل وأي مؤشّر، لأنه يعطيك صورة الموقع كاملًا من بيانات الميدان. ثم خذ صفحة ممثّلة من مجموعة فاشلة وافحصها في PageSpeed Insights لرؤية تفصيل المؤشّرات وتوصيات أوّلية. وأخيرًا انزل إلى DevTools على تلك الصفحة لتشخيص دقيق: ما عنصر LCP؟ أي مهمّة JS تحجب الخيط وتُفسد INP؟ ما العناصر التي تتزحزح وتُراكم CLS؟
قاعدة عملية في القياس
اختبر في وضع التصفّح الخفي وبلا إضافات متصفّح (تشوّش النتائج)، وكرّر اختبار المختبر 3–5 مرات وخذ الوسيط لا أفضل نتيجة. واختبر دائمًا على ظروف الجوال (شبكة بطيئة، معالج محدود) لأنها الأقسى وهي ما يواجهه أغلب زوّارك، وهي التي يعتمدها فهرس الجوال أوّلًا.
جاهز لإطلاق موقعك على استضافة سريعة؟
خطط استضافة wpressly على أقراص NVMe مع SSL مجاني ودعم عربي — اختر الخطة المناسبة لحجمك وانطلق اليوم.
اكتشف خطط الاستضافةكيف يتفاعل المؤشّرات الثلاثة معًا؟
من الخطأ علاج كل مؤشّر بمعزل، فبينها تداخل: تحسين أحدها قد يحسّن آخر، وإهمال طبقة أساسية يضرّ أكثر من واحد. مثلًا، تأجيل JavaScript الثقيل يحسّن INP (خيط رئيسي أخفّ) وقد يحسّن LCP أيضًا (موارد حاجبة أقل). وضبط أبعاد الصور يحسّن CLS مباشرة ولا يضرّ غيره.
| الإجراء | LCP | INP | CLS |
|---|---|---|---|
| خفض TTFB (استضافة + كاش) | تحسين كبير | تحسين غير مباشر | محايد |
| تأجيل/تقليل JavaScript | تحسين | تحسين كبير | محايد–تحسين |
| تحسين صورة LCP (صيغة/أبعاد/preload) | تحسين كبير | محايد | تحسين (الأبعاد) |
| حجز أبعاد الصور والإعلانات | محايد | محايد | تحسين كبير |
| تقليل سكربتات الطرف الثالث | تحسين | تحسين كبير | تحسين (إعلانات) |
| Critical CSS + تأجيل CSS | تحسين | محايد | محايد |
الخلاصة: الطبقات السفلية (استضافة، كاش، تقليل JS) ترفع أكثر من مؤشّر دفعة واحدة، فابدأ بها قبل التحسينات الدقيقة. وعند تحديد الأولوية، عالج المؤشّر الذي تفشل فيه فعلًا في الميدان أوّلًا — لا تُحسّن مؤشّرًا مجتازًا أصلًا على حساب وقتك.
تشخيص ومعالجة كل مؤشّر خطوة بخطوة
عند فشل مؤشّر في الميدان، انزل إلى المختبر وشخّص من العَرَض إلى السبب. التالي خطوات عملية لكل مؤشّر:
تشخيص LCP
افتح DevTools ← لوحة Performance، سجّل تحميل الصفحة، وحدّد علامة LCP لتعرف العنصر الدقيق وزمنه. ثم اسأل: أين يضيع الوقت؟
- إن كان TTFB كبيرًا قبل أي رسم ← المشكلة في الخادم/الكاش (راقب TTFB في WebPageTest).
- إن ظهر LCP متأخّرًا رغم TTFB جيّد ← المورد ثقيل أو يُكتشَف متأخّرًا ← حسّن الصيغة والأبعاد وأضف
preloadوfetchpriority. - إن كان عنصر LCP نصًّا متأخّرًا ← خطّ يحجب النص ←
font-display: swapوpreload للخطّ.
تشخيص INP
في DevTools، فعّل لوحة Performance ثم نفّذ التفاعل البطيء فعليًا (انقر الزرّ، افتح القائمة). ابحث عن المهامّ الطويلة (Long Tasks) المعلّمة بالأحمر على الخيط الرئيسي حول لحظة التفاعل:
- مهمّة طويلة عند النقر ← قسّمها وأجّل العمل غير العاجل.
- المهمّة من سكربت طرف ثالث ← أجّله أو حمّله عند التفاعل.
- إعادة تخطيط ضخمة ← قلّل تغييرات DOM واجمعها.
تشخيص CLS
في DevTools، فعّل خيار إبراز مناطق التزحزح (Layout Shift Regions) لترى أي عنصر يقفز ومتى. ثم في لوحة Performance ستجد سجلّات Layout Shift مع العنصر المسؤول:
- صورة/إعلان بلا أبعاد ← احجز المساحة (
width/heightأوaspect-ratioأو حاوية ثابتة). - بانر مُحقن أعلى الصفحة ← احجز مكانه أو ضعه دون إزاحة الموجود.
- تبديل خطّ يزيح النص ← اضبط مقاييس الخطّ البديل.
| المؤشّر | أداة التشخيص الأمثل | ما تبحث عنه | الحلّ الأشيع |
|---|---|---|---|
| LCP | Performance / WebPageTest | عنصر LCP وزمن كل مرحلة | TTFB + صورة + preload |
| INP | Performance أثناء التفاعل | مهامّ طويلة على الخيط | تقسيم JS + تأجيل الطرف الثالث |
| CLS | Layout Shift Regions | العنصر الذي يقفز | حجز الأبعاد مسبقًا |
أخطاء شائعة
تجنّب هذه الأخطاء المتكرّرة التي تُفشل تحسين Core Web Vitals أو تضيّع الوقت:
- الاعتماد على نتيجة المختبر وحدها: رقم 100 في Lighthouse لا يعني اجتياز الميدان. الحُكم على بيانات CrUX الحقيقية، فتابعها في Search Console وPageSpeed.
- الخلط بين INP المخبري والميداني: INP لا يُقاس مباشرة في المختبر (يُقرَّب بـ TBT). إن أردت رقمه الحقيقي فمن الميدان أو من تفاعل فعلي في DevTools.
- توقّع تغيّر الميدان فورًا: بيانات CrUX نافذة 28 يومًا متحرّكة؛ التحسين لا ينعكس إلا بعد أسابيع. أكّد بالمختبر ثم اصبر.
- جعل صورة LCP كسولة التحميل: تطبيق
lazyعلى أهمّ عنصر مرئي يدمّر LCP. الكسول للصور أسفل الطيّة فقط. - اختبار CLS عند اللحظة الأولى فقط: التزحزح تراكمي طوال عمر الصفحة؛ البانرات والإعلانات المتأخّرة تُفسده بعد التحميل. اختبر بالتمرير والتفاعل.
- تجاهل سكربتات الطرف الثالث: غالبًا أكبر سبب لتردّي INP، ويُنسى فحصها لأنها «ليست كودنا». حمّلها بكسل أو عند الحاجة.
- اختبار سطح المكتب فقط: الحُكم على الجوال (أضعف معالجًا وشبكة) وهو مصدر أغلب الزيارات. اختبر بمحاكاة جهاز متوسّط على شبكة بطيئة.
- علاج مؤشّر مجتاز وإهمال الفاشل: تحسين LCP من 2 إلى 1.8 ثانية بلا قيمة بينما INP يفشل. عالج الفاشل في الميدان أوّلًا.
نصائح خبير وقائمة تحسين سريعة
بعد التشخيص، اعتمد قائمة عملية مرتّبة بالأثر تغطّي المؤشّرات الثلاثة. هذه نقطة بداية لأغلب المواقع:
| البند | المؤشّر المستهدف | الأثر | الجهد |
|---|---|---|---|
| استضافة قويّة + خفض TTFB | LCP | مرتفع جدًا | متوسّط |
| كاش الصفحة/الكائنات | LCP | مرتفع جدًا | منخفض |
| تحويل الصور إلى AVIF/WebP + أبعاد | LCP + CLS | مرتفع | منخفض |
| preload وfetchpriority لعنصر LCP | LCP | مرتفع | منخفض |
| تأجيل/تقليل JavaScript | INP | مرتفع | متوسّط |
| تأجيل سكربتات الطرف الثالث / تحميلها عند التفاعل | INP | مرتفع | منخفض–متوسّط |
| تقسيم المهامّ الطويلة (yield) | INP | متوسّط–مرتفع | متوسّط |
| حجز أبعاد كل صورة/إعلان/iframe | CLS | مرتفع | منخفض |
| ضبط الخطوط (swap + مقاييس بديل) | LCP + CLS | متوسّط | منخفض |
| Critical CSS + تأجيل CSS غير الحرج | LCP | متوسّط | متوسّط |
نصائح إضافية من الممارسة:
- اختبر على جوال متوسّط فعلي إن أمكن، لا محاكاة فقط. ضعف المعالج الحقيقي هو ما يكشف مشاكل INP الفعلية.
- استخدم CDN لتوزيع الأصول جغرافيًا فيقلّ زمن وصول صورة LCP للزوّار البعيدين — راجع دليل شبكة CDN.
- راقب بعد كل تحديث (قالب/إضافة/سمة): الأداء يتدهور بصمت مع تراكم الإضافات وتغيّر الكود. اجعل القياس روتينًا شهريًا.
- رتّب بالميدان لا بالحدس: ابدأ من المؤشّر والمجموعة التي تفشل فعليًا في Search Console، ولا تطارد أرقامًا مخبرية لا أثر لها على الزائر.
الخلاصة
Core Web Vitals ثلاثة مؤشّرات تترجم تجربة الزائر إلى أرقام قابلة للقياس والتحسين: LCP (سرعة ظهور أكبر عنصر، الهدف أقل من 2.5 ثانية)، وINP (سرعة الاستجابة للتفاعل، الهدف أقل من 200 مللي ثانية)، وCLS (ثبات التخطيط، الهدف أقل من 0.1). الشرط أن يقع المئين 75 من زياراتك ضمن النطاق الجيّد لكل مؤشّر، مقاسًا على بيانات الميدان (CrUX) لا المختبر وحده. القاعدة الذهبية: شخّص بالمختبر، احكم بالميدان — استخدم DevTools وLighthouse لتعرف السبب وتجرّب الحلّ بسرعة، وتابع نجاحك الحقيقي في Search Console مع الصبر على نافذة الـ28 يومًا.
عمليًا: ابدأ من الطبقات السفلية (استضافة قويّة، كاش، تقليل JavaScript) لأنها ترفع أكثر من مؤشّر دفعة واحدة، ثم عالج كل مؤشّر بالأسباب الموضّحة — صورة LCP وpreload للأوّل، تأجيل وتقسيم JS للثاني، وحجز الأبعاد للثالث. عالج المؤشّر الفاشل فعلًا في الميدان أوّلًا، واختبر على الجوال لأنه الأقسى وهو مصدر أغلب زوّارك.
أهمّ خطوة الآن: افتح Search Console، حدّد المجموعة والمؤشّر الفاشل، وافحص صفحة ممثّلة في PageSpeed Insights ثم DevTools، وعالج السبب من جذره وفق هذا الدليل.
جاهز لإطلاق موقعك على استضافة سريعة؟
خطط استضافة wpressly على أقراص NVMe مع SSL مجاني ودعم عربي — اختر الخطة المناسبة لحجمك وانطلق اليوم.
اكتشف خطط الاستضافةالأسئلة الشائعة
ما المؤشّرات الثلاثة في Core Web Vitals؟
هي LCP (سرعة ظهور أكبر عنصر مرئي، الهدف أقل من 2.5 ثانية)، وINP (سرعة استجابة الصفحة للتفاعل، الهدف أقل من 200 مللي ثانية)، وCLS (ثبات التخطيط ومقدار قفز العناصر، الهدف أقل من 0.1). كلٌّ يقيس بُعدًا مختلفًا من التجربة: التحميل، والاستجابية، والاستقرار البصري. تُقاس على بيانات المستخدمين الحقيقيين عبر تقرير تجربة Chrome.
ما الفرق بين INP وFID؟
FID (First Input Delay) كان يقيس تأخّر أول استجابة فقط، أي اللحظة بين أول تفاعل وبدء معالجته. INP حلّ محلّه في مارس 2024 وهو أدقّ لأنه يقيس كامل دورة التفاعل (من التفاعل حتى الرسم التالي) عبر الجلسة كلّها لا أوّل تفاعل وحده. هذا يجعله أصدق تعبيرًا عن استجابية الصفحة الفعلية كما يلمسها الزائر.
ما الفرق بين بيانات المختبر وبيانات الميدان؟
بيانات المختبر تُقاس في بيئة مضبوطة واحدة بجهاز وشبكة محدّدين (مثل Lighthouse)، وهي مفيدة للتشخيص والتجربة المتكرّرة. بيانات الميدان تأتي من زيارات مستخدمين حقيقيين بأجهزة وظروف متنوّعة، مجمّعة في تقرير تجربة Chrome (CrUX)، وهي ما يعتمده Google في الترتيب. القاعدة: شخّص بالمختبر واحكم بالميدان.
كيف أعرف أن صفحتي اجتازت Core Web Vitals؟
تجتاز المؤشّر إذا وقع المئين 75 (p75) من زياراتك ضمن النطاق الجيّد له، مقاسًا على بيانات الميدان. أسهل طريقة: افحص الصفحة في PageSpeed Insights وراقب قسم بيانات الميدان، أو تابع تقرير Core Web Vitals في Search Console الذي يصنّف مجموعات صفحاتك إلى جيّد ويحتاج تحسين وضعيف.
لماذا نتيجتي في Lighthouse ممتازة لكن الصفحة لم تجتز؟
لأن Lighthouse بيانات مختبرية في بيئة مثالية واحدة، بينما الحُكم الرسمي على بيانات الميدان من مستخدمين حقيقيين بأجهزة وشبكات أبطأ غالبًا. قد يعطيك المختبر 100 بينما يعاني زوّارك فعلًا. تابع بيانات CrUX في PageSpeed وSearch Console، واعتبر Lighthouse أداة تشخيص لا حُكمًا نهائيًا.
كم أنتظر حتى تظهر نتائج التحسين في الميدان؟
بيانات CrUX تمثّل نافذة 28 يومًا متحرّكة، فالتحسين الذي تطبّقه اليوم لن ينعكس كاملًا إلا بعد عدّة أسابيع مع دخول زيارات جديدة ضمن النافذة. لا تُحبَط إن لم تتغيّر الأرقام فورًا — أكّد بالمختبر أن الإصلاح يعمل، ثم اصبر على تراكم بيانات الميدان.
هل INP يُقاس في المختبر؟
لا يُقاس INP مباشرة في المختبر لأنه يحتاج تفاعلات بشرية حقيقية عبر الجلسة. تقرّب أدوات المختبر منه عبر مقياس TBT (Total Blocking Time) كمؤشّر بديل، أو يمكنك قياس تفاعل فعلي في DevTools. لكن الرقم الرسمي لـINP يأتي من بيانات الميدان فقط.
أيّ مؤشّر أبدأ بإصلاحه أولًا؟
ابدأ بالمؤشّر الذي تفشل فيه فعليًا في بيانات الميدان عبر Search Console، لا بمؤشّر مجتاز أصلًا. وإن فشل أكثر من واحد، ابدأ بالطبقات السفلية المشتركة (استضافة، كاش، تقليل JavaScript) لأنها تحسّن عدّة مؤشّرات دفعة واحدة، ثم عالج المتبقّي بأسبابه الخاصّة.
هل تؤثّر Core Web Vitals على ترتيب البحث فعلًا؟
نعم، هي ضمن إشارات تجربة الصفحة في الترتيب، لكنها ليست العامل الأقوى — المحتوى وملاءمته يبقيان الأساس. أثرها يظهر كمُرجّح بين صفحتين متقاربتين في الجودة، وكشرط لبعض ميزات النتائج. والأهمّ أنها تحسّن تجربة الزائر ومعدّل التحويل بغضّ النظر عن الترتيب، فتحسينها مربح في كل الأحوال.
ما علاقة الاستضافة بـ Core Web Vitals؟
علاقة مباشرة وقويّة عبر LCP خصوصًا. استضافة بطيئة ترفع زمن استجابة الخادم (TTFB) فيتأخّر كل ما بعده، ولا يمكن لأي تحسين أمامي أن يعوّض خادمًا بطيئًا أو بلا كاش. استضافة قويّة بأقراص NVMe وكاش فعّال تخفض TTFB فتحسّن LCP لكل صفحات الموقع دفعة واحدة، وهي أساس قبل أي تحسين دقيق آخر.
هل تكفي إضافة تحسين أداء لتمرير Core Web Vitals؟
ليست حلًّا سحريًا بمفردها. إضافة الكاش والتحسين تساعد كثيرًا في LCP وأحيانًا CLS، لكنها قد لا تعالج INP الناتج عن سكربتات طرف ثالث ثقيلة، ولا تعوّض استضافة بطيئة. اقترن الإضافة بأساس سليم (استضافة جيّدة + قياس موضوعي)، واضبطها جيّدًا، وتجنّب تكديس عدّة إضافات متعارضة معًا.