Core Web Vitals: ما الذي يجب مراقبته وكيفية إصلاح التراجعات
تراجعات الأداء لا تُشحَن عن قصد تقريباً أبداً. تصل مع تغيير يبدو بريئاً: carousel صور جديد، tag طرف ثالث، تبديل خط. بحلول الوقت الذي يلاحظ فيه أحدهم انخفاض التحويلات، يكون التراجع عمره أسبوعان. تقلب المراقبة المستمرة الحلقة — ترى التراجع في اليوم نفسه.
Google يُرتِّب المواقع حسب أداء المستخدم الحقيقي. LCP وFCP وCLS وTTFB — ليست أرقاماً مجردة، بل قاتلة للتحويلات حين تنحرف. هكذا تُراقبها باستمرار وتصطاد التراجعات قبل أن تصل إلى المستخدمين.
ما تقيسه Core Web Vitals فعلاً
المقاييس الستة التي تهتم بها، بمصطلحات بسيطة:
• LCP (Largest Contentful Paint) — الوقت حتى انتهاء عرض أكبر عنصر مرئي. جيد < 2.5s. • FCP (First Contentful Paint) — الوقت حتى عرض أي بكسل. جيد < 1.8s. • CLS (Cumulative Layout Shift) — مقدار قفز الصفحة عند التحميل. جيد < 0.1. • TTFB (Time to First Byte) — تأخير الخادم/CDN الصافي. جيد < 0.8s. • TBT (Total Blocking Time) — مدة انشغال الخيط الرئيسي. جيد < 200ms. • Speed Index — درجة مُركَّبة لإحساس السرعة. جيد < 3.4s.
لماذا تكذب درجات المختبر الاصطناعية
يُشغِّل Lighthouse-CI صفحتك على جهاز متوسط مُحاكى مع 3G مُحاكاة. هو جيد للمقارنات النسبية، لكنه يفوته كثير من حالات الفشل الحقيقية. سكربتات طرف ثالث تُحمَّل ببطء بناءً على موافقة الكوكيز، فروع A/B تظهر لنصف المستخدمين فقط — لا يراها Lighthouse أبداً.
فحص Playwright بمتصفح كامل يصطاد الإخفاقات التي يفوتها Lighthouse. يُشغِّل SpeedTest الاثنين.
قراءة الرسوم: تراجعات تدريجية مقابل قفزات
شكلان من التراجعات يرويان قصصاً مختلفة.
تسلق تدريجي في LCP على مدى أسبوعين يعني عادةً أن مصدراً واحداً ينمو — تغذية صور منتج تضيف عناصر دون ترقيم، حزمة تحليلات تكتسب ميزات.
تغيير قفزة عند نشر واحد — TTFB يقفز من 400ms إلى 1200ms بين عشية وضحاها — هو سبب مباشر على مستوى الكود. اربط الطابع الزمني بمُدخلات DeployLog الخاصة بك.
حدود التنبيه لكل مقياس التي تريدها فعلاً
حد واحد لكل مقياس، تنبيه عند تجاوز حدود 'poor' بدلاً من 'تراجع بنسبة 10%' الصارخ:
• LCP > 4.0s — تنبيه • FCP > 3.0s — تنبيه • CLS > 0.25 — تنبيه • TTFB > 1.8s — تنبيه • TBT > 600ms — تنبيه
اقرن هذه بحد 'تحذير' عند خط 'needs improvement' من Google.
ماذا تفعل عند تراجع CWV بعد نشر
الكُتيِّب عند اشتعال مقياس أحمر مباشرة بعد إصدار:
1. افتح أثر Playwright للتشغيل الفاشل. 2. ابحث عن المصدر الجديد أو المُعدَّل. 3. إذا كان طرف ثالث، افحص صفحة حالتهم وفكِّر في `async` أو `defer`. 4. إذا كان كودك، اربط مع DeployLog وتراجع أو hotfix. 5. أضف نمط الفشل إلى قائمة ما قبل النشر.
دليل ميزة
Uptime Monitoring
AlertsDock gives teams uptime monitoring for websites, APIs, TCP checks, DNS checks, SSL expiry, and fast alert routing without enterprise overhead.
اقرأ الدليلصفحة بديل
Better Stack Alternative
Compare AlertsDock with Better Stack for teams that want a more focused monitoring product covering uptime, cron jobs, status pages, and webhooks.
شاهد المقارنةMore articles
سجلات التغييرات المُولَّدة بالذكاء الاصطناعي: حوّل git commits إلى ملاحظات إصدار تلقائياً
كتابة ملاحظات الإصدار مهمة لا يريدها أحد. يقرأ DeployLog الcommits عند كل push ويُولِّد سجلات تغييرات نظيفة وقابلة للقراءة مُجمَّعة حسب النوع — لا حاجة إلى Anthropic، يعمل مع Groq وGemini وCloudflare وOpenRouter أو Ollama المُستضاف ذاتياً.
توقَّف عن إرسال ملفات .env بالبريد: دليل عملي للخزائن المُشفَّرة
DATABASE_URL فريقك في رسائل Slack الخاصة لشخص ما. STRIPE_SECRET_KEY لديك يعيش في صفحة Notion. هكذا تتسرَّب الأسرار. هذه هي النظافة التي كان يجب أن تمتلكها من اليوم الأول — وكيف تجعلها الخزائن المُشفَّرة غير مؤلمة.
كُتيِّبات الحوادث التي تُنفَّذ تلقائياً: من runbook إلى runtime
كتابة runbook لا يقرؤه أحد في الثالثة صباحاً هو هدر. كتابة واحد يبدأ تلقائياً لحظة تعطُّل monitor ويسجِّل كل خطوة هو مضاعِف قوة. هكذا تجعل on-call يشعر بأنه أقل كاستجابة أزمة منفردة وأكثر كاتباع قائمة تحقق.