درجة Lighthouse 90+: كيف أحسّن كل مشروع React للأداء

مقدمة

درجة Lighthouse ليست رقمًا للتفاخر.

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

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

هذا الدليل يشرح طريقتي العملية كما أطبقها في مشاريع React قبل الإطلاق.

1. افهم ماذا يقيس Lighthouse فعليًا

Lighthouse يقيس خمس فئات:

Performance — سرعة التحميل وجاهزية الصفحة
Accessibility — الوصول عبر لوحة المفاتيح وقارئات الشاشة والتباين والدلالة الدلالية
Best Practices — HTTPS، APIs غير مهجورة، أخطاء Console، نسب الصور الصحيحة
SEO — قابلية الزحف والفهم لمحركات البحث
PWA — توافق مع متطلبات تطبيقات الويب التقدمية

أهم مقاييس الأداء: LCP (25%)، TBT (30%)، CLS (15%)، FCP (10%)، SI (10%).

TBT هو الأكثر وزنًا، لذلك تقليل JavaScript الذي يحجب الـ main thread هو أقوى تحسين ممكن.

2. سير عمل التدقيق (Audit)

لا تدقق في وضع التطوير. دائمًا استخدم build إنتاجي:

npm run build
npm run preview

شغّل Lighthouse في وضع incognito ثلاث مرات وخذ النتيجة الوسيطة.

أضف Lighthouse CI:

npm install -D @lhci/cli

module.exports = {
  ci: {
    collect: { staticDistDir: './dist', numberOfRuns: 3 },
    assert: {
      assertions: {
        'categories:performance': ['error', { minScore: 0.9 }],
        'categories:accessibility': ['error', { minScore: 0.9 }],
        'categories:best-practices': ['error', { minScore: 0.9 }],
        'categories:seo': ['error', { minScore: 0.9 }]
      }
    }
  }
};

3. تحسين حزمة JavaScript — أعلى تأثير

حلّل الحزمة أولًا:

npm install -D rollup-plugin-visualizer

ثم فعّل visualizer في vite.config.js، وراقب الوحدات الثقيلة.

طبّق manual chunk splitting للمكتبات الأساسية (React، Router، i18n، Framer Motion...).

استبدل المكتبات الثقيلة ببدائل أخف، واستورد الوظائف بشكل انتقائي بدل استيراد الحزمة كاملة.

4. تقسيم الكود حسب المسارات

كل صفحة يجب أن تُحمّل عند الحاجة فقط عبر lazy وSuspense. زائر الصفحة الرئيسية لا يجب أن يحمل كود صفحات لا يحتاجها فورًا.

5. تحسين الصور — عامل LCP

غالبًا LCP يتحدد عبر صورة الـ hero.

حوّل الصور إلى WebP/AVIF، واستخدم srcset responsive، وامنح صورة الـ hero أولوية تحميل عالية.

ضع width وheight لكل صورة لتقليل CLS، واستخدم loading="lazy" للصور أسفل الصفحة.

6. تحسين الخطوط

<link rel="preconnect" href="https://fonts.googleapis.com" />
<link rel="preconnect" href="https://fonts.gstatic.com" crossorigin />

استخدم display=swap، واضبط fallback بخاصية size-adjust لتقليل تغيّر التخطيط عند تحميل الخط الحقيقي.

7. إزالة CLS

المصادر الأكثر شيوعًا: صور بلا أبعاد، محتوى يُحقن بعد التحميل، خطوط ويب، تضمينات بلا أبعاد، وحركات تغيّر خصائص layout.

استخدم الحركات على transform وopacity بدل height/margin/padding.

8. إمكانية الوصول — الدرجة التي يتجاهلها كثيرون

درجة Accessibility أقل من 90 تعني أن أشخاصًا حقيقيين لا يستطيعون استخدام الموقع بشكل صحيح.

الحد الأدنى: alt text مناسب، labels للحقول، تباين WCAG AA، تنقل كامل بلوحة المفاتيح، ARIA لأزرار الأيقونات، ورابط “تخطي إلى المحتوى”.

9. SEO في React

إذا لم تستخدم SSR كاملًا، فعلى الأقل قم بعمل prerender للمسارات المهمة، واضبط metas لكل صفحة (title/description/OG/Twitter/canonical).

أضف Structured Data (JSON-LD) خصوصًا في مشاريع الأعمال المحلية.

10. قائمة ما قبل الإطلاق

تحليل الحزمة والتأكد من عدم وجود تبعيات ضخمة غير ضرورية
تحميل صورة hero بأولوية عالية
ضبط أبعاد الصور وخصائص التحميل الصحيحة
تفعيل route code splitting وvendor chunking
تحسين الخطوط (swap + preconnect + fallback)
مراجعة كاملة لإمكانية الوصول
مراجعة SEO شاملة (Meta، OG/Twitter، Structured Data، Canonical، Sitemap)
تشغيل Lighthouse ثلاث مرات وأخذ النتيجة الوسيطة فوق 90

الخاتمة

تحقيق 90+ في Lighthouse ليس صدفة. هو نتيجة قرارات دقيقة ومستمرة في البنية والصور والخطوط والوصول وSEO.

الفارق بين مطور “يسلّم” ومطور “يسلّم بجودة أداء عالية” هو الالتزام بهذه المعايير في كل مشروع.

في Dywan Dev، 90+ عبر Lighthouse هو معيار أساسي. الأداء وإمكانية الوصول وSEO ليست إضافات اختيارية. إذا أردت منتج ويب بهذه المعايير، لنبنيه معًا.