درجة Lighthouse ليست نتيجة للتحسين، بل هي مرآة تعكس جوهر الهندسة المعمارية

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

ما تشير إليه مقاييس الأداء

Lighthouse يقيس ليس تصنيفات الأدوات أو الأُطُر، بل النتائج الفعلية:

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

هذه المقاييس (TTFB، LCP، CLS) هي رد فعل متسلسل للقرارات التي تم اتخاذها أثناء التنفيذ، وتؤثر بشكل مباشر على كمية الحسابات التي يعالجها المتصفح أثناء التشغيل.

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

معنى جشع JavaScript: المسبب الحقيقي لانخفاض الأداء

هناك مشكلة مشتركة في العديد من المشاريع التي تُراجع، وهي تنفيذ JavaScript.

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

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

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

إزالة عدم اليقين عبر المعالجة أثناء البناء

الإخراج المعاد تصييره مسبقًا يزيل عدة متغيرات من معادلة الأداء:

• لا حاجة لتكلفة التقديم من جانب الخادم عند الطلب
• لا حاجة لتهيئة العميل لعرض المحتوى
• المتصفح يتلقى HTML كاملًا ومتوقعًا

نتيجة لذلك، تتحسن مقاييس مثل TTFB، LCP، CLS بشكل طبيعي. رغم أنها لا تضمن درجات مثالية، إلا أنها تقلل بشكل كبير من احتمالية الفشل.

دروس من الأمثلة الواقعية

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

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

الأمر المدهش ليس الدرجة الأولية، بل استقرار الأداء مع مرور الوقت:

• عدم انخفاض الدرجة مع نشر محتوى جديد
• عدم ظهور تحذيرات متسلسلة من عناصر تفاعلية صغيرة
• عدم تدهور الخط الأساسي

في هذا البنية، لم تعد درجة Lighthouse هدفًا، بل كانت نتيجة طبيعية.

واقع التوازنات

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

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

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

كيف تتسبب الاستقرار أو الانخفاض في الدرجات

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

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

الاختيار الجوهري

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

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

هذا التغيير لا يتعلق باختيار إطار عمل معين، بل بقرار أين نسمح بالتعقيد.