قياس سرعة الموقع: كيف تعرف أثر البطء على عملائك؟

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

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

قياس سرعة الموقع باستخدام PageSpeed Insights

1. افتح PageSpeed Insights، وأدخل رابط الصفحة المقصودة كاملًا ثم ابدأ التحليل.
2. اختر الهاتف أو الكمبيوتر وسجّل الاختيار مع الرابط وتاريخ الفحص. قارن نتائج الجهاز نفسه عند إعادة الاختبار.
3. ابدأ ببيانات المستخدمين إن توفرت، وانتبه إلى ما إذا كانت تخص الصفحة أو النطاق. غيابها لا يعني نجاح الصفحة أو فشلها.
4. انتقل إلى التشخيص المختبري. اقرأ الملاحظات عن الصور والخادم والملفات، واختر سببًا محددًا يمكن فحصه بدل تفعيل كل اقتراح دفعة واحدة.
5. احتفظ بالتقرير، ونفّذ تغييرًا واحدًا، ثم أعد القياس واختبر أن النموذج والقائمة والدفع ما زالت تعمل.

بحسب وثائق PageSpeed Insights، تعرض البيانات الميدانية فترة جمع سابقة من 28 يومًا. لذلك قد يظهر أثر التحسين سريعًا في الاختبار المختبري، بينما يتغير ملخص تجربة المستخدمين تدريجيًا. الرسم السابق يوضح أجزاء القراءة والحدود المرجعية، ولا يمثل تقرير أداء WP Star أو أي عميل.

ما المقصود بسرعة الموقع؟

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

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

مؤشرات Core Web Vitals: ثلاثة مقاييس لقراءة تجربة الزائر

تحدد وثائق Google لمؤشرات أداء الويب الأساسية الحدود التالية للتجربة الجيدة. وهي تقيس جوانب مختلفة، لذلك لا يعوّض نجاح أحدها فشل الآخر.

اسحب لعرض باقي الجدول ←

المؤشر	ما يعبّر عنه	الحد الجيد
LCP	وقت ظهور أكبر عنصر محتوى ضمن منطقة العرض	2.5 ثانية أو أقل
INP	استجابة الصفحة لتفاعلات المستخدم	200 مللي ثانية أو أقل
CLS	مقدار تحركات التخطيط غير المتوقعة	0.1 أو أقل، دون وحدة زمن

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

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

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

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

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

لماذا لا أرى INP في اختبار Lighthouse العادي؟

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

كيف تقدّر الفرص المفقودة دون اختلاق نسبة عامة؟

إليك مثالًا حسابيًا افتراضيًا، وليس نتيجة تخص WP Star أو دليلًا على أثر ثانية تأخير. لنفترض أن صفحة تستقبل 10,000 جلسة مؤهلة خلال فترة معينة، وأن معدل إرسال الطلب فيها 1.5٪. هذا يساوي 150 جلسة ذات طلب. إذا وصل المعدل إلى 2٪ مع عدد جلسات مماثل، يصبح العدد 200، بفارق 50 طلبًا.

الفارق هنا نصف نقطة مئوية في معدل التحويل. ويمكن استخدام المعادلة التالية لبناء سيناريو، لا لإثبات السبب:

فرق الطلبات المتوقع = عدد الجلسات × الفرق بين معدلي التحويل.

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

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

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

أين تبدأ تحسين سرعة الموقع؟

الصورة الرئيسية والصور الكبيرة

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

الأكواد الخارجية والتفاعلات

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

استجابة الخادم والتخزين المؤقت

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

الخطوط والملفات غير المستخدمة

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

كيف تعرف أن التحسين نجح؟

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

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

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