تفتح PageSpeed Insights، تلصق رابط موقعك، وتضغط على تحليل. بعد ثلاثين ثانية تجد نفسك أمام جدار من الدوائر الملونة والنقاط والاختصارات مثل LCP وINP وCLS. شيء ما يظهر باللون الأحمر. لست متأكدًا ماذا يعني أو من أين تبدأ الإصلاح.
هذا يحدث لكل شخص تقريبًا في المرة الأولى — وبصراحة، في المرة الثانية والثالثة أيضًا. تقارير Core Web Vitals تحشو كمًّا كبيرًا من المعلومات في مساحة صغيرة، وبدون خريطة واضحة، من السهل أن تنشغل بالرقم الخطأ أو تفوتك المشكلة التي تضر بترتيبك في محركات البحث بهدوء.
هذا الدليل سيساعدك على قراءة التقرير بثقة، وفهم ما تقيسه كل مقياس فعليًا، ومعرفة من أين تبدأ.
ما الذي تقيسه Core Web Vitals فعلًا
تتلخص Core Web Vitals من Google في ثلاثة أسئلة حول شعور الزائر الحقيقي بصفحتك:
- هل تُحمَّل بسرعة؟ (LCP — Largest Contentful Paint)
- هل تستجيب بسرعة؟ (INP — Interaction to Next Paint)
- هل تبقى ثابتة؟ (CLS — Cumulative Layout Shift)
هذا كل شيء. ثلاثة أسئلة. كل ما تبقى في التقرير موجود لمساعدتك على الإجابة عنها.
LCP — Largest Contentful Paint
يقيس LCP المدة التي يستغرقها أكبر عنصر مرئي في الصفحة حتى يكتمل تحميله. عادةً ما يكون صورة رئيسية أو عنوانًا كبيرًا أو صورة مصغرة لفيديو.
الهدف: أقل من 2.5 ثانية. بين 2.5 و4.0 ثانية يحتاج إلى تحسين. أكثر من 4.0 ثانية ضعيف.
يتأثر LCP بشكل كبير بسرعة استجابة الخادم. إذا كان Time to First Byte بطيئًا، فإن LCP سيكون بطيئًا في الغالب أيضًا — لأن المتصفح لا يستطيع عرض ما لم يستلمه بعد. تناولنا العلاقة بين TTFB والتحويلات في مقال لماذا يكلفك Time to First Byte تحويلات، وهو أحد أوضح المسارات نحو تحسين نقاط LCP.
INP — Interaction to Next Paint
حلّ INP محل FID (First Input Delay) في مارس 2024، ويقيس مدى سرعة استجابة صفحتك لتفاعلات المستخدم طوال فترة الزيارة — وليس فقط عند النقرة الأولى.
الهدف: أقل من 200ms. بين 200ms و500ms يحتاج إلى تحسين. أكثر من 500ms ضعيف.
بطء INP عادةً ما يشير إلى أن JavaScript يقوم بعمل كثير على الخيط الرئيسي. السكريبتات الثقيلة التي تعيق التحميل، أو معالجات الأحداث غير المحسّنة، أو أدوات الطرف الثالث التي تتصل بخوادمها باستمرار هي المشتبه بها المعتادة.
CLS — Cumulative Layout Shift
يقيس CLS عدم استقرار التخطيط البصري — مقدار تحرك عناصر الصفحة بشكل غير متوقع بعد التحميل الأولي. تعرف الشعور: أنت على وشك النقر على زر ثم تتحرك الصفحة فجأة وتضغط على شيء آخر عن طريق الخطأ.
الهدف: أقل من 0.1. بين 0.1 و0.25 يحتاج إلى تحسين. أكثر من 0.25 ضعيف.
مشاكل CLS عادةً تأتي من صور بدون تحديد صريح للعرض والارتفاع، أو خطوط ويب تُحمَّل في وقت متأخر، أو إعلانات تُحمَّل وتدفع المحتوى للأسفل.
بيانات الميدان مقابل بيانات المختبر — ولماذا كلاهما مهم
هنا يتشوش كثير من الناس. يعرض PageSpeed Insights مجموعتين منفصلتين من البيانات وغالبًا ما تتعارضان.
بيانات الميدان (تُسمى أيضًا بيانات CrUX — Chrome User Experience Report) تأتي من مستخدمين حقيقيين زاروا موقعك خلال الـ28 يومًا الماضية. هذا ما تستخدمه Google فعليًا كإشارات للترتيب. إذا كان موقعك لا يحظى بزيارات كثيرة، قد لا تتوفر لديك بيانات ميدان أصلًا.
بيانات المختبر تأتي من اختبار محاكاة يُجرى في بيئة محكومة. إنها متسقة وقابلة للتكرار، مما يجعلها مفيدة لتشخيص المشاكل. لكنها تستخدم ملف تعريف جهاز واحد واتصالًا محدود السرعة — لذا لن تعكس دائمًا ما يختبره المستخدمون الحقيقيون.
الطريقة الصحيحة لقراءة التقرير: استخدم بيانات الميدان لفهم تأثيرك الفعلي على الترتيب، واستخدم بيانات المختبر لتشخيص المشاكل وإصلاحها. لا تقلق إذا بدت النتائج مختلفة بين الاثنين — هذا أمر طبيعي.
كيف تؤثر استضافة Core Web Vitals في الاستضافة على كل مقياس
إليك شيء يستحق الفهم قبل أن تقضي ساعات في تعديل الكود: بيئة الاستضافة تحدد السقف لجميع المقاييس الثلاثة.
لا يمكن لأي قدر من تحسينات الواجهة الأمامية أن يعوّض خادمًا بطيئًا. إذا كانت استضافتك تستغرق 800ms فقط لتوليد الاستجابة (قبل إرسال أي بيانات للمتصفح)، فأنت تبدأ بالفعل متأخرًا بـ800ms. هذا يأكل مباشرةً من ميزانية LCP ويجعل كل مقياس آخر أصعب في التحقيق.
قرارات Core Web Vitals في الاستضافة — مثل موقع الخادم، واستراتيجية التخزين المؤقت، وإصدار PHP، والذاكرة المتاحة — تحدد الأداء الأساسي. ليست العامل الوحيد، لكنها الأساس الذي يقوم عليه كل شيء آخر. يتناول مقال Core Web Vitals والاستضافة: لماذا يساعدك خادمك أو يضرك هذه النقطة بتعمق.
بعض الأشياء التي يجب البحث عنها على جانب الاستضافة:
- هل التخزين المؤقت على جانب الخادم مفعّل حتى يحصل الزوار المتكررون على صفحات جاهزة مسبقًا بدلًا من انتظار تشغيل PHP؟
- هل خادمك في منطقة جغرافية قريبة من جمهورك الرئيسي؟
- هل إصدار PHP حديث؟ PHP 8.x أسرع بشكل ملحوظ من 7.x لمعظم مواقع WordPress.
- هل التخزين المؤقت للكائنات مفعّل للعمليات الكثيفة على قاعدة البيانات؟
في الاستضافة المُدارة، يُعالَج معظم هذا تلقائيًا. لكن يستحق التحقق من أنها فعلًا نشطة — خاصة التخزين المؤقت، إذ كثيرًا ما يكون معطلًا افتراضيًا في التثبيتات الجديدة.
قراءة قسم التشخيصات دون الغوص في التفاصيل المعقدة
تحت النقاط الثلاث الرئيسية، يسرد PageSpeed Insights سلسلة من التشخيصات والفرص. يبدو هذا القسم مرهبًا لكنه يعمل بشكل جيد عند استخدام فلتر بسيط:
اعمل فقط على العناصر التي تؤثر مباشرة على المقياس الضعيف لديك.
إذا كان LCP لديك أحمر لكن CLS وINP بخير، ابحث عن التشخيصات المرتبطة بـLCP. الشائعة منها:
- صورة Largest Contentful Paint غير مُحمَّلة مسبقًا
- موارد تعيق التحميل
- CSS غير مستخدم يؤخر التحميل
- أوقات استجابة طويلة من الخادم (TTFB)
إذا كان INP بطيئًا، ابحث عن:
- تقليل العمل على الخيط الرئيسي
- تقليل وقت تنفيذ JavaScript
- تأثير كود الطرف الثالث
لا تحاول إصلاح كل شيء دفعة واحدة. اختر تشخيصًا واحدًا، عالجه، أعد الاختبار، ثم انتقل للتالي. سيتحدث التقرير مع تقدمك.
أدوات عملية للتحقيق الأعمق
PageSpeed Insights نقطة بداية ممتازة، لكنه لن يخبرك دائمًا بالعنصر المحدد الذي يسبب المشكلة. هذه الأدوات تملأ الفراغ:
- لوحة الأداء في Chrome DevTools — تسجل تحميل الصفحة الحقيقي وتوضح لك بالضبط أين يُصرف الوقت. رائعة لتشخيص INP.
- WebPageTest (webpagetest.org) — يمنحك مخططات waterfall وعروض filmstrip وبيانات TTFB أكثر تفصيلًا. يستحق تشغيله من مواقع جغرافية متعددة.
- Google Search Console — يعرض بيانات ميدان Core Web Vitals في الاستضافة مجمّعة حسب نوع الصفحة. مفيد لرصد الأنماط عبر موقعك بأكمله، وليس URL واحدًا فقط.
- Lighthouse في Chrome DevTools — يجري نفس تحليل PageSpeed Insights لكن محليًا، حتى تتمكن من اختبار الصفحات المحمية بكلمة مرور أو بيئات التجريب.
إذا كنت تشغّل WordPress، فإن أدوات التحليل التي تقيس وقت تنفيذ PHP الفعلي وعدد الاستعلامات واستهلاك الذاكرة لكل تحميل صفحة تستحق كثيرًا — خاصة عندما تبدو النقاط جيدة على الصفحات البسيطة لكن تسوء على الصفحات المعقدة.
ترتيب منطقي لإصلاح المشاكل
عندما يبدو كل شيء معطوبًا، من المفيد اتباع تسلسل محدد. إليك تسلسلًا عمليًا:
- أصلح TTFB أولًا. كل شيء بعده يعتمد على سرعة استجابة خادمك. إذا كان TTFB فوق 600ms، عالجه قبل أن تلمس كود الواجهة الأمامية.
- عالج LCP بعد ذلك. إنه المقياس ذو التأثير المباشر الأكبر على السرعة المُدرَكة ويحمل وزنًا كبيرًا في SEO.
- تعامل مع CLS. عادةً يمكن إصلاحه بتغييرات HTML محددة — أضف العرض والارتفاع للصور، احجز مساحة للإعلانات، وتعامل مع تحميل الخطوط بشكل صحيح.
- عالج INP أخيرًا. غالبًا ما يتطلب عملًا دقيقًا في JavaScript. أصلح مشاكل البنية الأساسية أولًا حتى لا تشخّص فوق أساس بطيء.
للاطلاع على نظرة أشمل حول التحسينات التي تحرك الأرقام فعلًا، يغطي مقال تحسين سرعة الموقع: ما الذي يحرك الأرقام فعلًا التغييرات عالية التأثير التي تستحق الأولوية. وإذا كنت تعمل على موقع WordPress تحديدًا، ستجد أن تقنيات التحسين الخاصة به — مثل تأجيل JavaScript وإزالة CSS غير المستخدم — تُحدث فرقًا ملموسًا في المقاييس الثلاثة عند تطبيقها بتأنٍّ.
لمزيد من المعلومات حول نهجنا في تحسين الأداء، راجع كيف نتعامل مع الأداء على مستوى الخادم وإعداد التخزين المؤقت لدينا.
العقلية الصحيحة لتفسير النقاط
الحصول على 100 كاملة في PageSpeed Insights ليس الهدف. نقاط 100 على صفحة مجرّدة بلا صور أو JavaScript لا قيمة لها إذا كانت الصفحة لا تخدم زوارك فعليًا.
الهدف الحقيقي هو الحصول على اللون الأخضر في المقاييس الثلاثة لـCore Web Vitals في الاستضافة ضمن بيانات الميدان. هذا يعني أن المستخدمين الحقيقيين يختبرون تجربة سريعة ومستقرة — وهذا ما تقيسه Google.
النقاط ستتفاوت. قد تكون 78 اليوم و82 غدًا دون أي تغييرات من طرفك، لأن بيانات الميدان تتجدد كل 28 يومًا. لا تبالغ في تحسين رقم بعينه. حسّن تجربة المستخدم الفعلية التي تحاول هذه المقاييس تمثيلها.
عندما تتعامل مع التقرير بهذه الطريقة، يتوقف عن كونه مصدر قلق ويصبح تمامًا ما هو عليه: أداة تشخيص مفيدة تخبرك أين تنظر بعد ذلك.
