قد تحصل صفحة على درجة أفضل، بينما يظل زر الشراء ثقيلًا على هاتف العميل. وقد تضغط الصور كلها، ثم تكتشف أن المشكلة كانت في انتظار الخادم. تقرير PageSpeed Insights يصبح مفيدًا عندما تربط كل ملاحظة بمشكلة يلمسها الزائر.
الهدف من هذا الدليل أن تخرج من التقرير بثلاثة أشياء: وصف واضح للمشكلة، تعديل يمكن اختباره، وطريقة تعرف بها هل نجح. أما تنفيذ كل اقتراح دفعة واحدة، فيجعل من الصعب معرفة ما الذي ساعد وما الذي عطّل وظيفة كانت تعمل.
ابدأ بالسياق قبل قراءة الدرجة
سجّل رابط الصفحة التي اختبرتها ونوع الجهاز وتاريخ القياس. لا تجعل الرئيسية ممثلة للموقع كله؛ اختر أيضًا صفحة خدمة أو مقالًا وصفحة منتج إذا كان لديك متجر. لكل قالب عناصره ومسار تحميله، وقد تختبئ المشكلة في قالب واحد بينما تبدو الرئيسية سليمة.
اكتب السبب العملي للاختبار: هل يشتكي الزائر من تأخر المحتوى، أم من القفزات أثناء القراءة، أم من استجابة القوائم؟ وجود هدف يمنعك من إنفاق الوقت على ملف صغير لا يفسر الشكوى الأساسية. احتفظ بالتقرير قبل التعديل حتى لا تعتمد المقارنة على الذاكرة.
بيانات الزوار ليست اختبار Lighthouse
يعرض PageSpeed Insights بيانات ميدانية من CrUX عندما تتوفر عينات كافية، وتغطي فترة متحركة مقدارها 28 يومًا. تحقق هل المعروض يخص عنوان الصفحة أم الموقع على مستوى Origin. غياب البيانات لا يعني أن الصفحة فشلت؛ قد تكون العينات غير كافية. أما Lighthouse فيقيس تحميلًا داخل بيئة محاكاة، ويقدم تفاصيل تساعد في التشخيص.
لهذا قد تختلف النتيجتان، ولا يلزم أن يتغير التقرير الميداني فور نشر الإصلاح. ويعتمد تقييم المؤشرات الميدانية على المئين 75؛ الحدود الجيدة هي LCP حتى 2.5 ثانية، وINP حتى 200 ملّي ثانية، وCLS حتى 0.1. اقرأ النطاق والجهاز مع الرقم، ولا تخلط نتيجة سطح المكتب بالموبايل.
إذا تأخر المحتوى الرئيسي: تتبّع LCP
حدد العنصر الذي اعتبره التقرير LCP أولًا. قد يكون صورة أو كتلة نص. افصل زمن وصول HTML عن تأخر بدء تحميل المورد، ومدة تحميله، ثم انتظار ظهوره. ضغط الصورة يعالج جزءًا واحدًا فقط؛ إذا ظل ظهورها مؤجلًا خلف JavaScript فقد يبقى التأخير واضحًا. ولصورة المحتوى الرئيسي، راجع إمكانية اكتشافها مبكرًا وتجنب معاملتها كصورة بعيدة أسفل الصفحة عبر Lazy Loading.
حوّل الملاحظة إلى مهمة محددة: «مراجعة سبب تأخر طلب صورة الغلاف» أو «فحص انتظار HTML في صفحة الخدمة». لا تكتب «تحسين الصور» بوصفها مهمة شاملة ثم تغير كل مكتبة الوسائط. اختيار مورد واحد مؤثر يجعل التجربة أقصر ويسهل الرجوع عنها عند الحاجة.
إذا كان الضغط على الأزرار ثقيلًا: افحص INP
INP يتعلق بسرعة استجابة الصفحة للتفاعلات. قد ينتظر الإدخال انتهاء عمل آخر، أو يستغرق معالج الحدث وقتًا، أو يتأخر الرسم بعده. جرّب التفاعلات نفسها في تسجيل Performance: فتح القائمة، تغيير خيار، أو إظهار نافذة. ابحث عن المهام الطويلة والعمل غير الضروري، ثم قلل ما يُنفذ داخل المسار الحرج للتفاعل أو قسّمه بصورة مناسبة.
لا تكتفِ بتجربة زر واحد وأنت تستخدم جهازًا قويًا. ضع قائمة قصيرة بالتفاعلات التي يحتاجها العميل فعلًا، وراجعها بعد كل تعديل على تأخير JavaScript. تحسين تحميل الصفحة الذي يمنع القائمة من الفتح أو يؤخر اختيار المنتج لا يحقق هدف التجربة.
إذا تحرك المحتوى فجأة: ابحث عن سبب CLS
من أسباب عدم استقرار التخطيط الصور بلا مساحة محجوزة، والمحتوى الذي يُدرج فجأة، وتغيّر أبعاد النص عند تحميل الخطوط. احجز أبعادًا أو نسبة عرض مناسبة للصور والفيديو، وخطط لمساحة المكونات المتأخرة. راقب الصفحة بعد تحميلها أيضًا؛ انتقالات التخطيط قد تظهر لاحقًا أثناء التصفح ولا تختزلها لقطة البداية.
سجّل موضع القفزة بدل الاكتفاء بعبارة «هناك CLS». مثال تشخيصي: هل تحرك زر إرسال النموذج بعد ظهور رسالة؟ أم تغيّر ارتفاع العنوان عند وصول الخط؟ هذا الوصف يساعد المصمم والمطوّر على معالجة المكوّن المسؤول دون تثبيت ارتفاعات عشوائية تقطع النص العربي على الشاشات الصغيرة.
حوّل النتائج إلى قائمة أولويات قابلة للتنفيذ
| الملاحظة | المهمة الأولى | ما الذي يثبت نجاحها؟ |
|---|---|---|
| محتوى رئيسي متأخر | تحديد المرحلة الأطول في وصوله | تحسن توقيت العنصر مع بقاء جودته |
| تفاعل يتوقف لحظات | تسجيل التفاعل وتحديد العمل الذي يعطله | استجابة أسرع واستمرار الوظيفة |
| عناصر تتحرك أثناء القراءة | تحديد المكوّن الذي يغيّر المساحة | استقرار الموضع على المقاسات المتأثرة |
| تحذيرات كثيرة بلا شكوى محددة | ترتيبها بحسب الصفحات المتأثرة والأثر المتوقع | مهمة صغيرة بقياس واضح قبلها وبعدها |
اقتراحي العملي أن تبدأ بالمشكلة المتكررة في مسار مهم، ثم بالإصلاح الأقل مخاطرة بين الحلول المناسبة لها. إصلاح قالب تستخدمه عشرات المنتجات قد يستحق الأولوية على تعديل صفحة نادرًا ما تُزار. هذا ترتيب للعمل بحسب احتياج الموقع، وليس معادلة تضمن ترتيبًا في البحث.
كيف تقارن قبل التعديل وبعده؟
نفّذ تغييرًا محددًا على نسخة تجريبية، ثم أعد القياس في ظروف متقاربة أكثر من مرة. دوّن النطاق الذي تتحرك فيه النتائج بدل اختيار أفضل تشغيل فقط. بعد النشر، راجع النسخة الفعلية لأن طبقات التخزين والإعدادات قد تختلف عن بيئة التجربة.
أضف فحصًا وظيفيًا قصيرًا إلى المقارنة: القائمة والنموذج والشراء والخط العربي على الموبايل. احتفظ بتاريخ نشر التعديل لمتابعة البيانات الميدانية لاحقًا. وإذا لم يتحسن المؤشر المتوقع، راجع فرضيتك قبل تطبيق حزمة تعديلات جديدة. ويمكنك الرجوع إلى دليل تسريع WordPress عندما يتضح المكوّن الذي يحتاج المعالجة.
أسئلة شائعة
هل أحتاج درجة 100 حتى أعتبر الموقع جيدًا؟
لا تجعل هذا الرقم شرط التسليم الوحيد. اتفق على صفحات وتفاعلات ومقاييس واضحة، وقيّم الجودة البصرية والوظائف معها. الوصول إلى رقم أعلى لا يبرر حذف شيء يحتاجه المستخدم.
هل أرسل تقريرًا واحدًا للمطوّر؟
أرسله مع رابط الصفحة، والجهاز المتأثر، ووصف المشكلة وخطوات تكرارها. هذه التفاصيل تجعل التقرير قابلًا للتحويل إلى مهمة فعلية، بدل تبادل صور درجات لا تشرح ما يواجهه الزائر.
ما أول خطوة إذا كانت النتائج متناقضة؟
راجع أنك تقارن الجهاز نفسه ونطاق البيانات نفسه، ثم كرر الاختبار وسجّل الظروف. لا تغيّر الإعدادات بين كل تشغيل؛ وإلا لن تعرف هل الاختلاف جاء من القياس أم من التعديل.
المصادر والمراجعة
المعلومات وخطوات الإعداد تعكس الوثائق التالية وقت المراجعة. قوائم الاختبار إرشادات للتطبيق، ولا تعني تنفيذ اختبارات على متجر أو حساب دفع فعلي. راجع توثيق نسختك قبل التنفيذ.
- Google: كيف يعمل PageSpeed Insights
- Google: تشخيص وتحسين LCP
- Google: تحسين استجابة التفاعل INP
- Google: معالجة حركة عناصر الصفحة CLS
