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

Barry Pollard

أعاد فريق 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 الصفحة مسبقًا لك تلقائيًا عند الضغط مع الاستمرار على المؤشر فوق أحد أزرار الإشارات المرجعية.
3. عند كتابة عبارة بحث في شريط عناوين Chrome، قد يعرض Chrome صفحة نتائج البحث تلقائيًا عندما يطلب محرّك البحث ذلك.
4. يمكن للمواقع الإلكترونية استخدام واجهة برمجة تطبيقات قواعد التوقُّع لإعلام Chrome آليًا بالصفحات المطلوب عرضها مُسبقًا. تحلّ هذه السياسة محلّ الإجراءات التي اعتاد <link rel="prerender"...> تنفيذها، وتسمح للمواقع الإلكترونية بعرض صفحة مُسبَقة بشكل استباقي استنادًا إلى قواعد التوقُّع على تلك الصفحة. ويمكن أن توجد هذه الصفحات بشكل ثابت على الصفحات، أو يتم إدخالها ديناميكيًا بواسطة JavaScript على النحو الذي يراه مالك الصفحة.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

أو باستخدام قواعد المستندات (المتوفّرة في الإصدار 121 من Chrome)، والتي تعرض مسبقًا الروابط المتوفّرة في المستند استنادًا إلى أدوات اختيار href (استنادًا إلى واجهة برمجة تطبيقات نمط عنوان URL) أو أدوات اختيار لغة 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 مللي ثانية أو عند حدث تسجيل الدخول كتنفيذ أساسي لقواعد التوقُّع، ولكن قوية في الوقت نفسه:

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

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

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

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

حدود Chrome

هناك حدود قصوى مفروضة في 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

يمكن أيضًا تقديم قواعد التوقُّع باستخدام عنوان 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>

دعم 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 مشابه.

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

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

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

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

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

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

يمكنك اكتشاف إتاحة واجهة برمجة التطبيقات لقواعد التوقُّع باستخدام عمليات فحص 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);
}

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

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

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

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

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

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

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

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

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

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

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

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

ملاحظات

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

روابط ذات صلة

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

شكر وتقدير

صورة مصغّرة من مارك أوليفييه جودوين على Unإعادة البداية