تقييم Lighthouse ليس أداة ضبط، بل هو مرآة تعكس صحة الهندسة المعمارية

لماذا تختلف النتائج على نفس الموقع

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

ما الذي يختبره Lighthouse حقاً

Lighthouse ليس أداة لتقييم جودة الأطر أو الإطارات البرمجية، بل هو أداة لقياس تجربة المستخدم الفعلية من خلال الأرقام.

• سرعة عرض المحتوى على الشاشة
• مدى حجب JavaScript للمسار الرئيسي
• استقرار التخطيط أثناء تحميل الصفحة
• إمكانية الوصول وبنية المستند وقابلية الزحف

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

JavaScript والتفاعل: المسبب الرئيسي لانخفاض الأداء

من خلال العديد من مشاريع التدقيق، يتضح أن تنفيذ JavaScript هو العامل الأكبر الذي يعيق نتائج Lighthouse. هذا ليس مشكلة في جودة الكود، بل هو قيد أساسي في بيئة المتصفح ذات الخيط الواحد.

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

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

الانتاج الثابت يضمن الثبات

تقديم HTML مُعالج مسبقاً يزيل العديد من العوامل من حسابات الأداء:

• عدم وجود تأخير في التقديم من جانب الخادم
• عدم الحاجة لعملية تهيئة من جانب العميل
• استلام المتصفح HTML كامل ومتوقع

وبالتالي، تتحسن مقاييس مثل TTFB، LCP، CLS بشكل تلقائي. التوليد الثابت لا يضمن درجات مثالية، لكنه يقلل بشكل كبير من حالات الفشل.

مثال عملي: ما تعلمته من إعادة بناء مدونة شخصية

عند إعادة بناء المدونة، جربت عدة طرق قياسية. الاعتماد الافتراضي على التهيئة (الهيدريشن) باستخدام React كان مرناً، لكنه كان يسبب مشاكل مع كل إضافة وظيفة جديدة، خاصة فيما يتعلق بوضعية التقديم، واسترجاع البيانات، وحجم الحزمة.

قررت تجربة نهج مختلف، حيث يكون HTML ثابتاً بشكل افتراضي، ويُعامل JavaScript كاستثناء. اخترت Astro لهذا الاختبار لأنه يتوافق مع فرضية القيود الافتراضية التي أردت اختبارها.

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

لا يوجد حل شامل واحد يناسب الجميع

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

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

ما الذي يؤثر على استقرار نتائج Lighthouse

ما تكشفه Lighthouse هو ليس الجهد المبذول، بل الإنتروبيا.

الأنظمة التي تعتمد على الحساب في وقت التشغيل تتراكم فيها التعقيدات مع إضافة وظائف جديدة. أما الأنظمة التي تنقل المعالجة إلى مرحلة البناء، فهي بشكل افتراضي أقل عرضة للتعقيد.

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

الخلاصة: النتائج ليست شيئاً يجب مطاردته، بل شيئاً يجب مراقبته

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

بدمج الأداء كجزء من تصميم النظام، يتحول Lighthouse من مؤشر يجب السعي لتحقيقه إلى أداة لمراقبة صحة النظام. المهم ليس اختيار الإطار الصحيح، بل تحديد أين يمكن تحمل التعقيد.