إذا بدا متجر WooCommerce بطيئًا على هاتف أو اتصال متغير، لا تبدأ بتصغير كل صورة أو مطاردة درجة 100 في PageSpeed Insights. حدّد أولًا أين يتأخر المحتوى، وما التفاعل الذي يتأخر، وهل يتحرك التصميم أثناء التحميل. استخدم بيانات المستخدمين عندما تكون متاحة، ثم أعد إنتاج المشكلة باختبار مختبري لتعرف ما الذي تغيّره.
Core Web Vitals تقيس ثلاثة جوانب من تجربة فعلية: سرعة ظهور المحتوى الرئيسي (LCP)، سرعة الاستجابة للتفاعل (INP)، والثبات البصري (CLS). توصيات Google عند المئين 75 هي LCP خلال 2.5 ثانية، وINP لا يزيد عن 200 مللي ثانية، وCLS لا يزيد عن 0.1. هذه أهداف تجربة مستخدم وليست وعدًا بترتيب؛ تحسين الدرجة وحده لا يضمن الظهور في أعلى النتائج. تعريف Core Web Vitals · تجربة الصفحة في Google Search
افصل بيانات الميدان عن المختبر
بيانات الميدان من CrUX أو Search Console تعكس جلسات مستخدمين حقيقية خلال فترة مجمعة. قد تُظهر اختلافًا بين الهاتف وسطح المكتب، أو بين صفحات المنتج والفئات. لا تكشف دائمًا السبب التفصيلي أو تجربة كل مدينة وشبكة، وقد لا تتوفر بيانات URL منفرد إذا كانت الزيارات قليلة.
بيانات المختبر من Lighthouse تحمّل صفحة في بيئة محاكاة يمكن تكرارها. استخدمها لمعرفة الموارد أو المهام الطويلة أو عناصر التخطيط التي تسببت في المشكلة؛ لكنها لا تمثل كل جهاز أو شبكة في مصر.
قد تختلف النتيجتان دون أن تكون إحداهما «خاطئة»: المختبر تجربة مضبوطة واحدة، والميدان تاريخ لتجارب مختلفة. لذلك سجّل كليهما ولا تستبدل بيانات مستخدمين بنتيجة اختبار واحدة. كيف يختلف اختبار المختبر عن بيانات الميدان
حدّد القالب والعنصر قبل تغيير الموقع
ابدأ بعينة تمثل رحلة الشراء: الصفحة الرئيسية، فئة مزدحمة، منتج ذو صورة كبيرة، صفحة سلة، وصفحة هبوط لحملة إذا كانت موجودة. سجّل لكل URL نوع الجهاز، نوع الصفحة، مقياس Core Web Vital المتأثر، الفترة، وحالة Search Console أو PSI.
إذا أظهرت صفحات المنتجات النمط نفسه، افحص قالب المنتج ومكوناته المشتركة قبل تعديل كل منتج يدويًا. وإذا كانت المشكلة محصورة بصفحة واحدة، لا تغيّر القالب العام. قسّم الزيارات حسب الهاتف وسطح المكتب؛ لا تدمج تجربتين مختلفتين في متوسط واحد.
لا تستنتج أن كل زوار مصر يستخدمون هاتفًا منخفض المواصفات أو شبكة 4G بطيئة. استخدم بيانات جمهور المتجر المصرح بها، واختبر على جهاز وشبكة يمكن وصفهما بدقة. عندما لا تتوفر عينة ميدانية كافية، اذكر أن الاختبار محاكاة لا تمثيل كامل للسوق.
تشخيص LCP: ما العنصر الأكبر الذي ينتظر؟
حدد عنصر LCP على الصفحة: صورة المنتج أو صورة البانر أو عنوان أو كتلة نص. إذا كانت صورة رئيسية، راجع أبعادها الفعلية، صيغة الملف، ضغطه، أولوية التحميل، وهل تُحمّل صورة مناسبة لحجم الشاشة. لا تؤخر صورة البطل بأسلوب التحميل الكسول إذا كانت هي العنصر الذي يحتاج أن يظهر أولًا. تجنب تنزيل صورتين كاملتين للأجهزة المختلفة إذا كان القالب قادرًا على اختيار مورد مناسب.
إذا كان العنصر نصيًا، افحص وقت استجابة الخادم وCSS أو الخطوط التي تؤخر الرسم. لا تضف preload عشوائيًا إلى كل صورة؛ يمكن أن ينافس ملفات أخرى مهمة. اختبر تعديلًا واحدًا، ثم قارن المختبر والميدان بعد فترة كافية لتجميع بيانات جديدة.
تشخيص INP: أي تفاعل يتأخر؟
اختبر البحث والمرشحات واختيار المقاس وإضافة المنتج إلى السلة. افحص هل النقر يشغّل JavaScript كثيفًا أو عمليات طرف ثالث أو تحديثات DOM كبيرة. راجع سجلات التفاعل في أدوات الأداء، وافصل تنفيذ الحدث عن التأخير الناتج عن تحميل عنصر مرئي بعده.
لا تزيل أداة دردشة أو تحليل لمجرد أنها خارجية. قِس أثرها على المهمة وعلى التحويل، ثم اختبر تحميلها عند الحاجة أو تأخير تشغيلها عندما لا تعطل الوظيفة. تخلص من الشيفرة الميتة أو النسخ المتكررة فقط بعد التأكد من اعتماد القالب والإضافات عليها.
تشخيص CLS: ما الذي يقفز بعد بدء القراءة؟
ابحث عن صور بلا مساحة محجوزة، شريط عروض يظهر متأخرًا، خط بديل يغير أبعاد النص، نافذة موافقة تغطي محتوى الصفحة، أو بطاقة تتغير بعد تحميل البيانات. خصص أبعادًا أو نسبة عرض وارتفاع للعناصر المرئية، وثبّت مساحة المكونات التي تُحقن لاحقًا، وتأكد من أن رسائل الخصوصية لا تدفع واجهة الشراء دون تنبيه.
اختبر على شاشة هاتف فعلية: ابدأ من أعلى الصفحة، افتح القوائم والخيارات، وانتقل إلى زر الشراء. لقطة ثابتة بعد اكتمال التحميل قد لا تكشف قفزة حصلت قبلها.
رتّب الإصلاح حسب الأثر والمخاطر
استخدم قائمة الأولوية التالية:
- صفحات تجلب حركة أو مبيعات ولديها مقياس ميداني ضعيف.
- عنصر أو شيفرة مشتركة تظهر في عدة قوالب.
- إصلاح محدود يمكن قياسه وإرجاعه إذا كسر الوظيفة.
- تحسين موضعي صغير مقارنة بإعادة بناء الثيم كاملًا.
- فحص السلة والدفع بعد كل تغيير، لأن أداء الصفحة لا يبرر إفساد عملية الطلب.
قبل تعديل الإنتاج، سجل قيمة البداية والمقاطع المراد تغييرها، واحفظ نسخة إعدادات أو استعمل بيئة اختبار عند توفرها. لا تحذف إضافة لمجرد أن اسمها يشير إلى بطء؛ تحقق من اعتماد الميزات عليها ومن أثر إزالتها على العرض والتتبع.
خطة قياس للموقع المصري
استخدم مزيجًا من بيانات CrUX وSearch Console وPSI، وسجّل تاريخ الاختبار وموقعه الظاهر في التقرير والجهاز والمحاكاة. إن توفر لديك RUM أو تحليلات أداء بموافقة مناسبة، قسّم البيانات بحسب فئة الجهاز والصفحة دون جمع معلومات شخصية لا تحتاجها. افحص الطلبات المؤكدة ومعدل إتمام السلة بالتوازي؛ قد يتحسن مقياس أداء دون تغيير ملحوظ في الطلبات.
بعد الإصلاح، قارن القالب أو مجموعة الصفحات نفسها على الفترة السابقة، وانتظر تجميع ميدان كافٍ. نتائج PSI الفورية مفيدة للتحقق من المختبر؛ لا تقدّمها على أنها تحسن ميداني مستقر في اليوم نفسه.
مصادر الأداء الرسمية
- Google: Core Web Vitals
- Google: Page experience
- web.dev: Core Web Vitals field and lab data
- PageSpeed Insights
توضح هذه المراجع المقاييس وأدوات الفحص؛ أما سبب البطء في متجرك فيحتاج بيانات الصفحة والقالب والأجهزة الفعلية.
سكريبت فيديو قصير: لا تطارد رقم 100
المدة: ٥٥ ثانية. الصورة: ثلاث لقطات: صورة المنتج، زر إضافة للسلة، ثم عنصر يتحرك.
الخطاف: «PSI جابلك 55 على الموبايل؟ متصغّرش كل الصور مرة واحدة.»
المشهد الأول: «شوف بيانات الميدان في Search Console أو PSI: المشكلة تحميل ولا تفاعل ولا ثبات؟»
المشهد الثاني: «حدد العنصر المتأخر في Lighthouse: صورة المنتج، كود إضافة، ولا شريط بيظهر بعدين.»
المشهد الثالث: «غيّر سببًا واحدًا، واختبر السلة والشراء، وبعدين راقب بيانات المستخدمين.»
الخاتمة: «الهدف تجربة شراء مستقرة، مش درجة كاملة على حساب الوظيفة.»
كاروسيل تعليمي: ثلاثة مقاييس، ثلاثة أسباب
- الغلاف: «متجر الموبايل بطيء؟ حدّد المقياس أولًا».
- LCP: ما أكبر عنصر ظاهر، ولماذا ينتظر؟
- INP: ما التفاعل الذي يستغرق وقتًا للاستجابة؟
- CLS: ما العنصر الذي يغيّر مكانه بعد بدء العرض؟
- افصل بيانات CrUX الميدانية عن Lighthouse المختبرية.
- أصلح السبب في القالب المتأثر واختبر رحلة الشراء.
- الخلاصة: «الدرجة مؤشر تشخيص؛ تجربة العميل هي الهدف».
سلسلة تجربة ميدانية: اختبر تحسين قالب المنتج
هذه خطة اختبار مقترحة وليست نتائج أداء مرصودة.
السؤال: هل تعديل صورة LCP أو شيفرة التفاعل في قالب المنتج يحسن تجربة الهاتف دون الإضرار بالسلة؟
- اختر مجموعة صفحات منتج متقاربة، وسجل CrUX أو Search Console والمقاييس المختبرية لكل نوع جهاز.
- حدد العنصر المسبب من تقرير Lighthouse وسجل المورد أو المهمة التي ستغيّرها.
- احتفظ بمجموعة مقارنة أو اطرح التغيير على مراحل إذا كان ذلك ممكنًا، مع تثبيت العروض والمخزون قدر الإمكان.
- نفذ تحسينًا واحدًا في كل مرحلة، مثل تحديد أبعاد الصورة أو تقليل تنفيذ JavaScript غير الضروري.
- أعد اختبار الصفحة على ظروف مختبرية موثقة، وامشِ يدويًا في البحث والاختيار والسلة والدفع.
- راقب الميدان على نافذة مناسبة؛ افصل النتائج حسب الجهاز والقالب، ودوّن حجم العينة.
- أوقف أو ارجع التغيير إذا تأثرت الوظيفة أو ظهرت أخطاء؛ لا تفسر اختبارًا واحدًا كتحسن دائم.
حزمة مطالبات محايدة للأدوات: تشخيص قابل للتكرار
قراءة تقرير PSI
حلل التقرير التالي [الصق البيانات]. افصل مقياس الميدان عن المختبر، وحدد لكل ملاحظة: URL، الجهاز، العنصر أو المورد، السبب المحتمل، وما يلزم قياسه قبل تعديل الموقع. لا تضمن تحسن الترتيب.
تجميع صفحات المتجر
صنف هذه الصفحات إلى قالب رئيسي/فئة/منتج/سلة، واجمع فقط الصفحات التي تشترك في سبب أداء موثق. احتفظ بحدود العينة وأخرج الصفحات التي لا تكفي بياناتها للاستنتاج.
خطة تغيير آمن
صمم اختبارًا لتغيير واحد في [القالب أو المورد]. أدرج قيمة البداية، اختبار عدم الإضرار بالبحث والسلة والدفع، نافذة قياس الميدان، ومعيار التراجع. لا تضف افتراضات عن مستخدمي مصر غير موجودة في البيانات.
ملف أمثلة: أوقف هذا: تحسين السرعة
أوقف: «وصلت للدرجة 100، إذن موقعي صار أسرع لكل الناس».
استخدم: «تحسن اختبار المختبر على هذا URL وهذه المحاكاة؛ سأتحقق من بيانات الميدان والجهاز الآخر».
أوقف: «احذف كل الإضافات الخارجية».
استخدم: «قِس أثر كل سكريبت على التفاعل والوظيفة، ثم اختبر التخفيف أو التحميل عند الحاجة».
أوقف: «كل مشاكل LCP سببها الصور».
استخدم: «حدد عنصر LCP أولًا؛ قد يكون صورة أو نصًا أو وقت استجابة الخادم».
الخطاف والقيمة والقالب: مقياس ثم سبب ثم إصلاح
الخطاف: «درجة السرعة مش تشخيص؛ اسم المقياس هو البداية.»
القيمة: «LCP تحميل المحتوى، INP تفاعل، CLS ثبات. افحص بيانات الميدان ثم استخدم المختبر للعثور على السبب.»
القالب: «القالب [نوع الصفحة]؛ الجهاز [نوعه]؛ المقياس [LCP/INP/CLS]؛ العنصر [الدليل]؛ التغيير [محدد]؛ فحص الوظيفة [النتيجة]؛ نافذة الميدان [الفترة].»
مثال: «صفحة المنتج على الهاتف لديها CLS بسبب صورة بلا أبعاد؛ نحدد المساحة ثم نعيد فحص فتح الخيارات والسلة قبل مراقبة الميدان».