إيجي تاج · اعرف. ناقش. جرّب. نفّذ.

Core Web Vitals: ماذا تقيس ولماذا تهم المستخدم أكثر من رقم Lighthouse؟

Core Web Vitals: ماذا تقيس ولماذا تهم المستخدم أكثر من رقم Lighthouse؟

شرح LCP و INP و CLS وكيف تقيس تجربة التحميل والاستجابة والاستقرار البصري، ولماذا تحتاج بيانات حقيقية بجانب الاختبار المعملي.

الإجابة السريعة

شرح LCP وINP وCLS وكيف تقيس تجربة التحميل والاستجابة والاستقرار البصري، ولماذا تحتاج بيانات حقيقية بجانب الاختبار المعملي.

  • TTFB السيئة ترفع LCP قبل أن يبدأ الرسم.
  • صورة hero تحتاج sizing وpriority مناسبة.
  • CSS blocking قد تؤخر عرض النص.

Core Web Vitals تحاول قياس ثلاث جوانب يشعر بها المستخدم: متى يظهر المحتوى الرئيسي، مدى سرعة استجابة الصفحة للتفاعل، وهل يتحرك المحتوى بصورة مزعجة أثناء الاستخدام. المقاييس الأساسية الحالية هي LCP و INP و CLS. قيم Lighthouse مفيدة للتشخيص في بيئة معملية، لكنها ليست نفس تجربة كل المستخدمين على شبكات وأجهزة حقيقية. لذلك الأفضل الجمع بين Lab data و Real User Monitoring.

LCP تقيس ظهور المحتوى الرئيسي

Largest Contentful Paint تراقب وقت رسم أكبر عنصر محتوى مناسب داخل viewport خلال التحميل. الصور الكبيرة و hero text و server latency و CSS/JS blocking كلها قد تؤثر. تحسين LCP يبدأ بمعرفة العنصر الفعلي لا تطبيق قائمة عامة.

INP تقيس استجابة التفاعل

Interaction to Next Paint تنظر إلى latency للتفاعلات خلال الزيارة وتختار قيمة تمثل أسوأ الاستجابات تقريبًا بدل أول تفاعل فقط. long tasks و JavaScript ثقيلة و render متأخر يمكن أن تجعل click تشعر ببطء حتى لو الصفحة حملت بسرعة.

CLS تقيس الحركة غير المتوقعة

Cumulative Layout Shift تجمع shifts غير المتوقعة أثناء عمر الصفحة وفق قواعد المقياس. صور بلا dimensions، banners تُضاف فوق المحتوى، أو Fonts تغير المقاسات قد تسبب حركة مزعجة.

خطوات عملية

  1. حدد العنصر أو التفاعل المسبب.
  2. قِس على أجهزة حقيقية.
  3. قلل blocking work.
  4. خصص أبعاد media.
  5. اختبر بعد التغيير.
  6. راقب field data عبر الوقت.

لا تطارد Score واحد

Lighthouse score تجمع عوامل متعددة في run واحدة. استخدمها لاكتشاف فرص، لكن راقب كل metric واتجاهاتها. قد تتحسن score بينما user journey معينة تظل بطيئة.

Field data تكشف التوزيع

المتوسط يخفي مستخدمين بطيئين. راقب percentiles وفرق mobile/desktop والبلدان والصفحات. إصلاح template سيئة قد يعطي أثرًا أكبر من تحسين micro-optimization في الصفحة الرئيسية.

الأداء وظيفة Product

كل feature تضيف JavaScript أو images أو widgets لها تكلفة. ضع performance budgets في CI أو review، وراقب regression بعد releases بدل حملة تحسين مرة واحدة.

قائمة مراجعة

  • LCP element معروفة.
  • INP interactions مرصودة.
  • CLS sources محددة.
  • RUM موجودة إن أمكن.
  • Budgets واضحة.
  • التغييرات تقاس قبل/بعد.

قسّم Field Data حسب السياق

نتيجة الموقع الكلية قد تخفي صفحة أو بلدًا أو device type سيئًا. قسم القياسات حسب template، mobile/desktop، وربما connection class عندما تتوفر البيانات بشكل يحترم الخصوصية. هذا يساعدك على إصلاح مشكلة حقيقية بدل تحسين الصفحة الأسرع أصلًا.

افصل ما هو Server-side وما هو Client-side

LCP قد تتدهور بسبب TTFB أو بسبب صورة hero متأخرة أو JavaScript تحجب الرسم. INP غالبًا ترتبط بال main thread، بينما CLS قد تأتي من media أو fonts. قبل اختيار الحل، حدد أي طبقة مسؤولة حتى لا تحاول إصلاح مشكلة backend بإزالة CSS أو العكس.

هل تريد الاحتفاظ بالمقال أو إعادة استخدامه؟
مجتمع إيجي تاجعن المجتمع

شارك في تقييم ونقاش المقال

رأيك يضيف قيمة للمقال ويساعدنا على تحسين المحتوى والنقاش حوله.

تفاعل مع المقالاختر التفاعل المناسب، ويمكنك تغيير رأيك لاحقًا.
قيّم جودة المقاللا توجد تقييمات بعد — كن أول من يقيّم.

نقاش القراء

النقاش

جارٍ تحميل التعليقات…

بعد هذه المادة

تابع القراءة

كل مواد #البرمجة وتطوير الويب
مرتبطة بنفس الوسوم04
  1. 02
  2. 03
  3. 04
اختيار القراء

الأكثر قراءة

الترتيب الكامل
  1. 01
  2. 02
  3. 03
  4. 04
  5. 05
يتجدد مع النشر

أحدث المواد

  1. 01
  2. 02
  3. 03
  4. 04
  5. 05
  6. 06