دليلك لفهم تقرير Google PageSpeed Insights
كيف تقرأ تقرير مؤشرات Google PageSpeed Insights وتحوّله إلى خطة لتحسين أداء موقعك؟
لا يكفي أن تعرف أن موقعك «سريع» أو «بطيء»، بل يجب أن تفهم لماذا حصل على هذه النتيجة ، وما الذي ينبغي تحسينه أولًا. وهنا يأتي دور Google PageSpeed Insights (PSI)، الذي يساعد أصحاب المواقع والمطورين على قياس الأداء وفهم تجربة المستخدم واتخاذ قرارات عملية لتحسين الموقع.
فيما يلي أهم النقاط التي ينبغي معرفتها عند قراءة تقرير PageSpeed Insights.
أولًا: فرّق بين بيانات الميدان وبيانات المختبر
يعرض PageSpeed Insights نوعين رئيسيين من البيانات، ولكل نوع وظيفة مختلفة:
- 1. بيانات الميدان Field Data
تعتمد بيانات الميدان على زيارات حقيقية أجراها مستخدمون فعليون للموقع خلال آخر 28 يومًا. لذلك فهي تعكس تجربة المستخدمين في ظروف متنوعة، مثل اختلاف الأجهزة وسرعات الإنترنت والمواقع الجغرافية.
وتُستخدم هذه البيانات أساسًا للحكم على مؤشرات الويب الحيوية الأساسية Core Web Vitals. وإذا ظهرت عبارة No Data، فهذا يعني غالبًا أن الموقع لا يمتلك عددًا كافيًا من الزيارات خلال الفترة المطلوبة لتكوين تقرير ميداني موثوق.
- 2. بيانات المختبر Lab Data
تظهر هذه البيانات عادة ضمن قسم Diagnose performance issues، وتنتج عن محاكاة تنفذها أداة Lighthouse باستخدام مواصفات محددة للجهاز وموقع جغرافي وسرعة اتصال معينة.
ولهذا السبب قد تختلف نتيجة PageSpeed Insights عن نتيجة الفحص الذي تجريه من متصفحك ، فقد ينفذ PSI الاختبار من خوادم في منطقة جغرافية مختلفة، بينما تجري فحصك من بلد آخر وبسرعة إنترنت مختلفة. ويؤثر هذا الاختلاف خصوصًا في مقاييس مثل Total Blocking Time.
ثانيًا: استخدم Google Search Console عند غياب البيانات الكافية
إذا لم يعرض PageSpeed Insights بيانات ميدانية كافية، فانتقل إلى Google Search Console وافتح قسم Core Web Vitals. يوفر هذا القسم تقريرًا أوسع عن الروابط التي تواجه مشكلات في الأداء، كما يصنفها ضمن ثلاث فئات:
- ضعيف : Poor
- يحتاج الي تحسين : Needs Improvement
- جيد: Good
وبذلك، لا تكتفي بفحص صفحة واحدة، بل تحدد الصفحات المتأثرة بالمشكلة وتتعامل معها وفق الأولوية.
ثالثًا: افهم الفرق بين This URL وOrigin
يمنحك التقرير خيارين مهمين عند مقارنة الأداء:
- (This URL ) يعرض بيانات الصفحة التي تفحصها تحديدًا، مثل الصفحة الرئيسية.
- (Origin ) يعرض متوسط أداء الموقع على مستوى نطاقه وجميع صفحاته.
وقد تبدو الصفحة الرئيسية جيدة، بينما يعكس متوسط الموقع أداءً ضعيفًا. فمثلًا، قد تحقق الصفحة الرئيسية زمن LCP قدره 2.1 ثانية، في حين يصل متوسط الموقع إلى 3.6 ثوانٍ. ويشير هذا الفرق إلى وجود صفحات أخرى تحتاج إلى تحسين عاجل.
رابعًا: تعرّف إلى أهم مقاييس الأداء
FCP : First Contentful Paint
يقيس FCP الوقت الذي يحتاجه المتصفح لعرض أول عنصر مرئي في الصفحة، مثل نص أو زر أو صورة.
ويصنّف التقرير النتيجة على النحو التالي:
- من 0 إلى 1.8 ثانية: جيد.
- أكثر من 1.8 وحتى 3 ثوانٍ: يحتاج إلى تحسين.
- أكثر من 3 ثوانٍ: ضعيف.
كلما ظهر أول محتوى بسرعة، شعر المستخدم بأن الصفحة بدأت في الاستجابة مبكرًا.
LCP : Largest Contentful Paint
يقيس LCP الوقت اللازم لعرض أكبر عنصر مرئي في الجزء الظاهر من الصفحة، مثل صورة رئيسية أو عنوان كبير أو كتلة نصية بارزة.
وتكون المستويات كالتالي:
- من 0 إلى 2.5 ثانية: جيد.
- أكثر من 2.5 وحتى 4 ثوانٍ: يحتاج إلى تحسين.
- أكثر من 4 ثوانٍ: ضعيف.
ويعكس هذا المقياس مدى سرعة ظهور المحتوى الرئيسي الذي ينتظره المستخدم.
CLS : Cumulative Layout Shift
يقيس CLS مدى استقرار تخطيط الصفحة أثناء التحميل. فإذا تحرك زر أو قفز نص أو ظهر إعلان ودفع العناصر إلى الأسفل، واجه المستخدم تجربة مربكة، وقد ينقر على عنصر غير مقصود.
وتصنّف القيم كالتالي:
- من 0 إلى 0.1: جيد.
- أكثر من 0.1 وحتى 0.25: يحتاج إلى تحسين.
- أكثر من 0.25: ضعيف.
لذلك، يجب تثبيت المساحات المخصصة للصور والإعلانات والعناصر الديناميكية قبل تحميلها.
TBT : Total Blocking Time
يقيس TBT إجمالي الوقت الذي يمنع فيه المتصفح المستخدم من التفاعل مع الصفحة بسبب انشغاله بتنفيذ ملفات، وخصوصًا ملفات JavaScript.
وعندما ترتفع قيمة هذا المقياس، يتأخر النقر والكتابة وفتح القوائم؛ لذلك يرتبط مباشرة بمدى استجابة الموقع.
SI : Speed Index
يقيس Speed Index سرعة ظهور محتوى الصفحة بصريًا حتى تكتمل الصورة أمام المستخدم. وكلما ظهرت أجزاء الصفحة بسرعة وبصورة متتابعة، تحسّن مؤشر السرعة.
خامسًا: انتبه إلى انتقال Google من FID إلى INP
ابتداءً من مارس 2024، اعتمد Google مقياس INP — Interaction to Next Paint بدلًا من FID — First Input Delay ضمن مؤشرات تجربة المستخدم.
حيث كان FID يركز على زمن استجابة المتصفح لأول تفاعل فقط. أما INP، فيقيس زمن الاستجابة لمختلف تفاعلات المستخدم طوال فترة وجوده في الصفحة، مثل الضغط على قائمة منسدلة أو زر أو نموذج.
وبالتالي، يقدم INP صورة أدق عن الاستجابة الفعلية للموقع، لأنه لا يحكم على تفاعل واحد فقط، بل يقيّم التفاعلات المتعددة.
سادسًا: كيف تتكوّن نتيجة Lighthouse الإجمالية؟
لا تمثل النتيجة الإجمالية، مثل 29 من 100، مقياسًا واحدًا، بل تجمع نتائج عدة مقاييس وفق أوزان مختلفة في Lighthouse 10:
- TBT: 30%.
- LCP: 25%.
- CLS: 25%.
- FCP: 10%.
- Speed Index: 10%.
ويظهر من ذلك أن TBT يمتلك الوزن الأكبر، لذلك قد يؤدي تقليل وقت تنفيذ JavaScript والملفات التي تعيق التفاعل إلى تحسن واضح في النتيجة النهائية.
سابعًا: حوّل التقرير إلى خطوات عملية
بعد قراءة النتائج، افتح قسم Diagnostics في أسفل التقرير. يقدم هذا القسم توصيات عملية مرتبطة بالمشكلات المكتشفة، مثل:
- تقليل ملفات CSS غير المستخدمة.
- تحسين ملفات JavaScript.
- تقليل الموارد التي تعطل عرض الصفحة.
- تحسين الصور والموارد الكبيرة.
- معالجة أسباب تحرك العناصر أثناء التحميل.
ولا تتعامل مع النتيجة الإجمالية وحدها ، بل ابدأ بالمشكلات التي تؤثر في تجربة المستخدم وفي مؤشرات الويب الحيوية الأساسية، ثم أعد الفحص بعد كل مجموعة من التحسينات.
ثامنًا: نفّذ فحص Lighthouse في وضع التصفح المتخفي
عند إجراء فحص يدوي من متصفحك، استخدم Incognito Mode أو وضع التصفح المتخفي. يساعدك ذلك على تقليل تأثير إضافات المتصفح Extensions التي قد تغيّر نتائج القياس أو تستهلك موارد إضافية أثناء الاختبار.
الخلاصة
يمنحك Google PageSpeed Insights أكثر من مجرد درجة رقمية ، فهو يوضح كيف يختبر المستخدمون موقعك، وأين تتعطل تجربة التصفح، ونحن في كرييتف كلاود تكنولوجي سي.سي.تك ندرك تماما ما الخطوات التي يمكننا اتخاذها للتحسين. نبدأ بتمييز بيانات الميدان عن بيانات المختبر، ثم نقارن بين الصفحة المحددة ومتوسط النطاق، ونراجع بدقة مؤشرات FCP وLCP وCLS وTBT وSI، ولا نهمل INP بوصفه مقياسًا مهمًا للتفاعل.
وأخيرًا، استخدام Google Search Console وقراءة قسم Diagnostics يمكننا من تحويل نتائج القياس إلى خطة عمل واضحة. فالأداء الجيد لا يتحقق بمطاردة درجة مثالية فحسب ، بل ببناء تجربة سريعة ومستقرة وسهلة الاستخدام.
