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

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

لمحة موجزة عن المعالجة المسبقة

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Speculation Rules API

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

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

أو من خلال قواعد المستند (متوفّرة من الإصدار 121 من Chrome)، والتي تُعرِض روابط المستند مسبقًا استنادًا إلى أدوات اختيار 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>

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

الحماس

يُستخدَم الإعداد 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 حلًا وسطًا، ويمكن أن تستفيد العديد من المواقع الإلكترونية من قاعدة التوقّعات التالية التي ستؤدي إلى عرض الرابط مسبقًا عند تثبيت المؤشر فوق الرابط لمدة 200 ملي ثانية أو عند حدث pointerdown كتطبيق أساسي وفعّال لقواعد التوقّعات:

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

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

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

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

حدود Chrome

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

الحماس	الجلب المُسبَق	العرض المُسبَق
immediate / eager	50	10
moderate / conservative	2 (FIFO)	2 (FIFO)

يعمل إعدادا 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

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

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

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

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

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

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

دعم No-Vary-Search

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

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

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

إضافة قواعد التوقّع من خلال أداة إدارة علامات

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

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

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

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

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

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

يمكن إضافة 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

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

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

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

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

تُستخدَم "إحصاءات Google" لقياس استخدام الموقع الإلكتروني، على سبيل المثال، باستخدام "إحصاءات 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 ثانية، ما يشير إلى أنّ هذه طريقة رائعة لتحسين "مؤشرات أداء الويب الأساسية".

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

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

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

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

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

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

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

ملاحظات

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

روابط ذات صلة

• درس تطبيقي حول قواعد التوقّع
• تصحيح أخطاء قواعد التوقّع
• تقديم ميزة "التحميل المُسبَق بدون حالة"
• مواصفات Speculation Rules API
• مستودع GitHub الخاص بالتكهّنات المتعلّقة بالتنقّل
• إضافات Chrome: توسيع نطاق واجهة برمجة التطبيقات لتتوافق مع ميزة "التنقّل الفوري"

الشكر والتقدير

صورة مصغّرة من إنشاء Marc-Olivier Jodoin على Unsplash