تمت ترجمة هذه الصفحة بواسطة Cloud Translation API‏.

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

Barry Pollard

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

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

ميزات إضافية

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

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

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

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

حدود التوقُّع في Chrome

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

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

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

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

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

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

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

`source` اختياري

يجعل متصفّح Chrome 122 مفتاح 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 عند ضبطها يدويًا:

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

عند تحريك مؤشر الماوس فوق الثمار، سترى الصفحات يتم عرضها مسبقًا. يؤدي النقر عليها إلى إظهار وقت LCP أسرع بكثير من إحدى الوصفات التي لم يتم عرضها مسبقًا. يمكن أيضًا شرح هذا العرض التوضيحي في الفيديو التالي:

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

دعم النظام الأساسي لقواعد التوقُّع

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

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

WordPress

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

تتوفّر مجموعتان من الإعدادات: وضع التوقُّع وإعداد الاهتمام:

لقطة شاشة للوحة قراءة إعدادات WordPress باستخدام إعدادات قواعد التوقُّع هناك خياران: وضع التوقُّع مع خيار "الجلب المُسبَق" أو "العرض المُسبَق"، وإعداد "سرعة القراءة" مع إعدادات "منخفض" أو "متوسط" أو "سريع". — المكوِّن الإضافي لقواعد توقُّع WordPress

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

أكاماي

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

NitroPack

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

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

نجم

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

الخلاصة

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

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

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

شكر وتقدير

صورة مصغّرة من Robbie Down في UnLaunch