Core Web Vitals ببساطة: المؤشرات الثلاثة التي تقرأ بها سرعة موقعك

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

أهم ما ستفعله بعد قراءة هذا المقال:

• فهم ماذا يقيس كل مؤشر من LCP وINP وCLS بلغة بشرية
• قياس مؤشرات موقعك مجانًا من أداة واحدة موثوقة
• تطبيق إصلاحات مرتبة حسب أثرها من غير لجوء لأدوات مدفوعة
• بناء عادة مراقبة بسيطة تحمي سرعتك مع كل تعديل جديد

ما هي Core Web Vitals ولماذا تهمك فعلًا

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

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

المؤشر الأول LCP: سرعة ظهور المحتوى الرئيسي

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

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

المؤشر الثاني INP: استجابة الصفحة حين يتفاعل الزائر

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

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

المؤشر الثالث CLS: ثبات العناصر أثناء التحميل

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

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

كيف تقيس مؤشراتك مجانًا وبطريقة صحيحة

ابدأ من PageSpeed Insights المجانية من جوجل، وأدخل رابط صفحتك ثم اقرأ جزأين مختلفين في الأهمية: قسم بيانات الحقل من زوار حقيقيين إن توفر، وقسم التشخيص المعملية من بيئة اختبار. الحقل هو الحقيقة التي تحكم، والمعملية مفيدة لتشخيص أسباب المشكلة بتفاصيلها. كرر القياس على الصفحة الرئيسية وعلى صفحة مقال تمثيلي، فالموقع لا يُقاس بأفضل صفحاته بل بصفحاته الممثلة لمعظم الزيارات.

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

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

إصلاحات عملية مرتبة حسب أثرها الفعلي

اضغط الصور أولًا، فهي في المواقع النصية أكبر ملفات الصفحة وأسرع مكسب. حوّل الصور إلى WebP، واضبط أبعاد العرض الفعلية، وأجّل تحميل الصور أسفل الشاشة بخاصية التحميل الكسول مع إبقاء صورة الغلاف خارجها لأنها الـLCP نفسها. هذا التعديل وحده يحرك LCP لموقع ثابت أحيانًا لأكثر من نصف المسافة إلى الهدف، وبلا أي مخاطرة على الشكل أو المحتوى.

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

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

قياس الأداء عبر الموقع كله لا صفحة واحدة

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

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

صور الويب بتفصيل أعمق: أكبر ملف في صفحتك

الصورة غالبًا أكبر ملف في صفحة مقال، ولهذا تستحق معاملة تفصيلية لا مجرد ضغط عام. اختر الصيغة الصحيحة: WebP للجميع تقريبًا، مع JPEG كخيار احتياطي للتوافق مع متصفحات قديمة إن احتجت. اضبط أبعاد العرض على أقصى عرض يظهر فعليًا في قالبك، فصورة عرضها ألفي بكسل داخل عمود عرضه سبعمائة هي ملف أكبر بثلاث مرات بلا أي فائدة بصرية. أداة الضغط المجانية تكفي، ولا تحتاج برامج مدفوعة لهذا العمل إطلاقًا.

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

تأجيل الجافاسكربت بلغة غير مبرمجين

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

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

السرعة على الجوال: الحكم الحقيقي

أغلب زوار مواقع المحتوى العربية يصلون من الهواتف، فموقعك يُقاس عمليًا على شاشة صغيرة بشبكة متفاوتة لا على حاسوب مكتب بشبكة فايبر سريعة. جوجل نفسها تستخدم فهرسة الجوال أولًا، أي أن نسخة الجوال هي التي تُفهرس وتُقيّم رسميًا. لذلك اختبر موقعك دائمًا من هاتفك الفعلي على بيانات الجوال، وافتحه في لحظة ازدحام الشبكة مثل أثناء التنقل، فهذا المشهد هو يوم زائرك الحقيقي لا الاستثناء.

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

علاقة السرعة بالسيو وبالأرباح معًا

جوجل تذكر صراحة أن Core Web Vitals جزء من إشارات تجربة الصفحة التي تدخل في الترتيب، والصياغة الأمينة للواقع أن الأثر يظهر عند الحدود: موقع بطيء جدًا يخسر موقعه أمام منافس مماثل المحتوى أسرع منه، وموقع سريع لا يقفز بمعجزة فوق محتوى أضعف. المهم أن السرعة تعمل لصالحك مركبًا مع بقية العوامل، لا كخداع منفرد، وهذا ما يفعله منافسوك الجادون فعلًا.

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

خطة أسبوع واحد لتحسين واقعي

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

بعد الأسبوع ابق على روتين خفيف: قياس شهري سريع بعد كل تغيير كبير، ومراقبة تقرير تجربة المستخدم في Search Console الذي يظهر لك اتجاهات الزوار الحقيقيين على مدار الشهور. وإن كنت تبني موقعًا جديدًا الآن فابدأ بإطار سريع من الأساس، لأن إصلاح موقع نظيف أسهل دائمًا من إنقاذ موقع تراكمت عليه الإضافات، وشرحت أول الخطوات في مقال الطريق إلى ادسنس الأساسات.

أسئلة يطرحها أصحاب المواقع عن السرعة

هل تؤثر المؤشرات في الترتيب بشكل مباشر؟

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

ما الفرق بين نتيجة الاختبار وبيانات الزوار الحقيقيين؟

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

هل الخدمات الثقيلة مثل أدوات الدردشة تفسد مؤشراتي؟

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

هل أحتاج شبكة توزيع محتوى CDN لموقعي الصغير؟

شبكة التوزيع تخدم ملفاتك من خوادم قريبة من زوارك جغرافيًا، فتختصر زمن الوصول وتخفف الضغط عن خادمك الأصلي. لموقع صغير بجمهور ممركز في بلد واحد قد لا يشعر بأثر كبير، أما إن كان جمهورك موزعًا بين الخليج ومصر والمغرب العربي فالأثر واضح في LCP لكل منهم. استضافة GitHub Pages التي تعتمدها المدونات الثابتة تأتي مع بنية توزيع عالمية مدمجة، فتحصل على الميزة بلا تكلفة إضافية.

هل القوالب الجاهزة بطيئة بطبيعتها؟

القالب بذاته نادرًا ما يكون السبب الكامل، فالقالب النظيف مهما كان جاهزًا يبقى أسرع من مجموعة إضافات مثقلة عليه. المشكلة عادة ما يلحق بالقالب: خطوط كثيرة، وسلايدرات لم تُطلب، وأيقونات محملة كمكتبة كاملة لاستخدام خمسة منها. القالب الجيد يمنحك أرضية سليمة، والانضباط فيما تضيفه بعده هو الذي يحفظ الأداء، وهذا المنطق نفسه الذي بني به قالب هذه المدونة.

هل ستؤثر الإعلانات لاحقًا على هذه المؤشرات؟

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

أبدأ بإصلاح أي مؤشر أولًا؟

ابدأ بالمؤشر الأسوأ رقمًا في بيانات زوارك الحقيقيين، فالأثر المركب أكبر حين ترفع أضعف نقطة. وإن كانت الأرقام متقاربة فابدأ بـLCP لأن إصلاحاته عادة الأبسط والأسرع أثرًا، من صور وخطوط وأولويات تحميل. ثم انتقل لCLS بضبط الأبعاد، واترك INP للنهاية لأنه يحتاج غالبًا مراجعة سكربتات أعمق وتدريجية.

الخلاصة: ثلاثة أرقام تحمي تجربة زوارك

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