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

Barry Pollard

عمل فريق Chrome على بعض التعديلات المشوّقة على Speculation Rules API المستخدَمة لتحسين أداء التنقّل من خلال الترجيع المُسبَق أو حتى التقديم المُسبَق لعمليات التنقّل المستقبلية. تتوفّر هذه التحسينات الإضافية الآن في الإصدار 122 من Chrome (مع توفّر بعض الميزات في الإصدارات الأقدم).

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

ميزات إضافية

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

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

في السابق، كانت Speculation Rules API تعمل من خلال تحديد قائمة بعناوين URL لتحميلها مسبقًا أو عرضها مسبقًا:

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

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

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

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

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

يمكن أيضًا استخدام أدوات اختيار CSS كبديل أو مع مطابقات href للعثور على الروابط في الصفحة الحالية:

<script type="speculationrules">
{
  "prerender": [{
    "source": "document",
    "where": {
      "and": [
        { "selector_matches": ".prerender" },
        { "not": {"selector_matches": ".do-not-prerender"}}
      ]
    },
    "eagerness": "moderate"
  }]
}
</script>

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

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

الحماس

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

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

يتيح لك إعداد eagerness تحديد الحالات التي يجب فيها تنفيذ التكهّنات، مع فصل الحالات التي يجب فيها التكهّن عن عناوين URL التي يجب تنفيذ التكهّنات عليها. يتوفّر الإعداد eagerness لكل من قواعد المصدر list وdocument، ويحتوي على أربعة إعدادات، ويستخدم Chrome الأساليب الاستقرائية التالية لها:

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

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

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

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

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

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

حدود Chrome

حتى مع اختيار eagerness، يفرض Chrome حدودًا لمنع الاستخدام المفرط لواجهة برمجة التطبيقات هذه:

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

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

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

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

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

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

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

اختياري source

يجعل الإصدار 122 من Chrome مفتاح source اختياريًا لأنّه يمكن استنتاج ذلك من توفّر مفتاحَي url أو where. وبالتالي، فإنّ هاتين القاعدتَين متطابقتَين:

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

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

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

إعادة استخدام ذاكرة التخزين المؤقت بشكل أفضل

أجرينا عددًا من التحسينات على ميزة التخزين المؤقت في Chrome لكي يؤدي تحميل المحتوى مسبقًا (أو حتى التقديم المُسبَق) لمستند إلى تخزين الموارد وإعادة استخدامها في ذاكرة التخزين المؤقت لبروتوكول HTTP. وهذا يعني أنّ المضاربة لا تزال تحقّق مزايا مستقبلية، حتى إذا لم يتم استخدامها.

ويؤدي ذلك أيضًا إلى تقليل تكلفة إعادة التكهّن (على سبيل المثال، لقواعد المستندات التي تتضمّن إعدادًا moderate للاندفاع) بشكلٍ كبير، لأنّ Chrome سيستخدم ذاكرة التخزين المؤقت لبروتوكول HTTP للموارد القابلة للتخزين المؤقت.

نحن نؤيد أيضًا اقتراح No-Vary-Search الجديد لتحسين إعادة استخدام ذاكرة التخزين المؤقت بشكل أكبر.

دعم 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://speculative-rules.glitch.me/common-fruits.html يمكن استخدامه للاطّلاع على قواعد المستندات مع إعداد moderate للحرص في العمل:

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

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

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

إتاحة المنصة لقواعد التوقّع

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

نحن نعمل أيضًا جاهدين لتوحيد واجهة برمجة التطبيقات من خلال مجموعة Web Incubator Community Group (WICG) للسماح للمتصفّحات الأخرى أيضًا بتنفيذ واجهة برمجة التطبيقات هذه إذا أرادت ذلك.

WordPress

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

تتوفّر مجموعتَان من الإعدادات: وضع التوقّعات وإعداد الحرص:

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

Akamai

شركة Akamai هي إحدى الشركات الرائدة في مجال توفير شبكات توصيل المحتوى (CDN) في العالم، وهي تختبر بنشاط واجهة برمجة التطبيقات Speculation Rules API منذ بعض الوقت. أصدرت Akamai مستندات حول كيفية تفعيل واجهة برمجة التطبيقات هذه في إعدادات شبكة توصيل المحتوى (CDN). وقد شاركوا أيضًا في السابق النتائج المُبهرة التي يمكن تحقيقها باستخدام واجهة برمجة التطبيقات الجديدة هذه.

NitroPack

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

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

Astro

أضافت Astro ميزة العرض المُسبَق للصفحات باستخدام Speculation Rules API في الإصدار 4.2 بشكل تجريبي، ما يتيح للمطوّرين الذين يستخدمون Astro تفعيل هذه الميزة بسهولة، مع الرجوع إلى ميزة التحميل المُسبَق العادي للمتصفّحات التي لا تتوافق مع Speculation Rules API. اطّلِع على مستندات المعالجة المسبقة للعملاء للحصول على مزيد من المعلومات.

الخاتمة

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

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

نتطلّع إلى زيادة استخدام Speculation Rules API على مدار عام 2024، وسنطلعك على أي تحسينات أخرى نُجريها على واجهة برمجة التطبيقات.

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

الصورة المصغّرة مقدمة من روبي داون على Unsplash