مؤشرات الويب الأساسية مجموعة من ثلاثة مقاييس تقيس جوانب محددة وحقيقية من شعور استخدام الصفحة — لا "درجة أداء" مجردة واحدة. يعزل كل مقياس نوعًا مختلفًا من المشكلة التي يلاحظها المستخدم، وهذا أيضًا ما يجعلها مفيدة تشخيصيًا: نتيجة ضعيفة في مقياس محدد تشير إلى فئة إصلاح محددة، لا إلى تعليمة غامضة بـ"تسريع الموقع".
ماذا تقيس مؤشرات الويب الأساسية فعليًا
المقاييس الثلاثة الحالية هي Largest Contentful Paint (سرعة التحميل، من منظور الزائر)، وInteraction to Next Paint (الاستجابة للإدخال)، وCumulative Layout Shift (الثبات البصري أثناء تحميل الصفحة). تُقاس الثلاثة جميعًا بناءً على أنماط تجربة مستخدم حقيقية لا ظروف معملية اصطناعية بحتة، وهذا سبب تفاوت نتيجة الصفحة نفسها باختلاف أجهزة وظروف شبكة الزوار الفعليين.
مثال ملموس: قبل وبعد
صفحة رئيسية نموذجية لشركة قبل معالجة مؤشرات الويب الأساسية: صورة رئيسية غير مضغوطة بحجم 4 ميجابايت تجلس أعلى الصفحة دون عرض أو ارتفاع محدد صراحة، وثلاثة نصوص برمجية خارجية منفصلة (تحليلات، أداة محادثة، تضمين اجتماعي) تُحمَّل بشكل متزامن في رأس الصفحة قبل عرض أي محتوى، ولافتة ترويجية تُدرج نفسها فوق العنوان الرئيسي بعد ثانية من تحميل بقية الصفحة بالفعل. النتيجة رسم أول بطيء (لا يستطيع المتصفح بدء العرض حتى تنتهي النصوص البرمجية المعطّلة للعرض)، وتأخير إضافي قبل ظهور الصورة الرئيسية نفسها، وقفزة مرئية مع دفع اللافتة المتأخرة للعنوان للأسفل — LCP ضعيف وCLS ضعيف من سببين غير مرتبطين على الصفحة نفسها.
بعد معالجة كل سبب مباشرة: تُضغط الصورة الرئيسية وتُقدَّم بصيغة حديثة بأبعاد محددة صراحة، بحيث يحجز المتصفح مساحتها فورًا؛ وتُؤجَّل النصوص البرمجية الخارجية لتُحمَّل بعد المحتوى الرئيسي لا أن تعطّله؛ وتُحجَز مساحة اللافتة الترويجية في التخطيط من البداية، بحيث تملأ فتحة مخصصة مسبقًا بدلاً من دفع المحتوى عند وصولها. لا يمس أي من هذه التغييرات تصميم الصفحة الفعلي — الإصلاحات تتعلق بـكيفية تحميل المحتوى نفسه، لا بمحتوى الصفحة.
LCP: أكبر عنصر محتوى مرئي
يقيس LCP المدة التي يستغرقها أكبر عنصر محتوى مرئي — عادة صورة رئيسية، أو كتلة نص كبيرة، أو صورة خلفية — ليُعرَض بالكامل ضمن نافذة العرض. يهدف هذا لتقريب "متى تشعر هذه الصفحة بأنها محمّلة" من منظور الزائر، لا قياس معلم تقني عشوائي لا يقابل شيئًا يلاحظه الزائر فعليًا. LCP جيد أقل من 2.5 ثانية؛ وأي شيء بعد 4 ثوانٍ يُعتبر ضعيفًا. عمليًا، يعود LCP البطيء دائمًا تقريبًا إلى أحد ثلاثة أسباب: زمن استجابة خادم بطيء قبل استقبال المتصفح أي محتوى أصلاً (الوقت حتى أول بايت)؛ أو CSS أو JavaScript معطّل للعرض في رأس الصفحة يؤخر بدء المتصفح رسم أي شيء، حتى محتوى جاهز خلاف ذلك؛ أو أن عنصر LCP نفسه — عادة صورة — كبير جدًا أو غير مضغوط أو يُحمَّل بعد موارد أقل أولوية بدلاً من إعطائه الأولوية.
INP: زمن الاستجابة للتفاعل
يقيس INP زمن الاستجابة بين تفاعل الزائر مع الصفحة — نقرة، لمسة، ضغطة مفتاح — واستجابة المتصفح بصريًا لذلك التفاعل. حلّ محل مقياس سابق يُدعى First Input Delay تحديدًا لأنه يلتقط الاستجابة طوال عمر الصفحة، لا التفاعل الأول فقط. INP جيد أقل من 200 ميلي ثانية. لـINP الضعيف مجموعة أسباب أضيق من LCP: مهام JavaScript طويلة التشغيل تعطّل الخيط الرئيسي للمتصفح مسؤولة عن معظمها تقريبًا — نص برمجي ثقيل يُنفَّذ عند النقر على زر، أو معالج حدث غير فعّال يؤدي عملاً أكثر من اللازم، أو كمية كبيرة من المعالجة المتزامنة (إعادة عرض مكوّن كبير، تشغيل حساب معقّد) تحدث مباشرة استجابة لتفاعل واحد بدلاً من تقسيمها إلى أجزاء أصغر أو تأجيلها.
CLS: التحول التراكمي في التخطيط
يقيس CLS الحركة البصرية غير المتوقعة لمحتوى الصفحة أثناء تحميلها — التجربة المزعجة لتحول صفحة تحت مؤشر الزائر وهو على وشك النقر على شيء ما. الأسباب العملية متسقة عبر معظم المواقع: صور أو تضمينات فيديو دون عرض/ارتفاع محجوز (أو نسبة أبعاد CSS)، فلا يعرف المتصفح كمية المساحة التي يتركها حتى ينتهي الملف نفسه من التحميل؛ إعلانات أو تضمينات خارجية تُدرج محتوى في الصفحة بعد عرض التخطيط المحيط بها بالفعل؛ خطوط ويب تتبدّل وتغيّر حجم النص أو طول السطر بعد عرض خط احتياطي أولي؛ ومحتوى — لافتات، إشعارات ملفات تعريف الارتباط، أشرطة ترويجية — يُدرَج فوق محتوى موجود بدلاً من فتحة محجوزة مسبقًا. نتيجة CLS جيدة أقل من 0.1، وإصلاح كل هذه الأسباب تقريبًا من فئة التغيير نفسها: احجز المساحة قبل وصول المحتوى، بدلاً من إعادة تحجيم التخطيط عند وصوله.
لماذا يتجاوز تأثير هذا ترتيب البحث فقط
مؤشرات الويب الأساسية مكوّن مؤكد في ترتيب البحث، وهذا سبب مناقشتها أساسًا كموضوع SEO — لكن التعامل معها كمجرد مربع اختيار للترتيب يقلل من قيمة ما تقيسه فعليًا. تتبع المقاييس الثلاثة جميعًا شيئًا يختبره الزائر الحقيقي مباشرة: كم ينتظر، ومدى استجابة الصفحة عند تفاعله معها، وما إذا كانت الصفحة تتصرف بشكل متوقع أثناء التحميل. ترتبط النتائج الضعيفة بمعدلات ارتداد أعلى وتحويل أقل بمعزل عن أي أثر لترتيب البحث، لأن صفحة بطيئة ومتقلبة وغير مستجيبة تجربة أسوأ بغض النظر عن كيفية وصول الزائر إليها.
مسار تشخيصي بسيط
بدلاً من تخمين أي المقاييس الثلاثة هو المشكلة، يحدد فحص تشخيصي قصير ذلك مباشرة: شغّل الصفحة عبر أداة قياس مؤشرات الويب الأساسية ولاحظ أي من النتائج الثلاث ضعيف — فهي مستقلة، لذا من الشائع أن يفشل موقع في واحد وينجح في الاثنين الآخرين. إن كان LCP هو المشكلة، تحقق من الوقت حتى أول بايت أولاً (استجابة خادم بطيئة تؤخر كل ما بعدها بغض النظر عما حُسِّن آخر)، ثم تحقق مما إذا كان عنصر LCP معطَّل العرض أو غير مُحسَّن. إن كان INP هو المشكلة، ابحث عن أثقل نص برمجي خارجي أو داخلي يعمل عند التفاعل، لأن هذا السبب المهيمن في معظم الحالات الواقعية. إن كان CLS هو المشكلة، ابحث تحديدًا عن صور دون أبعاد محجوزة وأي محتوى يُحمَّل فوق محتوى صفحة موجود، لأن هذين النمطين يفسران معظم مشاكل CLS الواقعية. إصلاح المقاييس بمعزل، بناءً على أيها فاشل فعليًا، أكفأ من تطبيق كل تحسين ممكن على صفحة لها مشكلة واحدة محددة فقط.
إصلاح الأسباب الأكثر شيوعًا
قائمة بداية عملية وعالية الأثر، مرتبة تقريبًا حسب التأثير النموذجي لموقع شركة قياسي: اضغط الصور وحدد حجمها بشكل صحيح، وقدّمها بصيغة حديثة؛ أزل الموارد المعطّلة للعرض حيث أمكن، أو أجّل CSS وJavaScript غير الحرجين؛ حدد أبعادًا صريحة للصور والمحتوى المضمّن لمنع تحول التخطيط؛ دقّق النصوص البرمجية الخارجية (تحليلات، أدوات محادثة، علامات إعلانية) لمعرفة مدى مساهمتها في كل من وقت التحميل وتعطيل الخيط الرئيسي، لأن الكود الخارجي سبب شائع بشكل غير متناسب لكل من LCP البطيء وINP الضعيف؛ وتأكد أن بيئة الاستضافة نفسها تملك معالجًا كافيًا وتخزينًا سريعًا — فزمن استجابة بطيء حتى أول بايت على مستوى الخادم يضع كل تحسين آخر في وضع غير مؤاتٍ قبل أن تبدأ الصفحة في العرض أصلاً. يساعد تخزين NVMe تحديدًا في مكوّن زمن استجابة الخادم من LCP؛ راجع ما هي استضافة NVMe لمزيد عن هذا الجزء. اتصال HTTPS آمن أيضًا شرط أساسي لعدة ميزات أداء حديثة؛ راجع شهادات SSL: لماذا يهم HTTPS كل موقع؟. بالنسبة لموقع بجمهور موزّع جغرافيًا، يمكن لـCDN أيضًا تقليل الجزء المرتبط بزمن استجابة الشبكة من LCP تحديدًا — راجع ما هي شبكة توصيل المحتوى (CDN)؟ ومتى يحتاجها موقعك فعلاً؟
