ما تعنيه حقًا درجة Lighthouse: اختيار الهندسة المعمارية يحدد الاستقرار

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

حجم العمل على المتصفح يؤثر على الأداء

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

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

هذه المقاييس تتخذ قراراتها بناءً على طبقات التحسين، خاصة فيما يتعلق بحجم العمليات التي تتم أثناء التنفيذ على المتصفح.

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

تنفيذ JavaScript هو العامل المعرقل الأكبر

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

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

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

تقليل عدم اليقين من خلال الإخراج الثابت

HTML المُنشأ مسبقًا يزيل عدة متغيرات من معادلة الأداء:

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

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

مثال على التنفيذ: الانتقال من React

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

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

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

واقع المقايضات

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

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

الجذور وراء استقرار الدرجات والهشاشة

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

الخلاصة: الاستقرار ينبع من الهندسة المعمارية

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

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