المقاييس الثلاثة لـ Core Web Vitals ومعاييرها لعام 2026
تقيس Google تجربة المستخدم من خلال ثلاثة مقاييس رئيسية تُعرف بـ Core Web Vitals. لكل منها معيار «جيد» ومعيار «يحتاج إلى تحسين» تتأثر الترتيبات عند تجاوزه.
LCP — Largest Contentful Paint. يقيس وقت ظهور أكبر عنصر مرئي (صورة رئيسية، كتلة نص أساسية). معيار الجودة: ≤ 2 500 ms. يحتاج إلى تحسين: بين 2 500 ms و4 000 ms. ما فوق 4 000 ms: ضعيف.
INP — Interaction to Next Paint. استُحدث خلفاً لـ FID، ويقيس الفجوة الزمنية بين إيماءة المستخدم (نقرة، ضغطة مفتاح، لمس) والتصيير المرئي التالي. معيار الجودة: ≤ 200 ms. يحتاج إلى تحسين: بين 200 ms و500 ms. ما فوق 500 ms: ضعيف.
CLS — Cumulative Layout Shift. يقيس عدم استقرار تخطيط الصفحة — إزاحات الكتل أثناء التحميل. معيار الجودة: ≤ 0,1. يحتاج إلى تحسين: بين 0,1 و0,25. ما فوق 0,25: ضعيف.
تنطبق هذه المعايير على بيانات الميدان (CrUX)، لا على نتائج المختبر. درجة 90 في مختبر PageSpeed Insights لا تضمن اجتياز المعيار من قِبل المستخدمين الفعليين — وهذا الفارق مهم للوكالات التي تُقدّم تقارير المقاييس لعملائها.
- تراجع ترتيب البحث — دمجت Google مقاييس Core Web Vitals في إشارة تجربة الصفحة منذ عام 2021؛ الموقع المُصنَّف ضعيفاً في LCP أو INP يفقد مراكزه أمام منافس مماثل حققت مقاييسه نتائج خضراء.
- انخفاض نسبة النقر على الجوال — النتائج المرتبة جيداً تحمل ضمانةً ضمنية للثقة؛ بطء التحميل الملحوظ بعد النقر يرفع معدل الارتداد ويُسجَّل كإشارة مشاركة سلبية.
- انخفاض معدل التحويل — ترتبط كل ثانية إضافية في LCP تتجاوز 2.5 ثانية بارتفاع في معدل التخلي عن عربة التسوق؛ بالنسبة لموقع تجارة إلكترونية، قد يُلغي TTFB بقيمة 1 200 ms جزءاً كبيراً من الإيرادات الناتجة عن SEO.
- ارتفاع الإنفاق الإعلاني — يتضمن نقاط جودة Google Ads تجربة الصفحة المقصودة؛ LCP ضعيف يخفض النقاط ويرفع تكلفة النقرة على نفس الكلمة المفتاحية.
- خسارة عملاء الوكالة — حين يُظهر التقرير الشهري لأحد العملاء INP أحمر، يأتي السؤال فوراً؛ بدون بنية تحتية قادرة على الالتزام بالمعايير، لا تستطيع الوكالة ضمان حل دائم.
- بطء الفهرسة على الجوال — يتبع Googlebot للجوال نفس تأخير التصيير الذي يعانيه المستخدمون؛ TTFB مرتفع يُبطئ الزحف وقد يؤخر فهرسة الصفحات الجديدة.
- أثر ملموس على تجربة المستخدم — INP يتجاوز 500 ms يجعل التفاعلات (القوائم، المرشحات، النماذج) بطيئةً بشكل ملحوظ؛ التغذية الراجعة السلبية من المستخدمين غالباً ما تسبق تنبيهات المقاييس.
كيف يعيق TTFB وصول LCP: السلسلة السببية
TTFB (Time to First Byte) هو الوقت المنقضي بين طلب HTTP من المتصفح واستقبال أول بايت من استجابة الخادم. وهو الحد الأدنى الذي لا يمكن تجاوزه لكل شيء آخر.
على اتصال جوال عادي (متوسط 4G)، يملك المتصفح نحو 2 500 ms للوصول إلى معيار LCP الجيد. من هذه الميزانية تُستقطع أولاً: تحليل DNS، ومصافحة TLS، والـ TTFB. TTFB بقيمة 800 ms — شائع على استضافة مشتركة مشبعة — يُبقي 1 700 ms لتنزيل HTML والتحليل وتحميل الموارد الحاجبة وتصيير عنصر LCP. من الناحية العملية، هذه الميزانية غير كافية.
السلسلة السببية هي: يُنشئ الخادم الصفحة (PHP وقاعدة البيانات)، ثم يُرسل أول بايت. إذا لم يكن PHP-FPM مُفعَّلاً واستخدم الخادم mod_php بوضع prefork، فكل طلب يستأثر بعامل Apache كامل. تحت الحمل، تنضب العمال وتدخل الطلبات في طابور انتظار. يتمدد TTFB بشكل غير خطي — استضافة مشتركة مشبعة قد تتجاوز 1 200 ms في الـ TTFB بينما تُظهر 200 ms حين تكون فارغة.
إضافة مخزن مؤقت للكائنات Redis يُقلل هذا الوقت بشكل ملحوظ: بدلاً من تنفيذ 40 إلى 80 استعلام SQL لتركيب صفحة WordPress، يُعيد المخزن المؤقت النتيجة المُسبقة الحساب في غضون ميلي ثوانٍ. بدون Redis، كل إخفاقة لمخزن الصفحة الكاملة (WP Rocket أو W3TC) تُطلق إعادة توليد كاملة ترفع TTFB إلى ما يتجاوز 600 ms.
HTTP/3 (QUIC) يُقلل زمن انتقال الاتصال بإلغاء رحلة الذهاب والإياب الإضافية في مصافحة TCP+TLS، وهو أثر محسوس بشكل خاص على الجوال وعلى الشبكات ذات فقدان الحزم. يستلزم التفعيل خادماً يدعم QUIC — غير متوفر على جميع بيئات الاستضافة المشتركة.
استضافة مشتركة مشبعة مقابل VPS مع PHP-FPM وRedis
| المعيار | استضافة مشتركة مشبعة | VPS + PHP-FPM + Redis |
|---|---|---|
| متوسط TTFB تحت الحمل | 800 – 1 200 ms | 120 – 250 ms |
| تنفيذ PHP | mod_php prefork (عامل مشترك) | PHP-FPM (حوض مخصص، غير حاجب) |
| مخزن مؤقت للكائنات | غير متوفر أو معطَّل | مقبس Redis محلي، زمن انتقال < 1 ms |
| HTTP/3 (QUIC) | نادراً ما يكون متوفراً | قابل للتهيئة على nginx / Caddy |
| درجة LCP (ميدانياً) | يحتاج تحسيناً إلى ضعيف في الغالب | جيد يتحقق على اتصال عادي |
| درجة INP (ميدانياً) | يعتمد على JS من جانب العميل | نفس JS، أحداث حجب شبكة أقل |
| عزل الموارد | CPU والذاكرة مشتركة بين العملاء | موارد مخصصة، لا تأثير للجيران الصاخبين |
تحسين الطبقة الخادمية من جانب الاستضافة
تفعيل PHP-FPM بدلاً من mod_php
على Apache، استبدال mod_php بـ PHP-FPM مع mpm_event يُزيل انسداد العمال على الطلبات البطيئة. التحقق من الوضع النشط: apache2ctl -M | grep php. على nginx، يُعد PHP-FPM الوضع الوحيد المتاح — تأكد من تحجيم الحوض وفق الحمل (pm.max_children يُحسب من الذاكرة المتاحة مقسومةً على متوسط استهلاك العامل).
تهيئة Redis كمخزن مؤقت للكائنات في WordPress
تثبيت Redis على الخادم (apt install redis-server أو عبر مدير حزم التوزيعة). تفعيل مقبس Unix بدلاً من TCP لتقليل زمن الانتقال: unixsocket /var/run/redis/redis.sock. في WordPress، تثبيت مكوّن مخزن كائنات Redis والإشارة إلى المقبس. التحقق من التفعيل بـ wp redis status — يجب أن يُظهر الحالة Connected.
تفعيل ضغط Brotli وGzip
Brotli يُحقق معدل ضغط أعلى من Gzip على موارد النص (HTML وCSS وJS). على nginx، التحقق من توفر الوحدة: nginx -V 2>&1 | grep brotli. بدون Brotli يبقى Gzip فعّالاً: gzip_comp_level 6; gzip_types text/plain text/css application/javascript application/json image/svg+xml;. تفعيل الخدمة المُضغوطة مسبقاً (ملفات .gz ثابتة) للموارد التي لا تتغير.
تفعيل HTTP/3 (QUIC) على nginx أو Caddy
Caddy يُفعّل HTTP/3 افتراضياً دون إعداد إضافي. على nginx، يعتمد التوفر على النسخة المُصرَّفة: nginx -V 2>&1 | grep http3. إضافة في كتلة server: listen 443 quic reuseport; add_header Alt-Svc 'h3=":443"; ma=86400';. فتح منفذ UDP 443 في جدار الحماية (ufw allow 443/udp). التحقق بـ curl --http3 -I https://yourdomain.com.
تهيئة ترويسات ذاكرة التخزين المؤقت للمتصفح
الموارد الثابتة (الصور والخطوط وCSS وJS المُصدَّرة بإصدار) يجب أن تحمل Cache-Control: public, max-age=31536000, immutable. صفحات HTML يجب أن تحمل Cache-Control: no-store أو max-age قصيراً إذا كان هناك مخزن صفحات نشط في المنبع. التحقق من الترويسات في الإنتاج: curl -I https://yourdomain.com/wp-content/themes/my-theme/style.css.
تفعيل مخزن الصفحات على الخادم (إذا لم يكن CDN يتولاه)
مخزن صفحات جانب الخادم (nginx FastCGI cache أو وحدة Varnish) يُعيد HTML المُسبق التجميع دون لمس PHP أو قاعدة البيانات. حينها يهبط TTFB إلى أقل من 50 ms للصفحات المخزَّنة. استبعاد صفحات السلة والحساب والصفحات ذات ملف تعريف ارتباط الجلسة من التخزين المؤقت: fastcgi_cache_bypass $cookie_woocommerce_items_in_cart;.
قياس TTFB في ظروف حقيقية باستخدام WebPageTest
إجراء اختبار من webpagetest.org باختيار نقطة تواجد قريبة من الهدف الجغرافي للعملاء. اختر ملف جوال (Moto G4 أو ما يعادله) واتصال 4G محاكاةً. في النتائج، اقرأ عمود TTFB في شلال التحميل — يعزل وقت الخادم عن وقت الشبكة. قارن الاختبارات الساخنة (مخزن مؤقت حاضر) والباردة (مخزن مؤقت مُفرَّغ عبر معامل الاختبار).
التحقق من الأثر الفعلي عبر CrUX وSearch Console
PageSpeed Insights يعرض بيانات CrUX للنطاق المحلَّل حين تكون متوفرة (حجم زيارات كافٍ). مقاييس الميدان تظهر في قسم 'بيانات الحقل' — هذه هي الوحيدة التي تهم Google. في Search Console، يجمّع تقرير 'تجربة الصفحة' عناوين URL حسب الحالة (جيد / يحتاج تحسيناً / ضعيف) على نافذة 28 يوماً متجددة.
القياس الصحيح: WebPageTest مقابل PageSpeed Insights
WebPageTest وPageSpeed Insights يقيسان شيئين مختلفين، والخلط بينهما يُفضي إلى قرارات خاطئة.
PageSpeed Insights يُجري تدقيقاً بـ Lighthouse في المختبر — ظروف محكومة، جهاز محاكاة، شبكة محاكاة. الدرجة المعروضة (من 0 إلى 100) هي تقييم لفرص التحسين، لا قياس لأداء المستخدمين الفعليين. موقع قد يسجّل 95 في المختبر ويُصنَّف ضعيفاً في بيانات الميدان إذا أفسد المحتوى الديناميكي أو تفاعلات JavaScript المقاييس الحقيقية. درجة PageSpeed Insights ليست إشارة ترتيب Google.
WebPageTest يُتيح التهيئة الدقيقة لنقطة الاختبار الجغرافية وملف الجهاز ومحاكاة الشبكة. يكشف شلال التحميل الكامل وتوقيتات DNS/TCP/TLS/TTFB، ويدعم الاختبارات متعددة الخطوات لقياس INP على تفاعل محاكى. لتشخيص TTFB مرتفع، WebPageTest هو الأداة المرجعية.
بيانات CrUX (Chrome User Experience Report) تجمع المقاييس الحقيقية من مستخدمي Chrome على مدار 28 يوماً. متاحة عبر PageSpeed Insights وSearch Console وواجهة برمجة CrUX مباشرةً. هذه هي البيانات التي تستخدمها Google للترتيب — لا درجة Lighthouse.
قراءة تقرير CrUX في Search Console: افتح الخاصية، انتقل إلى 'تجربة الصفحة'، ثم 'تقرير Core Web Vitals'. يُميّز التقرير بين الجوال وسطح المكتب. انقر على 'عناوين URL الجيدة' أو 'عناوين URL الضعيفة' لمعرفة الصفحات المتأثرة. إذا كان حجم البيانات غير كافٍ (موقع بزيارات قليلة)، لن تظهر بيانات CrUX — استخدم حينئذٍ PageSpeed Insights على عناوين URL الرئيسية، ولاحظ أن أثر الترتيب يبقى حقيقياً حتى بدون تقرير Search Console متاح. بالنسبة لعملاء الوكالة ذوي الزيارات المنخفضة، ركّز على قياسات WebPageTest والمعايير المطلقة بدلاً من تقارير CrUX.
تشخيص الأعطال: أربعة حالات شائعة
TTFB صحيح لكن INP أحمر. TTFB أقل من 250 ms لا يضمن INP دون 200 ms. يقيس INP استجابة التفاعلات لا التحميل الأوّلي. الأسباب الشائعة لـ INP مرتفع رغم TTFB جيد: خيط JavaScript الرئيسي محجوب بسكريبتات طرف ثالث (تحليلات، دردشة، إعلانات) أثناء مرحلة التفاعلية؛ مهام طويلة (Long Tasks تتجاوز 50 ms) تؤخر التصيير بعد النقر؛ ترطيب Vue أو React مكلف على صفحة SSR. التشخيص في Chrome DevTools > Performance بتسجيل تفاعل وتحديد المهام الطويلة على الخيط الرئيسي.
INP يجتاز المختبر لكنه يفشل في الميدان. أدوات المختبر (Lighthouse وWebPageTest) تقيس INP على تفاعلات محاكاة في ظروف محكومة. في بيانات الميدان، يشمل INP جميع تفاعلات جميع المستخدمين، بما فيهم أصحاب الأجهزة منخفضة المواصفات مع سكريبتات طرف ثالث محمَّلة وإضافات متصفح نشطة واتصال متذبذب. قد يتجاوز INP بقيمة 180 ms في المختبر 500 ms في الميدان إذا كان سكريبت طرف ثالث يحجب الخيط الرئيسي أثناء التحميل الأولي. حدّد سكريبتات الطرف الثالث بـ webpagetest.org وقِس أثرها على الخيط الرئيسي.
LCP بطيء رغم Cloudflare. تُخزِّن Cloudflare الموارد الثابتة مؤقتاً لكنها لا تُخزِّن صفحات HTML افتراضياً (إلا بتهيئة صريحة عبر Page Rules أو Cache Rules). إذا كان LCP مدفوعاً بعنصر HTML (نص أو صورة مضمَّنة في HTML)، يظل TTFB صفحة HTML هو المحدد لـ LCP. تحقق من ترويسة CF-Cache-Status في استجابة HTTP: curl -I https://yourdomain.com | grep CF-Cache-Status. إذا كانت القيمة DYNAMIC أو BYPASS، فالصفحة غير مخزَّنة في Cloudflare ويُطبَّق TTFB الخادم بالكامل.
CLS يتراجع بعد تحديث القالب. CLS حساس للموارد التي تُحمَّل بدون أبعاد محددة (صور بدون width/height، خطوط ويب تُسبب FOIT/FOUT، لافتات يُضيفها JavaScript). بعد تحديث القالب، تحقق منهجياً من أن الصور تحمل سمات أبعاد صريحة وأن خطوط الويب تستخدم font-display: swap أو optional. افحص جلسة تسجيل CLS في PageSpeed Insights (قسم التشخيص) لتحديد العنصر المتحرك.
ما يمكن للوكالة أن تعده لعملائها
تقرير PageSpeed الأحمر ليس حكماً نهائياً، لكن من الضروري التمييز بين ما يخص الاستضافة وما يخص كود العميل.
من جانب الاستضافة، الالتزامات القابلة للقياس هي: TTFB أقل من 250 ms في ظروف الحمل العادية، توفر PHP-FPM مع حوض مُحجَّم، مخزن كائنات Redis نشط، وضغط Brotli أو Gzip على موارد النص. هذه النقاط الأربع تغطي الجانب الخادمي من LCP وتُقلل ميكانيكياً من خطر تجاوز 2 500 ms على صفحة مُحسَّنة من جانب العميل.
INP يبقى جزئياً تحت مسؤولية كود الواجهة الأمامية — سكريبتات الطرف الثالث وترطيب JavaScript والمهام الطويلة لا تتبع مزوّد الاستضافة. ما تستطيع الاستضافة فعله لـ INP: تقليل TTFB (وقت انتظار أقل قبل بدء تنفيذ JS)، وتفعيل HTTP/3 (زمن انتقال أقل للموارد الحاجبة)، وتجنّب التنافس على CPU الذي يُطيل مهام JavaScript أثناء تصيير SSR.
وكالة تدير محفظة من العملاء تستطيع ضمان المعايير من جانب الخادم، وتوثيق قياسات WebPageTest وCrUX لكل نطاق، وعزل حالات التراجع إلى مصدرها — قالب، مكوّن، سكريبت طرف ثالث أو طاقة خادم. هذه القدرة على العزل هي ما يُميّز الوكالة التي تنفعل بتقارير PageSpeed عن تلك التي تتحكم فيها.
