العرض المُسبَق للصفحات في Chrome للانتقال الفوري إلى الصفحات

Barry Pollard

تاريخ النشر: 2 ديسمبر 2022، تاريخ آخر تعديل: 29 أكتوبر 2026

Browser Support

  • Chrome: 109.
  • Edge: 109.
  • Firefox Technology Preview: supported.
  • Safari: behind a flag.

Source

أعاد فريق Chrome العرض المُسبق الكامل للصفحات المستقبلية التي من المرجّح أن ينتقل إليها المستخدم.

لمحة موجزة عن العرض المُسبَق

في السابق، كان Chrome يتيح استخدام تلميح المورد <link rel="prerender" href="/next-page">، ولكن لم يكن متوافقًا على نطاق واسع خارج Chrome، ولم تكن واجهة برمجة تطبيقات معبّرة جدًا.

تم إيقاف العرض المُسبق القديم باستخدام تلميح الرابط rel=prerender نهائيًا لصالح الجلب المُسبق بدون حالة، والذي جلب بدلاً من ذلك الموارد التي تحتاجها الصفحة المستقبلية، ولكن لم يعرض الصفحة مُسبقًا بشكل كامل ولم ينفّذ JavaScript. تساعد ميزة NoState Prefetch في تحسين أداء الصفحة من خلال تحسين تحميل الموارد، ولكنّها لن توفّر تحميل الصفحة بشكل فوري كما هو الحال في العرض المُسبَق الكامل.

أعاد فريق Chrome الآن تقديم ميزة العرض المُسبَق الكامل في Chrome. لتجنُّب التعقيدات في الاستخدام الحالي، وللسماح بتوسيع نطاق العرض المُسبَق في المستقبل، لن تستخدم آلية العرض المُسبَق الجديدة بنية <link rel="prerender"...> التي تظلّ متوفّرة لميزة "الجلب المُسبَق بدون حالة"، وذلك بهدف إيقافها في وقت ما في المستقبل.

كيف يتم عرض الصفحة مُسبقًا؟

يمكن عرض الصفحة مسبقًا بإحدى الطرق الأربع التالية، وتهدف جميعها إلى تسريع عمليات التنقّل:

  1. عند كتابة عنوان URL في شريط عناوين Chrome (المعروف أيضًا باسم "مربّع متعدد الاستخدامات")، قد يعرض Chrome الصفحة مسبقًا تلقائيًا إذا كان يتوقّع بدرجة كبيرة أنّك ستزور تلك الصفحة، وذلك استنادًا إلى سجلّ التصفُّح السابق.
  2. عند استخدام شريط الإشارات، قد يعرض Chrome الصفحة مسبقًا تلقائيًا عند تثبيت المؤشر فوق أحد أزرار الإشارات.
  3. عند كتابة عبارة بحث في شريط عناوين Chrome، قد يعرض Chrome صفحة نتائج البحث مسبقًا تلقائيًا، عندما يطلب منه محرك البحث ذلك.
  4. يمكن للمواقع الإلكترونية استخدام واجهة برمجة التطبيقات Speculation Rules API لإعلام Chrome برمجيًا بالصفحات التي يجب عرضها مسبقًا. يحلّ هذا الإجراء محلّ ما كان يفعله <link rel="prerender"...> ويسمح للمواقع الإلكترونية بعرض صفحة بشكل استباقي استنادًا إلى قواعد التوقّع على الصفحة. ويمكن أن تكون هذه الروابط ثابتة على الصفحات أو أن يتم إدخالها ديناميكيًا من خلال JavaScript حسب ما يراه مالك الصفحة مناسبًا.

في كل حالة من هذه الحالات، يتصرف العرض المُسبق كما لو تم فتح الصفحة في علامة تبويب في الخلفية غير مرئية، ثم يتم "تفعيلها" من خلال استبدال علامة التبويب في المقدّمة بتلك الصفحة المعروضة مُسبقًا. إذا تم تفعيل صفحة قبل اكتمال عرضها المُسبَق، ستكون حالتها الحالية "في المقدّمة" وسيستمر تحميلها، ما يعني أنّه لا يزال بإمكانك الاستفادة من ميزة العرض المُسبَق.

بما أنّ الصفحة التي يتم عرضها مسبقًا تُفتح في حالة مخفية، لا يتم تفعيل عدد من واجهات برمجة التطبيقات التي تسبّب سلوكيات تطفّلية (مثل الطلبات) في هذه الحالة، بل يتم تأجيلها إلى أن يتم تفعيل الصفحة. وفي الحالات القليلة التي لا يكون فيها ذلك ممكنًا بعد، يتم إلغاء العرض المُسبق. يعمل فريق Chrome على عرض أسباب إلغاء العرض المُسبَق كواجهة برمجة تطبيقات، بالإضافة إلى تحسين إمكانات "أدوات مطوري البرامج في Chrome" لتسهيل تحديد هذه الحالات الاستثنائية.

تأثير العرض المُسبَق

يتيح العرض المُسبَق تحميل الصفحة بشكل فوري تقريبًا كما هو موضّح في الفيديو التالي:

مثال على تأثير العرض المُسبَق

الموقع الإلكتروني في المثال سريع، ولكن حتى في هذه الحالة، يمكنك ملاحظة كيف يؤدي العرض المُسبَق إلى تحسين تجربة المستخدم. وبالتالي، يمكن أن يؤثر ذلك أيضًا بشكل مباشر في Core Web Vitals للموقع الإلكتروني، مع اقتراب قيمة "سرعة عرض أكبر محتوى مرئي" (LCP) من الصفر، وانخفاض قيمة "متغيّرات التصميم التراكمية" (CLS) (لأنّ أيّ قيمة لـ CLS تحدث قبل العرض الأولي)، وتحسُّن قيمة "مدى استجابة الصفحة لتفاعلات المستخدم" (INP) (لأنّه من المفترض أن يكتمل التحميل قبل تفاعل المستخدم).

حتى عندما يتم تفعيل صفحة قبل تحميلها بالكامل، فإنّ البدء في تحميل الصفحة من المفترض أن يحسّن تجربة التحميل. عند تفعيل رابط أثناء استمرار العرض المُسبَق، ستنتقل صفحة العرض المُسبَق إلى الإطار الرئيسي وتواصل التحميل.

ومع ذلك، يستخدم العرض المُسبَق ذاكرة إضافية وعرض نطاق ترددي إضافي للشبكة. احرص على عدم الإفراط في العرض المُسبَق على حساب موارد المستخدم. لا تستخدِم العرض المُسبق إلا عندما يكون هناك احتمال كبير للانتقال إلى الصفحة.

يُرجى الاطّلاع على قسم قياس الأداء لمزيد من المعلومات حول كيفية قياس التأثير الفعلي في الأداء في إحصاءاتك.

الاطّلاع على توقّعات شريط العناوين في Chrome

بالنسبة إلى حالة الاستخدام الأولى، يمكنك الاطّلاع على توقّعات Chrome لعناوين URL في صفحة chrome://predictors:

صفحة &quot;أدوات التوقّع في Chrome&quot; (Chrome Predictors) التي تمت فلترتها لعرض التوقّعات المنخفضة (باللون الرمادي) والمتوسطة (باللون الكهرماني) والعالية (باللون الأخضر) استنادًا إلى النص الذي تم إدخاله
صفحة "أدوات التوقّع في Chrome"

تشير الخطوط الخضراء إلى ثقة كافية لتفعيل العرض المُسبَق. في هذا المثال، تمنح كتابة "s" ثقة معقولة (باللون الكهرماني)، ولكن بعد كتابة "sh"، يكون لدى Chrome ثقة كافية بأنّك تنتقل دائمًا تقريبًا إلى https://sheets.google.com.

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

تؤدي أدوات التوقّع هذه أيضًا إلى ظهور الخيارات المقترَحة في شريط العناوين التي ربما لاحظتها:

ميزة &quot;الكتابة المسبقة&quot; في شريط عناوين Chrome
ميزة "الكتابة الاستباقية" في شريط العناوين

سيواصل Chrome تعديل أدوات التوقّع استنادًا إلى ما تكتبه وتختاره.

  • بالنسبة إلى مستوى الثقة الذي يزيد عن %30 (يظهر باللون الكهرماني)، يتصل Chrome مسبقًا بالنطاق بشكل استباقي، ولكنّه لا يعرض الصفحة مسبقًا.
  • إذا كان مستوى الثقة أكبر من %50 (يظهر باللون الأخضر)، سيعرض Chrome عنوان URL مسبقًا.

واجهة Speculation Rules API

بالنسبة إلى خيار العرض المُسبَق في Speculation Rules API، يمكن لمطوّري تطبيقات الويب إدراج تعليمات JSON في صفحاتهم لإعلام المتصفّح بعناوين URL التي يجب عرضها مُسبَقًا.

قوائم عناوين URL

يمكن أن تستند قواعد التوقُّع إلى قوائم عناوين URL:

<script type="speculationrules">
{
  "prerender": [{
    "urls": ["next.html", "next2.html"]
  }]
}
</script>

قواعد المستندات

يمكن أن تكون قواعد التوقُّع أيضًا "قواعد مستندات" باستخدام بنية where. يؤدي ذلك إلى تخمين الروابط التي تم العثور عليها في المستند استنادًا إلى أدوات اختيار href (استنادًا إلى URL Pattern API) أو أدوات اختيار لغة CSS:

<script type="speculationrules">
{
  "prerender": [{
    "where": {
      "and": [
        { "href_matches": "/*" },
        { "not": {"href_matches": "/wp-admin"}},
        { "not": {"href_matches": "/*\\?*(^|&)add-to-cart=*"}},
        { "not": {"selector_matches": ".do-not-prerender"}},
        { "not": {"selector_matches": "[rel~=nofollow]"}}
      ]
    }
  }]
}
</script>

الحماس

Browser Support

  • Chrome: 121.
  • Edge: 121.
  • Firefox Technology Preview: supported.
  • Safari: behind a flag.

Source

يُستخدَم الإعداد eagerness للإشارة إلى الحالات التي يجب فيها تفعيل التخمينات، وهو مفيد بشكل خاص لقواعد المستندات:

  • conservative: يتم التخمين عند النقر على المؤشر أو اللمس.
  • ‫moderate: على الكمبيوتر المكتبي، يؤدي هذا الخيار إلى إجراء عمليات تخمين إذا ثبّت المؤشر فوق رابط لمدة 200 ملي ثانية (أو عند وقوع الحدث pointerdown إذا كان ذلك أسرع، وعلى الأجهزة الجوّالة التي لا يقع فيها الحدث hover). على الأجهزة الجوّالة، غيّرنا هذه الطريقة لتستند إلى الاستدلالات المعقّدة لإطار العرض اعتبارًا من أغسطس 2025. يتم تفعيل الأساليب الإرشادية المعقّدة لإطار العرض بعد 500 ملي ثانية من توقّف المستخدم عن الانتقال للأعلى أو للأسفل، وذلك بالنسبة إلى نقاط الارتساء التي تقع ضمن %30 من المسافة العمودية من موضع النقر السابق، حيث تكون نقاط الارتساء أكبر بمقدار 0.5 مرة على الأقل من أكبر نقطة ارتساء في إطار العرض. كما هو موضّح في هذا المستند.
  • ‫eager: كان هذا الإعداد يعمل بالطريقة نفسها التي يعمل بها immediate، ولكن تم تغييره في الإصدار 143 من Chrome. على الكمبيوتر المكتبي، يتم تنفيذ التخمينات إذا ثبّت المؤشر فوق رابط لمدة 10 ملي ثانية. على الأجهزة الجوّالة، غيّرنا ذلك لنستند إلى الاستدلالات البسيطة لإطار العرض اعتبارًا من يناير 2026. يتم تفعيل الأساليب الإرشادية البسيطة لإطار العرض بعد 50 ملي ثانية من دخول الرابط إلى إطار العرض.
  • ‫immediate: يُستخدَم هذا الخيار للتوقّع في أقرب وقت ممكن، أي فور رصد قواعد التوقّع.

الإعداد التلقائي لـ eagerness في قواعد list هو immediate. يمكن استخدام الخيارات eager وmoderate وconservative لتقييد قواعد list على عناوين URL التي يتفاعل معها المستخدم في قائمة معيّنة. ومع ذلك، في كثير من الحالات، قد تكون قواعد document التي تتضمّن شرط where مناسبًا أكثر ملاءمةً.

الإعداد التلقائي لـ eagerness في قواعد document هو conservative. بما أنّ المستند يمكن أن يتألف من عدة عناوين URL، يجب استخدام immediate لقواعد document بحذر (يُرجى أيضًا الاطّلاع على قسم حدود Chrome أدناه).

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

يُعدّ الخيار moderate حلاً وسطًا، ويمكن أن تستفيد العديد من المواقع الإلكترونية من قاعدة التوقّع التالية التي ستعرض رابطًا بشكل مُسبق عند تمرير المؤشر فوق الرابط لمدة 200 ملي ثانية أو عند وقوع الحدث pointerdown كتنفيذ أساسي، ولكنه فعّال، لقواعد التوقّع:

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

الجلب المُسبَق

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

<script type="speculationrules">
{
  "prefetch": [{
    "urls": ["next.html", "next2.html"]
  }]
}
</script>

Prerender until script

يعمل فريق Chrome أيضًا على إضافة prerender_until_script إلى Speculation Rules API (راجِع: خطأ في التنفيذ). ستكون هذه خطوة بين الجلب المُسبَق والعرض المُسبَق، وسيتم استخدامها بطريقة مشابهة:

<script type="speculationrules">
{
  "prerender_until_script": [{
    "urls": ["next.html", "next2.html"]
  }]
}
</script>

على غرار NoState prefetch، سيؤدي ذلك إلى الجلب المُسبق لكل من مستند HTML والموارد الفرعية المتاحة في ملف HTML هذا. ومع ذلك، سيتجاوز ذلك ويبدأ أيضًا في العرض المُسبَق للصفحة، ويتوقف عند العثور على النص البرمجي الأول.

هذا يعني أنّه بالنسبة إلى الصفحات التي لا تحتوي على JavaScript أو التي تحتوي على JavaScript في التذييل فقط، يمكن عرض الصفحة مسبقًا بشكل كامل تقريبًا. لن تتمكّن الصفحات التي تحتوي على نصوص برمجية في <head> من العرض المُسبق، ولكنها ستستفيد من جلب الموارد الفرعية.

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

حدود Chrome

يفرض Chrome حدودًا لمنع الإفراط في استخدام واجهة Speculation Rules API:

الحماس الجلب المُسبَق العرض المُسبَق
immediate 50 10
‫eager / moderate على الأجهزة الجوّالة ‫6 (الوارد أولاً يُباع أولاً) ‫2 (الوارد أولاً يُباع أولاً)
‫eager / moderate على الكمبيوتر المكتبي ‫2 (الوارد أولاً يُباع أولاً) ‫2 (الوارد أولاً يُباع أولاً)
conservative ‫2 (الوارد أولاً يُباع أولاً) ‫2 (الوارد أولاً يُباع أولاً)
حدود التخمين في Chrome

تعمل الإعدادات eager وmoderate وconservative، التي تعتمد على تفاعل المستخدم، وفقًا لمبدأ "الوارد أولاً يُباع أولاً" (FIFO): بعد الوصول إلى الحدّ الأقصى، سيؤدي التخمين الجديد إلى إلغاء أقدم تخمين واستبداله بالتخمين الأحدث للحفاظ على الذاكرة.

يمكن إعادة تفعيل عملية تأمُّل تم إلغاؤها، مثلاً من خلال التمرير فوق الرابط مرة أخرى، ما يؤدي إلى إعادة تأمُّل عنوان URL هذا وإزالة أقدم عملية تأمُّل. في هذه الحالة، ستكون عملية التخمين السابقة قد خزّنت مؤقتًا أي موارد قابلة للتخزين المؤقت في ذاكرة التخزين المؤقت لبروتوكول HTTP لعنوان URL هذا، لذا من المفترض أن تكون تكلفة التخمين مرة أخرى أقل. لهذا السبب، يتم ضبط الحدّ الأقصى على القيمة المتواضعة 2 تلقائيًا. نستخدم حدًا أعلى يبلغ 6 للجلب المُسبق على الأجهزة الجوّالة لأنّه لا يتوفّر خيار "التمرير"، كما أنّ الأساليب الإرشادية البديلة لإطار العرض على الأجهزة الجوّالة أقل دقة، والجلب المُسبق أقل تكلفة من العرض المُسبق (نُبقي الحدّ الأقصى 2 للعرض المُسبق على الأجهزة الجوّالة).

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

يدرس Chrome أيضًا زيادة الحدّ الأقصى إلى 5 على الأجهزة الجوّالة لـ eager وmoderate على الأقل للجلب المُسبَق، نظرًا لأنّ هذا الأسلوب الإرشادي أقل دقة. قد يحتاج المطوّرون الذين يستخدمون eager إلى استخدام قواعد conservative أيضًا عندما تتوفّر روابط متعددة في إطار العرض، وذلك لكي يستمر التخمين حتى إذا لم يتم اختيارها كأحد الرابطَين الأولَين.

الحدّ الأقصى لعدد عناوين URL التي يمكن لـ immediate تخمينها هو أيضًا ديناميكي، لذا فإنّ إزالة عنصر نص برمجي لعنوان URL في list سيؤدي إلى توفير سعة من خلال إلغاء عمليات التخمين التي تمت إزالتها.

سيمنع Chrome أيضًا استخدام التخمينات في ظروف معيّنة، بما في ذلك:

  • Save-Data:
  • توفير الطاقة عند تفعيلها وعند انخفاض مستوى شحن البطارية
  • قيود الذاكرة
  • عند إيقاف إعداد "تحميل الصفحات مُسبقًا" (الذي يتم إيقافه أيضًا صراحةً من خلال إضافات Chrome، مثل uBlock Origin)
  • الصفحات التي تم فتحها في علامات تبويب في الخلفية

لا يعرض Chrome أيضًا إطارات iframe المتعدّدة المصادر على الصفحات المعروضة مسبقًا إلا بعد تفعيلها.

تهدف كل هذه الشروط إلى الحدّ من تأثير التخمين المفرط عندما يكون ضارًا بالمستخدمين.

كيفية تضمين قواعد التوقُّع في صفحة

يمكن تضمين قواعد التخمين بشكل ثابت في رمز HTML الخاص بالصفحة أو إدراجها ديناميكيًا في الصفحة باستخدام JavaScript:

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

بالنسبة إلى المستخدمين الذين يفضّلون الإدراج الديناميكي استنادًا إلى إجراءات مثل تمرير مؤشر الماوس فوق رابط أو النقر عليه، كما فعلت العديد من المكتبات في السابق باستخدام <link rel=prefetch>، ننصحهم بالاطّلاع على قواعد المستندات، لأنّها تتيح للمتصفّح معالجة العديد من حالات الاستخدام.

يمكن إضافة قواعد التوقّع في <head> أو <body> في الإطار الرئيسي. لا يتم تنفيذ قواعد التوقّع في الإطارات الفرعية، ولا يتم تنفيذ قواعد التوقّع في الصفحات التي يتم عرضها مسبقًا إلا بعد تفعيل تلك الصفحة.

عنوان HTTP يتضمّن العنصر Speculation-Rules

Browser Support

  • Chrome: 121.
  • Edge: 121.
  • Firefox: not supported.
  • Safari: behind a flag.

Source

يمكن أيضًا عرض قواعد التوقّع باستخدام عنوان HTTP‏ Speculation-Rules، بدلاً من تضمينها مباشرةً في رمز HTML الخاص بالمستند. يتيح ذلك نشر المحتوى بسهولة أكبر من خلال شبكات توصيل المحتوى (CDN) بدون الحاجة إلى تغيير محتوى المستندات نفسها.

يتم عرض عنوان HTTP‏ Speculation-Rules مع المستند، ويشير إلى موقع ملف JSON الذي يحتوي على قواعد التخمين:

Speculation-Rules: "/speculationrules.json"

يجب أن يستخدم هذا المورد نوع MIME الصحيح، وإذا كان موردًا متعدّد المصادر، يجب أن يجتاز فحص CORS.

Content-Type: application/speculationrules+json
Access-Control-Allow-Origin: *

إذا أردت استخدام عناوين URL نسبية، يمكنك تضمين المفتاح "relative_to": "document" في قواعد التخمين. وإلا، ستكون عناوين URL النسبية مرتبطة بعنوان URL الخاص بملف JSON لقواعد التخمين. قد يكون ذلك مفيدًا بشكل خاص إذا كنت بحاجة إلى اختيار بعض الروابط من المصدر نفسه أو جميعها.

حقل علامة قواعد التوقّع

Browser Support

  • Chrome: 136.
  • Edge: 136.
  • Firefox: not supported.
  • Safari: behind a flag.

Source

يمكن أيضًا إضافة "علامات" في بنية JSON الخاصة بقواعد التخمين على المستوى العام لجميع قواعد التخمين في مجموعة قواعد:

{
  "tag": "my-rules",
  "prefetch": [{
      "urls": ["next.html"]
  }],
  "prerender": [{
      "urls": ["next2.html"]
  }]
}

أو على مستوى القاعدة الفردية:

{
  "prefetch": [{
    "tag": "my-prefetch-rules",
    "urls": ["next.html"]
  }],
  "prerender": [{
    "tag": "my-prerender-rules",
    "urls": ["next2.html"]
  }]
}

تظهر هذه العلامة بعد ذلك في عنوان HTTP‏ Sec-Speculation-Tags، والذي يمكن استخدامه لفلترة قواعد التخمين في الخادم. يمكن أن يتضمّن عنوان HTTP‏ Sec-Speculation-Tags علامات متعدّدة إذا كان التخمين مشمولاً بقواعد متعدّدة، كما هو موضّح في المثال التالي:

Sec-Speculation-Tags: null
Sec-Speculation-Tags: null, "cdn-prefetch"
Sec-Speculation-Tags: "my-prefetch-rules"
Sec-Speculation-Tags: "my-prefetch-rules", "my-rules", "cdn-prefetch"

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

تظهر علامات مجموعة القواعد أيضًا في "أدوات مطوّري البرامج في Chrome".

حقل قواعد التوقّع target_hint

Browser Support

  • Chrome: 138.
  • Edge: 138.
  • Firefox: not supported.
  • Safari: not supported.

Source

يمكن أن تتضمّن قواعد التوقّع أيضًا حقل target_hint، والذي يحتوي على اسم أو كلمة رئيسية صالحة لسياق التصفّح يشير إلى المكان الذي تتوقّع الصفحة أن يتم فيه تفعيل المحتوى الذي تم عرضه مسبقًا:

<script type=speculationrules>
{
  "prerender": [{
    "target_hint": "_blank",
    "urls": ["next.html"]
  }]
}
</script>

تسمح هذه الإشارة بمعالجة التوقعات المتعلقة بالعرض المُسبَق لروابط target="_blank":

<a target="_blank" href="next.html">Open this link in a new tab</a>

في الوقت الحالي، يتوافق Chrome مع "target_hint": "_blank" و"target_hint": "_self" فقط (الخيار التلقائي في حال عدم تحديده) وفقط للعرض المُسبَق، ولا يتوافق مع الجلب المُسبَق.

لا تكون السمة target_hint مطلوبة إلا لقواعد التخمين urls، لأنّ السمة target تكون معروفة من الرابط نفسه في قواعد المستندات.

قواعد التوقّع وتطبيقات الصفحة الواحدة

لا تتوافق قواعد التخمين إلا مع عمليات التنقّل في الصفحة الكاملة التي يديرها المتصفّح، وليس مع تطبيقات الصفحة الواحدة (SPA) أو صفحات هيكل التطبيق. لا تستخدم هذه البنية عمليات جلب المستندات، بل تستخدم واجهة برمجة التطبيقات أو عمليات جلب جزئية للبيانات أو الصفحات، والتي تتم معالجتها بعد ذلك وعرضها في الصفحة الحالية. يمكن للتطبيق جلب البيانات اللازمة لعمليات "التنقّل السلس" هذه مسبقًا خارج قواعد التوقّع، ولكن لا يمكن عرضها مسبقًا.

يمكن استخدام "قواعد التوقّع" لعرض التطبيق نفسه مسبقًا من صفحة سابقة. يمكن أن يساعد ذلك في تعويض بعض تكاليف التحميل الأولي الإضافية التي تتكبّدها بعض تطبيقات الصفحة الواحدة. ومع ذلك، لا يمكن عرض تغييرات المسار داخل التطبيق مسبقًا.

تصحيح أخطاء قواعد التوقّع

يمكنك الاطّلاع على المنشور المخصّص حول تصحيح أخطاء قواعد التخمين للتعرّف على ميزات "أدوات مطوري البرامج في Chrome" الجديدة التي تساعد في عرض واجهة برمجة التطبيقات الجديدة هذه وتصحيح أخطائها.

قواعد توقُّع متعددة

يمكن أيضًا إضافة قواعد تخمين متعددة إلى الصفحة نفسها، ويتم إلحاقها بالقواعد الحالية. وبالتالي، تؤدي الطرق المختلفة التالية إلى العرض المُسبَق لكل من one.html وtwo.html:

قائمة عناوين URL:

<script type="speculationrules">
{
  "prerender": [{
    "urls": ["one.html", "two.html"]
  }]
}
</script>

نصوص برمجية متعددة في speculationrules:

<script type="speculationrules">
{
  "prerender": [{
    "urls": ["one.html"]
  }]
}
</script>
<script type="speculationrules">
{
  "prerender": [{
    "urls": ["two.html"]
  }]
}
</script>

قوائم متعددة ضمن مجموعة واحدة من speculationrules

<script type="speculationrules">
{
  "prerender": [
    {
      "urls": ["one.html"]
    },
    {
      "urls": ["two.html"]
    }
  ]
}
</script>

Browser Support

  • Chrome: 141.
  • Edge: 141.
  • Firefox: 154.
  • Safari: not supported.

Source

عند جلب صفحة مسبقًا أو عرضها مسبقًا، قد لا تكون بعض معلَمات عناوين URL (المعروفة تقنيًا باسم معلَمات البحث) مهمة للصفحة التي يقدّمها الخادم فعليًا، ويتم استخدامها فقط من خلال JavaScript من جهة العميل.

على سبيل المثال، تستخدم "إحصاءات Google" مَعلمات نظام مراقبة الزيارات من Urchin لقياس أداء الحملات، ولكنّها لا تؤدي عادةً إلى عرض صفحات مختلفة من الخادم. يعني ذلك أنّ page1.html?utm_content=123 وpage1.html?utm_content=456 سيعرضان الصفحة نفسها من الخادم، وبالتالي يمكن إعادة استخدام الصفحة نفسها من ذاكرة التخزين المؤقت.

وبالمثل، قد تستخدم التطبيقات مَعلمات أخرى لعناوين URL يتم التعامل معها فقط من جهة العميل.

يسمح اقتراح No-Vary-Search للخادم بتحديد المَعلمات التي لا تؤدي إلى اختلاف في المورد الذي يتم عرضه، وبالتالي يسمح للمتصفّح بإعادة استخدام النُسخ المخزّنة مؤقتًا من مستند تختلف فقط في هذه المَعلمات. تتوفّر هذه الميزة في Chrome (والمتصفّحات المستنِدة إلى Chromium) لعمليات التخمين في التنقّل لكل من الجلب المُسبَق والعرض المُسبَق.

تتيح قواعد التوقّع استخدام expects_no_vary_search للإشارة إلى المكان الذي يُتوقّع أن يعرض عنوان HTTP يتضمّن السمة No-Vary-Search. ويمكن أن يساعد ذلك في تجنُّب عمليات التنزيل غير الضرورية قبل الاطّلاع على الردود.

<script type="speculationrules">
{
  "prefetch": [{
    "urls": ["/products"],
    "expects_no_vary_search": "params=(\"id\")"
  }]
}
</script>

<a href="/products?id=123">Product 123</a>
<a href="/products?id=124">Product 124</a>

في هذا المثال، يكون ملف HTML الأوّلي للصفحة /products هو نفسه لكل من معرّفَي المنتج 123 و124. ومع ذلك، يختلف محتوى الصفحة في النهاية استنادًا إلى العرض من جهة العميل باستخدام JavaScript لجلب بيانات المنتج باستخدام مَعلمة البحث id. لذلك، نجلب عنوان URL هذا مسبقًا، ومن المفترض أن يعرض عنوان HTTP ‏No-Vary-Search يشير إلى أنّه يمكن استخدام الصفحة لأي مَعلمة بحث id.

ومع ذلك، إذا نقر المستخدم على أي من الروابط قبل اكتمال الجلب المُسبق، قد لا يكون المتصفّح قد تلقّى صفحة /products. في هذه الحالة، لا يعرف المتصفّح ما إذا كان سيتضمّن عنوان HTTP‏ No-Vary-Search. بعد ذلك، يمكن للمتصفّح اختيار جلب الرابط مرة أخرى أو انتظار اكتمال عملية الجلب المُسبق لمعرفة ما إذا كان يتضمّن عنوان HTTP يتضمّن No-Vary-Search. يتيح الإعداد expects_no_vary_search للمتصفّح معرفة أنّه من المتوقّع أن تحتوي استجابة الصفحة على عنوان HTTP‏ No-Vary-Search، والانتظار حتى تكتمل عملية الجلب المُسبق هذه.

يمكنك أيضًا إضافة مَعلمات متعددة إلى expects_no_vary_search مع الفصل بينها بمسافة (بما أنّ No-Vary-Search هو عنوان HTTP منظَّم):

    "expects_no_vary_search": "params=(\"param1\" \"param2\" \"param3\")"

القيود المفروضة على قواعد التوقُّع والتحسينات المستقبلية

تقتصر قواعد التوقّع على الصفحات المفتوحة ضمن علامة التبويب نفسها، ولكنّنا نعمل على تقليل هذا القيد.

يقتصر العرض المُسبَق تلقائيًا على الصفحات من المصدر نفسه. يمكن تفعيل العرض المُسبَق للصفحات متعدّدة المصادر للموقع الإلكتروني نفسه (على سبيل المثال، يمكن لـ https://a.example.com إجراء عرض مُسبَق لصفحة على https://b.example.com). لاستخدام هذه الميزة، يجب أن توافق الصفحة المُتوقَّعة (https://b.example.com في هذا المثال) على ذلك من خلال تضمين عنوان HTTP‏ Supports-Loading-Mode: credentialed-prerender، وإلا سيلغي Chrome التوقّع.

قد تسمح الإصدارات المستقبلية أيضًا بالعرض المُسبق للصفحات المتعدّدة المصادر وغير التابعة للموقع الإلكتروني نفسه طالما أنّ ملفات تعريف الارتباط غير متوفّرة للصفحة التي يتم عرضها مُسبقًا، وتوافق الصفحة التي يتم عرضها مُسبقًا على استخدام عنوان HTTP مشابه لـ Supports-Loading-Mode: uncredentialed-prerender.

تتيح قواعد التوقّع عمليات الجلب المُسبَق المتعدّدة المصادر، ولا توجد قيود على عمليات الجلب المُسبَق المتعدّدة المصادر للموقع الإلكتروني نفسه. لا تتوفّر عمليات الجلب المُسبَق المتعدّدة المصادر من مواقع إلكترونية مختلفة إلا في حال عدم توفّر ملفات تعريف الارتباط للنطاق المتعدّد المصادر. إذا كانت هناك ملفات تعريف ارتباط من زيارة المستخدم لهذا الموقع الإلكتروني من قبل، فلن يتم استخدام التخمين وسيظهر فشل في "أدوات مطوري البرامج في Chrome".

نظرًا إلى هذه القيود الحالية، هناك نمط واحد يمكنه تحسين تجارب المستخدمين لكل من الروابط الداخلية والروابط الخارجية حيثما أمكن، وهو إجراء عرض مُسبَق لعناوين URL من المصدر نفسه ومحاولة الجلب المُسبَق لعناوين URL من مصادر متعددة:

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

إنّ القيود المفروضة لمنع التخمينات المتعدّدة المصادر للروابط المتعدّدة المصادر بشكل تلقائي ضرورية لأغراض الأمان. وهو تحسين على <link rel="prefetch"> للوجهات المتعدّدة المصادر التي لن ترسل أيضًا ملفات تعريف الارتباط ولكنها ستستمر في محاولة الجلب المُسبق، ما سيؤدي إما إلى جلب مُسبق غير مفيد يجب إعادة إرساله أو، والأسوأ من ذلك، تحميل الصفحة غير الصحيحة.

رصد توافق Speculation Rules API

يمكنك رصد ميزات Speculation Rules API من خلال عمليات التحقّق العادية من HTML:

if (HTMLScriptElement.supports && HTMLScriptElement.supports('speculationrules')) {
  console.log('Your browser supports the Speculation Rules API.');
}

إضافة قواعد التخمين بشكل ديناميكي من خلال JavaScript

في ما يلي مثال على إضافة قاعدة تخمين prerender باستخدام JavaScript:

if (HTMLScriptElement.supports &&
    HTMLScriptElement.supports('speculationrules')) {
  const specScript = document.createElement('script');
  specScript.type = 'speculationrules';
  specRules = {
    prerender: [
      {
        urls: ['/next.html'],
      },
    ],
  };
  specScript.textContent = JSON.stringify(specRules);
  console.log('added speculation rules to: next.html');
  document.body.append(specScript);
}

يمكنك الاطّلاع على عرض توضيحي للعرض المُسبق باستخدام واجهة Speculation Rules API، من خلال إدراج JavaScript، في صفحة العرض التوضيحي للعرض المُسبق هذه.

إنّ إدراج عنصر <script type = "speculationrules"> مباشرةً في نموذج DOM باستخدام innerHTML لن يؤدي إلى تسجيل قواعد التوقّع لأسباب تتعلّق بالأمان، ويجب إضافة ذلك كما هو موضّح سابقًا. ومع ذلك، فإنّ المحتوى الذي يتم إدراجه ديناميكيًا باستخدام innerHTML والذي يحتوي على روابط جديدة، سيتم رصده من خلال القواعد الحالية على الصفحة.

وبالمثل، فإنّ التعديل المباشر للوحة العناصر في "أدوات مطوري البرامج في Chrome" لإضافة العنصر <script type = "speculationrules"> لا يسجّل قواعد التوقّع، وبدلاً من ذلك يجب تشغيل النص البرمجي لإضافة ذلك ديناميكيًا إلى DOM من "وحدة التحكّم" لإدراج القواعد.

إضافة قواعد المضاربة من خلال Tag Manager

لإضافة قواعد المضاربة باستخدام أداة لإدارة العلامات، مثل Google Tag Manager، يجب إدراجها من خلال JavaScript، بدلاً من إضافة العنصر <script type = "speculationrules"> من خلال Google Tag Manager مباشرةً للأسباب نفسها المذكورة سابقًا:

إعداد علامة HTML مخصّصة في Google Tag Manager
إضافة قواعد المضاربة من خلال Google Tag Manager

يُرجى العِلم أنّ هذا المثال يستخدم var لأنّ أداة "إدارة العلامات من Google" لا تتيح استخدام const.

إلغاء قواعد التوقّع

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

Browser Support

  • Chrome: 138.
  • Edge: 138.
  • Firefox: not supported.
  • Safari: not supported.

Source

يمكن أيضًا إلغاء عمليات التخمين باستخدام عنوان HTTP‏ Clear-Site-Data مع التوجيهَين prefetchCache وprerenderCache.

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

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

قواعد التخمين وسياسة أمان المحتوى

بما أنّ قواعد التخمين تستخدم عنصر <script>، على الرغم من أنّها تحتوي على ملف JSON فقط، يجب تضمينها في script-src سياسة أمان المحتوى إذا كان الموقع الإلكتروني يستخدم هذه السياسة، إما باستخدام تجزئة أو رقم خاص.

يمكن إضافة inline-speculation-rules جديد إلى script-src للسماح بدعم عناصر <script type="speculationrules"> التي يتم إدخالها من نصوص برمجية مجزأة أو نصوص برمجية تستخدم أرقامًا عشوائية. لا يتيح ذلك استخدام القواعد المضمّنة في ملف HTML الأولي، لذا يجب إدخال القواعد من خلال JavaScript للمواقع الإلكترونية التي تستخدم سياسة أمان محتوى صارمة.

رصد ميزة "العرض المُسبَق" وإيقافها

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

ومع ذلك، قد تكون هناك حالات لا تريد فيها أن يتم العرض المُسبق للصفحات، على سبيل المثال عندما يتغيّر وضع الصفحات، إما استنادًا إلى الطلب الأولي أو استنادًا إلى تنفيذ JavaScript على الصفحة.

تفعيل ميزة "العرض المُسبَق" وإيقافها في Chrome

لا يتم تفعيل ميزة "العرض المُسبَق" إلا لمستخدمي Chrome الذين فعّلوا إعداد "تحميل الصفحات مُسبقًا" في chrome://settings/performance/. بالإضافة إلى ذلك، يتم إيقاف العرض المُسبَق أيضًا على الأجهزة ذات الذاكرة المنخفضة، أو إذا كان نظام التشغيل في وضع "توفير البيانات" أو "توفير الطاقة". يُرجى الاطّلاع على قسم حدود Chrome.

رصد ميزة العرض المُسبَق وإيقافها من جهة الخادم

سيتم إرسال الصفحات التي تم عرضها مسبقًا مع عنوان HTTP التالي:Sec-Purpose

Sec-Purpose: prefetch;prerender

بالنسبة إلى الصفحات التي يتم جلبها مسبقًا باستخدام Speculation Rules API، سيتم ضبط هذا العنوان على prefetch فقط:

Sec-Purpose: prefetch

يمكن للخوادم الاستجابة استنادًا إلى هذا العنوان، لتسجيل طلبات التخمين أو عرض محتوى مختلف أو منع حدوث عرض مسبق. إذا تم عرض رمز استجابة نهائي غير ناجح، أي ليس في النطاق 200-299 بعد عمليات إعادة التوجيه، لن يتم عرض الصفحة مسبقًا وسيتم تجاهل أي صفحة تم جلبها مسبقًا. يُرجى العِلم أيضًا أنّ الاستجابتَين 204 و205 غير صالحتَين للعرض المُسبَق، ولكنّهما صالحتان للجلب المُسبَق.

إذا كنت لا تريد عرض صفحة معيّنة مسبقًا، فإنّ عرض رمز استجابة غير 2XX (مثل 503) هو أفضل طريقة لضمان عدم حدوث ذلك. ومع ذلك، لتقديم أفضل تجربة، ننصحك بالسماح بالعرض المُسبَق، ولكن مع تأخير أي إجراءات يجب أن تحدث فقط عند عرض الصفحة فعليًا، وذلك باستخدام JavaScript.

رصد العرض المُسبَق في JavaScript

ستعرض واجهة برمجة التطبيقات document.prerendering القيمة true أثناء عرض الصفحة مسبقًا. يمكن للصفحات استخدام هذه السمة لمنع أو تأخير أنشطة معيّنة أثناء العرض المُسبق إلى أن يتم تفعيل الصفحة فعليًا.

بعد تفعيل مستند تم عرضه مسبقًا، سيتم أيضًا ضبط السمة activationStart في PerformanceNavigationTiming على قيمة غير صفرية تمثّل الوقت بين بدء العرض المُسبَق وتفعيل المستند فعليًا.

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

function pagePrerendered() {
  return (
    document.prerendering ||
    self.performance?.getEntriesByType?.('navigation')[0]?.activationStart > 0
  );
}

أسهل طريقة لمعرفة ما إذا تم عرض صفحة مسبقًا (إما بالكامل أو جزئيًا) هي فتح "أدوات مطوري البرامج" بعد تفعيل الصفحة وكتابة performance.getEntriesByType('navigation')[0].activationStart في وحدة التحكّم. إذا تم عرض قيمة غير صفرية، يعني ذلك أنّه تم عرض الصفحة مسبقًا:

وحدة التحكّم في &quot;أدوات مطوّري البرامج في Chrome&quot; تعرض قيمة موجبة لـ activationStart، ما يشير إلى أنّه تم عرض الصفحة مسبقًا
اختبار العرض المُسبَق في وحدة التحكّم

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

باستخدام واجهات برمجة التطبيقات هذه، يمكن لـ JavaScript للواجهة الأمامية رصد الصفحات المعروضة مسبقًا والتعامل معها بشكل مناسب.

التأثير في الإحصاءات

تُستخدَم الإحصاءات لقياس استخدام الموقع الإلكتروني، على سبيل المثال، استخدام "إحصاءات Google" لقياس عدد مشاهدات الصفحة والأحداث. أو من خلال قياس مقاييس أداء الصفحات باستخدام مراقبة المستخدمين الحقيقيين (RUM).

يجب عرض الصفحات مسبقًا فقط عندما يكون هناك احتمال كبير بأن يتم تحميل الصفحة من قِبل المستخدم. لهذا السبب، لا يتم تفعيل خيارات العرض المُسبَق في شريط عناوين Chrome إلا عندما يكون هناك احتمال كبير (أكثر من %80 من الوقت).

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

ويمكن تحقيق ذلك باستخدام Promise ينتظر حدث prerenderingchange إذا كان المستند قيد العرض المُسبَق، أو يتم حله فورًا إذا كان الآن:

// Set up a promise for when the page is activated,
// which is needed for prerendered pages.
const whenActivated = new Promise((resolve) => {
  if (document.prerendering) {
    document.addEventListener('prerenderingchange', resolve, {once: true});
  } else {
    resolve();
  }
});

async function initAnalytics() {
  await whenActivated;
  // Initialise your analytics
}

initAnalytics();

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

// Set up a promise for when the page is first made visible
const whenFirstVisible = new Promise((resolve) => {
  if (document.hidden) {
    document.addEventListener('visibilitychange', resolve, {once: true});
  } else {
    resolve();
  }
});

async function initAnalytics() {
  await whenFirstVisible;
  // Initialise your analytics
}

initAnalytics();

قد يكون هذا منطقيًا في ما يتعلق بالإحصاءات وحالات الاستخدام المشابهة، ولكن في حالات أخرى، قد تحتاج إلى تحميل المزيد من المحتوى، وبالتالي قد تحتاج إلى استخدام document.prerendering وprerenderingchange لاستهداف صفحات العرض المُسبَق تحديدًا.

حجب المحتوى الآخر أثناء العرض المُسبَق

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

على سبيل المثال، في النص البرمجي التالي:

<script src="https://example.com/app/script.js" async></script>

يمكنك تغيير ذلك إلى عنصر نص برمجي يتم إدراجه ديناميكيًا ولا يتم إدراجه إلا استنادًا إلى دالة whenActivated السابقة:

async function addScript(scriptUrl) {
  await whenActivated;
  const script = document.createElement('script');
  script.src = 'scriptUrl';
  document.body.appendChild(script);
}

addScript('https://example.com/app/script.js');

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

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

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

من الطرق التي يحدّ بها Chrome من الحاجة إلى التفاف النصوص البرمجية أو الدوال يدويًا هي حجب بعض واجهات برمجة التطبيقات كما ذكرنا سابقًا، وعدم عرض إطارات iframe التابعة لجهات خارجية، وبالتالي لا يلزم حجب سوى المحتوى الذي يظهر فوق ذلك يدويًا.

قياس الأداء

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

بالنسبة إلى مؤشرات Core Web Vitals التي يقيسها Chrome من خلال تقرير تجربة المستخدم على Chrome، تهدف هذه المؤشرات إلى قياس تجربة المستخدم. لذلك يتم قياسها بناءً على وقت التفعيل. سيؤدي ذلك غالبًا إلى أن يكون مقياس LCP يساوي 0 ثانية على سبيل المثال، ما يشير إلى أنّ هذه طريقة رائعة لتحسين مؤشرات Core Web Vitals.

اعتبارًا من الإصدار 3.1.0، تم تعديل مكتبة web-vitals للتعامل مع عمليات التنقّل التي تم عرضها مسبقًا بالطريقة نفسها التي يقيس بها Chrome مؤشرات Core Web Vitals. يضع هذا الإصدار أيضًا علامة على عمليات التنقّل التي تم عرضها مسبقًا لهذه المقاييس في السمة Metric.navigationType إذا تم عرض الصفحة مسبقًا بشكل كامل أو جزئي.

قياس عمليات العرض المُسبَق

يمكن معرفة ما إذا كانت الصفحة معروضة مسبقًا من خلال إدخال activationStart غير صفري في PerformanceNavigationTiming. ويمكن بعد ذلك تسجيل هذه البيانات باستخدام سمة مخصّصة أو ما شابه ذلك عند تسجيل مشاهدات الصفحة، على سبيل المثال باستخدام الدالة pagePrerendered الموضّحة سابقًا:

// Set Custom Dimension for Prerender status
gtag('set', { 'dimension1': pagePrerendered() });
// Initialise GA - including sending page view by default
gtag('config', 'G-12345678-1');

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

عند قياس تأثير العرض المسبَق للصفحات في عمليات التنقّل الفوري على نشاطك التجاري، يمكنك تحديد ما إذا كان من المفيد بذل المزيد من الجهد في استخدام هذه التكنولوجيا للسماح بعرض المزيد من عمليات التنقّل بشكل مسبَق، أو التحقيق في سبب عدم عرض الصفحات بشكل مسبَق.

قياس معدلات الإصابة

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

ويمكن قياس ذلك من خلال إطلاق حدث إحصاءات عند إدراج قواعد التوقّع، بعد التأكّد من أنّ المتصفّح يتيح العرض المُسبَق باستخدام HTMLScriptElement.supports('speculationrules')، للإشارة إلى أنّه تم طلب العرض المُسبَق. (يُرجى العِلم أنّ طلب العرض المُسبَق لا يشير إلى أنّه قد بدأ أو اكتمل، لأنّ العرض المُسبَق هو تلميح للمتصفِّح وقد يختار عدم عرض الصفحات مُسبقًا بناءً على إعدادات المستخدم أو استخدام الذاكرة الحالي أو غير ذلك من الإرشادات).

يمكنك بعد ذلك مقارنة عدد هذه الأحداث بعدد مشاهدات الصفحة الفعلية التي تم عرضها مسبقًا. أو بدلاً من ذلك، يمكنك تنشيط حدث آخر عند التفعيل إذا كان ذلك يسهّل المقارنة.

ويمكن بعد ذلك تقريب "معدّل النتائج الناجحة" من خلال النظر إلى الفرق بين هذين الرقمين. بالنسبة إلى الصفحات التي تستخدم فيها واجهة Speculation Rules API لعرض الصفحات بشكل مسبق، يمكنك تعديل القواعد بشكل مناسب لضمان الحفاظ على معدّل نجاح مرتفع من أجل تحقيق التوازن بين استخدام موارد المستخدمين لمساعدتهم واستخدامها بدون داعٍ.

يُرجى العِلم أنّ بعض عمليات العرض المُسبَق قد تحدث بسبب العرض المُسبَق لشريط العناوين وليس فقط بسبب قواعد التوقّعات. ويمكنك التحقّق من document.referrer (الذي سيكون فارغًا لعمليات التنقّل في شريط العناوين، بما في ذلك عمليات التنقّل في شريط العناوين التي تم عرضها مسبقًا) إذا كنت تريد التفريق بينها.

يُرجى أيضًا الاطّلاع على الصفحات التي لا تتضمّن عمليات عرض مسبق، لأنّ ذلك قد يشير إلى أنّ هذه الصفحات غير مؤهّلة للعرض المسبق، حتى من شريط العناوين. قد يعني ذلك أنّك لا تستفيد من هذا التحسين في الأداء. يتطلّع فريق Chrome إلى إضافة أدوات إضافية لاختبار أهلية العرض المُسبَق، ربما على غرار أداة اختبار bfcache، وربما أيضًا إضافة واجهة برمجة تطبيقات لتوضيح سبب تعذُّر العرض المُسبَق.

التأثير في الإضافات

اطّلِع على المنشور المخصّص حول إضافات Chrome: توسيع واجهة برمجة التطبيقات لإتاحة ميزة "التنقّل الفوري" الذي يوضّح بعض الاعتبارات الإضافية التي قد يحتاج مؤلفو الإضافات إلى التفكير فيها بشأن الصفحات التي يتم عرضها بشكل مسبَق.

الملاحظات

يعمل فريق Chrome على تطوير ميزة العرض المُسبَق بشكل نشط، وهناك العديد من الخطط لتوسيع نطاق ما تم توفيره في الإصدار 108 من Chrome. نرحّب بأي ملاحظات على مستودع GitHub أو باستخدام أداة تتبُّع المشاكل، ونتطلّع إلى سماع ومشاركة دراسات حالة حول واجهة برمجة التطبيقات الجديدة والمثيرة هذه.

الإقرارات

الصورة المصغّرة من تصميم مارك أوليفييه جودوين على Unsplash