محتويات المقال
نعم، سرعة الموقع عامل ترتيب حقيقي في جوجل، لكن التأثير الأكبر يأتي من الخلف: الزائر الذي ينتظر أربع ثوانٍ يغادر، ومعدل المغادرة المرتفع يخبر جوجل أن صفحتك لم تُرضِ الباحث. هذه هي المعادلة باختصار. سرعة الموقع وتأثيرها على السيو ليست نظرية جميلة في مقالات التسويق، بل فرق ملموس في عدد الطلبات آخر الشهر.
سأشرح لك الأرقام المطلوبة فعلياً، والأدوات التي أثق بها، وخطة تنفيذ تصلح لمتجر إلكتروني أو مدونة.
كيف تؤثر سرعة الموقع على ترتيبك في جوجل فعلياً؟
سرعة الموقع إشارة ترتيب مؤكدة من جوجل عبر مؤشرات Core Web Vitals، لكنها إشارة ترجيح لا إشارة حاسمة. أي أن صفحة بطيئة بمحتوى ممتاز قد تتفوق على صفحة سريعة بمحتوى ضعيف. الأثر الحقيقي يظهر عند التعادل: بين صفحتين متقاربتين في الجودة، تفوز الأسرع.
هناك طبقة ثانية أهم. حين يفتح الزائر صفحتك من نتائج البحث ثم يرجع خلال ثانيتين لأن الشاشة بيضاء، فأنت خسرت مرتين: خسرت العميل، وأعطيت إشارة سلوكية سيئة.
جوجل نفسها نشرت بحثاً مع SOASTA يشير إلى أن احتمال مغادرة الزائر يرتفع بنحو 32٪ عندما ينتقل زمن التحميل من ثانية واحدة إلى ثلاث ثوانٍ. ودراسة ديلويت الشهيرة «Milliseconds Make Millions» وجدت أن تحسيناً قدره 0.1 ثانية فقط في سرعة الموقع على الجوال رفع معدلات التحويل في متاجر التجزئة بنحو 8.4٪.
عُشر ثانية. تخيّل ذلك.
أضف عاملاً تقنياً ثالثاً يغفل عنه الكثيرون: ميزانية الزحف. عنكبوت جوجل يخصص وقتاً محدوداً لموقعك، فإذا استغرقت كل صفحة ثلاث ثوانٍ للاستجابة، سيزحف لعدد أقل من الصفحات في الجلسة الواحدة. في متجر فيه 8000 منتج، هذا يعني أن منتجات جديدة قد تنتظر أسابيع قبل الفهرسة.
مؤشرات Core Web Vitals: الأرقام التي يجب أن تحفظها
ثلاثة مؤشرات فقط، ولكل واحد حد نجاح واضح. لا تُضِع وقتك في بقية الأرقام قبل أن تضبط هذه الثلاثة.
- LCP (أكبر عنصر مرئي): يجب أن يكتمل خلال 2.5 ثانية أو أقل. غالباً يكون صورة البطل في الأعلى أو عنوان كبير.
- INP (الاستجابة للتفاعل): 200 ملّي ثانية أو أقل. هذا المؤشر حلّ محل FID رسمياً في مارس 2024، وهو أقسى منه بكثير لأنه يقيس كل تفاعلات الزائر لا التفاعل الأول فقط.
- CLS (الانزياح البصري): 0.1 أو أقل. هو المسؤول عن تلك اللحظة المزعجة حين تضغط زر «أضف إلى السلة» فيقفز الإعلان مكانه.
القاعدة التي يجهلها كثيرون: جوجل تحكم على موقعك بناءً على البرسنتايل 75 من زوارك الحقيقيين خلال 28 يوماً. يعني أن 75٪ من الزيارات يجب أن تكون ضمن الحد الأخضر، لا المتوسط الحسابي. زائر واحد سريع على ألياف بصرية لن ينقذك من مئة زائر على شبكة جوال متذبذبة في الظهيرة.
INP تحديداً هو كابوس المتاجر العربية. لماذا؟ لأن قوالب ووردبريس المحمّلة بإضافات الفلاتر والسلة الديناميكية تنفّذ جافاسكربت ثقيلاً عند كل نقرة. اختبرت متجراً في جدة كان LCP لديه ممتازاً (1.9 ثانية) لكن INP وصل 480 ملّي ثانية بسبب إضافة فلترة منتجات واحدة. حذفناها واستبدلناها بفلترة من جانب الخادم، فنزل الرقم إلى 170.
ما الأدوات التي تقيس سرعة الموقع بدقة؟
أفضل مزيج مجاني: Google Search Console لتقرير Core Web Vitals من بيانات المستخدمين الحقيقيين، وPageSpeed Insights للتشخيص التفصيلي، وWebPageTest للاختبار من موقع جغرافي محدد. ابدأ دائماً ببيانات الحقل في Search Console، لأنها تعكس تجربة زوارك الفعليين لا محاكاة مخبرية.
الفرق بين نوعي البيانات مهم. بيانات المختبر (Lab) تُحاكي جهازاً افتراضياً على شبكة بطيئة، وبيانات الحقل (CrUX) تُجمع من متصفحات كروم الحقيقية. جوجل تعتمد الثانية للترتيب.
ولهذا أنصحك بعدم الهوس بنتيجة الـ 100/100 في PageSpeed Insights. رأيت أصحاب مواقع يقضون أسبوعين لرفع الرقم من 88 إلى 97 بينما مؤشراتهم الحقلية كانت خضراء أصلاً. وقت ضائع.
أدوات إضافية أستعملها فعلياً:
- Chrome DevTools › Performance: لتصوير شريط زمني وتحديد السكربت الذي يحجب الخيط الرئيسي.
- GTmetrix: مفيد لرسم شلال الطلبات (Waterfall) ورؤية الملف الذي يتأخر.
- Treo أو CrUX Dashboard: لمقارنة أدائك بمنافسيك بمرور الوقت.
نصيحة من تجربة: في WebPageTest اختر موقع اختبار قريب من جمهورك، مثل فرانكفورت أو مومباي إن كان زوارك من الخليج. الاختبار من فيرجينيا سيعطيك أرقاماً متفائلة كذباً. وبعد كل تحسين، تابع الأثر على ترتيبك عبر أدوات متابعة ترتيب الموقع في البحث بدل الاعتماد على الإحساس.
لماذا تكون المواقع العربية بطيئة عادة؟
ليست مصادفة. هناك أسباب متكررة أراها في كل مراجعة تقريباً، ومعظمها قابل للإصلاح في يوم عمل واحد.
الخطوط العربية. ملف خط عربي واحد قد يتجاوز 200 كيلوبايت لأنه يحمل آلاف المحارف والتشكيل. ثم يحمّل صاحب الموقع خطي «تجوال» و«القاهرة» معاً بستة أوزان لكل منهما. النتيجة: أكثر من ميجابايت من الخطوط قبل ظهور أول كلمة.
سلايدر الصفحة الرئيسية. ذلك المعرض الدوّار بخمس صور بعرض 2000 بكسل. الزائر لا يرى منه غير الشريحة الأولى، لكن المتصفح يحمّلها كلها.
الإضافات المتراكمة. متجر ووردبريس بـ 42 إضافة، نصفها معطّل عن العمل لكنه ما زال يحقن CSS و JS في كل صفحة. تراكم صامت لسنوات.
سكربتات التتبع. جوجل أناليتكس، بكسل فيسبوك، تيك توك، سناب، سكربت دردشة، خريطة حرارية. كل واحد يضيف طلبات خارجية وأحياناً 300 ملّي ثانية من التنفيذ.
استضافة مشتركة رخيصة. عشرون درهماً شهرياً تعني خادماً يشاركك فيه 300 موقع آخر. زمن استجابة الخادم (TTFB) يتجاوز 1.2 ثانية قبل أن يبدأ التحميل أصلاً.
هذه الأخطاء تنتمي لعائلة أوسع تناولناها في أخطاء السيو الشائعة التي تدمّر ترتيب موقعك، وأغلبها لا يحتاج مبرمجاً محترفاً لإصلاحه.
الصور: أسرع مكسب يمكنك تحقيقه اليوم
لو لم يكن أمامك سوى ساعتين لتحسين موقعك، اصرفهما على الصور. في المتاجر العربية، الصور تمثل عادة 60–70٪ من وزن الصفحة، وهي المسؤول الأول عن تأخر LCP.
خطة العمل بالترتيب:
- حوّل كل شيء إلى WebP أو AVIF. صورة منتج بصيغة JPEG بحجم 400 كيلوبايت تنزل غالباً إلى 60 كيلوبايت بصيغة WebP دون فرق مرئي. في ووردبريس تكفي إضافة مثل ShortPixel أو Imagify.
- اضبط الأبعاد الحقيقية. لا ترفع صورة 3000×2000 بكسل لتعرضها في مربع 400 بكسل. المتصفح سيحمّل الملف كاملاً ثم يصغّره.
- استخدم srcset ليحصل جوال بشاشة 390 بكسل على نسخة مناسبة بدل نسخة الديسكتوب.
- حدد width و height في وسم الصورة. هذه الخطوة وحدها تحل معظم مشاكل CLS لأن المتصفح يحجز المساحة مسبقاً.
والآن الجزء الذي لا يخبرك به أحد: لا تفعّل التحميل الكسول (lazy loading) على صورة الـ LCP. أرى هذا الخطأ أسبوعياً. صاحب الموقع يفعّل lazy load على «كل» الصور ظناً أنه يسرّع الأمور، فيتأخر ظهور صورة البانر الرئيسية نصف ثانية إضافية لأن المتصفح ينتظر تنفيذ جافاسكربت قبل طلبها. الصور فوق الطية تُحمّل بشكل عادي مع fetchpriority="high"، وما تحتها فقط يُؤجَّل.
احذف أيضاً أي صورة زخرفية لا تخدم غرضاً. الخلفية المزخرفة بحجم 800 كيلوبايت خلف نموذج الاشتراك؟ استبدلها بتدرج لوني CSS.
الاستضافة و CDN: أين يقف خادمك من زبونك؟
هنا مربط الفرس بالنسبة للسوق العربي. موقع مستضاف في تكساس يخدم زبائن في الرياض يدفع ضريبة مسافة تُقدَّر بـ 150–250 ملّي ثانية لكل رحلة ذهاب وإياب. اضرب ذلك في عدد الطلبات، وستفهم لماذا يبدو الموقع «ثقيلاً» رغم أن الصور مضغوطة.
رأيي صريح: انتقل من الاستضافة المشتركة إلى VPS أو استضافة مُدارة بمجرد أن يتجاوز موقعك 10 آلاف زيارة شهرياً. الفرق في الفاتورة قد يكون 15 دولاراً، والفرق في TTFB قد يكون 900 ملّي ثانية.
ثم ضع شبكة توصيل محتوى أمام الموقع. Cloudflare بخطتها المجانية تكفي معظم المواقع العربية، ولديها نقاط حضور في دبي والرياض وجدة والكويت والقاهرة. المحتوى الثابت — صور، CSS، خطوط — يُخدَم من نقطة قريبة من الزائر بدل عبور نصف الكوكب.
ثلاثة إعدادات أطبّقها في Cloudflare أول ما أضيف موقعاً:
- تفعيل Brotli للضغط بدل Gzip فقط.
- ضبط Cache Everything لصفحات المدونة الثابتة مع استثناء صفحات السلة والحساب.
- تشغيل Early Hints ليبدأ المتصفح تحميل الموارد الحرجة قبل وصول HTML كاملاً.
وانتبه لتخزين الصفحة المؤقت على مستوى الخادم: LiteSpeed Cache أو Redis يقلبان الموازين في ووردبريس. متجر عميل لي نزل TTFB من 1.4 ثانية إلى 210 ملّي ثانية بعد تفعيل LiteSpeed وحده، دون لمس سطر كود.
خطة تسريع عملية لمتجرك خلال أسبوع
لا تحاول فعل كل شيء دفعة واحدة. رتّب المهام حسب الأثر مقابل الجهد، ونفّذ على مراحل حتى تعرف ما الذي أحدث الفرق.
اليوم الأول: قِس الوضع الحالي. سجّل LCP و INP و CLS من Search Console، واحفظ لقطة شاشة. هذه نقطة الصفر التي ستقارن بها لاحقاً.
اليوم الثاني: الصور. تحويل جماعي إلى WebP، إعادة ضبط الأبعاد، إضافة width/height، واستثناء صورة البطل من التحميل الكسول.
اليوم الثالث: الخطوط. اختر خطاً عربياً واحداً بوزنين فقط (400 و700)، استضفه محلياً بصيغة WOFF2، وأضف font-display: swap ووسم preload. النص سيظهر فوراً بخط احتياطي بدل الشاشة البيضاء.
اليوم الرابع: تنظيف الإضافات. احذف كل إضافة معطّلة، واستبدل الإضافات الثقيلة ببدائل أخف. استعمل Query Monitor لمعرفة أي إضافة تستهلك وقت الخادم.
اليوم الخامس: السكربتات الخارجية. أجّل كل سكربت تتبع بـ defer، واحذف ما لا تستخدمه فعلاً. سكربت الدردشة تحديداً: حمّله بعد تفاعل المستخدم لا عند فتح الصفحة.
اليوم السادس: الاستضافة و CDN والتخزين المؤقت كما شرحنا.
اليوم السابع: أعد القياس، وسجّل الفرق. توقّع تحسناً بين 40٪ و60٪ في LCP إن كنت تبدأ من موقع مهمل.
ادمج هذه الخطة مع بقية عملك التقني عبر دليل تحسين السيو الداخلي خطوة بخطوة، فالسرعة جزء من منظومة لا حل منفرد.
أخطاء متكررة عند قياس السرعة وتفسير النتائج
الخطأ الأول: اختبار الصفحة الرئيسية فقط. الرئيسية عادة الأخف والأكثر عناية، بينما 80٪ من زياراتك تصل إلى صفحات منتجات أو مقالات. اختبر ثلاثة أنواع صفحات على الأقل.
الخطأ الثاني: القياس مرة واحدة. نتيجة الاختبار تتذبذب حسب حمل الخادم ولحظة التنفيذ. شغّل الاختبار ثلاث مرات وخذ الوسيط.
الخطأ الثالث: توقّع قفزة فورية في الترتيب. بيانات CrUX تُحدَّث على نافذة 28 يوماً متحركة، لذا حتى لو أصلحت كل شيء اليوم، لن يتحول تقرير Search Console إلى الأخضر قبل ثلاثة أو أربعة أسابيع. اصبر ولا تتراجع عن التعديلات ظناً أنها فشلت.
الخطأ الرابع، وهو الأكثر إيلاماً: تسريع موقع بمحتوى ضعيف. السرعة ترفع صفحة جيدة درجة أو درجتين، لكنها لن تُصعِد صفحة سطحية أمام منافس كتب دليلاً شاملاً. ابنِ الأساس أولاً بـمحتوى أصلي يستحق الترتيب، ثم اجعله سريعاً.
ونقطة أخيرة يخطئ فيها الجميع تقريباً: قياس السرعة من جهاز الديسكتوب في المكتب على واي فاي ممتاز. زبونك يتصفح من جواله في السيارة على شبكة 4G مزدحمة. فعّل خانق الشبكة (Network Throttling) في DevTools واختبر على وضع «Slow 4G» و«Mid-tier mobile». الصورة ستكون مختلفة تماماً، وأحياناً صادمة.
ماذا تفعل بعد أن يصبح موقعك سريعاً؟
السرعة تفتح الباب، والمحتوى والروابط تدخلك منه. بعد أن تصبح مؤشراتك خضراء، وجّه طاقتك إلى تغطية الكلمات المفتاحية وبناء السلطة، وراقب النتائج شهرياً بخطة واضحة مثل تلك الموجودة في رفع ترتيب الموقع في جوجل خلال ستة أشهر.
وتذكّر أن الأداء ليس مشروعاً ينتهي. كل إضافة جديدة، وكل سكربت تسويقي، وكل بانر موسمي، يقضم جزءاً من مكاسبك. راجع مؤشراتك كل ربع سنة على الأقل.
الأسئلة الشائعة
كم يجب أن تكون سرعة تحميل الموقع المثالية؟
استهدف اكتمال أكبر عنصر مرئي (LCP) خلال 2.5 ثانية أو أقل على شبكة الجوال، مع زمن استجابة خادم دون 600 ملّي ثانية. عملياً، أي صفحة تُظهر محتواها الرئيسي خلال ثانيتين تُعتبر ممتازة عربياً. تجاوز أربع ثوانٍ يعني خسارة ثلث الزوار قبل أن يقرؤوا كلمة واحدة.
هل تحسين سرعة الموقع يرفع الترتيب مباشرة؟
ليس بشكل فوري ولا دراماتيكي. السرعة عامل ترجيح يظهر أثره بوضوح عند المنافسة بين صفحات متقاربة في جودة المحتوى. الأثر الأكبر غير مباشر: انخفاض معدل المغادرة، وزيادة الصفحات المشاهدة، وتحسّن الفهرسة. توقّع ملاحظة النتائج بعد أربعة إلى ثمانية أسابيع من التحديث.
ما الفرق بين INP و FID في مؤشرات جوجل؟
FID كان يقيس تأخر الاستجابة للتفاعل الأول فقط، أما INP فيقيس زمن استجابة كل التفاعلات خلال الزيارة ويأخذ الأسوأ منها تقريباً. جوجل استبدلت FID رسمياً بـ INP في مارس 2024. الحد المطلوب 200 ملّي ثانية، وهو معيار أصعب يكشف مشاكل جافاسكربت التي كان FID يخفيها.
هل يكفي تفعيل CDN لتسريع متجري الإلكتروني؟
لا يكفي وحده. شبكة التوصيل تحل مشكلة المسافة الجغرافية والملفات الثابتة، لكنها لن تصلح صوراً بحجم ميجابايت، ولا قالباً محمّلاً بأربعين إضافة، ولا استعلامات قاعدة بيانات بطيئة. اعتبرها الطبقة الأخيرة بعد ضغط الصور وتنظيف الإضافات وتفعيل التخزين المؤقت على الخادم.