Core Web Vitals في المواقع العربية: بيانات مستخدمين حقيقيين لـ45 علامة تجارية

معظم مواقع العلامات التجارية العربية الكبرى ترسب في Core Web Vitals على الهواتف. قرأنا تقرير تجربة مستخدمي Chrome من جوجل (CrUX) لـ45 نطاقًا لعلامات تجارية في السعودية والإمارات ومصر وقطر والكويت يوم 4 أكتوبر 2026، فلم ينجح في المقاييس الثلاثة عند المئين الخامس والسبعين إلا 3 من 45. وتفسّر الخوادم البطيئة والوسوم الثقيلة والتخطيطات غير المستقرة معظم الفجوة.

أبرز النقاط

• 3 من 45 نطاقًا لعلامات عربية (7%) تجتاز LCP وINP وCLS معًا على الهواتف، وفق بيانات CrUX للأيام الثمانية والعشرين المنتهية في 26 سبتمبر 2026.
• LCP جيد: 9 من 45. INP جيد: 12 من 45. CLS جيد: 26 من 45.
• الوسيط لزمن وصول البايت الأول 1,246 ms، أي نحو 40% من LCP في الموقع الوسيط.
• شركات الطيران الأربع كلها سيئة في INP (من 514 إلى 1,205 ms). ولا يحقق أي من البنوك السبعة LCP جيدًا، ولا يحققه من شركات الاتصالات الثماني إلا 2.

كم موقعًا لعلامة تجارية عربية يجتاز Core Web Vitals على الهواتف؟

ثلاثة من 45: سلسلة بقالة سعودية، وبوابة عقارية إماراتية، وموقع إعلانات مبوّبة إماراتي، تجتاز المقاييس الثلاثة على الهواتف عند المئين الخامس والسبعين، وفق بيانات CrUX للأيام الثمانية والعشرين المنتهية في 26 سبتمبر 2026. ويخفق 7 نطاقات أخرى في مقياس واحد فقط، ويرسب 11 في المقاييس الثلاثة.

توثّق إرشادات Web Vitals تحدد الحدَّ المطلوب: LCP لا يتجاوز 2.5 ثانية، وINP لا يتجاوز 200 مللي ثانية، وCLS لا يتجاوز 0.1، وكلها عند المئين الخامس والسبعين. وقد حلّ INP محل First Input Delay في 12 مارس 2024.

ثلاثة نطاقات سعودية (تطبيق توصيل ومجموعة مستشفيات ومطوّر عقاري) لا تخفق إلا في LCP، وسوق إلكتروني سعودي لا يخفق إلا في CLS (0.12)، وشركتا اتصالات مصريتان وشركة طيران مصرية لا تخفق إلا في INP. وعلى الطرف الآخر يسجّل بنك مصري LCP قدره 8,835 ms، منها 4,633 ms لوصول البايت الأول، وتسجّل صيدلية سعودية CLS قدره 1.92، أي 19 ضعف الحد الجيد.

كيف تبدو المقارنة بين السعودية والإمارات ومصر؟

لا تُحسن أي دولة الأداء. للسعودية نطاق ناجح واحد من 15، وللإمارات 2 من 13، ولمصر 0 من 13. ويتراوح الوسيط لـLCP بين 3,446 و3,704 ms في الدول الثلاث، أي أعلى بكثير من حد 2,500 ms. وأوضح فرق هو INP: 8 من 15 نطاقًا سعوديًا جيدة، مقابل 2 في الإمارات و1 في مصر.

لمصر أكبر عدد من نتائج LCP الجيدة (4 من 13): شركتا اتصالات وسوق إلكتروني وشركة طيران، تُحمَّل سريعًا ثم تخفق في الاستجابة. ومع 13 إلى 15 نطاقًا لكل دولة، يحرّك موقع واحد النسبة نحو 7 نقاط، فاقرأ هذا اتجاهًا عامًا لا ترتيبًا.

أي القطاعات ترسب، وفي أي مقياس؟

كل القطاعات ترسب، ولكلٍّ مقياسه. شركات الطيران الأربع كلها سيئة في INP. والبنوك تخفق في LCP وCLS، وشركات الاتصالات تخفق في LCP وINP لكنها تحافظ على ثبات التخطيط، ومتاجر الإلكترونيات ترسب في الثلاثة. وأقرب القطاعات إلى النجاح البوابات العقارية والإعلانات المبوّبة، إذ ينجح 2 من 3. فالقطاع يتنبأ بالمقياس المعطوب أفضل مما تتنبأ به الدولة.

القطاعات الأصغر هي الصيدليات والتوصيل والمستشفيات والبقالة والأزياء وتطبيق شامل (Super App) والمدفوعات. ويخفق 6 من 7 بنوك في CLS، وأول ما سنفحصه اللافتات الترويجية المتأخرة، وإن كانت هذه البيانات لا تكشف السبب.

كيف أجرينا الفحص. في 4 أكتوبر 2026 قرأ فريق VOCTOS كل نطاق في CrUX Vis، لوحة جوجل لواجهة CrUX History API: على مستوى النطاق، للهاتف، في فترة 28 يومًا من 30 أغسطس إلى 26 سبتمبر 2026، بقيم p75. حاولنا قراءة 48 نطاقًا؛ لم يكن لشركة اتصالات مصرية سجل في CrUX، ولم نجمع بيانات شركتي طيران إماراتيتين لتوقف الأداة. واستبعدنا عملاء VOCTOS. أما الحدود: فالعلامات مختارة يدويًا لا عينة عشوائية، وبيانات النطاق تمزج كل الصفحات وبلدان الزوار كلها، وChrome على iOS لا يرسل بياناته إلى CrUX.

زمن استجابة الخادم يلتهم 40% من ميزانية LCP

يبدأ تعثّر LCP في هذه المواقع عند زمن وصول البايت الأول. فالنطاق الوسيط يحتاج 1,246 ms ليوصل أول بايت على الهواتف. ولا يحقق الدليل التقريبي لـweb.dev (0.8 ثانية) إلا 2 من 45، ويتجاوز 14 منها 1.8 ثانية. وفي الموقع الوسيط يستهلك TTFB نحو 40% من زمن LCP.

يسرد مقال TTFB على web.dev مكوّنات هذا الرقم: عمليات إعادة التوجيه، وبدء تشغيل service worker، وDNS، وإعداد الاتصال وTLS، وانتظار الخادم. وليس TTFB من مقاييس Core Web Vitals، لكن المتصفح لا يكتشف الصورة الرئيسية قبل وصول HTML. وتزيده عمليات إعادة التوجيه اللغوية (من الجذر إلى مسار عربي أو مسار الدولة)، وتقديمُ HTML من خادم أصلي بعيد. وتستغرق أبطأ ستة خوادم في عيّنتنا من 2.5 إلى 4.6 ثانية، أربعة منها مصرية.

ليست سعة الحوسبة الطرفية في المنطقة هي العائق، إذ إن صفحة الشبكةلدى Cloudflare، التي راجعناها في 4 أكتوبر 2026، تدرج مراكز بيانات في الرياض وجدة والدمام ودبي والدوحة ومدينة الكويت والمنامة ومسقط والقاهرة، و دراستنا عن التتبّع من جهة الخادم أحصت 16 منطقة سحابية عامة في الدول العربية. ولا ينفع القرب إلا إذا خُزّن HTML مؤقتًا أو وُلّد قريبًا من المستخدم.

هل تقترن الخطوط الثقيلة وبكسلات الإعلانات بالنتائج الراسبة؟

في عيّناتنا الصغيرة، نعم. الصفحات الرئيسية الست التي حمّلت 500 KB أو أكثر من خطوط الويب في زحفنا يوم 2 أكتوبر كلها ترسب في LCP على الهواتف، والأربع التي شغّلت بكسلات Meta وTikTok وSnap وX معًا كلها ترسب في INP. وهذه ارتباطات من 6 مواقع و4 مواقع، لا دليل على أن الخطوط أو البكسلات سبب الإخفاق.

وسيط LCP لمجموعة الخطوط 4,315 ms مقابل 3,678 ms للـ45 كلها، و دراستنا للخطوط العربية على الويب تتناول تقليص مجموعات الحروف (subsetting) وخفض الأوزان. والخطوط سبب من أسباب عدة: فالبنك صاحب 8,835 ms لديه أيضًا أبطأ خادم. ووسيط INP لمجموعة البكسلات الأربعة 375 ms مقابل 261 ms إجمالًا، و دراستنا عن وضع الموافقة والتتبّع وجدت تكديس البكسلات شائعًا في الصفحات الرئيسية العربية. ويختلف النطاق أيضًا: فالزحف قرأ صفحة رئيسية عربية واحدة على سطح المكتب من القاهرة، أما CrUX فيغطي كل الصفحات لمستخدمي الهواتف الحقيقيين.

إن أردت مطوّرًا يحوّل أرقام CrUX الخاصة بموقعك إلى قائمة إصلاحات مرتّبة حسب الأولوية، راجعوا Core Web Vitals لموقعي.

هل تؤثر Core Web Vitals في ترتيب جوجل؟

نعم، عاملًا واحدًا بين عوامل كثيرة. تنص وثائق تجربة الصفحة لدى جوجل على أن «أنظمة الترتيب لدينا تستخدم Core Web Vitals». وتنبّه الصفحة نفسها إلى أن النتائج الجيدة لا تضمن المراكز الأولى، وأن جوجل يعرض النتيجة الأكثر صلة حتى لو ضعفت تجربة الصفحة. فالنجاح يزيل عائقًا، لكنه لا يغني عن الصلة بالبحث.

‏ صفحة الأسئلة الشائعة عن تجربة الصفحة تضيف أن جوجل يقيّم الصفحات واحدةً واحدة، مع بعض التقييمات على مستوى الموقع كله، و صفحة Core Web Vitals في Search Central تحيل إلى Search Console للمتابعة.

كيف تقرأ بيانات CrUX الخاصة بك؟

استخدم ثلاث أدوات مجانية من جوجل بهذا الترتيب. يعرض CrUX Vis تاريخ 40 أسبوعًا للنطاق أو الرابط. ويعرض PageSpeed Insights أحدث بيانات ميدانية لـ28 يومًا بجانب اختبار معملي. ويجمع Search Console روابطك حسب حالتها. والأدوات الثلاث تقرأ مجموعة بيانات CrUX نفسها، فالفروق بينها تأتي من النطاق لا من اختلاف المستخدمين.

افتح cruxvis.withgoogle.com، وأدخل النطاق الأساسي (canonical) بدقة، واضبط الجهاز على Phone. وتُحدَّث CrUX History API التي يعتمد عليها كل يوم اثنين، وتغطي كل نقطة أسبوعية 28 يومًا. ويقسّم عرض التحميل فيه LCP إلى أجزاء الصورة الفرعية (زمن وصول البايت الأول، وتأخير التحميل، ومدة التحميل، وتأخير العرض)، فتعرف أي فريق يتولى الإصلاح.

غياب البيانات يعني غالبًا عدم الأهلية. إذ تشترط منهجية CrUX صفحة جذر تُرجع الرمز 200 دون noindex، وحركة Chrome كافية. وفي تقرير Core Web Vitals في Search Console، تأخذ مجموعة الروابط حالة أسوأ مقياس فيها.

إصلاح TTFB للجمهور العربي

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

قارن TTFB بمقياس زمن الذهاب والإياب (RTT) في CrUX Vis. فارتفاع RTT مع خادم سريع يدل على المسافة، وانخفاض RTT مع TTFB بطيء يدل على الواجهة الخلفية أو ضعف نسبة إصابة الذاكرة المؤقتة. خزّن قوالب الزوار غير المسجّلين على الحافة بضع دقائق، وأبقِ الأجزاء المخصّصة (عدد عناصر السلة، وقوائم الحساب) خارج تلك الذاكرة.

Cache-Control: public, max-age=0, s-maxage=300, stale-while-revalidate=60

إصلاح LCP: الصورة الرئيسية أولًا، والخطوط ثانيًا

اجعل عنصر LCP قابلًا للاكتشاف في HTML، واجلبه بأولوية عالية. فالصور تبدأ بأولوية منخفضة في Chrome ولا تُرفع إلا بعد التخطيط، كما يوضح دليل Fetch Priorityعلى web.dev. وبإضافة fetchpriority=”high” تبدأ الصورة الرئيسية مبكرًا، والصورة الرئيسية المعروضة خلفيةً في CSS تحتاج أيضًا إلى preload.

<!-- Hero as an img: high priority, never lazy-loaded -->
<img src="/img/hero-ar-800.avif"
     srcset="/img/hero-ar-480.avif 480w, /img/hero-ar-800.avif 800w"
     sizes="100vw" width="800" height="600"
     alt="Autumn offers on phones and laptops"
     fetchpriority="high">

<!-- Hero as a CSS background: preload it at high priority -->
<link rel="preload" as="image" href="/img/hero-ar-800.avif"
      fetchpriority="high">

إن أبقيت شريط التمرير (slider) فامنح الشريحة الأولى أولوية عالية والبقية fetchpriority=”low”. ثم أصلح الخطوط: فبعض الصفحات الرئيسية في زحفنا حمّلت مسبقًا ثمانية أو تسعة ملفات خطوط تنافس الصورة الرئيسية على عرض النطاق. حمّل مسبقًا ملفًا أو اثنين على الأكثر.

إصلاح INP: الوسوم والمهام الطويلة وإفساح المجال

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

المهمة الطويلة هي أي مهمة على الخيط الرئيسي تتجاوز 50 ms، وفق دليل web.dev عن تحسين المهام الطويلة. ولا يستطيع Lighthouse قياس INP لأن أحدًا لا ينقر في التشغيل المعملي، فاستعمل Total Blocking Time بديلًا معمليًا، واعتمد CrUX مرجعًا للحقيقة. وفي معالجات الأحداث لديك، حدّث الواجهة أولًا ثم أفسح المجال قبل العمل في الخلفية.

function yieldToMain() {
  if (globalThis.scheduler?.yield) return scheduler.yield();
  return new Promise((resolve) => setTimeout(resolve, 0));
}

async function onSearchSubmit(form) {
  showLoadingState(form);          // user sees a response first
  await yieldToMain();             // let the browser paint
  renderResults(filterFares(form));
  await yieldToMain();
  sendAnalytics('search', form);   // tags run after the paint
}

تعمل scheduler.yield() في Chrome وEdge 129 فما فوق وFirefox 142 فما فوق، لا في Safari، ومن هنا جاء البديل setTimeout.

إصلاح CLS: الخطوط والصور واللافتات

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

امنح الخط البديل قيم size-adjust وascent-override حتى يشغل مساحة خط العلامة نفسها (تجد شيفرة CSS في مقالنا عن الخطوط). وحدّد العرض والارتفاع، أو aspect-ratio، لكل صورة. واعرض اللافتات فوق المحتوى بدل أن تدفعه إلى الأسفل، ثم تتبّع كل إزاحة في لوحة Performance في DevTools.

روتين تدقيق في 30 دقيقة

ثلاثون دقيقة تكفي لتعرف أي مقياس يرسب، وفي أي قالب، ولماذا. اقرأ البيانات الميدانية أولًا، ثم أعد إنتاج المشكلة في المعمل، ثم اكتب ثلاث تذاكر. ولا تبدأ من درجة Lighthouse التي تختبر تحميلًا محاكى واحدًا؛ فتقرير Search Console يعتمد على البيانات الميدانية.

1. الدقائق 0 إلى 5. CrUX Vis، النطاق، Phone: دوّن قيم p75 لـLCP وINP وCLS وTTFB وRTT، والاتجاه العام.
2. الدقائق 5 إلى 10. PageSpeed Insights على الصفحة الرئيسية وصفحة قائمة وصفحة تفاصيل.
3. الدقائق 10 إلى 18. DevTools مع إبطاء المعالج والشبكة: تأكّد أن عمود Priority للصورة الرئيسية يقرأ High، وحدّد عنصر LCP وإزاحات التخطيط.
4. الدقائق 18 إلى 25. سجّل وأنت تنقر القائمة والبحث والنماذج، ودوّن التفاعلات التي تتجاوز 200 ms والسكربتات المسؤولة عنها.
5. الدقائق 25 إلى 30. اكتب تذاكر للخادم، ولعنصر LCP، ولأسوأ تفاعل أو إزاحة.

رأينا

أولى مشكلات مواقع العلامات التجارية العربية الخادم، وثانيتها حوكمة الوسوم، ويأتي صقل الواجهة الأمامية بعدهما. فمع وسيط TTFB قدره 1,246 ms على الهواتف، لا يبقى لبقية الصفحة إلا نحو 1.25 ثانية لتبلغ LCP جيدًا. وضغط الصور لا ينقذ HTML يصل بعد 2.5 ثانية.

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

قد يعود تقدّم السعودية في INP (8 من 15 جيدة، مقابل 2 من 13 في الإمارات و1 من 13 في مصر) إلى مزيج القطاعات؛ هذه العينة لا تحسم ذلك، وإعادة اختبار النطاقات الـ45 نفسها تحسمه.

ما الخطوة التالية

السؤال الأجدى من درجتك المعملية: كيف يعيش الربع الأبطأ من زوارك الحقيقيين على الهاتف تجربة موقعك؟ إن كان نطاقك يجتاز CrUX أصلًا فاحمِه بمراقبة المستخدمين الحقيقيين عبر مكتبة web-vitals، وميزانية للوسوم، وتتبّع منفصل لمستخدمي iPhone. وإن كان يرسب فأصلح TTFB أولًا، ثم عنصر LCP، ثم INP.

حين تمتد الإصلاحات إلى الاستضافة والقوالب والوسوم، أريد خطة SEO تقني مبنية على بياناتي الميدانية.

الأسئلة الشائعة

درجتي في PageSpeed مرتفعة لكن Search Console يصف صفحاتي بأنها سيئة. لماذا؟

تأتي الدرجة من تشغيل معملي في Lighthouse: تحميل محاكى واحد بلا نقرات حقيقية. أما Search Console فيستخدم بيانات CrUX الميدانية، أي المئين الخامس والسبعين لزيارات Chrome الحقيقية على مدى 28 يومًا. والهواتف والشبكات والتفاعلات الحقيقية أبطأ من المعمل، وLighthouse لا يقيس INP أصلًا. أصلح الأرقام الميدانية لا الدرجة.

هل تشمل بيانات CrUX مستخدمي iPhone في الخليج؟

لا. يجمع CrUX بياناته من Chrome على سطح المكتب وAndroid، بما فيها Custom Tabs. ولا تسهم فيه نسخة Chrome على iOS، ولا تطبيقات Android التي تستخدم WebView، ولا متصفحات Chromium الأخرى مثل Edge. فإن كان كثير من زوارك يستخدمون iPhone فأضف مراقبتك الخاصة للمستخدمين الحقيقيين بمكتبة web-vitals، وقسّمها حسب الجهاز والدولة.

هل يحسّن اجتياز Core Web Vitals ترتيبي في جوجل؟

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

متى يُظهر CrUX التحسن بعد الإصلاح؟

نحو أربعة أسابيع حتى يكتمل الأثر. فكل نقطة بيانات في CrUX تغطي الأيام الثمانية والعشرين السابقة، وواجهة History API التي يعتمد عليها CrUX Vis تُحدَّث كل يوم اثنين، فتتحرك كل نقطة أسبوعية جزءًا من الطريق. أما التحقق في Search Console فيجري فترة مراقبة خاصة به مدتها 28 يومًا بعد أن تنقر Start Tracking على المشكلة.