سرعة الموقع: دليل عملي لقياسها وتحسينها وفق مؤشرات Core Web Vitals

2026-10-18 Sunday

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

نكتب هذا الدليل من زاوية السيو التقني (Technical SEO)، أي ما يحتاجه صاحب الموقع ومسؤول التسويق ليعرف أين تقف صفحاته وما الذي يستحق الإصلاح أولًا، دون أن يغرق في تفاصيل برمجية لا تخصه.

محتويات المقال

  1. ما هي سرعة الموقع؟

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

  3. كيف تجري اختبار سرعة الموقع وتقرأ نتائجه؟

  4. كيف تحسن سرعة الموقع خطوة بخطوة؟

  5. ما الأخطاء الشائعة عند تحسين سرعة الموقع؟

  6. كيف يعمل فريق رابح على سرعة الموقع ضمن مشاريع السيو؟

  7. الأسئلة الشائعة حول سرعة الموقع

ما هي سرعة الموقع؟

سرعة الموقع (Page Speed) هي الوقت والجهد اللذان يحتاجهما المتصفح ليعرض الصفحة للزائر ويجعلها قابلة للاستخدام. وتقيسها Google اليوم بثلاثة مؤشرات تسمى مؤشرات أداء الويب الأساسية (Core Web Vitals): سرعة ظهور المحتوى الرئيسي، وسرعة الاستجابة للتفاعل، وثبات التصميم أثناء التحميل، وكلها تُقاس أساسًا من تجارب زوار حقيقيين.

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

مؤشرات Core Web Vitals الثلاثة وحدودها

يحدد دليل مؤشرات أداء الويب على موقع web.dev ثلاث فئات لكل مؤشر: جيد، ويحتاج إلى تحسين، وضعيف. والحدود المعتمدة حاليًا لكل مؤشر من المؤشرات الثلاثة كالتالي:

> 1. LCP (أكبر عرض للمحتوى): يقيس سرعة ظهور أكبر عنصر مرئي، وغالبًا يكون الصورة الرئيسية أو العنوان. جيد حتى 2.5 ثانية، وضعيف فوق 4 ثوانٍ.

> 2. INP (التفاعل حتى العرض التالي): يقيس سرعة استجابة الصفحة للنقر واللمس والكتابة طوال الزيارة. جيد حتى 200 مللي ثانية، وضعيف فوق 500 مللي ثانية.

> 3. CLS (متغير التصميم التراكمي): يقيس مقدار تحرك العناصر بشكل غير متوقع أثناء التصفح. جيد حتى 0.1، وضعيف فوق 0.25.

والمعيار هنا ليس متوسط الزيارات، بل الشريحة المئوية 75 (75th percentile)؛ أي أن الصفحة تُصنف جيدة في التقرير إذا حقق 75% من زياراتها على الأقل الحد المطلوب، ويُقاس ذلك للجوال وسطح المكتب كلٌّ على حدة. وهي الحدود نفسها التي نعتمدها نحن أيضًا في دليلنا الشامل عن تهيئة المواقع لمحركات البحث.

وإذا صادفت مقالات ما زالت تشرح مؤشر FID فهي قديمة؛ إذ أعلن فريق Chrome في 12 مارس 2024 اعتماد INP مؤشرًا أساسيًا مستقرًا بدلًا منه. والفرق جوهري: FID كان يقيس تأخر أول تفاعل فقط، بينما يقيس INP الاستجابة في التفاعلات على امتداد الزيارة.

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

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

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

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

أثر السرعة على الزائر والتحويلات

في بحث نشرته Think with Google استنادًا إلى بيانات Google/SOASTA لعام 2017، توقع نموذج تعلم آلي أن احتمال مغادرة زائر الجوال يرتفع بنسبة 123% عندما يزيد زمن تحميل الصفحة من ثانية إلى عشر ثوانٍ. الرقم قديم نسبيًا ومبني على نموذج تنبؤي لا على قياس مباشر لموقعك، لكنه يوضح الاتجاه العام.

وفي الإعلانات المدفوعة يتضاعف الأثر لأنك تدفع ثمن كل نقرة. يذكر مركز مساعدة Google Ads أن تأخير ثانية واحدة على الجوال قد يؤثر في التحويلات بنسبة تصل إلى 20%.

سرعة الموقع والجوال في السوق السعودي

تشير بيانات DataReportal المستندة إلى قياسات Ookla إلى أن متوسط سرعة تنزيل الإنترنت عبر الجوال في السعودية بلغ نحو 194 ميجابت في الثانية في أغسطس 2025. معنى ذلك أن البطء في أغلب الحالات لا يأتي من الشبكة، بل من الموقع نفسه: خادم بطيء الاستجابة، أو صور ضخمة، أو أكواد JavaScript ثقيلة يعالجها معالج الجوال.

ويوضح دليل Google عن الفهرسة مع إعطاء الأولوية للجوال أن Google تعتمد على نسخة الجوال من صفحاتك في الفهرسة والترتيب.

لذلك ابدأ بنتائج الجوال عند تحسين السيو للجوال (Mobile SEO)، فهي النسخة التي يعتمد عليها الزاحف في أرشفة موقعك في محركات البحث، حتى لو كان فريقك يتصفح الموقع من الحاسوب.

كيف تجري اختبار سرعة الموقع وتقرأ نتائجه؟

اختبار سرعة الموقع

ابدأ بأداة PageSpeed Insights لفحص صفحة محددة، ثم انتقل إلى تقرير مؤشرات أداء الويب الأساسية في Google Search Console لرؤية الموقع كاملًا. وفرّق دائمًا بين بيانات المستخدمين الحقيقيين (Field Data) التي تعتمد عليها Google، وبيانات المختبر (Lab Data) التي تساعدك على تشخيص السبب.

> 1. افحص القوالب لا الصفحة الرئيسية فقط: اختر الرئيسية، وصفحة خدمة أو تصنيف، وصفحة منتج أو مقال، فلكل قالب مشكلاته الخاصة.

> 2. اقرأ بيانات المستخدمين أولًا: القسم العلوي في التقرير يوضح هل اجتازت الصفحة تقييم Core Web Vitals أم لا.

> 3. انتقل إلى تشخيص المختبر: القسم السفلي يقترح فرص التحسين ويحدد العنصر المسؤول عن LCP والملفات التي تعطل العرض.

> 4. راجع تقرير Search Console: لتعرف عدد الصفحات المتأثرة بكل مشكلة بدل فحص الصفحات واحدة تلو الأخرى.

> 5. وثّق النتائج بتاريخها: احفظ لقطة من القياس قبل أي تعديل، حتى تقارن بدقة بعد الإصلاح.

قبل أي إصلاح، قارن في google analytics معدل التفاعل ومعدل التحويل لصفحات الهبوط البطيئة والسريعة، لترتب الأولويات حسب أثرها على المبيعات لا حسب لون المؤشر.

توضح وثائق PageSpeed Insights أن بيانات المستخدمين الحقيقيين تأتي من تقرير تجربة مستخدمي Chrome (CrUX) وتغطي آخر 28 يومًا. وإذا لم تتوفر بيانات كافية للصفحة تعرض بيانات النطاق كله.

أما درجة الأداء من 100 أعلى قسم المختبر فهي ناتجة عن اختبار Lighthouse في بيئة محاكاة بجهاز وشبكة محددين، لذلك تتغير من فحص لآخر. استخدمها لتعرف الفرص المقترحة، واحكم على النجاح من بيانات المستخدمين.

وفي تقرير مؤشرات أداء الويب الأساسية داخل Search Console تُجمع الصفحات المتشابهة في مجموعات، وتأخذ كل مجموعة حالة: جيدة أو تحتاج إلى تحسين أو ضعيفة، للجوال وسطح المكتب كلٍّ على حدة. وبعد الإصلاح تضغط زر بدء التتبع، فتراقب Google الصفحات مدة 28 يومًا قبل اعتبار المشكلة محلولة.

كيف تحسن سرعة الموقع خطوة بخطوة؟

حدد أولًا المؤشر الضعيف، ثم عالج سببه المباشر: LCP يرتبط غالبًا بالخادم والصورة الرئيسية، وINP بأكواد JavaScript الثقيلة والسكربتات الخارجية، وCLS بعناصر تظهر دون مساحة محجوزة. هذا الترتيب يوفر وقتك بدل تطبيق قائمة نصائح عامة قد لا تمس المشكلة الحقيقية في موقعك أصلًا.

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

تحسين LCP: ظهور المحتوى الرئيسي

يقسم دليل تحسين LCP زمن هذا المؤشر إلى أربعة أجزاء: زمن وصول أول بايت من الخادم (TTFB)، وتأخر بدء تحميل العنصر، ومدة تحميله، وتأخر عرضه. ومن هذا التقسيم تخرج خطوات عملية واضحة:

> 1. قلّل زمن استجابة الخادم: باستضافة تناسب حجم الزيارات، وتخزين مؤقت (Cache) للصفحات، وشبكة توصيل محتوى (CDN) لها نقاط قريبة من جمهورك.

> 2. لا تؤجل تحميل الصورة الرئيسية: التحميل الكسول (Lazy Loading) مفيد للصور أسفل الصفحة فقط، أما تأجيل صورة الواجهة فيبطئ LCP دائمًا.

> 3. امنح الصورة الرئيسية أولوية: بالخاصية fetchpriority="high"، وتأكد من أن رابطها موجود في كود HTML ولا يُضاف لاحقًا عبر JavaScript.

> 4. استخدم صيغًا حديثة: مثل WebP وAVIF، بأبعاد تناسب شاشة الجوال بدل رفع صورة بعرض آلاف البكسلات.

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

تحسين INP: سرعة الاستجابة

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

> 1. راجع السكربتات الخارجية: أدوات الدردشة وأكواد التتبع القديمة والإضافات التي لم تعد تستخدمها.

> 2. قسّم المهام الطويلة: ليتمكن المتصفح من الاستجابة للمس بين أجزاء العمل.

> 3. قلّل حجم DOM: الصفحات التي تضم آلاف العناصر تحتاج وقتًا أطول لإعادة العرض بعد كل تفاعل.

تحسين CLS: ثبات التصميم

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

المتاجر على المنصات الجاهزة

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

ما الأخطاء الشائعة عند تحسين سرعة الموقع؟

أكثر الأخطاء شيوعًا مطاردة درجة 100 في PageSpeed Insights بدل تحسين تجربة المستخدمين الحقيقيين، واختبار الصفحة الرئيسية على سطح المكتب فقط، وتثبيت أدوات تسريع متعددة تتعارض فيما بينها. والنتيجة جهد كبير لا ينعكس على تقرير Search Console ولا على المبيعات في نهاية الشهر.

> * الاعتماد على درجة المختبر وحدها: وتجاهل بيانات المستخدمين الحقيقيين التي تعتمد عليها Google.

> * اختبار سطح المكتب فقط: بينما أغلب زوارك يتصفحون من الجوال.

> * تأجيل تحميل صورة الواجهة: فيتأخر LCP بدل أن يتحسن.

> * تكديس إضافات التسريع: إضافتان للتخزين المؤقت أو لضغط الملفات تسببان تعارضًا وأخطاء في العرض.

> * إهمال السكربتات الخارجية: أكواد تتبع وإعلانات وتطبيقات دردشة تتراكم دون مراجعة دورية.

> * قياس مرة واحدة ثم النسيان: كل قالب جديد أو حملة موسمية أو تطبيق مضاف قد يعيد المشكلة.

> * التضحية بالمحتوى من أجل الرقم: حذف أقسام مفيدة أو صور منتجات أساسية لتحسين النتيجة.

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

كيف يعمل فريق رابح على سرعة الموقع ضمن مشاريع السيو؟

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

وتختلف المعالجة باختلاف نوع النشاط والمنصة، وهذه ثلاثة سيناريوهات نصادفها كثيرًا:

> * متجر إلكتروني في الرياض: LCP ضعيف على الجوال بسبب بانرات عروض ضخمة في الواجهة؛ نعيد تجهيز الصور بصيغ حديثة وأبعاد مناسبة، ونمنح صورة الواجهة الأولوية، ونتابع مجموعة صفحات المنتجات في التقرير.

> * عيادة في جدة: INP ضعيف لأن أداة الحجز وأكواد التتبع تعمل كلها عند فتح الصفحة؛ نراجع السكربتات مع فريق العيادة، ونحذف المكرر منها، ونؤخر غير الضروري.

> * شركة في القاهرة: CLS مرتفع بسبب الخط العربي وشريط ملفات تعريف الارتباط؛ نحجز مساحة ثابتة للشريط، ونضبط تحميل الخط حتى تستقر النصوص.

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

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

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

إذا كان تقرير Search Console يُظهر صفحات ضعيفة على الجوال ولا تعرف من أين تبدأ، فخدمة تحليل المواقع لدى رابح تفحص مؤشرات LCP وINP وCLS لأهم قوالب موقعك، وتخرج بقائمة إصلاحات مرتبة حسب الأثر؛ أرسل رابط موقعك مع الطلب لنبدأ التشخيص.

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

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

ما السرعة المثالية لتحميل الموقع؟

لا يوجد رقم واحد لزمن التحميل الكامل، لكن الهدف العملي أن يظهر المحتوى الرئيسي خلال 2.5 ثانية، وأن تستجيب الصفحة للتفاعل خلال 200 مللي ثانية، وألا يتجاوز CLS قيمة 0.1 لـ 75% من الزيارات.

ما الفرق بين PageSpeed Insights وتقرير Search Console؟

PageSpeed Insights يفحص صفحة واحدة ويعرض بيانات حقيقية وبيانات مختبر معًا، بينما يعرض تقرير Search Console حالة مجموعات الصفحات في الموقع كله اعتمادًا على البيانات الحقيقية فقط.

هل تؤثر سرعة صفحة الهبوط على إعلانات جوجل؟

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

هل الحصول على درجة 100 ضروري؟

لا. الدرجة مؤشر مختبري للمساعدة في التشخيص، والمهم أن تجتاز الصفحات حدود Core Web Vitals في بيانات المستخدمين الحقيقيين، وأن يبقى المحتوى مفيدًا وكاملًا.

ما المؤشر الذي حل محل FID؟

حل مؤشر INP محل FID في 12 مارس 2024. ويقيس INP سرعة الاستجابة في التفاعلات على امتداد الزيارة، لا في أول تفاعل فقط.

لماذا لا تظهر بيانات المستخدمين الحقيقيين لموقعي؟

لأن عدد الزيارات المسجلة في تقرير CrUX غير كافٍ بعد، وهذا شائع في المواقع الجديدة أو الصغيرة. اعتمد مؤقتًا على بيانات المختبر، وعلى أداة Lighthouse في متصفح Chrome، حتى تتراكم البيانات.

هل أحتاج إلى CDN إذا كان جمهوري في السعودية فقط؟

يعتمد ذلك على موقع الخادم وزمن الاستجابة الفعلي. افحص قيمة TTFB لزوارك؛ فإذا كانت مرتفعة لأن الخادم بعيد جغرافيًا، فشبكة توصيل محتوى لها نقاط قريبة من جمهورك قد تحسن LCP بوضوح.

هل أستطيع تحسين سرعة موقعي بنفسي؟

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

كم يستغرق ظهور أثر التحسين في Search Console؟

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

لماذا تختلف نتيجة اختبار سرعة الموقع من فحص لآخر؟

لأن درجة المختبر تتأثر بحالة الخادم والشبكة وقت الفحص والسكربتات الخارجية المتغيرة. لذلك قارن عدة فحوص، واعتمد على بيانات المستخدمين الحقيقيين لآخر 28 يومًا عند الحكم على التحسن.


مصر جدة الرياض