دليل عملي لاختبار أداء الموقع باستخدام Lighthouse وWindow Performance

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

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

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

لماذا لا يكفي الاعتماد على أداة واحدة

Lighthouse رائع لتقييم سريع لأي URL، لكنه لا يمثل كل سيناريوهات الاستخدام الفعلية. زوارك لا يأتون جميعاً من أجهزة قوية واتصال Wi-Fi ثابت. هناك هواتف متوسطة، وشبكات جوال متذبذبة، وسكربتات خارجية، ولافتات موافقة على الكوكيز، وخطوط ويب قد تؤخر كل شيء.

هنا يبدأ window.performance بإعطائك إجابات أكثر فائدة:

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

هذا هو الفرق بين رقم جميل، وتشخيص يمكن الدفاع عنه.

كيف تستخدم Lighthouse بشكل يفيدك فعلاً

أسهل نقطة بداية هي Chrome DevTools. افتح الصفحة، اضغط F12، ادخل إلى تبويب Lighthouse، اختر Mobile أو Desktop، ثم شغّل الفحص. وإذا كنت تحتاج مقارنة بين الإصدارات أو تريد إدخال الاختبار في CI، فنسخة CLI مناسبة جداً.

قبل ذلك، يمكنك تمرير الصفحة عبر SEO Analyzer للحصول على نظرة أولية سريعة حول مشاكل الأداء وتجربة الجوال قبل النزول إلى التفاصيل.

ما يستحق القراءة فعلاً ليس الرقم العام فقط، بل التفاصيل التي تصنع الفرق:

• JavaScript غير مستخدم
• موارد تحجب الرسم
• صور ثقيلة في الجزء الأول من الصفحة
• سكربتات خارجية ترفع TBT بلا داعٍ

عندها يتحول التقرير من نتيجة شكلية إلى قائمة أولويات واضحة.

ما المقاييس التي يجب أن تبدأ بها

لا تحتاج إلى حفظ كل الاختصارات. في الاستخدام العملي، ابدأ بهذه المقاييس:

1. LCP: متى يظهر المحتوى الرئيسي أمام المستخدم؟
2. INP: ما سرعة استجابة الصفحة للنقر واللمس والتفاعل الحقيقي؟
3. CLS: هل يتحرك التخطيط بشكل مزعج أثناء التحميل؟
4. FCP: متى تنتهي مرحلة الشاشة البيضاء؟
5. TBT: مؤشر مختبري ممتاز لفهم حظر الخيط الرئيسي.

ستجد في بعض الأدلة القديمة تركيزاً كبيراً على TTI أو FID. معرفتها مفيدة من باب السياق، لكن عند ترتيب الأولويات اليوم، غالباً ما تكون LCP وINP وCLS وTBT أكثر عملية.

ماذا يضيف Window Performance API إلى التحليل

في هذه المرحلة تبدأ فعلاً في فهم السبب، لا مجرد ملاحظة العرض.

performance.getEntriesByType('navigation') يعطيك أزمنة التنقل. وresource يكشف الملفات البطيئة. وpaint يساعدك على فهم اللحظة التي بدأ فيها المحتوى المفيد بالظهور. وإذا أردت مراقبة LCP أو CLS أو المهام الطويلة بطريقة حديثة، فالأفضل استخدام PerformanceObserver.

1const nav = performance.getEntriesByType('navigation')[0];
2const resources = performance.getEntriesByType('resource');
3
4console.log('DOMContentLoaded:', nav.domContentLoadedEventEnd);
5console.log('Load event:', nav.loadEventEnd);
6console.log(
7  'Top 5 slowest resources:',
8  resources.sort((a, b) => b.duration - a.duration).slice(0, 5)
9);

1const observer = new PerformanceObserver((list) => {
2  for (const entry of list.getEntries()) {
3    console.log(entry.entryType, entry.startTime, entry.duration || entry.value);
4  }
5});
6
7observer.observe({ type: 'largest-contentful-paint', buffered: true });
8observer.observe({ type: 'layout-shift', buffered: true });
9observer.observe({ type: 'longtask', buffered: true });

إذا كنت تريد قياس INP في بيئة الإنتاج بشكل يمكن الوثوق به، فمن الأفضل ربطه بطبقة RUM أو بتنفيذ من نوع web-vitals بدلاً من الاعتماد على تجميع يدوي مرتجل.

المقارنة بين أكثر من نوع شبكة تكشف الواقع بسرعة. صفحة تبدو "مقبولة" على Wi-Fi قد تصبح ثقيلة جداً بمجرد اختبارها على هاتف واتصال أبطأ.

سير عمل عملي يمكن الاعتماد عليه

لا تحتاج إلى طقوس معقدة. تحتاج فقط إلى ترتيب منطقي:

1. استخدم Lighthouse لتحديد الصفحات الأكثر خطورة وترتيب الأولويات.
2. استخدم window.performance لتحديد سبب البطء بدقة.
3. قارن النتائج بعد ذلك مع بيانات الاستخدام الحقيقي أو Search Console.
4. بعد الإصلاح، أعد القياس في نفس الظروف، لا في ظروف أسهل.

إذا ظهر أن المشكلة الأساسية في حجم الملفات، يمكنك تقليل الحمولة قبل النشر باستخدام JavaScript Compressor وCSS Compressor وHTML Compressor.

الخلاصة

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

Lighthouse يرفع الإشارة الأولى. وWindow Performance يحولها إلى تشخيص حقيقي. وإذا أردت البدء من صورة أوسع قبل الغوص في DevTools، فابدأ بفحص الصفحة عبر SeoSpeedup، ثم انزل بعد ذلك إلى مستوى التوقيتات والقياس داخل المتصفح.