Navigation Timing: فاتورة مفصلة لانتظار الصفحة

Summary

نشرت W3C أول مسودة عامة لـ Navigation Timing في 26 أكتوبر 2010، وانطلقت من خلل بسيط: ساعة تبدأ داخل شيفرة الصفحة لا ترى الانتظار الذي سبق وصول تلك الشيفرة.
ثبتت توصية 17 ديسمبر 2012 علامات زمنية لبداية الانتقال والبحث عن الاسم والاتصال والاستجابة وتجهيز المستند. بقي قرار جمعها وتحليلها وإصلاح موضع التأخير بيد الموقع.

يصل النزيل إلى بهو الفندق متعباً. انتظر سيارة، وضاع في البحث عن العنوان، ثم وقف عند الباب حتى فُتح. يبدأ موظف الاستقبال توقيته عند ظهور النزيل أمام المكتب، ويسلّمه المفتاح بعد نصف دقيقة، ثم يعلن بفخر سرعة الخدمة. قياسه صحيح؛ لكنه لا يجيب عن سؤال النزيل: لماذا استغرق الوصول كل هذا الوقت؟ هكذا كانت صفحة الويب حين تحاول قياس تحميلها بساعة يبدأها أول برنامج نصي يصل إليها.

في المسودة العامة الأولى بتاريخ 26 أكتوبر 2010، عرضت W3C هذا القصور بمثال مباشر. تسجل شيفرة في رأس الصفحة الوقت، ثم تطرح منه وقت حدث التحميل. غير أنها لا تعرف كم استغرق جلب المستند الذي تحملها صفحته. كان المتصفح قد بحث عن العنوان، وربما أنشأ اتصالاً وانتظر خادماً، قبل أن تتاح للشيفرة فرصة النظر إلى الساعة. أمضى القارئ تلك الثواني فعلاً، بينما اختفت من الحساب.

الحل أن يسأل الموقع من حضر منذ البداية. وضع المتصفح علامة navigationStart عند بدء الانتقال، وعرض علامات أخرى عبر performance.timing. أصبح بوسع الصفحة أن تقارن البداية بنهاية التحميل. ليست المعادلة هي الخبر؛ إنها مجرد طرح. الخبر أن نقطة البدء لم تعد رهينة لحظة تنفيذ شيفرة جاءت متأخرة إلى الحفل.

والفاتورة أكثر من مبلغ إجمالي. يسجل fetchStart بدء الجلب أو فحص ذاكرة التخزين المؤقت. تحيط علامتا domainLookupStart وdomainLookupEnd بالبحث عن اسم النطاق، وconnectStart وconnectEnd بإنشاء الاتصال. ثم تميّز requestStart وresponseStart وresponseEnd بين إرسال الطلب ووصول أول بايت واكتمال وصول المستند. تأتي بعد ذلك مراحل تجهيز المستند، وصيرورته قابلاً للتفاعل، وأحداث DOM والتحميل. يمكن عندئذ طرح سؤال نافع: هل طال البحث عن العنوان، أم الاتصال، أم انتظار الرد، أم عمل الصفحة بعد وصوله؟

مرت الفكرة عبر النص المرشح في 2 يونيو 2011 حتى وصلت إلى توصية W3C في 17 ديسمبر 2012. تبيّن سجلات النشر الأصلية الطريق من مسودة أكتوبر 2010 إلى مراحل الترشيح ثم التوصية. هذا التدرج جزء من القصة: لا تصبح الفاتورة حجة بين فرق العمل إلا بعد الاتفاق على معنى كل خانة فيها.

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

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

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

لم تضع Navigation Timing برنامجاً يجمع النتائج أو يرسلها أو يصلح الصفحة من تلقاء نفسه. منذ المسودة الأولى، تركت W3C جمع البيانات وتخزينها والإبلاغ عنها للتطبيق. وذكرت التوصية أن هذه الواجهة ليست سباقاً عاماً لترتيب المتصفحات. تتأثر زيارة واحدة بالجهاز والشبكة والذاكرة المؤقتة والصفحة. يسلّم المتصفح السجل؛ وعلى صاحب الخدمة اختيار زيارات قابلة للمقارنة وتحديد العمل الذي سيؤدي إلى فرق.

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