تخيل أن زائرًا يدخل إلى متجرك، ويتصفح الصفحة الرئيسية، ثم يمرر مؤشر الفأرة فوق أحد المنتجات.

قبل أن يضغط الزائر على المنتج، يكون المتصفح قد بدأ بالفعل في تجهيز الصفحة.

وعندما يضغط عليها…

تظهر الصفحة بسرعة تكاد تجعله يشعر أنها كانت مفتوحة أصلًا.

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

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

ما الفكرة ببساطة؟

في الموقع التقليدي يحدث شيء قريب من الآتي:

الزائر → يضغط على الرابط → المتصفح يطلب الصفحة → الخادم يعالج الطلب → تصل الصفحة → يبدأ المتصفح في عرضها

أما مع التحميل التنبؤي، فيمكن أن يصبح السيناريو:

الزائر → المتصفح يتوقع الصفحة التالية → يبدأ تجهيزها → الزائر يضغط → تظهر الصفحة بسرعة كبيرة

وهنا يتحول السؤال من:

كيف نجعل الصفحة أسرع بعد الضغط؟

إلى سؤال أكثر إثارة:

هل نستطيع أن نبدأ تحميل الصفحة قبل أن يضغط الزائر؟

والإجابة: نعم، في المتصفحات التي تدعم هذه التقنية.

Prefetch أم Prerender؟

هنا توجد نقطة مهمة جدًا.

Speculation Rules توفر طريقتين رئيسيتين:

1. Prefetch

المتصفح يبدأ في جلب استجابة الصفحة مسبقًا.

وعندما يقرر المستخدم الانتقال إليها، تكون بعض مراحل التحميل قد انتهت بالفعل.

وهو الخيار الأخف والأكثر أمانًا في الحالات العامة.

2. Prerender

وهذه هي الفكرة الأكثر إثارة.

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

ولهذا يمكن أن يبدو الانتقال إلى الصفحة التالية شبه فوري.

لكن هنا أيضًا تظهر المشكلة…

كلما زادت قوة التقنية، زادت مسؤولية استخدامها بطريقة صحيحة.

مثال بسيط

يمكن للمطور إضافة قواعد مثل:

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

الفكرة هنا أن الموقع يخبر المتصفح بأن صفحات المنتجات مرشحة للتحميل المسبق.

لكن لا ينبغي نسخ المثال ووضعه في كل موقع بشكل عشوائي.

فالمتصفح قد يستهلك موارد لتحضير صفحة لن يزورها المستخدم أصلًا.

وهذا يعني استهلاكًا إضافيًا للشبكة والذاكرة والمعالج.

المشكلة التي لا ينتبه إليها كثير من المطورين

لنفترض أن لديك متجرًا إلكترونيًا.

الزائر موجود في صفحة المنتج رقم 1، والمتصفح قرر أن المستخدم قد ينتقل إلى المنتج رقم 2.

بدأ المتصفح في عمل prerender للصفحة.

لكن ماذا لو كانت الصفحة تقوم عند تحميلها بتشغيل JavaScript يرسل:

“تمت مشاهدة المنتج”

إلى نظام الإحصائيات؟

قد تسجل مشاهدة للمنتج رقم 2 رغم أن المستخدم لم يشاهده فعليًا.

وماذا لو كانت الصفحة تقوم بعملية أخرى عند تحميلها؟

مثل:

• تعديل بيانات المستخدم.
• تغيير حالة معينة.
• إرسال حدث تحليلي.
• تعديل Local Storage.
• تنفيذ طلب إلى الخادم.
• تغيير محتويات السلة.

هنا يمكن أن تصبح ميزة السرعة مصدرًا لمشكلة حقيقية.

ولهذا توصي وثائق Chrome بالانتباه إلى التحليلات والـJavaScript والعمليات التي تحدث أثناء prerender، وعدم اعتبار الصفحة التي جرى تجهيزها مسبقًا صفحة تمت زيارتها فعليًا.

خطأ خطير في المتاجر الإلكترونية

هناك مثال مهم جدًا:

/logout

إذا كان تسجيل الخروج يتم بمجرد زيارة هذا الرابط باستخدام GET، فإن التحميل المسبق لهذا الرابط قد يؤدي إلى نتيجة غير مرغوبة.

ولهذا يجب ألا تكون الروابط التي تسبب تغييرًا في حالة المستخدم مرشحة للتحميل التنبؤي بهذه الطريقة.

وتذكر وثائق الويب أمثلة مثل تسجيل الخروج وتغيير اللغة كحالات ينبغي الحذر منها عند استخدام prefetch.

وهذه نقطة تستحق أن ينتبه لها كل مطور متجر إلكتروني.

متى تستخدم التقنية؟

يمكن أن تكون مناسبة جدًا للمواقع التي يكون فيها مسار المستخدم واضحًا.

مثلًا:

مقال → مقال آخر

أو:

تصنيف → منتج

أو:

الصفحة الرئيسية → صفحة الخدمات

أو:

صفحة المنتج → صفحة الشراء

كلما زادت احتمالية أن تكون الصفحة التالية معروفة، أصبح التحميل التنبؤي أكثر منطقية.

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

لا تستخدمها لكل شيء

من الأخطاء الشائعة أن يقول المطور:

سأجعل كل روابط الموقع تعمل بـ prerender.

هذه ليست استراتيجية جيدة.

Chrome نفسها توضح أن الإفراط في التنبؤ قد يؤدي إلى تكلفة إضافية على المستخدم من ناحية bandwidth والذاكرة والمعالج، ولذلك توجد مستويات مختلفة من eagerness للتحكم في مقدار التنبؤ.

بمعنى آخر:

لا تحاول أن تتنبأ بكل شيء.

حاول أن تتنبأ بما هو مرجح فقط.

ماذا عن دعم المتصفحات؟

وهذه نقطة مهمة قبل تطبيق التقنية في موقع حقيقي.

Speculation Rules ليست متاحة بالطريقة نفسها في جميع المتصفحات، ولذلك ينبغي التعامل معها باعتبارها تحسينًا تدريجيًا Progressive Enhancement وليس شرطًا أساسيًا لعمل الموقع.

أي أن الموقع يجب أن يعمل بصورة طبيعية بدونها.

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

وإذا لم يكن يدعمها، يستمر الموقع في العمل بالطريقة التقليدية.

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

ماذا يعني هذا لمتجرك الإلكتروني؟

هنا تصبح الفكرة أكثر إثارة.

يمكنك دراسة سلوك المستخدم في المتجر ومعرفة المسارات الأكثر شيوعًا.

مثلًا:

الصفحة الرئيسية → التصنيف → المنتج

إذا كانت نسبة كبيرة من المستخدمين تسلك هذا المسار، يمكن التفكير في استخدام speculation بشكل مدروس.

لكن يجب استبعاد الصفحات الحساسة مثل:

• تسجيل الخروج.
• صفحات تنفيذ العمليات.
• صفحات تغيير البيانات.
• الصفحات التي تحتوي على عمليات شراء أو تعديل حالة.
• الصفحات التي تنفذ JavaScript له آثار جانبية.

والأهم:

اختبر قبل وبعد.

لا تفترض أن التقنية ستجعل الموقع أسرع لمجرد أنك أضفتها.

كيف تعرف أن التجربة نجحت؟

راقب مؤشرات الأداء قبل التطبيق وبعده.

ومن المهم أيضًا معرفة نوع التنقل الذي حدث فعلًا؛ إذ يمكن استخدام بيانات مثل CrUX لمعرفة نسب التنقلات التي تمت عبر prerender أو أنواع التنقل الأخرى.

يمكن أن تكون لديك تجربة مثل:

قبل التقنية:

الضغط على المنتج
↓
انتظار تحميل الصفحة
↓
عرض الصفحة

بعد التقنية:

المستخدم يقترب من الرابط
↓
المتصفح يتوقع الانتقال
↓
يجهز الصفحة
↓
المستخدم يضغط
↓
تظهر الصفحة بسرعة شديدة

الفكرة الأهم

الجيل القادم من تحسين أداء المواقع لا يتعلق فقط بجعل الخادم أسرع.

بل يتعلق أيضًا بجعل المتصفح أذكى في توقع ما سيفعله المستخدم.

بدل أن تنتظر حتى يقول المستخدم:

أريد فتح هذه الصفحة.

يمكن للموقع أن يقول للمتصفح:

هناك احتمال كبير أن هذه هي الصفحة التالية، يمكنك تجهيزها مسبقًا.

لكن الذكاء هنا ليس في تحميل كل شيء.

الذكاء الحقيقي هو معرفة ماذا تحمل، ومتى تحمله، وماذا لا ينبغي أن تحمله أبدًا.

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

الخلاصة

إذا كنت صاحب موقع أو مطورًا، فهناك فرق كبير بين:

موقع سريع

و

موقع يبدو أسرع لأن العمل بدأ قبل أن يطلبه المستخدم.

وهذه الفكرة تفتح بابًا جديدًا في تحسين تجربة المستخدم.

لكنها تحتاج إلى تطبيق حذر، خصوصًا في المتاجر؛ لأن التحميل المسبق ليس مجرد تحميل ملفات، وprerender يمكن أن يؤدي إلى تشغيل JavaScript وتحميل موارد وإجراء عمليات قبل أن تصبح الصفحة مرئية للمستخدم.

لذلك اجعل القاعدة:

تنبأ بما سيحدث، ولكن لا تفترض أن توقعك صحيح دائمًا.

وهنا يكمن الفرق بين استخدام التقنية بذكاء واستخدامها بطريقة تضر الموقع بدلًا من تحسينه.