Speculation Rules API دليل عملي (2026)

ما هي Speculation Rules API ولماذا تستحق اهتمامك؟

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

هذا بالضبط ما تفعله Speculation Rules API.

هذه الواجهة البرمجية متوفرة في متصفحات Chromium منذ Chrome 109، وفكرتها ذكية وبسيطة: أنت تُخبر المتصفح مسبقًا بالصفحات التي يُحتمل أن يزورها المستخدم، فيقوم بجلبها أو حتى عرضها بالكامل في الخلفية — قبل أن ينقر المستخدم أصلًا. والنتيجة؟ تنقّل بزمن يقترب من صفر مللي ثانية. نعم، صفر.

وإذا كنت ممن تابعوا مقالاتنا السابقة عن تحسين LCP وINP وCLS، فأنت تعلم جيدًا كم يكون تحسين كل مقياس على حدة مرهقًا ومعقدًا. الجميل في Speculation Rules API أنها تُحسّن جميع هذه المقاييس دفعة واحدة — ببساطة لأن الصفحة تكون جاهزة تمامًا قبل أن يراها المستخدم.

وللتوضيح بالأرقام: بيانات Chrome تُظهر أن الصفحات المُعرضة مسبقًا تحقق LCP بقيمة 0 مللي ثانية عند النسبة المئوية 75، مقارنةً بـ 131 مللي ثانية للتنقل العادي. فرق مثل هذا يغيّر تجربة المستخدم بالكامل (وترتيبك في نتائج البحث أيضًا).

Prefetch مقابل Prerender: ما الفرق بالضبط؟

قبل أن نخوض في الكود، دعني أوضّح نقطة جوهرية كثيرون يخلطون فيها. الواجهة توفر نوعين من التحميل التخميني، وكل نوع له استخدامه:

Prefetch — الجلب المسبق

عملية Prefetch تقوم بتنزيل مستند HTML للصفحة المستهدفة فقط — بدون الموارد الفرعية كالصور وملفات CSS وJavaScript، وبدون عرض أي شيء. يعني ذلك أن المتصفح يحتاج وقتًا أقل لعرض الصفحة عند التنقل إليها، لكنه ليس فوريًا تمامًا.

التكلفة: منخفضة — مستند HTML فقط
السرعة عند التنقل: أسرع بشكل ملحوظ، لكن ليس فوريًا
متى تستخدمه: عندما تكون احتمالية التنقل متوسطة أو منخفضة

Prerender — العرض المسبق الكامل

هذا هو الوحش الحقيقي. Prerender يجعل المتصفح يجلب الصفحة بالكامل — HTML، CSS، JavaScript، صور — ويعرضها في تبويب مخفي غير مرئي. يشمل ذلك تنفيذ جميع سكريبتات JavaScript وجلب البيانات التي تطلبها. عندما ينقر المستخدم على الرابط، يقوم المتصفح ببساطة بتنشيط هذا التبويب المخفي ليحل محل الصفحة الحالية.

النتيجة؟ تنقل فوري حقيقي.

التكلفة: عالية — تحميل كامل مع جميع الموارد
السرعة عند التنقل: فورية تقريبًا (0 مللي ثانية)
متى تستخدمه: عندما تكون احتمالية التنقل عالية جدًا

القاعدة الذهبية هنا بسيطة: استخدم Prefetch بسخاء (تكلفته زهيدة)، واستخدم Prerender بحذر فقط للصفحات التي تكاد تكون متأكدًا أن المستخدم سيزورها.

الصياغة الأساسية: كيف تكتب قواعد التخمين

قواعد التخمين تُكتب بصيغة JSON داخل عنصر <script type="speculationrules"> في HTML. الموضوع أبسط مما تتوقع — لنبدأ بالأساسيات.

قواعد القائمة (List Rules) — تحديد صفحات بعينها

إذا كنت تعرف مسبقًا الصفحات التي يُرجّح أن يزورها المستخدم، حدّدها صراحةً:

<script type="speculationrules">
{
  "prefetch": [
    {
      "source": "list",
      "urls": ["/about", "/products", "/contact"]
    }
  ],
  "prerender": [
    {
      "source": "list",
      "urls": ["/checkout"]
    }
  ]
}
</script>

في هذا المثال، نطلب من المتصفح جلب ثلاث صفحات مسبقًا عبر prefetch، وعرض صفحة الدفع مسبقًا بالكامل عبر prerender. قواعد القائمة تستخدم مستوى حماس immediate افتراضيًا — أي أن المتصفح يبدأ فورًا.

قواعد المستند (Document Rules) — وهنا الأمور تصبح مثيرة

صراحةً، هذا هو الجزء الذي أحبه في Speculation Rules API. بدلًا من تحديد كل رابط يدويًا (وهو أمر مُمل ولا يتوسّع)، تضع قواعد عامة يطبقها المتصفح تلقائيًا على جميع الروابط:

<script type="speculationrules">
{
  "prerender": [
    {
      "source": "document",
      "where": {
        "and": [
          { "href_matches": "/*" },
          { "not": { "selector_matches": ".no-prerender" } }
        ]
      },
      "eagerness": "moderate"
    }
  ]
}
</script>

ما يقوله هذا الكود للمتصفح: "اعرض مسبقًا أي رابط داخلي في الصفحة، إلا الروابط التي تحمل كلاس no-prerender، وافعل ذلك عندما يمرر المستخدم مؤشر الفأرة فوق الرابط لمدة 200 مللي ثانية." هذا التوازن بين الأداء واستهلاك الموارد هو ما يجعل Document Rules فعّالة جدًا في الإنتاج.

استخدام Speculation-Rules عبر ترويسة HTTP

يمكنك أيضًا تحديد القواعد عبر ترويسة HTTP بدلًا من HTML — وهذا مفيد خاصةً إذا كنت تريد التحكم من الخادم أو CDN:

// Express.js مثال باستخدام
app.use((req, res, next) => {
  res.setHeader(
    'Speculation-Rules',
    '/speculationrules.json'
  );
  next();
});

ملف speculationrules.json يحتوي على نفس بنية JSON التي تضعها في عنصر <script>.

إعداد Eagerness: متى يبدأ المتصفح بالتحميل؟

إعداد eagerness (أو الحماس) هو أحد أهم القرارات التي ستتخذها هنا. هو يحدد متى بالضبط يبدأ المتصفح بالتحميل التخميني:

المستوى	السلوك	الاستخدام المثالي
`immediate`	يبدأ فورًا عند قراءة القواعد	صفحات مؤكدة الزيارة (الصفحة التالية في مسار واضح)
`eager`	عند تمرير المؤشر لـ 10 مللي ثانية (سطح المكتب) أو ظهور الرابط في العرض (الموبايل)	صفحات محتملة الزيارة بدرجة عالية
`moderate`	عند تمرير المؤشر لـ 200 مللي ثانية أو الضغط (pointerdown)	التوازن الأفضل — وهو الخيار الذي أنصح به لمعظم المواقع
`conservative`	فقط عند الضغط (pointerdown أو touchstart)	عندما تريد تقليل استهلاك الموارد لأدنى حد

ملاحظة: القيمة الافتراضية تختلف حسب نوع القاعدة — قواعد القائمة تستخدم immediate، وقواعد المستند تستخدم conservative.

تحديثات 2026 لسلوك Eagerness على الموبايل

في يناير 2026، غيّر Chrome سلوك eager على الأجهزة المحمولة بشكل ملحوظ. الخوارزمية الجديدة أصبحت أذكى وتعتمد على عدة عوامل:

يبدأ التخمين بعد 50 مللي ثانية من ظهور الرابط في منطقة العرض
يأخذ بعين الاعتبار موقع الرابط بالنسبة لآخر نقطة لمس
يقارن حجم الرابط بأكبر رابط في منطقة العرض
يحتفظ المتصفح بحد أقصى عمليتي عرض مسبق في الذاكرة بنظام FIFO

أما مستوى moderate على الموبايل فيعمل بشكل مختلف: ينتظر 500 مللي ثانية بعد توقف التمرير، ويستهدف الروابط ضمن 30% من المسافة العمودية من آخر نقطة لمس، مع تفضيل الروابط الأكبر حجمًا. ذكي، أليس كذلك؟

الاستراتيجية المُثلى: ابدأ بـ Prefetch ثم ارقِ إلى Prerender

هذه الاستراتيجية هي ما أستخدمه شخصيًا وأنصح بها دائمًا، وهي نفسها التي تتبناها منصات كبرى مثل Cloudflare وWordPress. الفكرة بسيطة:

ابدأ بـ Prefetch واسع النطاق مع مستوى eager — تكلفة منخفضة وتغطية واسعة
ثم ارقِ إلى Prerender مع مستوى moderate — عندما تزداد إشارات نية المستخدم

<script type="speculationrules">
{
  "prefetch": [
    {
      "source": "document",
      "where": { "href_matches": "/*" },
      "eagerness": "eager"
    }
  ],
  "prerender": [
    {
      "source": "document",
      "where": { "href_matches": "/*" },
      "eagerness": "moderate"
    }
  ]
}
</script>

إليك ما يحدث عمليًا: عند تحميل الصفحة، يبدأ المتصفح بجلب HTML لجميع الروابط الداخلية (prefetch بتكلفة منخفضة). ثم عندما يمرر المستخدم مؤشره فوق رابط لمدة 200 مللي ثانية، يعرض المتصفح تلك الصفحة مسبقًا بالكامل. النتيجة: تنقل فوري مع استهلاك ذكي للموارد.

بصراحة، هذا النهج المتدرج يعطيك أفضل ما في العالمين.

استبعاد الصفحات الحساسة — لا تتجاهل هذه الخطوة

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

<script type="speculationrules">
{
  "prerender": [
    {
      "source": "document",
      "where": {
        "and": [
          { "href_matches": "/*" },
          { "not": { "href_matches": "/logout" } },
          { "not": { "href_matches": "/api/*" } },
          { "not": { "href_matches": "/checkout/confirm" } },
          { "not": { "selector_matches": "[data-no-prerender]" } }
        ]
      },
      "eagerness": "moderate"
    }
  ]
}
</script>

لاحظ أيضًا استخدام سمة data-no-prerender — يمكنك وضعها على أي رابط تريد استبعاده يدويًا دون الحاجة لتعديل قواعد JSON كل مرة. مرونة مفيدة جدًا في المشاريع الكبيرة.

مشكلة التحليلات مع Prerender (وكيف تحلّها)

حسنًا، هنا نصل لأحد أكبر التحديات العملية. عندما يعرض المتصفح صفحة مسبقًا، يتم تنفيذ جميع سكريبتات JavaScript — بما فيها أكواد التحليلات. يعني ذلك أن Google Analytics (مثلًا) قد يسجل زيارة لصفحة لم يفتحها المستخدم فعليًا بعد!

الخبر الجيد: Google Analytics 4 وGoogle Publisher Tag يدعمان Speculation Rules تلقائيًا ويؤجلان تسجيل الزيارة حتى تنشيط الصفحة. لكن إذا كنت تستخدم أدوات تحليلات أخرى، ستحتاج للتعامل مع الموضوع يدويًا.

استخدام document.prerendering وحدث prerenderingchange

// التحقق من حالة العرض المسبق قبل تشغيل التحليلات
function initAnalytics() {
  if (document.prerendering) {
    // الصفحة في وضع العرض المسبق — انتظر التنشيط
    document.addEventListener(
      'prerenderingchange',
      () => trackPageView(),
      { once: true }
    );
  } else {
    trackPageView();
  }
}

function trackPageView() {
  console.log('Page actually viewed:', window.location.href);
  // myAnalytics.trackPageView(...)
}

initAnalytics();

ويمكنك أيضًا إنشاء Promise قابلة لإعادة الاستخدام — وهذا ما أفضّله شخصيًا لأنه يجعل الكود أنظف:

const whenActivated = new Promise((resolve) => {
  if (document.prerendering) {
    document.addEventListener(
      'prerenderingchange',
      resolve,
      { once: true }
    );
  } else {
    resolve();
  }
});

// استخدمها مع أي كود يحتاج انتظار التنشيط
whenActivated.then(() => {
  analytics.init();
  loadThirdPartyScripts();
  updateServerSideState();
});

التكامل مع أُطر العمل الشائعة

لست مضطرًا لبناء كل شيء من الصفر. عدة أُطر عمل ومنصات أضافت دعمًا مدمجًا لهذه الواجهة:

WordPress

فريق أداء WordPress الأساسي (يضم مطورين من Google) أنشأ إضافة Speculation Rules رسمية يمكن تفعيلها بنقرة واحدة من خلال إضافة Performance Lab. تُضيف الإضافة document rules تلقائيًا لجميع الروابط الداخلية مع مستوى moderate — وهو إعداد ممتاز لمعظم مواقع WordPress بدون أي تعديل إضافي.

Astro

Astro يدعم Speculation Rules API منذ الإصدار 4.2 مع آلية رجوع تلقائية إلى prefetch العادي للمتصفحات غير المدعومة. وبعد استحواذ Cloudflare على Astro في يناير 2026، يُتوقع تكامل أعمق مع شبكة الحافة لتوفير أداء أفضل.

التطبيق اليدوي مع أي إطار عمل

إذا كنت تستخدم إطار عمل آخر مثل Next.js (لمواقع MPA)، أضف القواعد يدويًا في <head> أو عبر ترويسة HTTP. لكن انتبه: Speculation Rules API مصممة لمواقع متعددة الصفحات (MPA). إذا كنت تبني تطبيق صفحة واحدة (SPA)، فالأفضل الاعتماد على آلية prefetch الخاصة بإطار العمل.

تصحيح الأخطاء: كيف تتأكد أن كل شيء يعمل؟

Chrome DevTools يوفر أدوات ممتازة لهذا الغرض. إليك الطريقة:

تبويب Speculations في DevTools

افتح Chrome DevTools بالضغط على F12
اذهب إلى لوحة Application
في القائمة الجانبية، ابحث عن Speculative loads
انقر على Speculations

ستجد قائمة بجميع عناوين URL المستهدفة مع تفاصيل كل واحد:

الإجراء: prefetch أو prerender
مجموعة القواعد: أي قاعدة أطلقت هذا التخمين
الحالة: قيد الانتظار، جاري التحميل، جاهز، أو فشل

التحقق البرمجي من دعم المتصفح

if (
  HTMLScriptElement.supports &&
  HTMLScriptElement.supports('speculationrules')
) {
  console.log('Speculation Rules API is supported!');

  const specScript = document.createElement('script');
  specScript.type = 'speculationrules';
  specScript.textContent = JSON.stringify({
    prerender: [{
      source: 'document',
      where: { href_matches: '/*' },
      eagerness: 'moderate'
    }]
  });
  document.head.appendChild(specScript);
} else {
  console.log('Speculation Rules API is NOT supported.');
  // استخدم بديلًا مثل prefetch العادي
}

جديد 2026: ميزة Prerender Until Script

في Chrome 144، أطلقت Google تجربة أصلية (Origin Trial) لميزة Prerender Until Script — وبرأيي هذه من أذكى الإضافات لهذه الواجهة. الفكرة تمثل حلًا وسطًا بين Prefetch وPrerender الكامل:

يجلب المتصفح مستند HTML ويبدأ عرض الصفحة
يحمّل جميع الموارد الفرعية (صور، CSS، خطوط)
لكنه يتوقف عند أول عنصر <script> حاجب وينتظر التنقل الفعلي

لماذا هذا مهم عمليًا؟ لأنه يحل مشكلة السكريبتات الحساسة (التحليلات والإعلانات تحديدًا) دون التضحية بمزايا الأداء. هذا يجعل تبني Speculation Rules أسهل بكثير للمواقع المعقدة التي تعتمد على كثير من السكريبتات الخارجية.

دعم المتصفحات (مارس 2026)

المتصفح	Prefetch	Prerender
Chrome / Edge / Opera	مدعوم (منذ Chrome 109)	مدعوم (منذ Chrome 109)
Firefox	موقف إيجابي (قيد التطوير)	غير مدعوم بعد
Safari	قيد المتابعة	غير مدعوم بعد

لكن لا تقلق — وهذا من أجمل ما في الموضوع — الواجهة تعمل كـ تحسين تدريجي (Progressive Enhancement). المتصفحات التي لا تدعمها تتجاهل عنصر <script type="speculationrules"> بصمت، بدون أي أخطاء أو تأثير سلبي. أضفها الآن بأمان: مستخدمو Chrome يحصلون على تنقل فوري، والباقون يحصلون على التجربة العادية.

حدود Chrome والاعتبارات العملية

قبل أن تتحمس أكثر من اللازم (وأنا أفهم الحماس تمامًا)، هناك قيود عملية يجب أن تكون على دراية بها:

حدود الذاكرة: Chrome يحتفظ بحد أقصى صفحتين للعرض المسبق في المستويات التفاعلية (moderate, conservative, eager)، و10 صفحات لمستوى immediate. حدود prefetch أعلى: تصل إلى 50 صفحة لمستوى immediate
الإلغاء التلقائي: يُلغى التخمين إذا كان المستخدم على اتصال بطيء، أو بطارية منخفضة مع وضع توفير الطاقة، أو ذاكرة محدودة
محتوى iframes الخارجية: يتم تأجيل تحميله حتى التنشيط — الإعلانات وأدوات التواصل الاجتماعي لن تتحمّل أثناء العرض المسبق
أدوات حظر الإعلانات: مثل uBlock Origin قد تعطّل التحميل المسبق بالكامل

خطة تطبيق عملية خطوة بخطوة

إليك خطة واقعية ومجرّبة لتبني Speculation Rules API تدريجيًا في موقعك:

المرحلة 1: ابدأ بـ Prefetch (الأسبوع الأول)

أضف قاعدة prefetch بسيطة لجميع الروابط الداخلية
استبعد الصفحات الحساسة (تسجيل الخروج، API endpoints، إلخ)
راقب استهلاك النطاق الترددي في DevTools
تحقق من صحة بيانات التحليلات

المرحلة 2: أضف Prerender (الأسبوع الثاني)

أضف prerender مع مستوى moderate للروابط الداخلية
تأكد من التعامل مع document.prerendering في أكواد التحليلات
اختبر على أجهزة حقيقية — سطح المكتب والموبايل معًا

المرحلة 3: النهج المتدرج (الأسبوع الثالث)

طبّق استراتيجية Prefetch eager + Prerender moderate الكاملة
راقب بيانات CrUX للتأكد من تحسّن LCP
عدّل القواعد بناءً على بيانات التحليلات

المرحلة 4: القياس والتحسين (مستمر)

قارن مقاييس Core Web Vitals قبل وبعد
استخدم تبويب Speculations لمراقبة معدل نجاح التخمين
حسّن القواعد بناءً على مسارات المستخدمين الفعلية

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

هل تعمل مع تطبيقات الصفحة الواحدة (SPA)؟

لا. Speculation Rules API مصممة لمواقع متعددة الصفحات (MPA) حيث كل تنقل يحمّل صفحة HTML جديدة. في تطبيقات SPA، التنقل يتم على جانب العميل — لذلك استخدم آليات الـ prefetch المدمجة في إطارك مثل next/link في Next.js أو router-link في Vue.

هل سيزيد التحميل التخميني من فاتورة الاستضافة؟

قد يزيد قليلًا من حركة مرور الخادم، نعم. لكن مع مستوى moderate أو conservative، الطلبات الإضافية تكون محدودة. وإذا كنت تستخدم CDN مع تخزين مؤقت جيد (وهو ما يجب أن تفعله أصلًا)، فالتكلفة الإضافية ستكون ضئيلة لأن معظم الطلبات تُخدّم من ذاكرة الحافة.

ماذا لو تغيّر المحتوى بين العرض المسبق والزيارة الفعلية؟

الصفحة المعروضة مسبقًا تبقى في الذاكرة كما كانت وقت العرض. إذا تغيّر المحتوى على الخادم بعد ذلك، سيرى المستخدم النسخة القديمة. لذلك لا تعرض مسبقًا صفحات ذات محتوى متغير بسرعة (أسعار حية، مخزون). يمكنك تحديث المحتوى عند التنشيط عبر حدث prerenderingchange.

كيف أقيس فعالية Speculation Rules؟

أفضل طريقة: قارن بيانات CrUX قبل وبعد — خاصةً LCP. للتحقق برمجيًا، استخدم performance.getEntriesByType('navigation')[0].activationStart — إذا كانت أكبر من صفر، فالصفحة كانت معروضة مسبقًا. تبويب Speculations في DevTools يعرض أيضًا نسبة التخمينات الناجحة مقابل الملغاة.

هل هي آمنة للاستخدام في الإنتاج الآن؟

نعم، بكل تأكيد. الواجهة مستقرة في Chromium منذ 2023، وتستخدمها WordPress رسميًا وAstro وCloudflare. ولأنها تعمل كتحسين تدريجي، لا يوجد أي خطر على المتصفحات غير المدعومة — هي ببساطة تتجاهل القواعد بصمت.