إذا كان متجرك يأخذ وقتًا طويلًا قبل أن تظهر صورة المنتج على هاتف الزائر، فأنت تدفع ثمن ذلك مرتين: مرة في الزوار الذين يغادرون قبل أن يروا شيئًا، ومرة في الإعلانات التي دفعت لتجلبهم. لهذا لم يعد تحسين سرعة الموقع مهمة تقنية جانبية، بل جزء من إدارة المتجر نفسه.
في هذا الدليل نشرح كيف تقيس سرعة الموقع بالأدوات الرسمية من جوجل، وما معنى مؤشرات Core Web Vitals (مؤشرات أداء الويب الأساسية) وحدودها الرسمية التي يُقاس بها تحسين سرعة الموقع، وما أكبر المكاسب المتاحة لمتاجر سلة وزد وشوبيفاي، وكم تؤثر السرعة في ترتيبك على جوجل فعلًا دون مبالغة.
كل رقم في هذا المقال مأخوذ من صفحات جوجل الرسمية (web.dev وGoogle Search Central ومساعدة Search Console) كما راجعناها في أكتوبر 2026، مع روابطها. هذه المعايير تتغير أحيانًا، لذلك ارجع إلى المصدر قبل أي قرار كبير.
لماذا تهمك سرعة تحميل الموقع في المبيعات؟
المتسوق الذي يضغط على إعلان أو نتيجة بحث يتوقع أن يرى المنتج فورًا. كل ثانية انتظار تعطيه فرصة للتراجع والعودة إلى المنصة التي جاء منها. وكلما كانت الرحلة من الإعلان إلى الدفع أطول وأبطأ، زادت نقاط التسرب في الطريق.
لن نعطيك نسبة مئوية عن «كم تخسر مع كل ثانية»، لأن هذه الأرقام تختلف كثيرًا بين المتاجر والقطاعات ولا يوجد رقم رسمي واحد ينطبق عليك. ما يحدد أثر البطء على متجرك هو: مصدر الزيارات، ونوع الجهاز، وسعر المنتج، ومدى تعلق الزائر بعلامتك.
ما تقوله شوبيفاي في صفحة مساعدتها الرسمية واضح: تحسين أداء المتجر «يمكن أن يحسن تجربة التسوق» ويساعد على الظهور وعلى رفع معدل التحويل. ونحن نرى عادة نمطًا مشابهًا: المتاجر البطيئة تخسر جزءًا من زوار الإعلانات قبل أن تُحتسب لهم حتى مشاهدة صفحة.
تحسين سرعة الموقع والإعلانات المدفوعة
إذا كنت تدفع على إعلانات سناب شات أو تيك توك أو جوجل، فإن صفحة الهبوط البطيئة ترفع تكلفة كل عملية بيع عمليًا، لأنك تدفع ثمن النقرة نفسها مهما كانت نتيجتها. لهذا يفيد ربط تحسين سرعة الموقع بحساب العائد الحقيقي كما شرحنا في دليل حساب ROAS.
والبطء في صفحة الدفع تحديدًا من أسباب ترك السلة. إذا كانت سلالك المتروكة كثيرة، فراجع أيضًا دليل استرجاع السلات المتروكة لأن السرعة جزء واحد فقط من المشكلة هناك.
مؤشرات Core Web Vitals: المعايير الرسمية من جوجل
تقيس جوجل تجربة التحميل بثلاثة مؤشرات أساسية. كل مؤشر يجيب عن سؤال بسيط يطرحه الزائر دون أن يدري: هل ظهر المحتوى؟ هل استجابت الصفحة عندما ضغطت؟ هل تحركت الأشياء تحت إصبعي؟
LCP: متى يظهر أكبر عنصر في الصفحة؟
مؤشر Largest Contentful Paint يقيس الوقت حتى يظهر أكبر عنصر مرئي في الشاشة الأولى، وغالبًا ما يكون صورة المنتج الرئيسية أو بانر الصفحة الرئيسية. حسب صفحة web.dev الرسمية، يجب أن يحدث خلال 2.5 ثانية من بداية تحميل الصفحة.
INP: هل تستجيب الصفحة بسرعة عند النقر؟
مؤشر Interaction to Next Paint يقيس زمن الاستجابة لتفاعلات الزائر طوال الزيارة، مثل الضغط على زر «أضف إلى السلة» أو فتح قائمة المقاسات. الهدف الرسمي 200 ملي ثانية أو أقل. وقد أصبح INP مؤشرًا أساسيًا ثابتًا في 2024 بدلًا من مؤشر FID القديم.
CLS: هل تقفز عناصر الصفحة أثناء التحميل؟
مؤشر Cumulative Layout Shift يقيس مقدار تحرك العناصر بشكل غير متوقع. المثال الكلاسيكي: تهم بالضغط على زر الشراء فينزل الزر لأن بانرًا ظهر فوقه فجأة. الهدف الرسمي 0.1 أو أقل.
جدول الحدود الرسمية
هذه الحدود منقولة من صفحة توثيق PageSpeed Insights على موقع مطوري جوجل (أكتوبر 2026)، وتُقاس عند الشريحة المئوية 75 من زيارات المستخدمين الحقيقيين، مع فصل الجوال عن الكمبيوتر:
| المؤشر | جيد | يحتاج إلى تحسين | ضعيف |
|---|---|---|---|
| LCP (التحميل) | حتى 2.5 ثانية | من 2.5 إلى 4 ثوانٍ | أكثر من 4 ثوانٍ |
| INP (الاستجابة) | حتى 200 ملي ثانية | من 200 إلى 500 ملي ثانية | أكثر من 500 ملي ثانية |
| CLS (الثبات البصري) | حتى 0.1 | من 0.1 إلى 0.25 | أكثر من 0.25 |
معنى الشريحة 75: يجب أن تحصل ثلاثة أرباع زيارات الصفحة على الأقل على تجربة ضمن الحد «الجيد». وتنجح الصفحة في التقييم عندما تحقق المؤشرات الثلاثة معًا هذا الشرط، كما تشرح صفحة Web Vitals على web.dev.
قياس سرعة الموقع: كيف تفحص متجرك بأدوات جوجل
قبل أن تبدأ أي تحسين سرعة الموقع، تحتاج إلى قياس صحيح تعود إليه بعد كل تعديل. أفضل ادوات سرعة الموقع للبداية مجانية ومن جوجل نفسها: PageSpeed Insights وتقرير Core Web Vitals في Search Console.
فحص سرعة الموقع جوجل عبر PageSpeed Insights خطوة بخطوة
- افتح PageSpeed Insights والصق رابط الصفحة، وليس الصفحة الرئيسية فقط.
- افحص ثلاث صفحات على الأقل: الرئيسية، وصفحة تصنيف مزدحمة، وصفحة منتج من الأكثر مبيعًا.
- ابدأ بتبويب الجوال، لأنه الأقرب إلى زوارك الحقيقيين في الخليج.
- اقرأ القسم العلوي أولًا: هل توجد بيانات من المستخدمين الحقيقيين؟ وهل اجتازت الصفحة تقييم Core Web Vitals؟
- انتقل بعدها إلى قسم التشخيص وانظر إلى عنصر LCP المحدد في الصفحة، وإلى قائمة الفرص المقترحة.
- سجل النتائج في جدول بسيط بتاريخ الفحص، حتى تقارن بعد كل خطوة في تحسين سرعة الموقع بدل الاعتماد على الذاكرة.
بيانات الميدان مقابل بيانات المختبر
هنا يقع أكثر أصحاب المتاجر في الخلط. يعرض PageSpeed Insights نوعين من البيانات، ولكل منهما وظيفة مختلفة كما يوضح توثيق PageSpeed Insights:
| النقطة | بيانات الميدان (Field) | بيانات المختبر (Lab) |
|---|---|---|
| المصدر | تقرير تجربة مستخدمي Chrome (CrUX) من زوار حقيقيين | محاكاة عبر Lighthouse على جهاز وشبكة افتراضيين |
| الفترة | آخر 28 يومًا | لحظة الفحص فقط |
| الاستخدام الأفضل | الحكم على نتيجة تحسين سرعة الموقع كما يعيشها زوارك | تشخيص السبب واختبار التعديلات |
| هل تتغير بسرعة؟ | ببطء، لأنها متوسط شهر تقريبًا | فورًا مع كل فحص |
أما الدرجة من 100 التي يحب الجميع مشاركتها فهي درجة المختبر. حسب التوثيق نفسه، 90 فما فوق تعتبر جيدة، ومن 50 إلى 89 تحتاج إلى تحسين، وأقل من 50 ضعيفة. لكنها ليست ما يعيشه زوارك، فلا تجعلها هدفك الوحيد.
تقرير Core Web Vitals في Search Console
إذا كان متجرك مضافًا إلى Search Console، فستجد تقرير Core Web Vitals الذي يعتمد على بيانات CrUX الميدانية. حسب صفحة مساعدة Search Console، يجمع التقرير الصفحات المتشابهة في مجموعات، ويعطي كل مجموعة حالة «جيدة» أو «تحتاج إلى تحسين» أو «ضعيفة» بحسب أسوأ مؤشر فيها، ويفصل الجوال عن الكمبيوتر.
بعد إصلاح مشكلة، اضغط على زر بدء التتبع لتبدأ جلسة مراقبة مدتها 28 يومًا. ولا تقلق إذا لم تجد بيانات، فالتقرير لا يعرض الصفحات التي لا تملك زيارات كافية، وهذا شائع في المتاجر الجديدة. في هذه الحالة اعتمد على بيانات المختبر مؤقتًا.

تحسين سرعة الموقع للمتاجر: أكبر المكاسب أولًا
لا تحاول إصلاح كل ما يقترحه PageSpeed Insights دفعة واحدة، لأن تحسين سرعة الموقع يعطي أفضل نتيجة عندما تبدأ بالأثقل. في المتاجر الإلكترونية، يأتي معظم البطء عادة من عدد محدود من المصادر: الصور، والتطبيقات والسكربتات، والخطوط، والاستضافة. ابدأ بها بهذا الترتيب.
1. الصور: صيغة WebP والمقاسات الصحيحة
أسرع طريق إلى تحسين سرعة الموقع في أغلب المتاجر يبدأ من الصور. فالصور هي أكبر جزء من وزن معظم صفحات المتاجر، وتذكر جوجل في إرشادات صور البحث أن الصور كثيرًا ما تكون العامل الأكبر في وزن الصفحة. محركات البحث تدعم WebP وAVIF، لذلك لا يوجد سبب لرفع صور PNG ضخمة لمنتجات مصورة.
- ارفع الصورة بمقاس قريب من مقاس عرضها الفعلي، لا صورة بدقة الكاميرا الأصلية.
- استخدم WebP أو AVIF للصور الفوتوغرافية، مع ضغط معقول لا يفسد التفاصيل.
- لا تؤجل تحميل صورة المنتج الرئيسية أو بانر الصفحة الأولى، فهذه غالبًا عنصر LCP. التحميل المؤجل loading=”lazy” مخصص للصور التي تحت الشاشة الأولى فقط.
- حدد عرض الصورة وارتفاعها في الكود، حتى يحجز المتصفح مكانها ولا تقفز الصفحة.
- قلل عدد الشرائح في السلايدر الرئيسي؛ شريحة واحدة قوية أسرع من ست شرائح ثقيلة.
وتنصح web.dev أيضًا باستخدام fetchpriority=”high” على صورة LCP المرجحة فقط، لا على كل الصور، لأن الإفراط فيه يلغي أثره.
2. تحسين سرعة الموقع في سلة وزد وشوبيفاي: التطبيقات والسكربتات
كل تطبيق تضيفه إلى متجرك، من نوافذ الخصم المنبثقة إلى عجلة الحظ وأدوات التقييمات والدردشة، قد يضيف سكربتات يجب على المتصفح تحميلها وتنفيذها. وهذا يضر بـ LCP وINP معًا.
تقول صفحة تحسين الأداء في مساعدة شوبيفاي بوضوح: راجع التطبيقات المثبتة وأزل ما ليس ضروريًا للمبيعات، وانتبه إلى أن حذف التطبيق لا يحذف كوده من القالب تلقائيًا. والمبدأ نفسه ينطبق على سلة وزد: كل إضافة تعرض شيئًا على واجهة المتجر لها كلفة أداء.
- اكتب قائمة بكل تطبيق ظاهر للزائر، واسأل عن كل واحد: هل جلب مبيعات فعلية في آخر 90 يومًا؟
- راجع مدير الوسوم (Tag Manager) واحذف البكسلات والوسوم المكررة أو القديمة.
- لا تضع أكثر من أداة دردشة أو أداة نوافذ منبثقة في الوقت نفسه.
- بعد حذف أي تطبيق، افحص الصفحة مرة أخرى للتأكد أن كوده لم يبق في القالب.
تتبع الإعلانات مهم ولا نطلب منك حذفه، لكن تكرار البكسل نفسه عبر تطبيقين مختلفين شائع ويبطئ الصفحة ويشوه الأرقام معًا. ضبط التتبع بشكل صحيح موضوع مستقل نتناوله في دليل تتبع التحويلات.
3. الخطوط العربية ودورها في تحسين سرعة الموقع
الخطوط العربية غالبًا أثقل من اللاتينية لأنها تحتوي على أشكال حروف أكثر. وكثير من المتاجر تحمل ثلاثة أو أربعة أوزان من خطين مختلفين دون حاجة. حسب إرشادات الخطوط في web.dev:
- استخدم صيغة WOFF2 فقط.
- قلل عدد الخطوط والأوزان؛ وزنان من خط واحد يكفيان أغلب المتاجر.
- استخدم font-display لتظهر النصوص سريعًا بدل بقائها مخفية.
- حمل مسبقًا (preload) الخط الأهم فقط، لا كل الخطوط.
- استخدم تقسيم الخط (subset) بحيث لا يُحمَّل إلا ما تحتاجه الصفحة من حروف.
وتلخص web.dev الفكرة في جملة واحدة: أسرع خط هو الخط الذي لا يُطلب أصلًا.
4. الاستضافة وزمن الاستجابة الأول TTFB
زمن الاستجابة الأول (TTFB) هو الوقت حتى يصل أول بايت من الصفحة إلى المتصفح. حسب web.dev، يُفضل أن يكون 0.8 ثانية أو أقل لمعظم المواقع. وهو ليس من مؤشرات Core Web Vitals، لكنه يضاف مباشرة إلى زمن LCP.
إذا كان متجرك على منصة جاهزة مثل سلة أو زد أو شوبيفاي، فالاستضافة بيد المنصة غالبًا، وما تتحكم فيه هو وزن القالب والتطبيقات والصور. أما إذا كان متجرك على ووردبريس أو كود خاص، فالاستضافة الرخيصة المشتركة سبب شائع للبطء، كما تذكر صفحة تحسين TTFB على web.dev.
وتجنب سلاسل التحويل: من http إلى https ثم إلى www ثم إلى رابط بشرطة مائلة. كل تحويل يضيف وقتًا قبل أن يبدأ التحميل الحقيقي، وأعط المعلنين والنشرات البريدية الرابط النهائي مباشرة.

5. التخزين المؤقت وشبكة توصيل المحتوى CDN
شبكة توصيل المحتوى (CDN) تخزن نسخًا من ملفات موقعك على خوادم أقرب إلى الزائر. إذا كان خادمك في أوروبا وزبائنك في الرياض ودبي، فإن المسافة نفسها تضيف وقتًا. وتوضح web.dev أن الزوار البعيدين عن الخادم الأصلي قد يعانون من TTFB مرتفع حتى لو كان الخادم نفسه سريعًا.
- فعل التخزين المؤقت للملفات الثابتة (الصور والخطوط وملفات CSS وJS) لمدة طويلة.
- خزن صفحات HTML العامة مؤقتًا على الشبكة عند الإمكان، ولو لفترات قصيرة.
- لا تخزن الصفحات الشخصية مثل السلة وحساب العميل.
- عند القياس، تذكر أن التخزين المؤقت قد يخفي بطء الخادم، فاختبر أيضًا دونه.
6. ثبات الصفحة: منع القفزات المزعجة
أسباب CLS في المتاجر متكررة: صور بلا أبعاد محددة، وشريط عروض يظهر أعلى الصفحة بعد التحميل، ونوافذ أو بانرات تدفع المحتوى للأسفل، وخطوط تتبدل بعد ظهور النص. الحل حسب دليل CLS على web.dev هو حجز المساحة مسبقًا لكل عنصر سيظهر لاحقًا، وعرض الإشعارات فوق المحتوى لا داخله.
7. سرعة الاستجابة عند النقر
إذا كانت الصفحة تظهر سريعًا لكن زر «أضف إلى السلة» يتأخر في الاستجابة، فالمشكلة في INP. السبب الأكثر شيوعًا هو كثرة الجافاسكربت التي تشغل المتصفح، وأغلبها في المتاجر يأتي من التطبيقات الخارجية. لذلك فإن تنظيف التطبيقات في الخطوة الثانية يحسن INP غالبًا أكثر من أي تعديل آخر.
ما الذي تتحكم فيه على كل منصة؟
تحسين سرعة الموقع يختلف حسب نوع المنصة. هذا الجدول يلخص أين تقع مسؤوليتك عادة؛ وقد تتغير خصائص المنصات، فراجع مساعدة منصتك قبل أي تعديل:
| العنصر | سلة وزد | شوبيفاي | ووردبريس أو كود خاص |
|---|---|---|---|
| الاستضافة وCDN | تديرها المنصة غالبًا | تديرها المنصة | مسؤوليتك بالكامل، وهي أساس تحسين سرعة الموقع |
| القالب | تختار وتخصص ضمن خيارات المنصة | تختار القالب وتعدل الكود | تحكم كامل |
| التطبيقات والإضافات | من متجر تطبيقات المنصة | من متجر تطبيقات شوبيفاي | إضافات ووردبريس أو برمجة خاصة |
| الصور | مسؤوليتك في الرفع والمقاس | مسؤوليتك في الرفع والمقاس | مسؤوليتك بالكامل |
| الخطوط | ضمن خيارات القالب | ضمن القالب أو الكود | تحكم كامل |
إذا كنت ما زلت تختار المنصة، فالمقارنة بين سلة وزد وشوبيفاي موضوع مستقل، والسرعة معيار واحد فيها لا المعيار الوحيد.
الجوال في الخليج: ابدأ من هاتف المتسوق
ما نراه عادة في متاجر السعودية والإمارات والكويت أن جزءًا كبيرًا من الزيارات يأتي من الهاتف، خاصة عندما يكون مصدرها إعلانات سناب شات وتيك توك وإنستغرام. وجوجل نفسها تعتمد على نسخة الجوال، إذ تقول في توثيق الفهرسة بأولوية الجوال: «تستخدم جوجل نسخة الجوال من محتوى الموقع لأغراض الفهرسة والترتيب». لذلك يجب أن يبدأ تحسين سرعة الموقع من تجربة الجوال، ثم الكمبيوتر.
نصائح تحسين سرعة الموقع للسوق الخليجي
- اختبر على هاتف متوسط الفئة، لا على أحدث هاتف لديك؛ زوارك لا يملكون جميعًا الهاتف نفسه.
- ابدأ تحسين سرعة الموقع قبل المواسم الكبرى مثل رمضان والجمعة البيضاء واليوم الوطني بأسابيع، لا في يوم الحملة.
- في المواسم يضيف الفريق عادة بانرات وعدادات تنازلية ونوافذ عروض؛ احسب أثرها على السرعة قبل نشرها.
- إذا كان متجرك ثنائي اللغة، فلا تحمل الخطوط العربية والإنجليزية كاملة في كل صفحة دون حاجة.
- إذا كنت تعتمد على تسويق واتساب، فتأكد أن الرابط المرسل يفتح صفحة خفيفة مباشرة، لا سلسلة تحويلات.
وإذا كان متجرك يعتمد على البحث المحلي أو خرائط جوجل، فهو يستفيد من الصفحات السريعة أيضًا، لأن الزائر من الخرائط غالبًا على الهاتف وفي عجلة.

كم تؤثر السرعة في السيو فعلًا؟
هذا السؤال يكثر فيه التهويل. الصورة الدقيقة من صفحات جوجل الرسمية كالتالي، كما في صفحة تجربة الصفحة في Google Search Central:
- جوجل تقول إن مؤشرات Core Web Vitals «تستخدمها أنظمة الترتيب لدينا».
- وتقول أيضًا: «لا توجد إشارة واحدة» لتجربة الصفحة.
- وتؤكد أن البحث «يسعى دائمًا لعرض المحتوى الأكثر صلة، حتى لو كانت تجربة الصفحة دون المستوى».
- وتنصح بعدم التركيز على جانب أو جانبين فقط من تجربة الصفحة.
الخلاصة: السرعة إشارة واحدة بين إشارات كثيرة. الصفحة السريعة بمحتوى ضعيف لن تتفوق على صفحة أبطأ قليلًا تجيب عن سؤال الباحث بشكل أفضل. لكن بين صفحتين متقاربتين في الصلة والجودة، التجربة الأفضل ميزة حقيقية، فضلًا عن أثرها المباشر على التحويل.
لذلك ننصح بأن يكون تحسين سرعة الموقع جزءًا من المرحلة التقنية في خطة السيو، لا الخطة كلها. إذا أردت ترتيب الأولويات من التقني إلى صفحات التصنيفات ثم المحتوى، فارجع إلى خطة سيو المتاجر في 90 يومًا. وإذا كنت تقارن عروض الوكالات، فتكلفة السيو موضوع مستقل نتناوله في مقال آخر.
أخطاء شائعة في تحسين سرعة الموقع وحلولها
مطاردة درجة 100 في PageSpeed
الخطأ: إنفاق أسابيع لرفع درجة المختبر من 85 إلى 100. الحل: ركز على اجتياز المؤشرات الثلاثة في بيانات الميدان للصفحات التي تبيع، ثم انتقل إلى المحتوى والتحويل.
فحص الصفحة الرئيسية فقط
الخطأ: الحكم على المتجر من الصفحة الرئيسية. الحل: أكثر زيارات الإعلانات والبحث تهبط على صفحات المنتجات والتصنيفات، فافحصها أولًا.
تطبيق جديد لكل مشكلة
الخطأ: حل كل مشكلة بتطبيق إضافي، حتى تطبيقات تحسين سرعة الموقع نفسها. الحل: كل تطبيق يجب أن يبرر وجوده بمبيعات أو بيانات تحتاجها فعلًا.
تأجيل تحميل صورة المنتج الرئيسية
الخطأ: تفعيل التحميل المؤجل على كل الصور. الحل: استثن صورة الشاشة الأولى، فتأجيلها يضر LCP مباشرة كما تشرح إرشادات LCP على web.dev.
قياس مرة واحدة ثم النسيان
الخطأ: اعتبار تحسين سرعة الموقع مهمة تُنجز مرة واحدة عند الإطلاق. الحل: كل قالب جديد أو تطبيق أو حملة موسمية قد يبطئ المتجر، فاجعل القياس شهريًا وقبل كل موسم.
قائمة تحقق تحسين سرعة الموقع
- فحصت الرئيسية وتصنيفًا وصفحة منتج في PageSpeed Insights على الجوال.
- سجلت نتائج الميدان (LCP وINP وCLS) وتاريخ الفحص.
- راجعت تقرير Core Web Vitals في Search Console للجوال والكمبيوتر.
- حولت صور المنتجات والبانرات إلى WebP بمقاسات عرضها الفعلية.
- استثنيت صورة الشاشة الأولى من التحميل المؤجل.
- حددت أبعاد كل الصور والبانرات وحجزت مكان العناصر المتأخرة.
- حذفت التطبيقات غير الضرورية وتأكدت من إزالة كودها، وهي أكبر خطوة في تحسين سرعة الموقع غالبًا.
- نظفت مدير الوسوم من البكسلات المكررة.
- خفضت الخطوط إلى خط واحد بوزنين بصيغة WOFF2.
- تأكدت من عدم وجود سلاسل تحويل في روابط الإعلانات.
- فعلت التخزين المؤقت وCDN إن كان الموقع على استضافة خاصة.
- جدولت فحصًا قبل رمضان والجمعة البيضاء بأسابيع.
ابدأ بالصفحات التي تبيع، وبالجوال، وبالبيانات الميدانية. الدرجة الخضراء في المختبر وسيلة للتشخيص، وليست الهدف.
الخلاصة
تحسين سرعة الموقع لا يحتاج إلى معجزة تقنية في أغلب المتاجر، بل إلى قياس صحيح وانضباط: صور أخف، وتطبيقات أقل، وخطوط أبسط، واستضافة مناسبة. وتذكر أن السرعة تخدم المبيعات أولًا، والسيو ثانيًا كإشارة من بين إشارات كثيرة. إذا أردت مراجعة شاملة لأداء متجرك وتصميمه، فاطلع على خدمة تصميم وتطوير المواقع أو تواصل معنا.
الأسئلة الشائعة
كيف أعمل فحص سرعة الموقع جوجل مجانًا؟
افتح PageSpeed Insights على pagespeed.web.dev، والصق رابط الصفحة، واختر تبويب الجوال. ستجد في الأعلى بيانات المستخدمين الحقيقيين إن توفرت، وتحتها نتيجة المختبر والاقتراحات. ولمتابعة الموقع كله، استخدم تقرير Core Web Vitals في Search Console.
ما سرعة تحميل الموقع المقبولة؟
حسب حدود جوجل الرسمية في أكتوبر 2026: أن يظهر أكبر عنصر (LCP) خلال 2.5 ثانية، وأن تكون الاستجابة للنقر (INP) 200 ملي ثانية أو أقل، وأن يبقى مؤشر الثبات (CLS) عند 0.1 أو أقل، وذلك لثلاثة أرباع الزيارات على الأقل.
ما أفضل ادوات سرعة الموقع لمتابعة تحسين سرعة الموقع؟
ابدأ بأداتي جوجل: PageSpeed Insights للفحص السريع والتشخيص، وSearch Console لمتابعة الموقع كاملًا ببيانات الزوار الحقيقيين. وأدوات المطورين في متصفح Chrome تفيد عند التشخيص العميق. الأداة الأهم هي التي تستخدمها بانتظام وتقارن نتائجها بمرور الوقت.
لماذا تتغير نتيجة قياس سرعة الموقع في كل مرة؟
هذا من أكثر ما يربك من يعمل على تحسين سرعة الموقع. السبب أن بيانات المختبر تُقاس في لحظة واحدة وتتأثر بحالة الخادم والشبكة وقت الفحص. لذلك افحص عدة مرات وخذ الصورة العامة. أما بيانات الميدان فتمثل آخر 28 يومًا، ولذلك تتغير ببطء.
هل تحسين سرعة الموقع يرفع ترتيبي في جوجل مباشرة؟
ليس وحده. جوجل تقول إن Core Web Vitals تستخدمها أنظمة الترتيب، لكنها تؤكد أنه لا توجد إشارة واحدة، وأن المحتوى الأكثر صلة يُعرض حتى لو كانت تجربة الصفحة أضعف. تحسين سرعة الموقع يساعدك عندما يكون المحتوى قويًا أصلًا.
لماذا لا يظهر تقرير Core Web Vitals في Search Console؟
غالبًا لأن الموقع جديد أو لأن الزيارات قليلة ولا تكفي لتكوين بيانات CrUX. حسب مساعدة Search Console، لا يعرض التقرير المجموعات التي لا تملك بيانات كافية. استخدم بيانات المختبر في PageSpeed Insights حتى تتراكم الزيارات.
هل أحتاج إلى مطور من أجل تحسين سرعة الموقع على سلة أو زد؟
جزء كبير من العمل لا يحتاج إلى برمجة: ضغط الصور، وحذف التطبيقات غير الضرورية، وتبسيط الصفحة الرئيسية والخطوط. أما تعديل كود القالب أو إزالة بقايا التطبيقات أو ضبط الاستضافة في المواقع الخاصة، فهنا تحتاج إلى مطور.



