نتيجة Lighthouse بلغت 89 ولم تكن تراجعًا

مباشرة بعد نشر أول شريحة من عمل التدويل على الإنتاج، عاد اختبار Lighthouse بنتيجة الأداء: 89 — أقل من الحد الصارم ≥90 الذي يفرضه هذا المشروع على نفسه، وانخفاضًا حقيقيًا عن المرجعية 93/100/99 المقاسة في اليوم نفسه، قبل هذا النشر.

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

قراءة التقرير بدلًا من ردة الفعل على الرقم

نتيجة Lighthouse واحدة تمثّل بيانات طلب HTTP واحد فقط، من بداية تشغيل باردة (cold start) واحدة على خدمة serverless، في لحظة واحدة. قبل التعامل مع 89 كحكم نهائي، فتحت التقرير الفعلي ونظرت إلى ما كان يخفض النتيجة بدلًا من الرقم الإجمالي وحده.

أظهر تدقيق server-response-time زمن وصول أول بايت (TTFB) للمستند الرئيسي بلغ 1150 مللي ثانية — أي ما يقارب 15 إلى 20 ضعف قيمة كل اختبار سابق لهذه الصفحة نفسها. انعكس هذا الرقم الواحد على speed-index، الذي هبط إلى 12.7 ثانية (نتيجة 0.03)، لأنه لا شيء في الصفحة يمكن أن يُعرض قبل وصول المستند نفسه.

اختبار الفرضية بدلًا من افتراضها

الفرضية ليست استنتاجًا. أعدت تشغيل Lighthouse ضد الإنتاج مرتين أخريين، بفارق بضع دقائق:

• الاختبار 2: 94/100/100/100 — عاد server-response-time إلى نحو 70 مللي ثانية، مطابقًا تقريبًا للمرجعية السابقة للنشر. عاد speed-index إلى 1.4 ثانية (نتيجة 1).
• الاختبار 3: متسق مع الاختبار 2.

الحزمة (chunk) البالغة 72 كيلوبايت من JS التي يشير إليها تدقيقا bootup-time/mainthread-work-breakdown في كل اختبار لهذا الموقع — دين تقني موجود مسبقًا ومتابَع بالفعل، ولا علاقة له بهذا النشر — كانت متطابقة بايتًا ببايت بين التقرير بنتيجة 89 والتقرير بنتيجة 94. لو كان الكود الجديد قد سبّب تراجعًا فعليًا، لكانت هذه الحزمة (أو حزمة جديدة) ستختلف بين الاختبارين. لم يحدث ذلك.

ما كنت سأفعله بشكل مختلف

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