كان فريق 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) |
يعمل إعدادا moderate وconservative، اللذين يعتمدان على تفاعل المستخدم، بطريقة تسجيل أول دخول وأول (FIFO). بعد الوصول إلى الحدّ الأقصى، ستؤدي توقُّع جديد إلى إلغاء التوقُّع الأقدم واستبداله بآخر توقُّع للحفاظ على مستوى الذاكرة.
إنّ حقيقة أنّ المستخدمين يشغّلون توقُّعَي moderate وconservative، ما يسمح لنا باستخدام حدّ أدنى أقل يبلغ 2 للحفاظ على الذاكرة. لا يؤدي إجراء المستخدِم إلى تفعيل إعدادَي immediate وeager، وبالتالي يكون حدّهما أعلى لأنّه لا يمكن للمتصفّح معرفة الإعدادات المطلوبة ووقت الحاجة إليها.
يمكن تشغيل توقع يتم إلغاؤه عن طريق دفعه خارج قائمة انتظار FIFO مرة أخرى - على سبيل المثال عن طريق التمرير فوق هذا الرابط مرة أخرى - مما سيؤدي إلى إعادة توقُّع عنوان 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 بشكل عملي:
افتح أدوات مطوّري البرامج، وانقر على لوحة التطبيق. بعد ذلك، في قسم الخدمات التي تعمل في الخلفية، انقر على عمليات التحميل المبني على توقُّع، ثم على لوحة التوقُّعات، ورتِّب البيانات حسب عمود الحالة.
عند تحريك الماوس فوق الثمار، ستظهر لك الصفحات يتم عرضها مُسبقًا. وسيؤدي النقر عليها إلى عرض وقت سرعة عرض أكبر جزء من المحتوى على الصفحة (LCP) بكثير من وقت إحدى الوصفات التي لم يتم عرضها مُسبقًا. يمكن شرح هذا العرض التوضيحي أيضًا في الفيديو التالي:
يمكنك أيضًا الاطّلاع على مشاركة المدونة السابقة حول تصحيح أخطاء قواعد التوقُّع للحصول على مزيد من المعلومات حول كيفية استخدام "أدوات مطوري البرامج" لتصحيح أخطاء قواعد التوقُّع.
توافق المنصة مع قواعد التوقّع
على الرغم من سهولة تطبيق قواعد التوقّع من خلال إضافة القواعد في عنصر <script type="speculationrules">، إلا أنّ إتاحة هذه الميزة على المنصة قد تسهّل تنفيذ ذلك بنقرة واحدة. لقد تعاونّا مع عدة منصّات وشركاء لتسهيل عملية طرح قواعد التوقّع.
نعمل جاهدين على توحيد واجهة برمجة التطبيقات من خلال Web Incubator Community Group (WICG) من أجل السماح للمتصفّحات الأخرى بتنفيذ واجهة برمجة التطبيقات الرائعة هذه أيضًا إذا أرادت ذلك.
WordPress
أنشأ فريق الأداء الأساسي في WordPress (بما في ذلك مطوّرو البرامج من Google) مكوّنًا إضافيًا لقواعد التوقُّع. يتيح هذا المكوّن الإضافي إمكانية إضافة قواعد المستند بسيطة بنقرة واحدة إلى أي موقع إلكتروني على WordPress. يتوفر هذا المكوّن الإضافي للتثبيت أيضًا من خلال المكوّن الإضافي WordPress Performance Lab الذي ننصحك بتثبيته أيضًا لأنّه سيبقيك على اطّلاع على المكوّنات الإضافية ذات الصلة بالأداء من الفريق.
تتوفّر مجموعتان من الإعدادات: وضع التوقُّع وإعداد مستوى سرعة الاستعداد:
بالنسبة إلى عمليات الإعداد الأكثر تعقيدًا، مثلاً لاستبعاد عناوين URL معيّنة من جلبها مسبقًا أو عرضها مُسبقًا، يُرجى الاطّلاع على المستندات.
Akamai
يُعد Akamai أحد مزودي شبكات توصيل المحتوى (CDN) الرائد على مستوى العالم، ويجري تجربة نشطة باستخدام واجهة Speculation Rules API منذ فترة. أصدر Akamai وثائق حول كيفية تمكين العملاء لواجهة برمجة التطبيقات هذه في إعدادات شبكة توصيل المحتوى (CDN). وقد شاركوا أيضًا في السابق النتائج المثيرة للإعجاب الممكنة باستخدام واجهة برمجة التطبيقات الجديدة هذه.
NitroPack
NitroPack هو حلّ لتحسين الأداء يستخدم الذكاء الاصطناعي المخصّص للتنقّل بهدف توقُّع الصفحات التي يجب إضافتها إلى قواعد التوقّع، وذلك بهدف توفير مهلة أطول مقارنةً بالتمرير فوق رابط معيَّن بدون إهدار توقُّع جميع الروابط التي تم رصدها بدون داعٍ. راجِع مستندات واجهة برمجة التطبيقات لقواعد التوقُّع في Nitropack للحصول على مزيد من المعلومات. يُظهر هذا الحل المبتكَر أنّه لا يزال هناك الكثير من القواعد القديمة التي يمكن تقديمها عند إقران هذه القواعد بالإحصاءات الخاصة بالمواقع الإلكترونية.
تعاون فريق Chrome أيضًا مع شركة NitroPack لإنشاء برنامج تعليمي على الويب حول واجهة برمجة تطبيقات قواعد التوقُّع موجّه إلى المستخدمين الذين يبحثون عن مزيد من المعلومات، بما في ذلك مناقشة جيدة حول الاعتبارات اللازمة بين التكهن مبكرًا وكثيرًا، وكذلك في وقت متأخّر وأقل.
Astro
أضافت شركة Astro صفحات العرض المُسبَق باستخدام واجهة برمجة تطبيقات قواعد التوقُّع في الإصدار 4.2 على أساس تجريبي، ما أتاح لمطوّري البرامج الذين يستخدمون Astro تفعيل هذه الميزة بسهولة، مع العودة إلى استخدام الجلب المُسبَق العادي مع المتصفّحات التي لا تتوافق مع واجهة Speculation Rules API. يمكنك الاطّلاع على مستندات العرض المُسبَق للعميل للحصول على مزيد من المعلومات.
الخاتمة
تتيح هذه الإضافات إلى واجهة برمجة تطبيقات قواعد التوقُّع استخدامًا أسهل بكثير لميزة الأداء الجديدة هذه للمواقع الإلكترونية، مع تقليل مخاطر إهدار الموارد بسبب التكهنات غير المستخدمة. من الرائع أن نرى أن الأنظمة الأساسية تعتمد حاليًا على واجهة برمجة التطبيقات هذه. ونأمل أن يتم استخدام واجهة برمجة التطبيقات هذه على نطاق أوسع في 2024، ما يؤدي بدوره إلى تحسين أداء المستخدمين النهائيين.
بالإضافة إلى المكاسب على صعيد الأداء التي توفّرها واجهة برمجة التطبيقات Speculation Rules API، نحن متحمّسون أيضًا لمعرفة الفرص الجديدة المتاحة. عرض الانتقالات هي واجهة برمجة تطبيقات جديدة تتيح للمطوّرين تحديد الانتقالات بين عمليات الانتقال بسهولة أكبر. يتوفّر هذا حاليًا لتطبيقات الصفحة الواحدة (SPA)، ولكن الإصدار المتعدّد الصفحات قيد التقدم (ويتوفّر بعد علامة في Chrome). فالعرض المُسبَق هو إضافة طبيعية لتلك الميزة لضمان عدم حدوث أي تأخير، ما قد يمنع تحسين تجربة المستخدم التي تهدف عملية النقل إلى توفيرها. وقد سبق أن لاحظنا مواقع إلكترونية تختبر هذه التركيبة.
نتطلّع إلى استخدام واجهة Speculation Rules API بشكل أكبر على مدار عام 2024، وسنطلعك على أي تحسينات أخرى نُجريها على واجهة برمجة التطبيقات.
شكر وتقدير
الصورة المصغّرة بواسطة Robbie Down على إلغاء البداية