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

Barry Pollard

التوافق مع المتصفح

  • 109
  • 109
  • x
  • x

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

نبذة تاريخية عن العرض المُسبَق

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

لقطة شاشة لصفحة توقّعات Chrome تمت فلترتها لتعرض توقعات منخفضة (رمادية) ومتوسطة (كهرمانية) ومرتفعة (أخضر) استنادًا إلى النص الذي تم إدخاله.
صفحة توقّعات Chrome

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

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

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

لقطة شاشة لميزة &quot;Typeahead&quot; في شريط العناوين
ميزة "Typeahead" في شريط العناوين:

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

  • للحصول على مستوى ثقة أكبر من% 50 (يظهر باللون الأصفر)، يتصل Chrome مسبقًا بالنطاق مسبقًا، ولكن لا يعرض الصفحة مسبقًا.
  • للحصول على مستوى ثقة أكبر من% 80 (معروض باللون الأخضر)، سيعرض Chrome عنوان URL مُسبقًا.

واجهة برمجة تطبيقات قواعد التوقُّع

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

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

أو من خلال قواعد المستند (المتوفّرة من Chrome 121)، والتي تعرض مُسبقًا الروابط الموجودة في المستند استنادًا إلى أدوات اختيار href أو CSS:

<script type="speculationrules">
{
  "prerender": [{
    "where": {
      "and": [
        { "href_matches": "/*" },
        { "not": {"selector_matches": ".do-not-prerender"}},
        { "not": {"selector_matches": "[rel=nofollow]"}}
      ]
    }
  }]
}
</script>

الحماس

التوافق مع المتصفح

  • 121
  • 121
  • x
  • x

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

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

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

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

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

يعتبر الخيار moderate نقطة انطلاق، ويمكن أن تستفيد العديد من المواقع الإلكترونية من قاعدة التوقُّع التالية التي قد تعرض مسبقًا جميع الروابط عند التمرير أو الانتقال للأسفل كإجراء أساسي - ولكنه فعّال في الوقت نفسه - لتطبيق قواعد التوقُّع:

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

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

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

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

حدود Chrome المسموح بها

يفرض Chrome حدودًا لمنع الاستخدام الزائد لواجهة برمجة تطبيقات Speculation Rules (قواعد التوقُّع):

الشغف الجلب المُسبَق العرض المُسبَق
immediate / eager 50 10
moderate / conservative 2 (FIFO) 2 (FIFO)
حدود التوقُّع في Chrome:

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

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

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

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

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

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

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

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

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

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

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

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

التوافق مع المتصفح

  • 121
  • 121
  • x
  • x

المصدر

يمكن أيضًا تسليم قواعد التوقُّع باستخدام عنوان 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 لقواعد التوقُّع. وقد يكون ذلك مفيدًا على وجه الخصوص إذا كنت بحاجة إلى اختيار بعض الروابط من المصدر نفسه أو كلها.

قواعد التوقُّع وSPA

لا تتوفّر قواعد التوقُّع إلا لعمليات التنقّل الكاملة في الصفحة التي يديرها المتصفِّح، وليس لصفحات تطبيقات الصفحة الواحدة (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>

التوافق مع المتصفح

  • 121
  • 121
  • x
  • x

المصدر

عند الجلب المُسبق لصفحة أو عرضها مسبقًا، قد لا تكون بعض مَعلمات عناوين 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، وأن تنتظر اكتمال هذا الجلب المُسبَق.

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

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

العرض المُسبَق للصفحات من مصادر متعددة للموقع الإلكتروني نفسه (على سبيل المثال، بإمكان 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)، وكذلك تفعيل العرض المُسبَق في علامات تبويب جديدة.

رصد دعم واجهة برمجة التطبيقات لقواعد التوقُّع

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

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

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

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

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

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

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

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

سيتم إرسال الصفحات المعروضة مُسبقًا باستخدام عنوان HTTP يتضمّن العنصر Sec-Purpose:

Sec-Purpose: prefetch;prerender

سيتم ضبط هذا العنوان على prefetch فقط في الصفحات التي تم جلبها مسبقًا باستخدام واجهة برمجة التطبيقات Speculation Rules (قواعد التوقُّع):

Sec-Purpose: prefetch

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

في حال كنت لا تريد عرض صفحة معيّنة مُسبقًا، فهذه هي أفضل طريقة لضمان عدم عرض الصفحة. ولتقديم أفضل تجربة، يُنصَح بدلاً من ذلك بالسماح بالعرض المُسبَق، مع تأخير أي إجراءات يجب تنفيذها فقط عند عرض الصفحة فعليًا، باستخدام 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; تعرض عملية تفعيل إيجابية تشير إلى بدء عرض الصفحة مسبقًا
اختبار العرض المُسبَق في وحدة التحكّم:

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

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

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

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

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

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

ويمكن تحقيق ذلك باستخدام 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 whenActivated = new Promise((resolve) => {
  if (document.hidden) {
    document.addEventListener('visibilitychange', resolve, {once: true});
  } else {
    resolve();
  }
});

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

initAnalytics();

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

قياس الأداء

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

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

وبدايةً من الإصدار 3.1.0، تم تحديث مكتبة web-vitals للتعامل مع عمليات الانتقال المعروضة مُسبقًا بالطريقة نفسها التي يقيس بها Chrome مؤشرات أداء الويب الأساسية. يحدِّد هذا الإصدار أيضًا عمليات التنقّل المعروضة مُسبقًا لتلك المقاييس في السمة 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')، للإشارة إلى أنّه تم طلب العرض المُسبَق. (ملاحظة: لا يشير العرض المُسبَق فقط إلى بدء العرض المُسبَق أو إكماله لمجرد طلب العرض المُسبَق، كما هو مذكور سابقًا، فهو يمثّل تلميحًا إلى المتصفِّح وقد يختار عدم عرض الصفحات مُسبقًا في إعدادات المستخدم أو استخدام الذاكرة الحالي أو إشارات استدلالية أخرى.)

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

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

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

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

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

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

إضافة ملاحظات

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

شكر وتقدير

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