تقنية13 سبتمبر 20265 دقائق قراءة

كيف تقرأ تقرير PageSpeed Insights لموقعك؟ دليل عملي بدون ما تكون مبرمجاً

شرح تقرير PageSpeed Insights خطوة بخطوة: الفرق بين بيانات المستخدمين الحقيقية واختبار المختبر، ومعنى LCP و INP و CLS، ووش تطلب من المبرمج لتحسين سرعة موقعك.

⏱️

تحط رابط موقعك في PageSpeed Insights، تطلع لك دائرة حمراء فيها رقم ٤١، وتحت منها قائمة طويلة بمصطلحات إنجليزية. أول ردة فعل: «موقعي خربان». ثاني ردة فعل: ترسل لقطة الشاشة للمبرمج وتقول «صلّحه». كلا الردّين متسرّع. التقرير يقول أشياء أدق بكثير من الرقم الكبير، ولو عرفت تقرأه بتوفّر على نفسك نقاشات طويلة وفلوس على تحسينات ما لها أثر.

القسم الأهم في الأعلى: بيانات المستخدمين الحقيقيين

أعلى التقرير، لو موقعك له زيارات كافية، بتشوف قسماً عن تجربة المستخدمين الفعليين خلال آخر ٢٨ يوماً. هذي أرقام جمعها متصفح كروم من زوّار حقيقيين بأجهزتهم وشبكاتهم. جوجل تعتمد هذي البيانات في تقييم تجربة الصفحة. لو كتب «Passed» أو نجح التقييم هنا، فموقعك في وضع جيد عملياً حتى لو الدائرة تحت ملوّنة بالبرتقالي.

المقاييس الثلاثة بلغة بسيطة

  • LCP — متى ظهر أكبر عنصر في الشاشة (غالباً صورة الواجهة أو العنوان الرئيسي). جوجل تعتبره جيداً إذا كان ٢.٥ ثانية أو أقل.
  • INP — كم ياخذ الموقع عشان يستجيب لما تضغط زراً أو تفتح قائمة. الجيد ٢٠٠ ملي ثانية أو أقل. هذا المقياس حلّ محل FID القديم في ٢٠٢٤.
  • CLS — هل تتحرك العناصر وأنت تقرأ؟ مثل زر ينزل فجأة لأن صورة تحمّلت فوقه فتضغط على شي ثاني. الجيد ٠.١ أو أقل.

الدائرة الملونة: اختبار مختبر، مو حكم نهائي

الرقم الكبير من ١٠٠ يجي من اختبار Lighthouse يُشغَّل مرة وحدة بمحاكاة جوال متوسط على شبكة بطيئة. مفيد جداً لاكتشاف المشاكل، لكنه يتذبذب: شغّله مرتين وبتلاقي فرقاً. لا تطارد ١٠٠؛ طارد مقاييس المستخدمين الحقيقيين الخضراء. وانتبه إن التقرير يعرض تبويبين: الجوال وسطح المكتب. ركّز على الجوال، لأنه غالباً مصدر أغلب زوارك وجوجل تعتمد نسخة الجوال أساساً.

قائمة «الفرص» — وش تسوي فيها

تحت الدائرة فيه اقتراحات مرتبة. ما كلها بنفس الأهمية. هذي أكثرها تكراراً ومعناها:

  • Properly size images / Serve images in next-gen formats: صورك أكبر من اللازم أو بصيغ قديمة. غالباً أسهل وأكبر مكسب.
  • Reduce unused JavaScript: الموقع يحمّل أكواداً ما تُستخدم — إضافات، أدوات تتبع، سكربتات دردشة.
  • Eliminate render-blocking resources: ملفات تمنع الصفحة تظهر لين تتحمّل كلها.
  • Reduce initial server response time: الخادم نفسه بطيء — مشكلة استضافة أو قاعدة بيانات، مو تصميم.
  • Avoid large layout shifts: صور أو إعلانات بدون أبعاد محددة تسبب حركة المحتوى.

طريقة صحيحة لطلب التحسين من المبرمج

  • اختبر ثلاث صفحات مختلفة، مو الرئيسية فقط: صفحة خدمة، صفحة منتج، مقالة.
  • حدّد الهدف بالمقاييس: «أبي LCP و INP و CLS خضراء على الجوال»، مو «أبي ١٠٠».
  • اطلب قياساً قبل وبعد لنفس الصفحات.
  • اسأل عن كل سكربت خارجي: هل نحتاجه فعلاً؟ أدوات التتبع المتراكمة من أكبر أسباب البطء.
  • تذكّر إن بيانات المستخدمين تحتاج أسابيع عشان تعكس التحسين.

لو ما ظهرت بيانات المستخدمين الحقيقيين

المواقع الجديدة أو قليلة الزيارات غالباً ما يظهر لها قسم بيانات المستخدمين، لأن كروم ما جمع عينة كافية. هنا تعتمد على اختبار المختبر، لكن بذكاء: شغّله ثلاث مرات وخذ المتوسط، واختبر في أوقات مختلفة. وافتح Google Search Console لموقعك، ففيه تقرير «مؤشرات أداء الويب الأساسية» يجمع الصفحات المتشابهة ويبين أي مجموعة فيها مشكلة لما تتوفر البيانات. وأخيراً، لا تنسَ الاختبار الأبسط والأصدق: افتح موقعك من جوال متوسط على بيانات الجوال وأنت في مكان تغطيته عادية، وعُدّ بصوت عالٍ لين يصير تقدر تقرأ وتضغط. لو احتجت تعدّ كثيراً، فأنت ما تحتاج تقريراً يقول لك إن فيه مشكلة.

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

جاهز تبدأ مشروعك مع أزهل؟

تواصل معنا الحين، وخلنا نطلّع فكرتك على أرض الواقع.