لفترة طويلة، افترضت أن درجات Lighthouse العالية كانت في الغالب نتيجة للضبط. ضغط الصور، تأجيل البرامج النصية، إصلاح تحولات التخطيط، تعديل السمات، تبديل المكونات الإضافية، وتكرار الدورة في كل مرة يظهر فيها تحذير جديد.
مع مرور الوقت، توقف هذا الافتراض عن مطابقة ما كنت أراه في الممارسة العملية.
المواقع التي حققت نتائج جيدة باستمرار لم تكن تلك التي بذلت أكبر جهد في التحسين. بل كانت تلك التي كان على المتصفح فيها ببساطة عمل أقل للقيام به.
في تلك المرحلة، توقف Lighthouse عن الشعور وكأنه أداة تحسين وبدأ يبدو وكأنه إشارة تشخيصية للخيارات المعمارية.
لا يقيّم Lighthouse الأطر أو الأدوات. بل يقيّم النتائج.
مدى سرعة ظهور المحتوى ذي المعنى.
مقدار حجب JavaScript للخيط الرئيسي.
مدى استقرار التخطيط أثناء التحميل.
مدى سهولة الوصول والزحف إلى هيكل المستند.
هذه النتائج هي تأثيرات لاحقة للقرارات المتخذة في وقت سابق من المجموعة. على وجه الخصوص، تعكس مقدار الحساب المؤجل إلى المتصفح في وقت التشغيل.
عندما تعتمد الصفحة على حزمة كبيرة من جانب العميل لتصبح قابلة للاستخدام، فإن الدرجات الضعيفة ليست مفاجئة. عندما تكون الصفحة في الغالب HTML ثابتًا مع منطق محدود من جانب العميل، يصبح الأداء أكثر قابلية للتنبؤ.
عبر عمليات التدقيق التي أجريتها والمشاريع التي عملت عليها، يعد تنفيذ JavaScript المصدر الأكثر شيوعًا لتراجع Lighthouse.
هذا ليس لأن الكود منخفض الجودة. بل لأن JavaScript يتنافس على بيئة تنفيذ أحادية الخيط أثناء تحميل الصفحة.
أوقات تشغيل الإطار، منطق الترطيب، رسوم التبعية، وتهيئة الحالة كلها تستهلك وقتًا قبل أن تصبح الصفحة تفاعلية. حتى الميزات التفاعلية الصغيرة غالبًا ما تتطلب حزمًا كبيرة بشكل غير متناسب.
الهياكل المعمارية التي تفترض JavaScript افتراضيًا تتطلب جهدًا مستمرًا للحفاظ على الأداء تحت السيطرة. الهياكل المعمارية التي تعامل JavaScript كخيار صريح تميل إلى إنتاج نتائج أكثر استقرارًا.
يزيل الإخراج المعروض مسبقًا عدة متغيرات من معادلة الأداء.
لا توجد تكلفة عرض من جانب الخادم في وقت الطلب.
لا يوجد تمهيد من جانب العميل مطلوب لظهور المحتوى.
يتلقى المتصفح HTML كاملًا قابلاً للتنبؤ.
من منظور Lighthouse، يؤدي هذا إلى تحسين المقاييس مثل TTFB وLCP وCLS دون الحاجة إلى عمل تحسين مستهدف. لا يضمن التوليد الثابت درجات مثالية، لكنه يضيق بشكل كبير نطاق أوضاع الفشل.
قبل إعادة بناء مدونتي الشخصية، استكشفت عدة مناهج شائعة، بما في ذلك إعدادات قائمة على React تعتمد على الترطيب افتراضيًا. كانت مرنة وقادرة، لكن الأداء تطلب اهتمامًا مستمرًا. كل ميزة جديدة قدمت أسئلة حول وضع العرض، وجلب البيانات، وحجم الحزمة.
من باب الفضول، جربت نهجًا مختلفًا افترض HTML ثابتًا أولاً وعامل JavaScript كاستثناء. اخترت Astro لهذه التجربة، لأن قيوده الافتراضية تتماشى مع الأسئلة التي أردت اختبارها.
ما برز لم يكن درجة أولية مذهلة، بل مدى قلة الجهد المطلوب للحفاظ على الأداء بمرور الوقت. نشر محتوى جديد لم يؤدي إلى تراجعات. العناصر التفاعلية الصغيرة لم تتسلسل إلى تحذيرات غير ذات صلة. كان خط الأساس ببساطة أصعب في التآكل.
وثقت عملية البناء والمقايضات المعمارية في ملاحظة تقنية منفصلة أثناء العمل خلال هذه التجربة على مدونة شخصية بدرجة Lighthouse مثالية.
هذا النهج ليس أفضل عالميًا.
الهياكل المعمارية الثابتة أولاً ليست مثالية للتطبيقات الديناميكية والحالة. يمكن أن تعقد السيناريوهات التي تعتمد بشكل كبير على بيانات المستخدم المصادق عليها، أو التحديثات في الوقت الفعلي، أو إدارة الحالة المعقدة من جانب العميل.
الأطر التي تفترض العرض من جانب العميل توفر مزيدًا من المرونة في تلك الحالات، على حساب تعقيد أعلى في وقت التشغيل. النقطة ليست أن نهجًا واحدًا متفوق، بل أن المقايضات تنعكس مباشرة في مقاييس Lighthouse.
ما يظهره Lighthouse ليس الجهد، بل الإنتروبيا.
الأنظمة التي تعتمد على الحساب في وقت التشغيل تتراكم فيها التعقيدات مع إضافة الميزات. الأنظمة التي تقوم بمزيد من العمل في وقت البناء تقيد هذا التعقيد افتراضيًا.
هذا الاختلاف يفسر لماذا تتطلب بعض المواقع عملاً مستمرًا في الأداء بينما تظل مواقع أخرى مستقرة مع الحد الأدنى من التدخل.
نادرًا ما تكون درجات Lighthouse العالية نتيجة لعمليات تحسين عدوانية. عادة ما تنبثق بشكل طبيعي من الهياكل المعمارية التي تقلل ما يجب على المتصفح القيام به عند التحميل الأول.
الأدوات تأتي وتذهب، لكن المبدأ الأساسي يبقى كما هو. عندما يكون الأداء قيدًا افتراضيًا وليس هدفًا، يتوقف Lighthouse عن كونه شيئًا تطارده ويصبح شيئًا تلاحظه.
هذا التحول يتعلق بشكل أقل باختيار الإطار الصحيح وأكثر باختيار المكان الذي يُسمح فيه بوجود التعقيد.


