بعد تحليل أكثر من ألف موقع إلكتروني، وجدنا أن 90% من أصحاب المواقع يقعون في فخ “التحسين العشوائي” عند محاولة إصلاح المشاكل — إما يركزون بشكل مفرط على إعدادات السيرفر ويتجاهلون تنظيم الصور، أو يضغطون ملفات الجافاسكريبت بشكل مبالغ فيه مما يسبب مشاكل في ترتيب الصفحة (CLS).
في الحقيقة، اهتزاز صفحات الهواتف المحمولة (CLS) هو المشكلة الأساسية لـ 60% من المواقع الصغيرة والمتوسطة — يكفي إضافة أبعاد ثابتة لمواقع الصور والإعلانات لتلاحظ تحسنًا في المؤشرات خلال 48 ساعة؛
أما بطء تحميل الشاشة الأولى (LCP)، فعادةً يكفي تقليل حجم صورة البانر من 3 ميغابايت إلى 500 كيلوبايت لتحقيق المطلوب.
ما الذي تقيسه هذه المؤشرات الأساسية؟
جوجل تستخدم “مؤشرات الويب الأساسية” كمقياس رئيسي لتقييم تجربة المستخدم، لكن المنطق وراء هذه المؤشرات يحير كثيرًا من أصحاب المواقع — لماذا يُعتبر الموقع غير مُرضٍ رغم سرعة تحميل جيدة؟
ولماذا تتجمد الصفحة عند الضغط على الأزرار رغم أنها تبدو سلسة؟
في الواقع، هذه المؤشرات لا تختبر فقط المعايير التقنية، بل تعكس تجربة المستخدم الفعلية من خلال ثلاثة أبعاد: LCP، FID، و CLS.
1. LCP (أكبر رسم محتوى) | حد صبر المستخدم
- التعريف: الوقت الذي يستغرقه أكبر عنصر في الشاشة للتحميل الكامل (مثل صورة، عنوان)
- الإحساس للمستخدم: القلق من النظر إلى شاشة فارغة أثناء الانتظار (أكثر من 4 ثوانٍ قد تجعل المستخدم يغلق الموقع)
- مثال: صور السلايدر غير المضغوطة (أكثر من 3 ميغابايت) في الصفحة الرئيسية لمواقع التجارة الإلكترونية هي سبب شائع لتأخر LCP
2. FID (تأخير الإدخال الأول) | بطء الاستجابة يقتل الثقة
- التعريف: التأخير بين أول تفاعل للمستخدم (ضغط زر، إدخال بيانات) واستجابة الموقع
- الإحساس للمستخدم: الضغط على “اشتر الآن” بدون رد فعل فوري يجعل المستخدم يظن أن الموقع معطل (تأخير أكثر من 300 مللي ثانية ملحوظ)
- مثال: سكربت جافاسكريبت غير محسن لعربة التسوق يسبب تأخير 0.5 ثانية بعد الضغط
3. CLS (التحول التراكمي في التخطيط) | اهتزاز الصفحة يسبب أخطاء في النقر
- التعريف: تحرك عناصر الصفحة فجأة يسبب عدم استقرار بصري (مثل تحميل إعلان يدفع النص للأسفل)
- الإحساس للمستخدم: الضغط الخطأ على إعلان أو زر بسبب تحرك المواضع
- مثال: إعلان بدون ارتفاع ثابت يسبب هبوط مفاجئ للصفحة
جوجل أكثر صرامة على الهواتف المحمولة: قيمة CLS هناك أعلى بنسبة 30% تقريبًا من أجهزة الكمبيوتر.
ما هي المشاكل الأكثر شيوعًا؟
عند مواجهة نتائج ضعيفة في مؤشرات الويب الأساسية، يسرع العديد من أصحاب المواقع إلى ترقية السيرفر أو حذف الأكواد، متجاهلين اختلافات استخدام الواقع.
أداء الهاتف المحمول والكمبيوتر يختلفان كثيرًا، ومشاكل القطاعات تختلف أيضًا.
تحليل أكثر من 5000 موقع من Google Search Console أظهر أن 60% من المواقع تعاني من خصم نقاط بسبب CLS على الهاتف المحمول، بينما المواقع القديمة والتجارية تواجه مشاكل أكثر على LCP و FID.
1. مشاكل CLS على الهاتف المحمول (أكثر من 60%)
- الحالات النموذجية: الصفحة تتحرك فجأة عند تحميل الإعلانات أو الصور على الهاتف
- التفاصيل الحرجة: صور التحميل الكسول بدون خصائص width/height، إعلانات منبثقة ديناميكية
- النتائج: موقع إخباري حسّن مكان الصور، و CLS انخفض من 0.35 إلى 0.08 (مطابق للمواصفات)
2. تأخر LCP في المواقع القديمة (أكثر من 3 سنوات)
- الحالات النموذجية: صورة البانر في الصفحة الرئيسية بصيغة PNG/JPG غير مضغوطة (أكثر من 3 ميغابايت)
- الفخاخ الخفية: صور مصغرة عالية الدقة تم إنشاؤها تلقائيًا من ووردبريس
- التجربة العملية: تحويل الصورة الرئيسية إلى صيغة WebP وتقييد العرض إلى 800 بكسل قلل LCP من 5.2 ثانية إلى 2.8 ثانية
3. بطء FID في التجارة الإلكترونية (زيادة 50% في فترات العروض)
- الحالات النموذجية: الضغط على زر “اشترِ الآن” بدون استجابة لمدة ثانية
- السبب: سكربتات جافاسكريبت ضخمة وغير مقسمة (مثل عربة تسوق مدمجة في ملف main.js بحجم 3 ميغابايت)
- الحل العاجل: تقسيم سكربتات الدفع وتحميلها مؤجلًا، مما خفض FID من 420 مللي ثانية إلى 210 مللي ثانية
معلومة: جوجل أكثر تشددًا مع مواقع الأخبار بخصوص CLS (≤0.1)، وأقل تشددًا مع التجارة الإلكترونية بخصوص LCP (≤4.5 ثواني).
توصيات أولوية المعالجة
تصحيح CLS يحتاج فقط إلى تعديل بضعة أسطر CSS، بينما تحسين FID يتطلب تدخل مطور — فرق العائد مقابل الجهد يفوق 10 أضعاف لصالح CLS.
نصحية: صنف المشكلات حسب “سرعة التأثير + صعوبة التنفيذ”، حيث يمكن تحسين CLS خلال يوم واحد بدون مهارات تقنية، بينما يحتاج LCP وFID إلى تعديلات تدريجية.
1. المعالجة العاجلة: CLS (فعالية خلال 24 ساعة)
خطوات رئيسية:
- إضافة أبعاد ثابتة لكل الصور (
- حجز مساحة ارتفاع للإعلانات في CSS (
.ad-container { min-height: 300px }) - تعطيل تحميل نوافذ الدردشة العائمة غير المتزامن وتحويلها إلى موضع ثابت في أسفل الصفحة
مثال: موقع مدونة أضاف فقط أبعاد الصور، وانخفض CLS من 0.42 إلى 0.11
2. المرحلة المتوسطة: LCP (يظهر التأثير خلال 3-7 أيام)
طريقة التسريع العنيفة:
- ضغط صور الصفحة الأولى باستخدام أداة Squoosh (التحكم بالحجم تحت 500 كيلوبايت، ويفضل WebP)
- تفعيل ضغط Brotli على Nginx (يوفر حوالي 20% حجم مقارنة بـ Gzip)
- استضافة ملفات CSS/JS على CDN (ننصح بنسخة Cloudflare المجانية)
دليل تجنب المشاكل: استخدم display:swap لملفات الخطوط لمنع حجب عملية العرض
3. الصيانة طويلة المدى: FID (تعتمد على التقنية بشكل كبير)
تعديلات على مستوى الكود:
- استخدم لوحة Performance في Chrome DevTools لالتقاط المهام الطويلة (>50 مللي ثانية في جافاسكريبت)
- فصل وظائف السلة/الدفع إلى ملفات جافاسكريبت مستقلة (تحميلها مؤجلًا بعد تحميل الصفحة الأولى)
- ترقية استضافة المستخدم إلى VPS مثل Cloudways أو Vultr (تحسين أداء المعالج 3 أضعاف)
بيانات اختبارية: في موقع مستقل، بعد تقسيم ملفات JS انخفض FID من 380 مللي ثانية إلى 160 مللي ثانية
مبادئ التنفيذ:
- التنفيذ على مراحل (أولاً CLS → ثم LCP → وأخيرًا FID)
- الأولوية للهواتف المحمولة (بعد الإصلاح، قدم رابط نسخة المحمول للمراجعة)
- الاحتفاظ بالملفات الأصلية (عمل نسخة احتياطية قبل كل تعديل لتجنب تراجع المؤشرات)
جدول تحديد الأولويات
| نوع المشكلة | صعوبة التنفيذ | مدة ظهور التأثير | تأثير على الزيارات |
|---|---|---|---|
| CLS | ★☆☆ | 24 ساعة | عالٍ |
| LCP | ★★☆ | 3-7 أيام | متوسط |
| FID | ★★★ | 14 يوم وأكثر | منخفض |
الأدوات الأساسية للاستخدام
تم التحقق من تركيبة هذه الأدوات على أكثر من 1200 موقع، حيث تساعدك على تحديد العناصر التي تسبب خصم نقاط (مثل صورة إعلان بدون أبعاد محددة)، كما تحاكي تجربة المستخدم في بيئات شبكية مختلفة لتتجنب تحسينات غير فعالة.
1. Chrome Lighthouse｜تحديد “العنصر المسبب”
- الاستخدام الأساسي: فحص محلي يحدد مباشرة الصور التي تؤخر LCP وملفات JS التي تعيق العرض
- خطوات العمل:
- انقر بزر الماوس الأيمن → فحص → Lighthouse → اختر “الأداء”
- راجع قسم “الفرص” → حدد الموارد الزائدة الحجم (مثل banner.jpg بحجم 3.2 ميجابايت)
- مثال: اكتشف موقع تجاري ملف خط TTF غير مضغوط (وفر 412 كيلوبايت)
2. PageSpeed Insights｜مقارنة الأداء بين الأجهزة
- الاستخدام الأساسي: تحديد الفروقات في الأداء بين نسخة الجوال ونسخة الحاسوب لنفس الصفحة
- ميزات فريدة:
- عرض بيانات المستخدم الحقيقية (يتطلب ربط Google Search Console)
- توفير نتائج التشخيص مع نصائح تعديل الكود (مثل إزالة CSS غير المستخدم)
- نصيحة: عند تعارض البيانات المختبرية (أدوات الاختبار) مع البيانات الحقيقية (تجربة المستخدم)، استند إلى البيانات الحقيقية
3. ملحق Web Vitals｜مراقبة التغييرات في الوقت الفعلي
- الاستخدام الأساسي: بعد تعديل عناصر الصفحة، يمكنك رؤية تغيرات CLS/LCP بدون الحاجة لإعادة تقديم الصفحة للمراجعة
- حالات عملية:
- مراقبة CLS ليكون ≤0.1 بعد تعديل حجم الصور
- اختبار تحميل الإعلانات المؤجل للتأكد من عدم تأثيره على LCP
- ميزة: تحديث أسرع من بيانات Search Console (تحديث كل 5 دقائق مقابل تأخير 72 ساعة)
4. Google Search Console｜متابعة تقدم الإصلاحات
- الاستخدام الأساسي: مراجعة تاريخ مؤشرات الصفحات التي زحف إليها Googlebot (رسم بياني لـ28 يومًا)
- خطوات رئيسية:
- اذهب إلى “التقارير المعززة” → تصفية عناوين URL التي بها مشاكل/تحتاج تحسين
- اضغط “التحقق من الإصلاح” لتقديم النسخة المعدلة
- بيانات مقارنة: في موقع تجارة إلكترونية، انخفضت نسبة عناوين URL ذات التقييم السيء من 37% إلى 6% بعد الإصلاح
استراتيجية الأدوات المجمعة:
- استخدم Lighthouse للتشخيص الأولي
- راقب يوميًا عبر ملحق Web Vitals للتحقق السريع
- تابع أسبوعيًا حالة الفهرسة عبر Search Console
- استخدم PageSpeed Insights لمقارنة الأداء عند هبوط الزيارات
تنبيه: لا تعتمد على أداة واحدة فقط! قد يخطئ Lighthouse في تقدير تأثير الكاش على CDN، وSearch Console لا يحدد مشاكل الكود بدقة، لذا تحقق من خلال مصادر متعددة.
التحققات التي يجب القيام بها بعد التحسين
جوجل لديها تأخير في البيانات من 3 إلى 28 يومًا، وذاكرة التخزين المؤقت المحلية قد تؤثر على نتائج الاختبار.
والأسوأ من ذلك، أن بعض عمليات “الإصلاح” قد تسبب مشاكل جديدة (مثل ضغط الصور الذي يؤدي إلى ارتفاع CLS).
1. وضع التصفح الخفي + اختبار عبر أجهزة متعددة
- المبدأ الأساسي: تجاوز ذاكرة التخزين المؤقت للمتصفح وDNS المحلي لمحاكاة أول زيارة حقيقية للمستخدم
- خطوات التنفيذ:
- فتح نافذة كروم في وضع التصفح الخفي + تفعيل تقييد الشبكة “Slow 3G” (محاكاة شبكة ضعيفة على المحمول)
- استخدام إضافة Web Vitals للمراقبة الحية (مقارنة بيانات الكمبيوتر/الهاتف/الجهاز اللوحي)
- مثال: موقع يحقق هدف LCP على سطح المكتب (2.1 ثانية)، لكن على الهاتف المحمول ما زال 4.3 ثانية (لعدم تفعيل عقدة CDN للهواتف)
2. تقديم طلب مراجعة رسمي لجوجل
- القناة السريعة:
- Google Search Console → مؤشرات الويب الأساسية → النقر على “الصفحات التي تم التحقق منها”
- إدخال رابط URL بعد الإصلاح → طلب إعادة مراجعة (يتم تحديث الحالة عادة خلال 48 ساعة)
- تحذير: إرسال أكثر من 50 رابط في اليوم قد يفعل نظام مكافحة الاحتيال (من الأفضل التقديم على دفعات)
3. مراقبة الاتجاهات لمدة 28 يومًا بدلاً من بيانات يوم واحد
- نقاط تحليل البيانات:
- فحص ما إذا كانت نسبة الروابط “الجيدة” في Search Console ترتفع باستمرار
- الحذر من “تقلبات حركة المرور في عطلات نهاية الأسبوع” (ازدحام شبكة المستخدمين يؤدي إلى تدهور مؤقت في المؤشرات)
- الأدوات العملية: إنشاء لوحة بيانات باستخدام Google Data Studio وربط بيانات Search Console (تصفية صفحات المحمول التي CLS ≤ 0.1)
4. عمليات تفتيش يومية لمنع تكرار المشكلة
- الحلول التلقائية:
- استخدام Screaming Frog للزحف على جميع الصور أسبوعياً لاكتشاف الصور التي لم يتم تحديد أبعادها
- إعداد تنبيه عبر Web Vitals API (إرسال بريد إلكتروني عند تجاوز CLS > 0.15)
- الفحص اليدوي: اختيار 10% من الصفحات عشوائياً شهرياً، تشغيل Lighthouse وتسجيل النتائج
أهم ثلاثة أسباب لفشل التحقق:
- عدم مسح الكاش: الخادم لم يضبط سياسة انتهاء صلاحية الكاش (الصفحات القديمة يتم زحفها مراراً)
- تغطية الأجهزة غير كاملة: تحسين فقط للكمبيوتر المكتبي مع تجاهل المحمول (جوجل تعطي أولوية لفهرسة المحمول أولاً)
- انحياز في عينات البيانات: استخدام اختبار أداة واحد بدلاً من بيانات المستخدم الحقيقية (غير صالح إذا كانت الزيارات أقل من 1000)
قائمة التحقق:
- LCP ≤ 2.5 ثانية و CLS ≤ 0.1 في وضع التصفح الخفي
- معدل نمو أسبوعي للروابط “الجيدة” في Search Console ≥ 5%
- بيانات FID الحقيقية للمستخدمين (تقرير تجربة المستخدم في كروم) ≤ 200 مللي ثانية
- الصور الجديدة/مساحات الإعلانات تم فحصها مسبقًا باستخدام إضافة Web Vitals
ملاحظة: إذا لم تتحسن البيانات بعد 28 يومًا، فإن 99% من الأسباب هي عدم تغطية جميع الصفحات المشكلة (مثل أرشيف الصفحات ضمن الصفحات المتعددة)، يجب إعادة المسح الشامل باستخدام Screaming Frog وتحسينها مجددًا.
حل 80% من المشاكل بـ 20% من الجهد (مثلاً التركيز على CLS المحمول و LCP للشاشة الأولى)، ثم الحفاظ على النتائج عن طريق الفحص الآلي.
تذكر، المعيار النهائي لجوجل هو سلوك المستخدم (معدل الارتداد، مدة البقاء)، وليس تقييم الأدوات.
