قواعد التخمين والعرض المسبق: ما تخطئ فيه أدوات التحليل بشأن الصفحات المُجلَبة مسبقًا

الصفحة التي تحمّلت قبل النقرة

تتيح واجهة Speculation Rules API، التي باتت متوفرة على نطاق واسع في متصفحات Chromium، للموقع أن يعلن عن الروابط التي ينبغي للمتصفح جلبها مسبقًا أو عرضها مسبقًا بالكامل قبل التنقل إليها. فعندما يمرّر المستخدم مؤشره أو يُبدي نيّة، يمكن أن تكون الوجهة معروضة بالفعل في علامة تبويب مخفية، ثم يجري استبدالها فورًا. والمكافأة هي زمن Largest Contentful Paint يقارب الصفر عند التفعيل. أما المشكلة، بالنسبة للقياس، فهي أن الصفحة المعروضة مسبقًا تشغّل نصوصك البرمجية قبل أن يقرر أحد زيارتها.

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

ما الذي يحدث فعليًا أثناء العرض المسبق

يُنفَّذ المستند المعروض مسبقًا بشكل طبيعي، ولكن في حالة دورة حياة خاصة. تكون قيمة document.prerendering هي true، ولم يجرِ بعدُ تفعيل الصفحة داخل علامة التبويب المرئية. ويُطلَق حدث prerenderingchange عندما — وفقط عندما — ينتقل المستخدم فعليًا إليها. والعديد من عمليات العرض المسبق لا تُفعَّل على الإطلاق؛ إذ قد يتخلص المتصفح منها.

وهذا مهم لسببين:

1. العدّ. استدعاء sendBeacon الساذج عند حدث DOMContentLoaded سيبلّغ عن مشاهدة صفحة لمستند قد لا يُشاهَد أبدًا.
2. إسناد الأداء. تُعرَّف Core Web Vitals نسبةً إلى التحميل كما يدركه المستخدم. وتراعي مكتبة web-vitals ومواصفات Paint Timing و Event Timing الأساسية العرضَ المسبق عبر القياس ابتداءً من نقطة التفعيل، لا من بداية التنقل الأصلية. والمقياس المُجمَّع دون هذا الإدراك يكون ببساطة خاطئًا.

النمط الصحيح

تمنحك منصة الويب إشارات نظيفة. أرجئ أي قياس إلى أن تصبح الصفحة مرئية بحقّ لشخص:

if (document.prerendering) {
  document.addEventListener('prerenderingchange', recordPageview, { once: true });
} else {
  recordPageview();
}

أما بالنسبة للتوقيت، فإن PerformanceNavigationTiming.activationStart يعطيك الفارق بين بداية التنقل والتفعيل. وينبغي قياس أي طابع زمني للرسم أو التفاعل نسبةً إلى تلك القيمة، مع تثبيت القيم السالبة عند الصفر. وهذا بالضبط ما تفعله مكتبة web-vitals من Google داخليًا، فإن كنت تحسب LCP أو INP بنفسك، فحاكِ هذا المنطق.

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

لماذا يكون هذا أسهل بلا ملفات تعريف ارتباط أو حالة على جانب العميل

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

تتجاوز Monoid هذه الفئة من المشكلات بأكملها. فنحن لا نخزّن شيئًا على الجهاز — لا ملفات تعريف ارتباط، ولا localStorage، ولا بصمة. فلا وجود لجلسة تخمينية يجب إنشاؤها ثم إلغاؤها لاحقًا. القياس إشارة واحدة عديمة الحالة لا نُصدرها إلا حين تصبح الصفحة حقيقية. ولأن التجميع يجري على حافة Cloudflare، تحدث المُجمَّعات على بيانات تعكس بالفعل عمليات تنقّل حقيقية ومُفعَّلة، لا تخمينات المتصفح المتفائلة.

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

قائمة تحقّق لأدوات تحليل آمنة تجاه العرض المسبق

• اجعل إصدار مشاهدة الصفحة مشروطًا بـ document.prerendering وحدث prerenderingchange.
• احسب LCP و FCP و INP نسبةً إلى activationStart، أو استخدم مكتبة تفعل ذلك بالفعل.
• تعامل مع سجلات طلبات الخادم كمجموعة أوسع من الزيارات الحقيقية، لا كبديل عنها.
• تأكد من أن سياسة Content-Security-Policy لديك تسمح بالوصول إلى نقطة نهاية القياس من مستند مُفعَّل؛ واختبر ذلك في لوحة العرض المسبق في Chrome DevTools.
• تجنّب أي كتابات تخمينية إلى تخزين الجهاز — فأنظف طريقة للتوافق مع العرض المسبق هي ألّا تحتفظ بأي حالة على جانب العميل إطلاقًا.

النقطة الأشمل

إن كل بدائية أداء جديدة — bfcache، والتنقلات الناعمة، والآن قواعد التخمين — تكسر بهدوء الافتراض القديم بأن تحميل الصفحة يعادل زيارة بشرية. أما أدوات التحليل التي تعتمد على ملفات تعريف الارتباط والجلسات القائمة على الحالة، فعليها أن تُضيف المزيد والمزيد من منطق التوفيق. في حين أن أدوات التحليل التي تقيس حدثًا عديم الحالة في لحظة الظهور الحقيقي لا تحتاج إلا إلى احترام أحداث دورة حياة المنصة. الصفحات الأسرع والأرقام الأمينة ليستا في تعارض؛ عليك فقط أن تعدّ في اللحظة الصحيحة.

Sources

• Speculation Rules API — MDN Web Docs
• Prerender pages in Chrome for instant page navigations — Chrome for Developers
• PerformanceNavigationTiming.activationStart — MDN Web Docs
• web-vitals library: prerender and bfcache handling — GitHub