قياس سرعة الموقع: دليل عملي بالأدوات المجانية

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

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

أولًا: لماذا نقيس بالأداة لا بالإحساس؟

القياس يكشف ما لا تراه عينك:

• التحيز الشخصي: حاسوبك قوي وشبكتك سريعة، تجربتك أفضل من تجربة عميلك.
• القياس الداخلي: المتصفح يعرض الموقع محليًا؛ العميل يسحبه من خادم بعيد.
• اكتشاف المشاكل: الأداة تخبرك السبب (صورة ضخمة؟ سيناريو ثقيل؟ خادم بطيء؟) لا النتيجة فقط.
• المقارنة مع الوقت: القياس قبل وبعد يثبت أن تحسينك فعلًا نفع، أو كشف أنك حللت المشكلة الخطأ.

المبدأ: لا تحسّن ما لا تقيس. أول خطوة في أي خطة أداء هي الصورة الحقيقية.

ثانيًا: الأدوات المجانية الأساسية

1. Google PageSpeed Insights، الأداة الأولى دائمًا

ما هي؟ أداة جوجل الرسمية: تدخل رابطك فتحصل على درجة 0-100 وتقرير تحسين مفصل.

الخطوات:

1. افتح pagespeed.web.dev.
2. ألصق رابط صفحتك.
3. اضغط تحليل وانتظر ثوانٍ.
4. اختر عرض الجوال أولًا (الأهم لجوجل).

ماذا سترى؟

• درجات مؤشرات الويب الأساسية (LCP, INP, CLS): خضراء (جيدة) / صفراء (تحتاج تحسين) / حمراء (ضعيفة).
• فرص التحسين (Opportunities): قائمة مرتبة بما يبطئ صفحتك مع التوفير المتوقع: ضغط الصور، توفير 1.2 ميجابايت.
• التشخيص: مشاكل أعمق (طلب بطيء، تأخير في الخادم).

2. GTmetrix، التحليل الأعمق

ما هي؟ أداة مستقلة تحاكي تحميل الصفحة وتحلل كل طلب.

الخطوات:

1. افتح gtmetrix.com وألصق رابطك.
2. بعد التحليل، انظر: درجة الأداء + مدة التحميل الكاملة + وزن الصفحة الإجمالي.
3. تبويب Waterfall (المخطط الزمني): يظهر كل ملف ووقت تحميله، تكشف أي ملف الأثقل.

متى تستخدمها؟ عندما تريد رؤية تفصيل الطلبات: ما الملفات الأبطأ؟ أي طلب ينتظر طلبًا آخر؟ هذا المستوى التشخيصي لا يقدمه PageSpeed دائمًا بوضوح.

3. WebPageTest، محاكاة العالم الحقيقي

ما هي؟ أقوى أداة لمحاكاة تجربة المستخدم في ظروف حقيقية.

الخطوات:

1. افتح webpagetest.org.
2. أدخل الرابط، واختر موقع الاختبار (اختر مدينة قريبة من جمهورك).
3. اختر نوع الاتصال (مثلاً 4G/5G)، الأهم اختبار الجوال.
4. تحليل شامل مع فيديو لتحميل الصفحة (شاهد بعينك متى ظهر المحتوى).

متى تستخدمها؟ عندما تريد دقة قريبة من الواقع: مدينة محددة، شبكة محددة، جهاز محدد.

4. Chrome DevTools (Tab Performance)، الفحص الداخلي

ما هي؟ أداة مدمجة في متصفح كروم (F12 ثم تبويب Performance) لتحليل ما يحدث داخل المتصفح.

متى تستخدمها؟ للمطورين: اكتشاف كود JavaScript البطيء وتأخير الاستجابة، أعمق طبقة تشخيصية.

ثالثًا: ما الذي تقيسه، المؤشرات الأساسية

مؤشرات الويب الأساسية (Core Web Vitals)

المؤشر	ماذا يقيس	الجيد	الضعيف
LCP	ظهور أكبر عنصر (الصورة/العنوان)	أقل من 2.5 ث	أكثر من 4 ث
INP	استجابة الموقع للنقرات	أقل من 200 مللي ث	أكثر من 500 مللي ث
CLS	اهتزاز التخطيط أثناء التحميل	أقل من 0.1	أكثر من 0.25

مؤشرات تشخيصية إضافية

• وزن الصفحة (Page Weight): الحجم الإجمالي بالميجابايت. موقع 5+ ميجابايت غالبًا زائد.
• عدد الطلبات (Requests): كم ملفًا يطلب؟ 100+ طلب علامة على كود متضخم.
• وقت استجابة الخادم (TTFB): المدة حتى يبدأ الخادم بالرد. أعلى من 600 مللي ثانية غالبًا مشكلة استضافة.

رابعًا: كيف تقرأ النتائج وتتصرف، خطة القرار

الخطوة 1: القياس المتكرر (لا مرة واحدة)

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

الخطوة 2: صنف النتائج حسب الأثر

المشكلة المكتشفة	الأثر	صعوبة الإصلاح
صور ضخمة	مرتفع جدًا	سهل
لا تخزين مؤقت/ضغط	مرتفع	سهل
استضافة بطيئة	مرتفع	متوسط
سيناريو ثقيل	متوسط	متوسط/صعب
أدوات خارجية كثيرة	متوسط	سهل

القاعدة: ابدأ بالأعلى أثرًا والأسهل (الصور والتخزين المؤقت)، تكسب أكبر تحسين بأقل جهد.

الخطوة 3: أصلح ثم أعد القياس

• بعد كل إصلاح، قس من جديد بنفس الأداة ونفس الصفحة.
• انظر هل تحسنت المؤشرات؟ قارن الأرقام لا المشاعر.
• إن لم تتحسن → إصلاحك لم يعالج السبب الحقيقي، تعمق أكثر أو استشر.
• ولأسباب البطء الشائعة مع حلولها خطوة بخطوة، راجع لماذا موقعك بطيء؟ وكيف تسرّعه بنفسك.

الخطوة 4: قس صفحات المال تحديدًا

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

خامسًا: أخطاء شائعة في القياس

1. القياس مرة واحدة فقط

قياس وحيد قد يعطيك رقمًا متطرفًا مضللًا. كرر وخذ المتوسط.

2. القياس على الحاسوب فقط

جوجل يقيم الجوال أولًا. جوالك البطيء بمحتوى ثقيل هو واقعك الحقيقي.

3. القياس بشبكة سريعة جدًا

قياس على اتصال 5G فائق لا يعكس تجربة عميلك على 4G في منطقة متوسطة. اختر ظروفًا واقعية في WebPageTest.

4. تجاهل التشخيص والاكتفاء بالدرجة

الدرجة 55 لا تخبرك السبب. اقرأ فرص التحسين، قائمة الإصلاحات هي ذهب الأداة.

5. عدم القياس بعد التعديلات

التحسين بلا قياس بعدي احتمال ضياع: قد تعتقد أنك أصلحت بينما المشكلة في موضع آخر. القياس بعد كل خطوة يبقي قراراتك صادقة.

سادسًا: جدول قياس عملي

أسبوعيًا (لموقع نشط)

• PageSpeed Insights للصفحة الرئيسية (جوال).
• نظرة على الوزن الإجمالي وعدد الطلبات في GTmetrix.

شهريًا

• قياس صفحات المال (خدمات/منتجات/دفع).
• مقارنة مع الشهر السابق، هل تتحسن؟ تراجعت؟

عند التغييرات الكبيرة

• بعد تغيير الاستضافة، إعادة تصميم، إضافة ميزة: قس فورًا قبل وبعد.

سابعًا: دراسة حالة، كيف قرأنا تقريرًا فعليًا؟

لتوضيح المنهجية عمليًا، تخيل أنك فتحت PageSpeed Insights لموقعك ووجدت:

النتيجة الأولية

• الدرجة: 38 (جوال).
• LCP: 5.8 ثانية (أحمر، سيئ جدًا).
• CLS: 0.12 (أصفر).
• INP: 180 مللي ثانية (أخضر).

الخطوة الأولى: ماذا تخبرك هذه الأرقام؟

• LCP سيئ جدًا = الصور أو العنصر الرئيسي يتأخر، أكبر عنصر بطيء الظهور.
• CLS أصفر = اهتزاز خفيف (إطارات بلا أبعاد، خط متأخر).
• INP أخضر = الاستجابة للنقر جيدة، السيناريو ليس المشكلة الكبرى.

الخلاصة: المشكلة الأساسية الوزن والتحميل لا الكود التفاعلي.

الخطوة الثانية: قراءة فرص التحسين

القائمة المرتبة غالبًا ستشمل: ضغط الصور (توفير 1.5 ميجابايت)، تحويل الصور إلى WebP، إزالة JavaScript غير المستخدم. تنفيذ ضغط الصور وحده غالبًا يرفع الدرجة قفزة كبيرة.

الخطوة الثالثة: التنفيذ والقياس بعدي

• تضغط الصور وتفعّل التخزين المؤقت.
• تعيد القياس: الدرجة 62، LCP 3.1 ثانية.
• تكرر: تعالج باقي القائمة → 74، LCP 2.4 ثانية (أخضر).

الخطوة الرابعة: ماذا لو علق التحسن؟

• بلغت 74 وبقيت؟ → انتقل للتشخيص العميق: GTmetrix Waterfall، أي طلب ينتظر ماذا؟. قد تجد طلبًا بطيئًا من خادم خارجي، أو استضافة بطيئة (TTFB مرتفع) لا تحلها الصور.
• عندها القرار: ترقية استضافة أو إزالة مكوّن خارجي بطيء.

الدرس من الحالة: القياس منهجية قرارات، لا أرقام للمفاخرة: كل رقم يوجهك للخطوة التالية، وتتقدم تدريجيًا نحو الأخضر مع كل جولة.

ثامنًا: قياس ما بعد الإصلاح، كيف تعرف أن تحسينك نفع فعلًا؟

1. القياس المقارن لا المطلق

رقم جيد واحد لا يكفي، قارن قبل وبعد بنفس الأداة والظروف. الارتفاع من 38 إلى 62 إثبات التقدم؛ والبقاء عند 38 رغم كل شيء دليل أنك حللت المشكلة الخطأ.

2. قس تجربة المستخدم لا الأرقام فقط

افتح موقعك بنفسك بعد التحسين: هل يبدأ العرض فورًا؟ هل يمكن القراءة والتصفح بسلاسة؟ الأرقام خادم صادق لكن الإحساس العميل الحقيقي.

3. أعد القياس بشكل دوري لا مرة واحدة

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

4. اربط القياس بالتحويل

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

التاسع: الأسئلة الشائعة

ما درجة PageSpeed الجيدة؟

تجاوز 80-90 جيد جدًا، و60-80 مقبول، وأقل من 50 ضعيف. لكن الأهم من الدرجة: هل مؤشرات الويب الأساسية خضراء؟ صفحة بدرجة 70 ومؤشرات خضراء أفضل من 90 بجودة صفراء.

ما الفرق بين PageSpeed وGTmetrix؟

PageSpeed: تقييم جوجل (الأول للسيو) مع قائمة تحسينات. GTmetrix: تحليل أعمق للطلبات والتفاصيل (للتشخيص الدقيق). استخدم الاثنين: PageSpeed للصورة الكبيرة، وGTmetrix للسبب.

هل أحتاج أدوات مدفوعة؟

لا للقياس الأساسي. المجانية (PageSpeed, GTmetrix, WebPageTest) تكفي تمامًا. المدفوعة تضيف مراقبة مستمرة وتاريخًا، وهي رفاهية وليست ضرورة للمبتدئ.

لماذا تختلف النتائج بين القياسات؟

الشبكة، ازدحام الخادم، موقع الاختبار، ووقت اليوم. لهذا: كرر، وسوّق نفس الظروف (نفس الأداة، نفس الموقع، نفس نوع الاتصال) عند المقارنة.

هل أستطيع محاكاة تجربة عميل في مدينة أخرى؟

نعم، WebPageTest يسمح باختيار مدينة الاختبار ونوع الشبكة والجهاز. هذا أقرب تقريب لتجربة العميل الحقيقية.

ما الفرق بين القياس والمراقبة المستمرة؟

• القياس: لقطة الآن، لمرة أو عدة مرات لتشخيص.
• المراقبة المستمرة: أداة تعيد الفحص تلقائيًا (يوميًا/أسبوعيًا) وتنبهك عند التراجع، إما مدفوعة (أدوات مثل Uptime) أو روتين يدوي شهري.

للمبتدئين: القياس الدوري اليدوي (شهري) كافٍ تمامًا. المراقبة الآلية رفاهية لمن يعتمد الموقع كمصدر دخل أساسي.

هل الأرقام مطابقة دائمًا لتجربة كل زائر؟

لا، القياس متوسط/نمط لا حقيقة كل زائر: شبكة الزائر، جهازه، مساره، كلها تختلف. لهذا كرر القياس وظروف متعددة (مدينة، شبكة، جهاز)، لا تبنِ قرارًا على قياس واحد. الهدف التحسين النمطي لا النمذجة لكل حالة.

متى أعتبر أن موقعي سريع بما يكفي وأتوقف؟

عندما تكون مؤشرات الويب الأساسية خضراء (LCP<2.5s, INP<200ms, CLS<0.1) على الجوال، وتجربة التصفح سلِسة على جوال حقيقي. بعدها: حافظ بالقائمة الدورية، لا تتعقب الرقم الأخير إلى ما لا نهاية، فالوقت الأفضل يذهب للمحتوى والتحويل.

هل أحتاج أن أفهم كل تفصيل تقني في التقرير؟

لا، ابدأ بأهم ثلاثة: الدرجة، LCP، وفرص التحسين. هؤلاء يكفون للبداية ولأغلب الإصلاحات. القائمة العميقة (Waterfall، طلبات إضافية) مستوى متقدم، عد إليها عندما تتوقف النتائج عن التحسن.

ماذا أفعل بأرقام مربكة في تقرير GTmetrix (مؤشرات كثيرة)؟

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

هل أقيس كل صفحة أم الأهم فقط؟

قِس النماذج التمثيلية: الرئيسية (الأكثر زيارة) + صفحة خدمة/منتج (حيث المال) + صفحة مقالة (نمط المحتوى). صفحة ديناميكية (متجر/لوحة) قد تقيسها مع مصادفة الـتسجيل دخول. لا تحرق وقتك بقياس كل صفحة، القياس التمثيلي يعطيك صورة كافية.

ما الخطأ الأكثر شيوعًا في استخدام هذه الأدوات؟

الاستنتاج من قياس واحد: نتيجة خضراء من فحص واحد تُعلَّق عليها قصة نجاح، أو نتيجة حمراء تُعتبر كارثة. الصحيح: كرر (3 مرات)، خذ المتوسط، قارن قبل/بعد بنفس الظروف. وحتى الأخضر، تأكد أنه على جوال بظروف واقعية، لا على حاسوب بشبكة مخبرية مثالية.

هل أشارك تقارير السرعة مع فريق تطويري؟

نعم، وهي لغة تواصل مثالية: بدل الموقع بطيء! الغامضة، أرسل LCP 4.2s، الصور هي السبب، التقرير يظهر توفير 2 ميجابايت. التقرير الملموس يحول النقاش من إنطباع إلى بيانات، ويمنع هل أنا متأكد؟ العقيمة. ارفق صورة للتقرير وحدد ما تريد بوضوح: ضغط الصور هذا الأسبوع ثم أعد القياس.

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

كيف أرصد تراجعًا مفاجئًا في السرعة؟

بانتظام القياس الدوري لا عند الأزمة فقط: جدول شهري يرصد الرقم المرجعي (مثل الوزن الكلي وLCP). تراجع 15%+ عن المرجع خلال شهر = تنبيه للتحقيق: محتوى مضاف؟ مكوّن جديد؟ تحديث ضار؟ الرصد المبكر أرخص من إصلاح الانكسار، والموقع الذي يمنع التراجع يبقى سريعًا دائمًا.

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

الخلاصة

قياس السرعة ليس رفاهية، إنه البوصلة لكل قرار تحسين. أدواتك المجانية (PageSpeed Insights للتقييم، GTmetrix للتشخيص، WebPageTest للمحاكاة) تكفيك تمامًا إن أتقنت قراءتها: كرر القياس، اقرأ قائمة التحسينات، أصلح الأسهل والأعلى أثرًا أولًا (الصور والتخزين المؤقت غالبًا)، وأعد القياس بعد كل خطوة. هكذا تبني موقعًا مقيسًا تتحسن أرقامه فعلًا، لا يبدو سريعًا على جهازك.

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