تاريخ النشر: 7 آذار (مارس) 2025
تسمح واجهة برمجة التطبيقات Speculation Rules API للمستخدمين بالاستفادة من تحسين الأداء من خلال الجلب المُسبَق أو العرض المُسبَق لعمليات التنقّل المستقبلية في الصفحات لتقديم عمليات تنقّل أسرع أو حتى فورية في الصفحات.
تم تصميم واجهة برمجة التطبيقات خصيصًا مع التركيز على سهولة التنفيذ، ولكن هناك بعض الاعتبارات التي يجب أن تأخذها المواقع الإلكترونية المعقدة في الاعتبار على وجه الخصوص قبل استخدامها. يساعد هذا الدليل مالكي المواقع الإلكترونية في فهم هذه الاعتبارات.
التخطيط
قبل تنفيذ قواعد التكهّنات، من المفيد التفكير في كيفية تنفيذ واجهة برمجة التطبيقات (لأنّ هناك بضعة خيارات)، وكذلك تكاليف التكهّنات (التي من المفترض أن ترشدك إلى الصفحات التي يجب التكهّن بشأنها).
تحديد كيفية تطبيق قواعد التوقّع
من أوّل القرارات التي عليك اتخاذها هي كيفية تنفيذ قواعد التكهّنات على موقعك الإلكتروني، لأنّ هناك طُرقًا مختلفة يمكنك استخدامها:
- في رمز HTML للصفحة مباشرةً
- استخدام JavaScript
- استخدام عنوان HTTP
في النهاية، يكون لكل طريقة التأثير نفسه، ولكن يمكن أن تكون هناك مزايا من حيث سهولة التنفيذ والمرونة.
على المواقع الإلكترونية اختيار الخيار الأنسب لها، ويمكنها أيضًا استخدام مجموعة من هذه الخيارات إذا لزم الأمر. بدلاً من ذلك، يمكن تنفيذها باستخدام مكوّن إضافي (مثل مكوّن "التحميل التوقّعي" الإضافي في WordPress) أو مكتبات أو منصات قد تختار لك الخيار المناسب، ولكن لا يزال من المفيد معرفة الخيارات المتاحة.
تضمين قواعد التوقّعات مباشرةً في ملف HTML للصفحة
يمكن تنفيذ قواعد التكهّنات مباشرةً على الصفحة من خلال تضمين عنصر <script type="speculationrules"> في ملف HTML. ويمكن إضافة هذا المحتوى إما في وقت إنشاء المواقع الإلكترونية الثابتة باستخدام النماذج، أو في وقت التشغيل من خلال الخادم عند طلب الصفحة. ويمكن أيضًا أن يتم إدراجها في HTML بواسطة عمال الحواف (على الرغم من أنّ طريقة عنوان HTTP التي تتم مناقشتها لاحقًا في هذا الدليل قد تكون أسهل لذلك).
يتيح لك ذلك تضمين قواعد ثابتة في الموقع الإلكتروني بأكمله، ولكن يمكن أن تظل قواعد المستند ديناميكية من خلال السماح لك باختيار عناوين URL المطلوب عرضها من الصفحة باستخدام القواعد التي يتم تفعيلها بواسطة فئات CSS:
<script type="speculationrules">
{
"prerender": [{
"where": { "selector_matches": ".prerender" }
}],
"prefetch": [{
"where": { "selector_matches": ".prefetch" }
}]
}
</script>
سيؤدي النص البرمجي السابق إلى عرض الروابط التي تحمل فئة prerender مسبقًا، وسيؤدي أيضًا إلى التحميل المُسبَق عندما يكون الرابط يحمل فئة prefetch. يتيح ذلك للمطوّرين تضمين هذه الفئات في HTML لبدء التكهّنات.
بالإضافة إلى تضمين روابط هذه الفئات في ملف HTML الأولي للصفحة، سيتم أيضًا التكهّن بالروابط إذا أضاف تطبيقك هذه الفئات بشكل ديناميكي، ما يسمح لتطبيقك بتشغيل التكهّنات (وإزالتها) حسب الحاجة. ويمكن أن يكون ذلك أبسط من إنشاء قواعد تكهّن أكثر تحديدًا أو إزالتها. من الممكن أيضًا تضمين قواعد تكهّن متعددة لكل صفحة إذا كنت تريد قاعدة أساسية يستخدمها معظم الموقع الإلكتروني وقواعد خاصة بالصفحة.
بدلاً من ذلك، إذا كنت بحاجة إلى استخدام قواعد تكهّن أكثر تحديدًا، يمكن أن تسمح القواعد الخاصة بالصفحة أو النموذج بقواعد مختلفة لصفحات أو أنواع صفحات معيّنة.
أخيرًا، يمكن أن تتضمّن الصفحات المعروضة من جهة الخادم أيضًا قواعد أكثر ديناميكية استنادًا إلى أي معلومات متاحة للخادم، مثل معلومات الإحصاءات لهذه الصفحة أو مسارات المستخدِمين الشائعة لصفحات معيّنة.
إضافة قواعد توقّعات باستخدام JavaScript
هناك بديل لتضمين القواعد في نص برمجي على الصفحة، وهو إدخالها باستخدام JavaScript. وقد يتطلّب ذلك إجراء تعديلات أقل على نماذج الصفحات. على سبيل المثال، يمكن أن يكون استخدام أداة إدارة العلامات من Google لإدخال القواعد طريقة سريعة لطرح قواعد التكهّنات (كما تتيح أيضًا إيقافها بسرعة إذا لزم الأمر).
يتيح هذا الخيار أيضًا قواعد ديناميكية من جهة العميل استنادًا إلى كيفية تفاعل المستخدم مع الصفحة. على سبيل المثال، إذا أضاف المستخدم سلعة إلى سلة التسوّق، يمكنك عرض صفحة الدفع مسبقًا. بدلاً من ذلك، يمكن استخدام هذا الإجراء لبدء تكهّنات استنادًا إلى شروط معيّنة. على الرغم من أنّ واجهة برمجة التطبيقات تتضمّن إعدادًا للاستعداد يسمح بتطبيق القواعد الأساسية المستندة إلى التفاعل، تسمح JavaScript للمطوّرين باستخدام منطقهم الخاص لتحديد الوقت والصفحات التي سيتم فيها إجراء التكهّنات.
كما ذكرنا سابقًا، هناك طريقة بديلة لإدراج قواعد جديدة وهي استخدام قاعدة مستند أساسية على الصفحة وجعل JavaScript تنشئ قواعد المستندات من خلال إضافة فئات مناسبة إلى الروابط التي تؤدي إلى مطابقة القاعدة.
إضافة قواعد توقّعات باستخدام عنوان HTTP
الخيار الأخير للمطوّرين هو تضمين القواعد باستخدام عنوان HTTP:
Speculation-Rules: "/speculationrules.json"
هناك بعض المتطلبات الإضافية المتعلّقة بطريقة إرسال مورد القواعد (/speculationrules.json في هذا المثال) واستخدامه.
يتيح هذا الخيار نشر المحتوى بسهولة أكبر من خلال خدمات CDN بدون الحاجة إلى تغيير محتوى المستند. ويعني ذلك أنّه لا يمكن تغيير قواعد التكهّن ديناميكيًا باستخدام JavaScript. ومع ذلك، يمكن أن تسمح قواعد المستندات التي تحتوي على عوامل تشغيل أدوات اختيار CSS بإجراء تغييرات ديناميكية، على سبيل المثال، من خلال إزالة فئة prerender من رابط.
على غرار خيار JavaScript، يتيح تنفيذ قواعد التكهّن باستخدام عنوان HTTP تنفيذها بشكل مستقل عن محتوى الموقع الإلكتروني، ما قد يسهّل إضافة القواعد وإزالتها بدون إعادة إنشاء الموقع الإلكتروني بالكامل.
ضع في اعتبارك تأثيرات التكلفة.
قبل تنفيذ قواعد التكهّن، من المفيد تخصيص بعض الوقت للتفكير في الآثار المترتبة على التكلفة لكلّ من المستخدمين وموقعك الإلكتروني باستخدام واجهة برمجة التطبيقات هذه. تشمل التكاليف معدل نقل البيانات (الذي يكبّد المستخدمين والمواقع الإلكترونية مبالغ مالية) وتكاليف المعالجة (من جهة العميل والخادم).
مراعاة التكلفة للمستخدمين
يعني التحميل التوقّعي إجراء تخمين مدروس بشأن الصفحة التي قد ينتقل إليها المستخدم. ومع ذلك، إذا لم يحدث هذا التنقّل، قد تكون قد أهدرت الموارد. لهذا السبب، يجب أن تكون على دراية بالتأثير في المستخدمين، على وجه الخصوص:
- معدل نقل البيانات الإضافي المستخدَم لتنزيل هذه التنقّلات المستقبلية، خاصةً على الأجهزة الجوّالة التي قد يكون فيها معدل نقل البيانات أكثر تقييدًا
- تكاليف معالجة إضافية لعرض هذه الصفحات عند استخدام ميزة "العرض المُسبَق"
في حال كانت التوقّعات دقيقة تمامًا، لن تكون هناك أي تكاليف إضافية، لأنّ الزوّار سيزورون هذه الصفحات بعد ذلك، مع الاختلاف الوحيد أنّ هذه التكاليف يتم تحميلها مقدّمًا. ومع ذلك، من المستحيل توقّع المستقبل بدقة كاملة، وكلما كانت استراتيجية المضاربة أكثر عدوانية، زاد خطر الهدر.
لقد فكّر فريق Chrome في هذه المشكلة بعناية، وتتضمّن واجهة برمجة التطبيقات عددًا من الميزات التي تعني أنّ التكلفة أقل بكثير مما تتوقّع. على وجه الخصوص، من خلال إعادة استخدام ذاكرة التخزين المؤقت لبروتوكول HTTP وعدم تحميل إطارات iframe من مصادر متعددة، غالبًا ما تكون تكلفة العرض المُسبَق لصفحة على الموقع الإلكتروني نفسه أقل بكثير من تكلفة صفحة كاملة بدون موارد مخزّنة مؤقتًا، ما يجعل عمليات التحميل التوقّعي أقل تكلفة مما قد يُفترض.
ومع ذلك، حتى مع توفّر هذه الإجراءات الوقائية، على المواقع الإلكترونية أن تضع في اعتبارها بعناية الصفحات التي تريد التكهّن بها وتكاليف المستخدم لهذه التكهّنات. تشمل الصفحات المرشحة جيدًا للتحميل التوقّعي تلك التي يمكن توقّعها بشكل معقول بدرجة عالية من الثقة (ربما استنادًا إلى الإحصاءات أو مسارات المستخدِمين الشائعة) وعندما تكون التكلفة منخفضة (على سبيل المثال، الصفحات الأقلّ ثراءً).
يمكنك أيضًا التفكير في رمز JavaScript الذي يجب تأخيره إلى أن يتم التفعيل. على غرار التحميل البطيء للمحتوى إلى أن يصبح مطلوبًا، يمكن أن يؤدي ذلك إلى تقليل تكلفة عمليات التقديم المُسبَق، ولكن مع توفير تجربة أفضل للمستخدم. مع التداولات الأقلّ تكلفة، قد تشعر بالارتياح للتداول بشكلٍ أكثر تكرارًا أو شغفًا.
وفي حال عدم توفّر هذا الخيار، يُنصح باستخدام استراتيجية أقل عدوانية باستخدام قواعد الحرص المعتدلة أو المحافظة. بدلاً من ذلك، يمكنك استخدام ميزة "التحميل المُسبَق" التي تُعدّ أقل تكلفة بكثير من ميزة "العرض المُسبَق" عندما يكون مستوى الثقة منخفضًا، ثم الترقية إلى ميزة "العرض المُسبَق الكامل" إذا زاد مستوى الثقة، على سبيل المثال، عند تمرير مؤشر الماوس فوق رابط أو النقر عليه.
مراعاة زيادة الحمل في الخلفية
بالإضافة إلى مراعاة التكاليف الإضافية التي يتحملها المستخدم، يجب أن يأخذ مالكو المواقع الإلكترونية في الاعتبار تكاليف البنية الأساسية الخاصة بهم. إذا كانت كل صفحة تؤدي إلى تحميل صفحتَين أو ثلاث أو أكثر، قد تزيد تكاليف الخلفية عند استخدام واجهة برمجة التطبيقات هذه.
سيؤدي التأكّد من إمكانية تخزين صفحاتك ومواردك مؤقتًا إلى تقليل مقدار تحميل المصدر بشكل كبير، وبالتالي تقليل المخاطر بشكل عام. عند استخدام شبكة توصيل المحتوى، من المفترض أن تواجه خوادم المصدر الحد الأدنى من الحمل الإضافي، مع الأخذ في الاعتبار أيّ زيادات في تكلفة شبكة توصيل المحتوى.
يمكن أيضًا استخدام خادم أو شبكة توصيل المحتوى (CDN) للتحكّم في نتائج التوقّعات كما هو محدّد من خلال عنوان HTTP sec-purpose. على سبيل المثال، لا يسمح منتج Speed Brain من Cloudflare إلا بالتكهّنات التي سبق أن تم تخزينها مؤقتًا على خادم CDN، ولن يُرسِل الطلبات مرة أخرى إلى المصدر.
ومع ذلك، بما أنّ عمليات التحميل التوقّعي تُستخدَم عادةً لتحميل الصفحات من المصدر نفسه، سيكون لدى المستخدمين موارد مشترَكة في ذاكرة التخزين المؤقت للمتصفّح، وذلك بافتراض أنّها قابلة للتخزين المؤقت في المقام الأول، وبالتالي، لا تكون عملية التحميل التوقّعي عادةً باهظة التكلفة مثل تحميل الصفحة بالكامل.
إيجاد التوازن بين التكهّن بشكل مفرط أو غير كافٍ
إنّ مفتاح الاستفادة إلى أقصى حد من Speculation Rules API هو إيجاد التوازن بين التكهّن بشكلٍ مفرط، أي عندما يتم دفع التكاليف بدون داعٍ ولا يتم استخدام التكهّن، والتكهن بشكلٍ متحفظ جدًا، أي بشكلٍ قليل جدًا أو بعد فوات الأوان عندما لا يتم تحقيق فائدة تذكر.
في الحالات التي تكون فيها التكاليف منخفضة (على سبيل المثال، الصفحات الصغيرة التي يتم إنشاؤها بشكل ثابت ويتم تخزينها مؤقتًا في عقد شبكة توصيل المحتوى)، يمكنك استخدام تخمينات أكثر كثافة.
ومع ذلك، بالنسبة إلى الصفحات الأكبر حجمًا والأكثر محتوى والتي قد لا يمكن تخزينها مؤقتًا في شبكة توصيل المحتوى (CDN)، يجب توخّي المزيد من الحذر. وبالمثل، يمكن أن تستهلك الصفحات التي تتطلّب موارد كثيرة معدل نقل البيانات في الشبكة أو طاقة المعالجة، ما قد يؤثّر سلبًا في الصفحة الحالية. يهدف واجهة برمجة التطبيقات إلى تحسين الأداء، لذا فإنّ التراجع في الأداء ليس ما نريد بالتأكيد. وهذا سبب آخر لحصر عمليات التقديم المُسبَق بصفحة واحدة أو صفحتَين كحد أقصى (يُرجى العلم أيضًا أنّ Chrome يحدّ من عمليات التقديم المُسبَق بصفحتَين أو عشر عمليات في المرة الواحدة استنادًا إلى مدى سرعة التحميل).
خطوات تنفيذ قواعد التوقّع
بعد تحديد كيفية تنفيذ قواعد التوقّعات، عليك بعد ذلك التخطيط لما يجب توقّعه وكيفية طرح ذلك. قد تتمكّن المواقع الإلكترونية البسيطة، مثل المدونات الشخصية الثابتة، من الانتقال مباشرةً إلى العرض المُسبَق الكامل لصفحات معيّنة، ولكن هناك تعقيدات إضافية يجب مراعاتها في المواقع الإلكترونية الأكثر تعقيدًا.
البدء بميزة "التحميل المُسبَق"
إنّ ميزة "التحميل المُسبَق" آمنة نسبيًا في معظم المواقع الإلكترونية، وهذا هو النهج الأولي الذي يتّبعه الكثيرون، بما في ذلك عمليات الطرح على نطاق واسع مثل Cloudflare وWordPress.
إنّ المشاكل الرئيسية التي يجب الانتباه إليها هي أنّه إذا كانت عملية التحميل المُسبَق لعنوان URL ستؤدي إلى أي تغييرات في الحالة وتكاليف من جهة الخادم، لا سيما للصفحات التي لا يمكن تخزينها مؤقتًا. من المفترض ألا يتم تنفيذ تغييرات الحالة، مثل التحميل المُسبَق لصفحة /logout، كروابط GET، ولكن للأسف، هذا الإجراء شائع على الويب.
يمكن استبعاد عناوين URL هذه تحديدًا من القواعد:
<script type="speculationrules">
{
"prefetch": [{
"where": {
"and": [
{ "href_matches": "/*" },
{ "not": {"href_matches": "/logout"}}
]
},
"eagerness": "moderate"
}]
}
</script>
يمكن أن تقتصر عمليات التحميل المُسبَق على عمليات التنقّل الشائعة من صفحة إلى أخرى، أو على جميع الروابط من المصدر نفسه عند التمرير فوقها أو النقر عليها باستخدام الإعداد moderate أو conservative eagerness. يمثّل الإعداد conservative أدنى مخاطر، ولكنه يمثّل أيضًا أدنى عائد محتمل. إذا كنت تبدأ من هذه النقطة، اهدف إلى الانتقال إلى moderate على الأقل، ولكن من الأفضل الانتقال إلى eager للحصول على مزيد من مزايا الأداء (ثم الترقية إلى prerender إذا كان ذلك منطقيًا).
عمليات التقديم المُسبَق ذات المخاطر المنخفضة
من الأسهل نشر عمليات الجلب المُسبَق المستندة إلى التوقّعات، ولكنّ الاستفادة القصوى من الأداء في واجهة برمجة التطبيقات هي من خلال العرض المُسبَق. يمكن أن يكون لهذا الإجراء بعض الاعتبارات الإضافية عندما لا تتم زيارة الصفحة بعد فترة قصيرة من التكهّن (سنتناول ذلك في القسم التالي)، ولكن مع العرض المُسبَق moderate أو conservative، حيث يُحتمَل أن يحدث التنقّل بعد ذلك بوقت قصير، قد تكون الخطوة التالية ذات مخاطر منخفضة نسبيًا.
<script type="speculationrules">
{
"prerender": [{
"where": {
"and": [
{ "href_matches": "/*" },
{ "not": {"href_matches": "/logout"}}
]
},
"eagerness": "moderate"
}]
}
</script>
ميزة "التحميل المُسبَق" للصفحات الشائعة لتحسين عمليات التقديم المُسبَق غير المُلحّة
من الأساليب الشائعة هي بدء تحميل عدد صغير من الصفحات التالية التي تتم زيارتها بشكل متكرر عند التحميل باستخدام الإعداد eager (إما عن طريق تحديدها في قائمة عناوين URL أو باستخدام selector_matches)، ثم بدء العرض المُسبَق باستخدام الإعداد moderate. وبما أنّه من المرجّح أن تكتمل عملية التحميل المُسبَق لصفحات HTML بحلول الوقت الذي يتم فيه تمرير مؤشر الماوس فوق الرابط، فإنّ ذلك يمنح سرعة أكبر من مجرد المعالجة المُسبَقة عند التمرير بدون تحميل مُسبَق.
<script type="speculationrules">
{
"prefetch": [{
"urls": ["next.html", "next2.html"],
"eagerness": "eager"
}],
"prerender": [{
"where": {
"and": [
{ "href_matches": "/*" },
{ "not": {"href_matches": "/logout"}}
]
},
"eagerness": "moderate"
}]
}
</script>
عمليات التقديم المُسبَق السابقة
على الرغم من أنّ قواعد مستندات moderate تسمح باستخدام واجهة برمجة التطبيقات بمخاطر منخفضة نسبيًا مع سهولة التنفيذ المرتبطة بها، إلا أنّ هذا الوقت غالبًا ما لا يكون كافيًا لإجراء عملية التقديم المُسبَق بالكامل. لتحقيق عمليات التنقّل الفورية التي تسمح بها واجهة برمجة التطبيقات هذه، من المحتمل أن تحتاج إلى تحسين الأداء بشكل أكبر من خلال تحسين سرعة عرض الصفحات.
ويتمّ ذلك باستخدام قائمة ثابتة من عناوين URL (مثل مثال الترجيع المُسبَق سابقًا) أو باستخدام selector_matches لتحديد عدد صغير من عناوين URL (صفحة واحدة أو صفحتَين على الأكثر)، مع قواعد المستندات التي تغطي عناوين URL الأخرى:
<script type="speculationrules">
{
"prerender": [
{
"where": {
"selector_matches": : ".prerender"
},
"eagerness": "eager",
},
{
"where": {
"and": [
{ "href_matches": "/*" },
{ "not": {"href_matches": "/logout"}}
]
},
"eagerness": "moderate"
}
]
}
</script>
وقد يتطلّب ذلك تحليل حركة المرور لتوفير أفضل فرصة لتوقع التنقّل التالي بدقة. يمكن أن يساعدك أيضًا فهم تجارب العملاء المعتادة على موقعك الإلكتروني في تحديد العناصر المناسبة للتحميل التوقّعي.
قد يؤدي الانتقال إلى ميزة التقديم المُسبَق بشكل أسرع إلى ظهور المزيد من الاعتبارات حول الإحصاءات والإعلانات وJavaScript والحاجة إلى تحديث الصفحة التي تمّ تقديمها مسبقًا، أو حتى إلغاء أو إعادة تحميل التوقّعات عند تغيير الحالة.
"إحصاءات Google" والإعلانات وJavaScript
عند استخدام ميزة "العرض المُسبَق"، يجب أن تأخذ المواقع الإلكترونية الأكثر تعقيدًا أيضًا في الاعتبار تأثيرها في الإحصاءات. لا تريد عادةً تسجيل مشاهدة صفحة (أو إعلان) عندما تكون الصفحة متوقّعة، ولا تريد تسجيلها إلا عند تفعيل التوقّعات.
يتيح بعض مقدّمي خدمات الإحصاءات (مثل "إحصاءات Google") ومقدّمي خدمات الإعلانات (مثل علامة الناشر من Google) قواعد التكهّن حاليًا، ولن يسجّلوا المشاهدات إلى أن يتم تفعيل الصفحة. ومع ذلك، قد تحتاج إلى مزيد من العناية في ما يتعلّق بمقدّمي الخدمة الآخرين أو الإحصاءات المخصّصة التي نفّذتها.
يمكنك إضافة عمليات تحقّق إلى JavaScript لمنع تنفيذ أجزاء معيّنة من الرمز البرمجي إلى أن يتم تفعيل الصفحات أو إظهارها، وحتى تضمين عناصر <script> بأكملها في عمليات التحقّق هذه. في حال كانت الصفحات تستخدم أدوات إدارة العلامات لإدراج هذه النصوص البرمجية، قد يكون من الممكن معالجة هذه المشكلة دفعة واحدة من خلال تأخير النص البرمجي الخاص بأداة إدارة العلامات نفسها.
وبالمثل، توفّر منصّات إدارة الموافقة فرصة لتأخير النصوص البرمجية التابعة لجهات خارجية إلى حين تفعيلها، وقد عملت Google مع منصّات مختلفة لإدارة الموافقة لجعلها على دراية بالعرض المُسبَق، ويسعدنا مساعدة الآخرين الذين يريدون إجراء ذلك أيضًا. PubTech هي إحدى هذه الشركات التي توفّر للمطوّرين خيار تشغيل JavaScript أو حظره أثناء العرض المُسبَق.
بالنسبة إلى رمز التطبيق، يمكنك إضافة تغيير مماثل لتأخير تنفيذ الرمز إلى أن يتم التفعيل، خاصةً عندما لا تتطلّب الصفحة عرض رمز JavaScript. هذا الخيار أسرع وأكثر أمانًا، ولكنه يعني أنّه سيتم تشغيل كل الرمز البرمجي في آنٍ واحد عند التفعيل. ويمكن أن يؤدي ذلك إلى بذل الكثير من الجهد في وقت التفعيل، ما قد يؤثر في INP، خاصةً أنّ الصفحة قد تبدو محمَّلة بالكامل ومستعدة للتفاعل معها.
بالإضافة إلى ذلك، إذا كان أي محتوى يعتمد على JavaScript (مثل المحتوى المعروض من جهة العميل)، سيؤدي تأخير ذلك إلى تقليل التأثير الإيجابي على LCP وCLS الذي يمكن أن يحقّقه العرض المُسبَق. سيؤدي اتّباع نهج أكثر استهدافًا للسماح بتشغيل المزيد من JavaScript أثناء مرحلة التقديم المُسبَق إلى تجربة أفضل، ولكن قد يكون من الصعب تنفيذه.
يمكن أن يكون البدء بتأخير الكثير من علامات النصوص البرمجية تمامًا استراتيجية جيدة للمواقع الإلكترونية الأكثر تعقيدًا في البداية. ومع ذلك، للاستفادة إلى أقصى حد من واجهة برمجة التطبيقات، يجب أن يكون الهدف النهائي هو السماح بتشغيل أكبر قدر ممكن من JavaScript أثناء التقديم المُسبَق.
قد تحتاج المواقع الإلكترونية التي تواجه مشاكل في الإحصاءات أو الإعلانات إلى البدء بميزة "التحميل المُسبَق"، حيث تكون هذه المشاكل أقلّ أهمية، بينما تفكر في الإجراءات التي يجب اتّخاذها لتفعيل ميزة "العرض المُسبَق".
تعديل التكهّنات المتعلّقة بالعرض المُسبَق
عند عرض الصفحات مسبقًا قبل الانتقال إليها، هناك خطر أن تصبح الصفحة المعروضة مسبقًا قديمة. على سبيل المثال، قد تتضمّن صفحة معروضة مسبقًا في موقع للتجارة الإلكترونية سلة تسوّق، إما سلة كاملة من السلع أو حتى عداد يعرض عدد السلع في السلة على صفحات أخرى. في حال إضافة المزيد من السلع إلى سلة التسوّق ثم الانتقال إلى صفحة تم عرضها مسبقًا، سيشعر المستخدم بالحيرة عند رؤية حالة الدفع القديمة.
هذه المشكلة ليست جديدة، ويواجه المستخدمون المشكلة نفسها عندما تكون لديهم علامات تبويب متعددة مفتوحة في المتصفّح. ومع ذلك، في ما يتعلّق بالصفحات التي تمّ عرضها مسبقًا، يكون حدوث ذلك أكثر احتمالًا وغير متوقّع لأنّ المستخدم لم يبدأ العرض المُسبَق عن قصد.
Broadcast Channel API هي إحدى الطرق التي تتيح لصفحة واحدة في المتصفّح بث آخر الأخبار إلى صفحات أخرى. سيؤدي ذلك أيضًا إلى حلّ مشكلة علامات التبويب المتعددة. يمكن للصفحات التي تمّ عرضها مسبقًا الاستماع إلى رسالة البث، ولكن لا يمكنها إرسال رسائل البث الخاصة بها إلى أن يتم تفعيلها.
بدلاً من ذلك، يمكن للصفحات التي تم عرضها مسبقًا الحصول على تعديلات باستخدام الخادم (باستخدام fetch() دوري أو اتصال WebSocket)، ولكن مع احتمال حدوث تأخيرات في التحديثات.
إلغاء أو إعادة تحميل التخمينات المتعلّقة بالعرض المُسبَق
يُنصح بتعديل الصفحات المعروضة مسبقًا لمواصلة استخدامها مع تجنُّب حدوث أيّ ارتباك للمستخدمين. وفي حال عدم توفّر هذا الخيار، يمكنك إلغاء التكهّنات.
ويمكن أيضًا استخدام هذه الميزة للبقاء ضمن حدود Chrome إذا أرادت المواقع الإلكترونية عرض صفحات أخرى مسبقًا يُرجَّح زيارتها.
لإلغاء التوقّعات، عليك إزالة قواعد التوقّعات من الصفحة أو إزالة الصفوف أو معايير المطابقة الأخرى في حال استخدام هذا النهج. بدلاً من ذلك، يمكن للصفحة التي تم التكهّن بها الاتصال بـ window.close() إذا رصدت أنّها لم تعُد حديثة. ومع ذلك، إذا كانت الصفحة قادرة على رصد ذلك، سيكون الخيار الأفضل هو تعديل حالتها لإعادة عرض آخر المعلومات.
من الممكن أيضًا إعادة إدراج هذه القواعد (أو معايير المطابقة) حتى يمكن إعادة عرض الصفحات مسبقًا (على الرغم من أنّ إبقاء الصفحة الحالية محدّثة هو الخيار الأفضل عادةً لأنّه أقل استهلاكًا للموارد). بعد إزالة قواعد التكهّنات، يجب إكمال عملية إعادة الإدراج في مهمة ميكرو جديدة أو لاحقًا، للسماح للمتصفّح بملاحظة عمليات الإزالة وإلغاء التكهّنات. في المثال التالي، يتم عرض إحدى الطرق لحذف جميع نصوص قواعد التوقّعات وإزالتها:
async function refreshSpeculations() {
const speculationScripts = document.querySelectorAll('script[type="speculationrules"]');
for (const speculationScript of speculationScripts) {
// Get the current rules as JSON text
const ruleSet = speculationScript.textContent;
// Remove the existing script to reset prerendering
speculationScript.remove();
// Await for a microtask before re-inserting.
await Promise.resolve();
// Reinsert rule in a new speculation rules script
const newScript = document.createElement('script');
newScript.type = 'speculationrules';
newScript.textContent = ruleSet;
console.log(newScript);
// Append the new script back to the document
document.body.appendChild(newScript);
}
}
ستؤدي إزالة القواعد إلى إلغاء الطلبات الحالية (أو عمليات التحميل المُسبَق)، ولكن ستؤدي إعادة إدراج القواعد إلى التكهّن بالقواعد الفورية أو السريعة فقط (بما في ذلك قواعد قائمة عناوين URL التي تستخدم الإعداد التلقائي "فوري"). ومع ذلك، ستتم إزالة التكهّنات المعتدلة أو المحافظة، ولكن لن تتم إعادة تشغيلها تلقائيًا إلى أن يتم التفاعل مع الرابط مرة أخرى.
لا يقتصر خيار إعادة التحميل هذا على القواعد التي تم إدراجها باستخدام JavaScript. يمكن أيضًا إزالة القواعد الثابتة المضمّنة في HTML أو تغييرها بالطريقة نفسها، لأنّ هذا تغيير عادي في DOM. لا يمكن إزالة قواعد التخمين في HTTP، ولكن يمكن إزالة معايير المطابقة (مثل فئات prerender) وإعادة إضافتها باستخدام JavaScript.
ينظر فريق Chrome أيضًا في إضافة علامة Clear-Site-Header للسماح لردود الخادم بإلغاء عمليات العرض المُسبَق (على سبيل المثال، عند تقديم طلب تحديث سلة التسوّق).
قياس التأثير
بعد تنفيذ قواعد التكهّن، عليك قياس مدى النجاح وعدم الافتراض فقط أنّه سيكون أسرع تلقائيًا. كما ذكرنا سابقًا، يمكن أن تؤدي التكهّنات الزائدة إلى تراجع الأداء إذا كان العميل أو الخادم مشغولَين بشكلٍ زائد.
عند التنفيذ من خلال خطوات متعدّدة (التحميل المُسبَق، والعروض المُسبَقة ذات الخطورة المنخفضة، ثم العروض المُسبَقة المبكّرة)، يجب إجراء القياس مع كل خطوة.
كيفية قياس النجاح
من المفترض أن يكون لقواعد التكهّن تأثير إيجابي في مقاييس الأداء الرئيسية، مثل سرعة عرض أكبر محتوى مرئي (LCP) (وربما أيضًا في متغيّرات التصميم التراكمية (CLS) ومدى استجابة الصفحة لتفاعلات المستخدم (INP))، ولكن قد لا يكون هذا التأثير واضحًا في المقاييس العامة على مستوى الموقع الإلكتروني. ويعود ذلك إلى أنّ المواقع الإلكترونية قد تتألف في الغالب من أنواع أخرى من التنقّل (مثل الصفحات المقصودة) أو لأنّ عمليات التنقّل من مصدر واحد تكون سريعة بما يكفي حتى أنّ تحسينها بشكل كبير قد لا يؤثّر في مقاييس الشريحة المئوية التسعون كما هو موضّح في تقرير تجربة مستخدمي Chrome (CrUX).
يمكنك استخدام أنواع التنقّل في الصفحات في CrUX للتحقّق من النسبة المئوية للتنقّلات التي تُعرَف بالرمزَين navigate_cache أو prerender وما إذا كانت هذه النسبة تزداد بمرور الوقت. ومع ذلك، لإجراء تحليل تفصيلي، قد تحتاج إلى استخدام ميزة "مراقبة المستخدِمين الفعليين" لتقسيم بياناتك إلى عمليات تنقّل متوقّعة لمعرفة مدى سرعتها مقارنةً بعمليات التنقّل الأخرى.
كيفية قياس معدّل الاستخدام والنفايات
ومن الاعتبارات الرئيسية الأخرى قياس ما إذا كنت تستهدف الصفحات الصحيحة. ويؤدي ذلك إلى تجنُّب إهدار الوقت، كما يضمن استهداف أفضل الصفحات للاستفادة من واجهة برمجة التطبيقات هذه.
لا يمكن للصفحة التي تبدأ التوقّعات الاطّلاع مباشرةً على حالة محاولات التوقّعات. بالإضافة إلى ذلك، لا يمكن افتراض أنّه تم بدء المحاولات لأنّ المتصفّح قد يؤجل التكهّنات في ظروف معيّنة. ولذلك، يجب قياس هذه العوامل على الصفحة نفسها. يتطلّب ذلك أيضًا التحقّق من واجهات برمجة تطبيقَين لمعرفة ما إذا كانت الصفحة تُقدّم معلومات متوقّعة أو قدّمت معلومات متوقّعة:
if (document.prerendering) {
console.log("Page is prerendering");
} else if (performance.getEntriesByType("navigation")[0]?.activationStart > 0) {
console.log("Page has already prerendered");
} else {
console.log("This page load was not using prerendering");
}
ويمكن لهذه الصفحة بعد ذلك تسجيل محاولة التوقّع في خوادم الخلفية.
من بين المشاكل المتعلّقة بالإحصاءات، مقدّمو الخدمات (مثل "إحصاءات Google") الذين يدركون العرض المُسبَق ويتجاهلون طلبات الإحصاءات إلى أن يتم تفعيل الصفحة، حتى طلبات الأحداث المنفصلة. لذلك، على مستخدمي "إحصاءات Google" استخدام خيار آخر لتسجيل البيانات من جهة الخادم.
من الممكن أيضًا إجراء ذلك من جهة العميل، حيث تسجِّل كل صفحة معروضة مسبقًا عملية العرض المُسبَق في مساحة التخزين المشتركة، وتقرأ الصفحة المُطلِبة هذه البيانات. يعمل الرمز localStorage بشكل أفضل لأنّه يمكن قراءته عند التنقّل بعيدًا عن الصفحة (يُرجى العِلم أنّه لا يمكن استخدام الرمز sessionStorage لأنّه يُستخدَم لمعالجة الصفحات التي تم عرضها مسبقًا). ومع ذلك، يُرجى العِلم أنّ localStorage غير آمن من حيث المعاملات، وقد تعدّله صفحات أخرى في الوقت نفسه إذا تمّ عرض صفحات متعدّدة مسبقًا. يستخدم هذا العرض التجريبي تجزئة فريدة وإدخالات فردية لتجنّب حدوث مشاكل في هذا الشأن.
الخاتمة
توفّر قواعد التكهّنات إمكانية تحسين أداء صفحتك بشكل كبير. يقدّم هذا الدليل نصائح حول النقاط التي يجب أخذها في الاعتبار عند تنفيذ واجهة برمجة التطبيقات هذه لتجنّب أي مشاكل محتملة، والاستفادة إلى أقصى حدّ من واجهة برمجة التطبيقات.
سيؤدي التخطيط المُسبَق لتنفيذ الإجراء إلى تجنُّب إعادة العمل. ويجب أن يتبع ذلك عملية طرح متعددة الخطوات، خاصةً في المواقع الإلكترونية الأكثر تعقيدًا، بدءًا من التحميل المُسبَق قبل الانتقال إلى التحميل المُسبَق المنخفض الخطورة ثم التحميل المُسبَق المبكر. أخيرًا، من المهم قياس التحسينات وأي استخدام وإهدار لضمان الاستفادة المثلى من واجهة برمجة التطبيقات.