موقعك يُحمّل اليوم في 1.8 ثانية. هل هذا جيد؟ لا تعرف، إلا إذا كنت تعلم كم كان زمن التحميل الأسبوع الماضي، أو الشهر الماضي، أو قبل أن يُفعّل ذلك الإضافة الجديدة. بدون خط أساس، كل رقم أداء تنظر إليه هو مجرد رقم معلّق في الفراغ. أما مع وجود خط أساس، فإنه يتحول إلى إشارة فعلية.
مراقبة أداء الموقع لا تنجح إلا إذا كان لديك شيء تقارن به. سيشرح هذا المقال كيف تبني نقطة مرجعية حقيقية، وكيف تستخدمها لرصد المشاكل قبل أن يلاحظها المستخدمون.
لماذا خط الأساس أهم من لقطة واحدة
كثير من أصحاب المواقع يشغّلون اختبار PageSpeed واحد، يرون نتيجة خضراء، ثم يمضون قدماً. المشكلة أن الأداء ليس ثابتاً. قاعدة بياناتك تكبر. قائمة الإضافات تكبر. أنماط الزيارات تتغير. لقطة من قبل ثلاثة أشهر لا تخبرك بأي شيء عن اليوم.
خط الأساس مختلف. هو قياس موثّق وقابل للتكرار لكيفية سلوك موقعك بشكل طبيعي، عبر عدة مقاييس، مأخوذ على مدى فترة زمنية. عندما يكون لديك ذلك، أي انحراف يظهر فوراً. هذا هو الهدف الكامل من مراقبة أداء الموقع: ليس فقط قياس السرعة، بل قياس التغيّر.
ما الذي يُعتبر "طبيعياً" على أي حال
الطبيعي ليس رقماً واحداً. هو نطاق. حركة الزيارات صباح يوم الاثنين تختلف عن حركتها مساء السبت. خط الأساس يجب أن يأخذ هذا التباين بعين الاعتبار، وإلا ستستمر في مطاردة إنذارات كاذبة.
- متوسط زمن الاستجابة والنسبة المئوية الـ95، وليس المتوسطات فقط
- حجم الزيارات المعتاد بحسب الساعة ويوم الأسبوع
- عدد استعلامات قاعدة البيانات ومدتها تحت الحمل الطبيعي
- استخدام موارد الخادم (CPU، الذاكرة، إدخال/إخراج القرص) في ساعات الذروة وخارجها
المقاييس الأساسية التي يجب تتبعها
لست مضطراً لتتبع كل شيء. أنت تحتاج فقط لتتبع مجموعة صغيرة من المقاييس التي تخبرك بشيء فعلي عند تغيّرها.
Time to First Byte (TTFB)
يقيس هذا سرعة استجابة الخادم قبل أن يبدأ المتصفح حتى برسم أي شيء. TTFB الصحي يكون أقل من 200 مللي ثانية في معظم الإعدادات المحسّنة جيداً. إذا كان TTFB في خط أساسك يزحف من 180 مللي ثانية إلى 600 مللي ثانية خلال بضعة أسابيع، فهذا يعني أن شيئاً تغيّر على جانب الخادم، قد تكون قاعدة بيانات متضخمة، أو عملية خارجة عن السيطرة، أو إضافة أصبحت مصدر مشكلة.
Core Web Vitals
Largest Contentful Paint (LCP)، Cumulative Layout Shift (CLS)، و Interaction to Next Paint (INP) تعطيك نظرة عن السرعة من منظور المستخدم. حدود Google تُعتبر نقطة انطلاق جيدة:
- LCP أقل من 2.5 ثانية جيد
- CLS أقل من 0.1 جيد
- INP أقل من 200 مللي ثانية جيد
لكن خط أساسك يجب أن يكون أرقامك الخاصة، وليس فقط حدود النجاح/الفشل العامة. إذا كان LCP لديك ثابتاً عند 1.2 ثانية ثم يقفز إلى 2.1 ثانية، فهذا تراجع حقيقي حتى لو كان لا يزال "جيداً" تقنياً بحسب معيار Google.
استخدام موارد الخادم
حمل المعالج، استهلاك الذاكرة، وإدخال/إخراج القرص تخبرك بما يحدث تحت الغطاء. خط الأساس هنا يساعدك على رصد أشياء مثل تسرّب في الذاكرة داخل سكربت مخصص أو مهمة cron تستهلك موارد أكثر كل أسبوع.
كيف تجمع البيانات فعلياً
تحتاج نوعين من القياس يعملان معاً.
Synthetic Monitoring
يشغّل هذا اختبارات مبرمجة من مواقع ثابتة على فترات منتظمة، تخيّله كروبوت يزور موقعك كل بضع دقائق ويسجّل ما يراه. أدوات مثل GTmetrix، WebPageTest، و Pingdom تندرج ضمن هذه الفئة. الميزة هي الثبات. نفس الشروط، نفس الاختبار، كل مرة، وهذا يجعلها مثالية لبناء خط أساس.
Real User Monitoring (RUM)
يجمع هذا بيانات أداء فعلية من زوار حقيقيين، باستخدام أجهزتهم واتصالاتهم ومواقعهم الحقيقية. تقرير Chrome User Experience Report (CrUX) من Google وأدوات مثل New Relic Browser أو سكربتات RUM المستضافة ذاتياً تعطيك هذه الرؤية. البيانات أكثر تشتتاً من البيانات الاصطناعية، لكنها تخبرك بما يعيشه جمهورك الفعلي.
أنت تحتاج كلا النوعين. Synthetic monitoring يعطيك خط أساس نظيف وقابل للتكرار. RUM يخبرك إن كان ذلك الخط يطابق الواقع.
حدد وتيرة القياس
شغّل اختبارات synthetic على الأقل كل 15-30 دقيقة للصفحات المهمة. اجمع بيانات RUM باستمرار لأنها سلبية أساساً. راجع كلا المصدرين أسبوعياً لتحديث خط أساسك مع نمو موقعك أو تغيّره بشكل طبيعي.
تحويل خط أساسك إلى تنبيهات
خط أساس جالس في ملف جدولي لا يساعد أحداً في الساعة 2 صباحاً. القيمة الحقيقية تأتي من وضع حدود تُطلق تنبيهات عندما ينحرف شيء بعيداً جداً عن الطبيعي.
- تنبيه عندما يتجاوز TTFB متوسط خط الأساس بأكثر من 50% لمدة 10 دقائق أو أكثر
- تنبيه عندما ترتفع معدلات الأخطاء (استجابات 4xx/5xx) فوق المعدل الطبيعي لخط الأساس
- تنبيه عندما يبقى استخدام CPU للخادم فوق 80% لفترة أطول من نافذة الذروة المعتادة
هنا يصبح مراقبة التوفر والأداء مفيداً فعلياً وليس مجرد ميزة زينة. إذا كنت على استضافة مُدارة، فهذا النوع من التنبيه يجب أن يكون يعمل بالفعل في الخلفية، حتى تُرصد المشكلة الحقيقية قبل أن يبدأ زوارك بالانصراف.
أعد بناء خط أساسك بعد التغييرات الكبيرة
أطلقت ميزة جديدة؟ نقلت موقعك إلى خادم جديد؟ أضفت كمية كبيرة من المحتوى الجديد؟ خط أساسك القديم لم يعد صالحاً. أعط الموقع بضعة أيام ليستقر في وضعه الطبيعي الجديد، ثم أعد القياس. اعتماد خط أساس قديم كأنه حالي هو من أكثر الأخطاء الشائعة التي نراها، فهو يؤدي إلى إنذارات كاذبة مستمرة أو إلى تراجعات فائتة لأن الحد كان مضبوطاً لنسخة من الموقع لم تعد موجودة.
قائمة بداية بسيطة
- اختر 3-5 مقاييس أساسية: TTFB، LCP، CLS، INP، ومعدل الأخطاء
- شغّل اختبارات synthetic لمدة أسبوعين كاملين قبل أن تسمّي أي شيء خط أساس
- أضف بيانات RUM لتأكيد ما تُظهره اختبارات synthetic
- حدد عتبات التنبيه بناءً على نسبة الانحراف، لا على أرقام ثابتة
- أعد بناء خط الأساس بعد أي تغيير كبير في الموقع أو البنية التحتية
إذا أردت التعمق أكثر في المقاييس نفسها، فقد تناولنا قراءة تقرير Core Web Vitals ولماذا يهم TTFB لمعدلات التحويل بتفصيل أكبر في مكان آخر من المدونة. وإذا كان synthetic testing جديداً عليك، فمقال كيف يرصد synthetic monitoring التراجعات في الأداء قراءة جيدة تالية.
الخلاصة
خط أساس الأداء ليس مهمة تُنفذ مرة واحدة، بل هو مرجع حي ينمو مع موقعك. عندما يكون لديك، تتوقف عن التخمين إن كان شيء ما يبدو بطيئاً وتبدأ بمعرفة، بالأرقام، متى وأين حدثت المشكلة تماماً. هذا هو الفرق بين الاستجابة لشكوى عميل وبين رصد المشكلة قبل أن يلاحظها أحد.
