كيف تضع ميزانية أداء لموقع Astro وتحافظ عليها
ضع ميزانية أداء قابلة للقياس لموقع Astro، وحدد حدود الصور وJavaScript والخطوط، ثم اختبر LCP وCLS وINP قبل أن تتراجع السرعة.
حدد سقفاً لكل نوع صفحة، واربطه بالمورد المسؤول وتجربة المستخدم، ثم افحص النسخة المبنية في كل إصدار. الميزانية التي لا توقف التراجع ليست ميزانية.
يعطي Astro موقع المحتوى بداية جيدة: HTML جاهزة، وJavaScript لا تصل إلى المتصفح إلا عندما تطلبها. لكن هذه الميزة قد تختفي تدريجياً بعد إضافة صورة رئيسية ضخمة وثلاثة خطوط وأداة تحليلات ومشغل فيديو ومكونات تفاعلية.
ميزانية الأداء تحول عبارة «نريد الموقع سريعاً» إلى حدود يستطيع الفريق قياسها ومناقشة أي استثناء عليها.
ابدأ من تجربة القارئ لا من رقم عشوائي
لا توجد ميزانية واحدة تصلح لكل المواقع. حدد أولاً جمهورك وأجهزته والصفحات الأكثر زيارة وما يحتاجه القارئ في الشاشة الأولى.
مقال تقني نصي يستطيع الالتزام بحدود أشد من صفحة تحتوي عرضاً مرئياً كبيراً. ويمكن البدء بهذه القيم التجريبية ثم تعديلها بناءً على بيانات الموقع:
| المورد أو المقياس | صفحة مقال | الصفحة الرئيسية |
|---|---|---|
| JavaScript أولي مضغوط | 35 KB | 60 KB |
| صور الشاشة الأولى | 250 KB | 500 KB |
| ملفات الخط الحرجة | ملفان | ملفان |
| CLS | أقل من 0.1 | أقل من 0.1 |
| LCP عند الشريحة 75 | 2.5 ثانية أو أقل | 2.5 ثانية أو أقل |
| INP عند الشريحة 75 | 200ms أو أقل | 200ms أو أقل |
هذه ليست وعوداً تلقائية لمجرد اختيار Astro. إنها نقطة مراجعة. قس النتائج على صفحات حقيقية وعدّل سقف الموارد عندما يثبت القياس أن افتراضك غير واقعي.
حدد عنصر LCP في كل قالب
قد يكون أكبر عنصر ظاهر في المقال هو العنوان، بينما يكون في الرئيسية صورة المقال المميز. افتح Chrome DevTools أو PageSpeed Insights واعرف العنصر الفعلي قبل تحسين شيء آخر.
إذا كانت صورة LCP:
- ضعها في HTML الأولية، لا تجعل JavaScript يضيفها لاحقاً.
- أضف
widthوheightأو نسبة أبعاد ثابتة. - وفر
srcsetوsizesمناسبين لأحجام العرض. - لا تستخدم
loading="lazy"عليها. - استخدم
fetchpriority="high"فقط إذا كانت بالفعل المورد الأهم.
لا تعمل Preload لعدة صور مرشحة؛ كل طلب زائد ينافس CSS والخط والمورد الحقيقي.
احجز المساحة لمنع تحرك الصفحة
تستطيع أدوات الصور في Astro معرفة أبعاد الصور المستوردة. أما الملفات الموضوعة داخل public فتحتاج إلى أبعاد صريحة أو aspect-ratio.
تنطبق القاعدة نفسها على الفيديوهات والتضمينات ونماذج الاشتراك وأي مكون سيظهر بعد تحميل سكربت. يجب أن يعرف المتصفح مساحة العنصر قبل وصوله حتى لا يتحرك النص تحت يد القارئ.
راقب أيضاً الخطوط: استخدام خط بديل قريب في القياسات وfont-display مناسب يقللان تغير التخطيط وتأخر ظهور النص.
احسب كلفة كل Astro Island
لا يحتاج زر تغيير الألوان أو قائمة إفصاح بسيطة إلى React أو Vue. استخدم JavaScript صغيرة عندما تكفي، واترك المقال والروابط وجدول المحتويات HTML ثابتة.
عندما تكون هناك حالة تفاعلية حقيقية، اختر توقيت التحميل وفق الحاجة:
client:visibleلمكون أسفل الشاشة.client:idleلتحسين غير ضروري في أول لحظة.client:mediaلتجربة مرتبطة بحجم شاشة.client:loadفقط عندما يجب أن يستجيب المكون فور ظهور الصفحة.
راجع ملف JavaScript الناتج، لا حجم كود المكون فقط. قد يستورد المكون تبعية كاملة أو ملف أيقونات ضخم من أجل وظيفة صغيرة.
عامل أدوات الطرف الثالث كقرار منتج
أدوات التحليل والدردشة والإعلانات والفيديو قد تستهلك وقتاً على المعالج أكثر من كود الموقع. سجل لكل سكربت:
- من يحتاجه ولماذا.
- الصفحات التي يجب أن يظهر فيها.
- حجم النقل ووقت التنفيذ.
- الاتصالات التي ينشئها.
- أثره في الخصوصية وسياسة الموافقة.
حمّل التضمين الثقيل بعد نقر المستخدم عندما لا يحتاج إلى العمل فوراً. وإذا لم يعد أحد يستخدم بيانات أداة ما، فالحذف تحسين أداء أوضح من تأخيرها نصف ثانية.
ضع فحصاً آلياً داخل الإصدار
اختبر النسخة المبنية لا خادم التطوير:
npm run build
npm run previewيمكن تشغيل Lighthouse CI أو أداة مشابهة على مجموعة صغيرة تمثل القوالب الأساسية. ضع حداً على الحجم وعدد الطلبات ومقاييس المختبر، واجعل التجاوز ظاهراً في مراجعة الكود.
لا تجعل اختباراً واحداً شرطاً هشاً؛ نتائج المختبر تتذبذب. استخدم عدة تشغيلات وحدوداً تمنع التراجع الواضح، واحتفظ بسجل يبين الإصدار الذي زاد الكلفة.
افصل بيانات المختبر عن بيانات المستخدمين
يساعد Lighthouse في تشخيص السبب قبل النشر، بينما توضح بيانات Chrome UX Report أو نظام مراقبة المستخدمين ما حدث فعلاً عبر أجهزة وشبكات متعددة.
إذا تحسن الاختبار اليوم ولم تتحسن Search Console فوراً، فهذا متوقع بسبب نافذة البيانات الميدانية. يشرح الفرق بين PageSpeed Insights وSearch Console كيف تقرأ النوعين من دون خلط.
قس الأداء حسب نوع الصفحة والجهاز. المتوسط العام قد يخفي قالب مقال بطيئاً أو شريحة هواتف ضعيفة. ولا تعتمد على الدرجة الإجمالية وحدها؛ اربط التغيير بعنصر LCP أو مهمة JavaScript أو تحرك تخطيط محدد.
ما القرار عندما تتجاوز الميزة الميزانية؟
لديك أربعة خيارات واضحة:
- تحسين المورد أو تقسيمه.
- تأخير تحميله حتى يحتاجه المستخدم.
- استبداله بحل أقل كلفة.
- قبول الاستثناء وتوثيق سببه ومدته.
الهدف ليس منع كل ميزة، بل جعل كلفتها مرئية قبل أن تصبح جزءاً دائماً من الموقع.
أخطاء شائعة
- قياس الصفحة الرئيسية فقط وتجاهل صفحات المقال.
- ضغط الصور مع بقاء TTFB مرتفعة.
- استخدام Lazy Loading لصورة LCP.
- تحميل الخط بكل أوزانه ولغاته رغم استخدام جزء صغير.
- إضافة Island لكل مكون لأن المشروع يدعمها.
- متابعة Lighthouse Score من دون مراقبة LCP وCLS وINP نفسها.
أسئلة شائعة
هل Astro يضمن نتيجة 100 في Lighthouse؟
لا. يقلل Astro JavaScript الافتراضية، لكن الصور والخطوط والخادم والسكربتات الخارجية وطريقة بناء الصفحة تظل مسؤوليتك.
هل الميزانية هي حدود Core Web Vitals فقط؟
لا. مقاييس المستخدم هي النتيجة، أما حدود الموارد مثل حجم JavaScript والصور وعدد الخطوط فهي إشارات مبكرة تساعدك على منع المشكلة قبل ظهورها في البيانات الميدانية.
متى أرفع الميزانية؟
عندما تحقق الميزة قيمة واضحة، وتثبت أن الخيارات الأقل كلفة غير كافية، ويقبل الفريق أثرها المقاس. لا ترفع الرقم لمجرد أن الإصدار فشل.
مراجع رسمية
لديك سؤال عن هذا الدليل أو فكرة لتعاون تقني؟ تواصل مع بكري عبر المركز التقني.
نهاية الملاحظة.