سرعة الموقع: كيف تقيسها وتحسّنها بخطوات جرّبتها على موقعي

في 13 نوفمبر 2026 فتحت تقرير PageSpeed Insights لموقعي، فوجدت سطراً أحمر في قسم جديد تفحص فيه Google جاهزية الصفحة لمساعدات الذكاء الاصطناعي: الأداة لم تستطع جلب ملف llms.txt لأن مهلة الطلب انتهت. الملف موجود ويعمل. مشكلته أنه كان يُبنى من الصفر مع كل طلب.

أضفت قاعدة تخزين مؤقت واحدة في Cloudflare، فصار الملف يخرج من أقرب خادم في جزء من الثانية. خمس دقائق عمل. بهذه الطريقة أتعامل مع سرعة الموقع: زمن ينتظره زائر أو زاحف، ولكل جزء منه سبب يمكن قياسه وإصلاحه. في هذا الدليل أشرح كيف تقيس سرعة موقعك قياساً صحيحاً، وكيف تعرف أين تضيع الثواني، وماذا غيّرت في موقعي حتى ارتفعت درجة أداء إحدى صفحاته على الجوال من 85 إلى 97.

هل تؤثر سرعة الموقع على ترتيبك في جوجل؟

نعم، لكن بوزن أصغر مما توحي به إعلانات إضافات التسريع. تقول Google في توثيقها الرسمي إن مؤشرات أداء الويب الأساسية تستخدمها أنظمة الترتيب لديها، وتقول في الصفحة نفسها إن النتائج الجيدة في تقاريرها لا تضمن ظهور صفحاتك في أعلى النتائج، وإن البحث يعرض المحتوى الأنسب للسؤال حتى لو كانت تجربة صفحته أضعف.

المعنى العملي: السرعة لا ترفع صفحة ضعيفة فوق صفحة أنفع منها. لكنها ترجّح بين صفحتين متقاربتين في الجودة، والتقارب هو الحال الغالب في أي سوق فيه منافسة.

الأثر الأوضح للسرعة يظهر في مكانين آخرين. الأول المبيعات. في دراسة أجرتها Deloitte لصالح Google على 37 علامة تجارية وأكثر من 30 مليون جلسة، ارتبط تحسين سرعة مواقع الجوال بعُشر ثانية بارتفاع التحويل 8.4% في متاجر التجزئة و10.1% في مواقع السفر، وبزيادة إنفاق متسوقي التجزئة 9.2%. وحين حسّنت Vodafone مؤشر LCP في صفحاتها بنسبة 31% ارتفعت مبيعاتها 8%. وإن كان متجرك يستقبل زيارات ولا يبيع، فالبطء أحد الأسباب التي شرحتها في مقال المتجر الذي يجلب زيارات ولا يبيع.

والثاني الزحف. توثيق Google عن ميزانية الزحف صريح في هذه النقطة: إن استجاب موقعك بسرعة لفترة ارتفع الحد الذي يزحف به Googlebot إليه، وإن طالت الاستجابة أو ظهرت أخطاء الخادم انخفض الحد وقلّ الزحف. وفي المواقع الكبيرة ينعكس ذلك على سرعة اكتشاف الصفحات الجديدة وتحديث القديمة.

مؤشرات أداء الويب الأساسية بلغة صاحب الموقع

تسميها Google بالإنجليزية Core Web Vitals، وهي ثلاثة مؤشرات فقط. وإن قرأت عن مؤشر رابع أو عن «إصدار ثانٍ» منها فراجع المصدر، لأن توثيق Google ما زال على هذه الثلاثة حتى نوفمبر 2026.

LCP: متى يرى الزائر ما جاء من أجله؟

اسمه في توثيق Google العربي «سرعة عرض أكبر محتوى مرئي». يقيس الزمن من بدء تحميل الصفحة حتى يظهر أكبر عنصر في الشاشة الأولى: صورة المنتج في صفحة المنتج، أو الصورة البارزة في المقال، أو أكبر كتلة نص إن لم توجد صورة. الحد الجيد 2.5 ثانية أو أقل.

INP: هل يستجيب الموقع حين ألمسه؟

«مدى استجابة الصفحة لتفاعلات المستخدم». يقيس المدة بين ضغطة الزائر على زر أو قائمة وظهور أثر الضغطة على الشاشة، ويراقب التفاعلات طوال الزيارة ثم يأخذ أبطأها تقريباً. الحد الجيد 200 ملي ثانية أو أقل. حلّ هذا المؤشر محل FID في مارس 2024، فإن صادفت نصيحة تتحدث عن FID فهي قديمة.

CLS: هل تقفز العناصر تحت إصبعك؟

«متغيّرات التصميم التراكمية». يقيس تحرك العناصر بعد ظهورها. مثال يتكرر في المتاجر: الزائر يهمّ بالضغط على زر «أضف إلى السلة» فينزل الزر فجأة لأن شريط عروض ظهر فوقه، فيضغط على شيء آخر. الحد الجيد 0.1 أو أقل.

القيمة المئوية الخامسة والسبعون تعني ببساطة: رتّب زيارات الصفحة من الأسرع إلى الأبطأ، وانظر إلى الزيارة رقم 75 من كل 100. إن كانت ضمن الحد نجحت الصفحة. لهذا لا يكفي أن يفتح موقعك بسرعة على جوالك وشبكة مكتبك، فالمعيار جهاز الزائر العادي وشبكته.

كيف تقيس سرعة موقعك قياساً صحيحاً؟

أكثر خطأ أراه في قياس سرعة الموقع أن يفتح صاحبه أداة واحدة، فيرى رقماً أحمر، فيبدأ بتثبيت الإضافات. القياس الصحيح يبدأ بالتفريق بين نوعين من البيانات.

البيانات الميدانية تأتي من زيارات حقيقية لمستخدمي متصفح Chrome، تجمعها Google في تقرير اسمه CrUX وتعرضها مجمّعة لآخر 28 يوماً، وإليها تستند في تقييم تجربة الصفحة. بيانات المختبر اختبار يجري لحظة طلبه على جهاز محاكى وشبكة مقيّدة السرعة، ممتاز للتشخيص، لكنه لا يمثل بالضرورة ما يعيشه زوارك.

في PageSpeed Insights اقرأ الجزء العلوي أولاً، الذي يعرض تجربة المستخدمين الفعليين. إن ظهر فيه حكم بالنجاح أو الإخفاق فهذا تقييم Google لصفحتك. الجزء السفلي اختبار مختبر يحاكي هاتفاً متوسطاً على شبكة جوال بطيئة، وأرى ذلك بعيني في سجلات موقعي: كل فحص من الأداة يصل إلى الخادم باسم جهاز Moto G Power.

وإن كان موقعك جديداً أو زياراته قليلة فقد لا تجد بيانات ميدانية أصلاً، لأن Google لا تعرضها إلا حين يكفي عدد الزيارات. عندها تبقى بيانات المختبر دليلك الوحيد، فاقرأها كمؤشر اتجاه لا كحكم نهائي. وتقرير مؤشرات الأداء وبقية تقارير الأداة شرحتها في دليل جوجل سيرش كونسول.

• افحص القوالب لا الرئيسية وحدها: صفحة منتج، وصفحة تصنيف، ومقالاً. لكل قالب مشاكله.
• كرر اختبار المختبر ثلاث مرات وخذ النتيجة الوسطى، فالرقم يتغير من تشغيل لآخر.
• ابدأ بالجوال. Google تفهرس نسخة الجوال من موقعك، وهي الأبطأ في الغالب.
• لا تطارد 100 في المختبر. صفحة بدرجة 90 تنجح في البيانات الميدانية أفضل من صفحة بدرجة 100 تفشل عند الزوار.

أين تضيع الثواني؟ تشخيص بطء الموقع من مصدره

رقم LCP وحده لا يحدد المشكلة. Google تقسمه إلى أربع مراحل متتالية، ولكل مرحلة متهم مختلف.

1. زمن أول بايت TTFB: المدة حتى يبدأ الخادم بإرسال الصفحة. توصي Google بأن يبقى عند 0.8 ثانية أو أقل لأغلب المواقع. إن تجاوزه فالمشكلة في الاستضافة أو في غياب التخزين المؤقت للصفحات، ولن تنفع تحسينات الواجهة قبل حلها. وفي دراستي على 138 موقعاً سعودياً كان الوسيط 950 ملي ثانية، واحتاج 18.1% من المواقع 1.8 ثانية أو أكثر.
2. تأخر بدء التحميل: المتصفح اكتشف الصورة الرئيسية متأخراً، لأنها تُحمَّل عبر JavaScript أو عليها تحميل كسول وهي في الشاشة الأولى.
3. مدة التحميل: الصورة نفسها ثقيلة أو أكبر من مقاس العرض. صيغة WebP أو AVIF بالمقاس الصحيح تحل أغلب الحالات، وفصّلت ذلك في دليل تحسين الصور والفيديو.
4. تأخر الرسم: الصورة وصلت، لكن المتصفح ينتظر ملفات CSS أو خطوطاً تحجب العرض، أو سكربتات طويلة تشغل المعالج.

القائمة تبدو نظرية حتى تراها على موقع حقيقي. وهذا ما وجدته في موقعي.

تجربتي: ماذا غيّرت في موقعي وماذا تغيّر في الأرقام

موقعي يعمل على ووردبريس فوق استضافة عادية، بقالب Themify للصفحات وElementor للمقالات، وأمامه Cloudflare على الخطة المجانية. خليط شائع في المواقع العربية، ويصير بطيئاً إن تُرك على إعداداته. لم أشترِ إضافة تسريع ولم أغيّر الاستضافة. هذه التعديلات بالترتيب:

1. تخزين الصفحات العامة في أطراف Cloudflare. أنشأت قاعدة تخزين مؤقت للمقالات وصفحات الخدمات وحدها، تتجاوز الزائر المسجل دخوله ومن ترك تعليقاً وأي رابط فيه معاملات. زمن استجابة الخادم للصفحة نزل من نحو 650 ملي ثانية حين يبنيها ووردبريس إلى أقل من 60 ملي ثانية حين تخرج من النسخة المخزنة.
2. استضافة خط Cairo داخل الموقع. كانت صفحات الخدمات تجلب الخط من Google Fonts عبر سطر @import داخل CSS، وهذا السطر يوقف عرض الصفحة حتى يكتمل التحميل. نقلت الخط إلى الموقع نفسه في ملفين حجمهما 63 كيلوبايت يُحمَّلان مسبقاً، وحذفت من المقالات 86 كيلوبايت من تعريفات خط Roboto لم يكن يستخدمها أي نص.
3. إيقاف قفزة الخط في الرئيسية. اكتشفت أن الرئيسية لم تكن تحمّل خطها إلا عبر سكربت نافذة الدردشة، فيصل متأخراً ويغيّر مقاسات النصوص بعد ظهورها. هذا وحده كان يرفع مؤشر CLS إلى 0.151.
4. تأجيل سكربتات التتبع. صار Google Tag Manager وبكسل Meta يُحمَّلان بعد أن تظهر الصفحة للزائر، بدل أن يزاحماها في الثواني الأولى.
5. إيقاف ما لم ينفع. جربت خيارات تسريع جاهزة في Cloudflare وأوقفت بعضها، لأنها كررت عملاً يقوم به الموقع أصلاً أو سببت أخطاء في تطبيقات أخرى على النطاق نفسه. ليس كل زر مكتوب عليه «تسريع» يسرّع موقعك.

هذه أرقام مختبر، وهي أول ما يتحرك. الحكم الذي يهم Google يأتي من البيانات الميدانية بعد أن تتراكم زيارات 28 يوماً على النسخة الجديدة. وعلى الكمبيوتر حصلت الرئيسية وصفحة الخدمة على 100 في الفئات الأربع.

تحسين سرعة الموقع حسب المنصة

الخطوات العامة واحدة، لكن ما تملك تغييره يختلف من منصة لأخرى. اختر منصتك:

وإذا لم تختر منصتك بعد، قارنت بين سلة وزد وشوبيفاي وووكومرس في دليل فتح متجر إلكتروني في السعودية، مع الشروط والتكلفة وخطوات الإطلاق.

السرعة وزواحف الذكاء الاصطناعي

كل حديث عن السرعة يدور حول الزائر البشري، لكن جزءاً متزايداً من الطلبات على موقعك يأتي من برامج تقرأ صفحاتك لتجيب منها في ChatGPT وPerplexity وبحث Google بالذكاء الاصطناعي. هذه أعداد الطلبات الناجحة على موقعي خلال سبعة أيام من نوفمبر 2026، بحسب اسم الزاحف في سجلات Cloudflare:

Google تربط مقدار زحفها بسرعة استجابة خادمك صراحة، كما ذكرت في أول المقال، والإجابات الذكية في بحثها تُبنى من الصفحات التي فهرسها Googlebot. فالسرعة هنا تخدم ظهورك في النتائج العادية والذكية معاً.

ودراسة نشرتها Vercel وجدت أن زواحف OpenAI وAnthropic وPerplexity تجلب ملفات JavaScript لكنها لا تشغّلها. أي أنها ترى HTML كما يرسله خادمك في الطلب الأول، والمحتوى الذي لا يظهر إلا بعد تشغيل سكربت قد لا تراه أصلاً. الصفحة التي تصل كاملة وسريعة في HTML تخدم الزائر والزاحف في وقت واحد، وهي نقطة أساسية في طريقة جعل ChatGPT يقتبس موقعك.

وفي 2026 أضافت Google إلى Lighthouse فئة تجريبية تفحص جاهزية الصفحة لمساعدات الذكاء الاصطناعي التي تتصفح المواقع: سلامة شجرة الوصول، وثبات التصميم، وملف llms.txt، وأدوات WebMCP. ظهرت هذه الفئة في PageSpeed Insights، ومنها جاء السطر الأحمر الذي بدأت به هذا الدليل.

خطة تحسين سرعة الموقع في 7 خطوات مرتبة بالأثر

1. اقرأ البيانات الميدانية في PageSpeed Insights وSearch Console، وحدد أي مؤشر يفشل وفي أي قالب.
2. قِس زمن أول بايت. إن تجاوز 0.8 ثانية فابدأ بالتخزين المؤقت والاستضافة قبل أي شيء آخر.
3. حدد عنصر LCP في كل قالب، واجعله يُحمَّل مبكراً: بلا تحميل كسول، وبأولوية عالية، وبحجم مناسب.
4. نظّف ما يحجب العرض: خطوط من خوادم خارجية، وملفات CSS لإضافات لا تعمل في الصفحة.
5. راجع السكربتات الخارجية واحداً واحداً: ما الذي يُستخدم فعلاً؟ وما الذي يمكن تأجيله؟
6. ثبّت التصميم: أبعاد لكل صورة وإطار، ومساحة محجوزة لأي عنصر يظهر متأخراً.
7. انتظر 28 يوماً ثم قارن البيانات الميدانية. تحسن المختبر يظهر فوراً، أما حكم Google فيتبع الزيارات الحقيقية.

متى تحتاج خبيراً لتحسين سرعة موقعك؟

أغلب ما في هذا الدليل يستطيع صاحب الموقع تنفيذه بنفسه. تحتاج مساعدة متخصصة في حالات محددة:

• تفشل البيانات الميدانية شهرين متتاليين رغم أن نتيجة المختبر جيدة.
• يتجاوز زمن أول بايت ثانية كاملة، ولا تعرف هل المشكلة في الاستضافة أم في الموقع.
• متجرك على سلة أو زد أو شوبيفاي ومليء بتطبيقات لا تعرف أيها يبطئه.
• تحتاج تعديلات في القالب أو في Cloudflare ولا تريد المخاطرة بكسر شيء.

عملي في هذه الحالات يبدأ بتشخيص مكتوب مرتب بالأولوية، ثم تنفيذ ما يلزم، ثم قياس قبل وبعد بالأرقام كما فعلت في موقعي. والسرعة عندي جزء من خدمة تحسين السيو التقني، لأن الصفحة السريعة التي لا تُفهرس لا تنفع، والصفحة المفهرسة البطيئة تخسر من يصل إليها. وإن كان موقعك متجراً فهي جزء من سيو المتاجر الإلكترونية أيضاً.

أسئلة شائعة عن سرعة الموقع

المصادر: توثيق Google عن تجربة الصفحة في نتائج البحث وعن ميزانية الزحف، وشرح web.dev بالعربية عن مؤشرات أداء الويب الأساسية وعن زمن أول بايت، ودراستا Deloitte لصالح Google وVodafone، ومساعدة Shopify عن تقارير أداء الويب، ودراسة Vercel عن زواحف الذكاء الاصطناعي، وشرح DebugBear لفئة Lighthouse الجديدة.