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

Barry Pollard

أعاد فريق 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 صفحة نتائج البحث تلقائيًا عندما يطلب محرّك البحث ذلك.
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:

يتم تطبيق إعدادَي 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 من خلال عمليات التحقّق العادية من 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

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

قياس الأداء

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

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

من الإصدار 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