14 يوليو 2025·5 دقيقة
قِس قبل التحسين: سير عمل Paul Irish للسرعة
قِس قبل أن تحسّن عبر حلقة بسيطة: خط أساس، تحليل، غيّر شيئًا واحدًا، تحقق من التأثير، وابنِ عادة هادئة للعمل على الأداء.
قِس قبل أن تحسّن عبر حلقة بسيطة: خط أساس، تحليل، غيّر شيئًا واحدًا، تحقق من التأثير، وابنِ عادة هادئة للعمل على الأداء.
عمل الأداء يبدو عشوائيًا عندما تبدأ بالإصلاحات بدون قياس. يومًا تقوم بتصغير الملفات، ويومًا تضبط التخزين المؤقت، ثم تحذف مكتبة. أحيانًا يساعد ذلك. أحيانًا لا يتغير شيء ولا تعرف السبب.
أكبر مخاطرة هي تحسين الشيء الخطأ. إذا كانت الصفحة بطيئة لأن الخيط الرئيسي محجوز بواسطة جافاسكربت، فقد لا يُحدث قضاء ساعات في ضغط الصور فرقًا يذكر. أو قد تُسرّع شيئًا لا يلاحظه المستخدمون بينما التأخير الحقيقي سببه استدعاء API طويل، أو إعادة تنسيق متكررة، أو سكربت واحد حاجز.
هناك فخ آخر في الحكم بناءً على الإحساس. "يبدو أسرع" قد يكون مجرد تأثير وهمي (مثل مؤشر تحميل) أو ناتجًا عن اختبار على شبكة أو جهاز مختلف. "إنه أسرع" يعني أن نفس الإجراء، تحت نفس الظروف، أعطى أرقامًا أفضل.
وعد بسيط يصلح معظم هذا: قِس قبل أن تحسّن، ثم قرّر. عندما تعامل الأداء كمشكلة قياس، تتوقف عن التخمين وتبدأ بالتعلّم.
حلقة عملية تبدو هكذا: اختر فعل مستخدم واحد لتحسّنه، سجّل خط الأساس في ظروف قابلة للتكرار، قم بتغيير واحد يمكنك تفسيره، ثم أعد القياس واحتفظ بالتغيير فقط إذا تحسّنت الأرقام.
Paul Irish هو واحد من أبرز الأصوات في أداء الويب. من خلال عمله في أدوات المتصفح وإرشادات الأداء، ساهم في تعميم فكرة بسيطة: مهمتك الأولى ليست التخمين ما هو البطيء، بل إثباته.
هذه العقلية تغيّر ديناميكيات الفريق. بدلًا من الجدال عن عادات مثل "الصور هي المشكلة دائمًا" أو "لابد أن الإطار هو السبب"، تبدأ بالأدلة. عندما تستطيع الإشارة إلى مخطط زمني، استعلام بطيء، أو مهمة طويلة، يتحول النقاش من لوم إلى إصلاحات.
"قِس قبل التحسين" يهدئ مناقشات الأداء أيضًا لأنه يخلق قواعد مشتركة: اتفقوا على ما تقيسونه، اتفقوا على ما يعنيه "أفضل"، واحتفلوا فقط عندما تتحرك الأرقام.
هذا يعمل على مواقع صغيرة وتطبيقات ضخمة. خط أساس واحد يمكن أن يوقف تحسينات دقيقة عشوائية على صفحة تسويقية. في منتج كبير، القياسات المتسقة تمنع الأداء من التحول إلى قائمة مهام لا تنتهي.
طريقة بسيطة لجعل هذا واقعًا هي معاملة الأداء كتقرير خطأ: خطوات واضحة لإعادة الإنتاج، المقياس الذي رأيته، وتغيير واحد مرتبط بنتيجة واحدة. إذا اختلف شخصان، أعد تشغيل القياس ودع البيانات تقرّر.
عامل الأداء كمشكلة أدوات قياس أولًا: أضف طرقًا لملاحظة ما يعيشه المستخدمون فعليًا. إذا لم تستطع رؤيته، ستقع في جدال الآراء بدل الأدلة. هذا هو المعنى الحقيقي للقياس أولًا.
الأدوات لا تحتاج أن تكون فاخرة. جمع بعض الإشارات بشكل ثابت، في نفس الأماكن، حتى تتمكن من الإجابة على أسئلة أساسية:
عادةً تريد نوعين من البيانات.
بيانات المختبر تُلتقط في إعداد مُتحكم به: لابتوب أو جهاز اختبار محدد، ملف تعريف شبكة مستقر، نفس الخطوات في كل تشغيل. مفيدة للتصحيح لأنك تستطيع إعادة البطء عند الطلب.
بيانات المستخدم الحقيقية هي ما يختبره الناس في الواقع: أجهزة ومواقع وجودة اتصال مختلفة. مفيدة للأولويات لأنها تظهر ما يؤذي المستخدمين الفعليين، لا مجرد تشغيل اختبار واحد.
حتى دون أن تكون خبيرًا، يمكنك قياس معالم تحميل الصفحة (مثل أول محتوى مرئي)، المهام الطويلة وحجب الخيط الرئيسي، الطلبات الشبكية البطيئة، عمل العرض المكلف (تخطيط، أسلوب، رسم)، ووقت استجابة الخادم.
توجد هذه الإشارات عادة في أماكن قليلة: أدوات مطوري المتصفح لملفات تعريف المختبر، سجلات الخادم وتتبعها لتوقيت الخلفية، ولوحات تحليلات أو RUM لبيانات المستخدم الحقيقية. على سبيل المثال، إذا بدا الخروج بطيئًا، قد تُظهر DevTools أن المتصفح مشغول في عرض واجهة سلة كبيرة بينما سجلات الخادم تُظهر أن الـ API سريع. بدون أدوات قياس، قد تحسّن الخلفية ولن تصلح المشكلة الحقيقية.
لكي تقيس قبل أن تحسّن، تحتاج نقطة بداية موثوقة. الخط الأساس هو نفس الفعل، يقاس بنفس الطريقة، تحت نفس الظروف.
ابدأ برحلة مستخدم حقيقية واحدة، وليس "الموقع كله". اختر شيئًا يمكنك وصفه في جملة واحدة، مثل "افتح الصفحة الرئيسية ومرّر إلى شبكة المنتجات الأولى" أو "سجّل الدخول واذهب إلى لوحة التحكم". تضييق النطاق يجعل الأرقام أكثر استقرارًا والخطوات اللاحقة أوضح.
بعدها، اختر من 1 إلى 3 مقاييس تتطابق مع الرحلة. لعرض صفحة، زوج شائع هو LCP (مدى سرعة ظهور المحتوى الرئيسي) وTTFB (مدى سرعة استجابة الخادم). لتدفق مثل الخروج، قد تتبع وقت إكمال الخطوة الأولى بالإضافة إلى زمن استجابة الـ API لنداء الدفع. كثرة المقاييس تجعل من السهل اختيار النتائج المريحة.
اكتب إعداد الاختبار حتى يستطيع شخص آخر إعادة إنتاجه لاحقًا. فروق صغيرة يمكن أن تغيّر النتائج:
أخيرًا، عرّف "جيد بما يكفي" لجمهورك. مثلاً: "LCP أقل من 2.5 ثانية على هاتف متوسط، على 4G." إذا استخدمت Koder.ai، التقاط لقطة قبل الاختبار يساعد ربط خط الأساس بنسخة معروفة.
قبل أن تحلل أي شيء، اجعل المشكلة تحدث مرة أخرى عند الطلب. إذا لم تستطع تكرارها، فلا يمكنك الوثوق بالنتيجة.
ابدأ مما يشعر به الناس، وليس مما تفترضه. هل هو عرض أولي بطيء؟ نقرة تتوقف قبل أن يتغير شيء؟ انتظار طويل بعد إرسال نموذج؟ اختر اللحظة التي يشتكي منها المستخدمون وركز عليها.
قم بتشغيل سريع لتأكيد أن البطء حقيقي وقابل للتكرار. حافظ على كل شيء آخر ثابتًا: نفس الصفحة، نفس الجهاز، نفس الشبكة إن أمكن. ثم اكتب الزناد والنقطة التي يشعر فيها البطء، مثل "بعد الضغط على دفع، يتجمد الزر لثانية" أو "التمرير يتلعثم عندما تظهر قائمة المنتجات".
طريقة بسيطة للحفاظ على التكرار هي سكربت صغير: افتح الصفحة من تبويب جديد، قم بالإجراء البطيء، لاحظ النقطة الدقيقة التي يبطئ فيها، ثم كرر مرة للتأكيد.
التقط تسجيلًا أو اثنين كخط أساس، لا العشرات. تريد دليلاً كافيًا لتقول: "نعم، البطء يحدث، ويحدث هنا بالضبط."
بمجرد أن تستطيع إعادة البطء، توقف عن التخمين. افتح أداة ملف التعريف (لأغلب الناس، تبويب Performance في المتصفح) وسجّل مرة واحدة للتفاعل البطيء. الهدف ليس إيجاد كل مشكلة، بل لمعرفة أين يذهب الوقت.
ابدأ بأكبر كتل الزمن. النبضات الصغيرة قد تكون حقيقية، لكنها نادرًا ما تفسر تأخيرًا ملحوظًا بمفردها.
طريقة مفيدة لقراءة التسجيل هي تقسيم الوقت إلى دلائل قليلة: الشبكة والتحميل (انتظار الطلبات)، جافاسكربت على الخيط الرئيسي (مهام طويلة)، العرض والرسم (تخطيط، أسلوب، رسم)، فترات الخمول (انتظار شيء آخر)، والعمل المتكرر (نفس الخطوة المكلفة تتكرر مرارًا).
خطأ شائع هو الخلط بين استجابة خادم بطيئة وعمل عميل بطيء. إذا أظهر المخطط فترات طويلة أثناء وجود طلبات، فقد يكون عنق الزجاجة شبكة أو خلفية. إذا أظهر مهام طويلة على الخيط الرئيسي، فالمشكلة أمامية حتى لو كانت الشبكة سريعة.
قبل أن تغيّر أي شيء، اكتب فرضية قصيرة وقابلة للاختبار بناءً على ما رأيت. على سبيل المثال: "الصفحة تبدو بطيئة لأن الخيط الرئيسي محجوز بتجهيز JSON مباشرة بعد وصول استجابة الـ API." هذه الجملة تحدد الخطوة التالية.
بعد أن تحدد عنق الزجاجة المحتمل، قاوم الرغبة في "إصلاح كل شيء". غيّر متغيرًا واحدًا لتتمكن من ربط السبب بالتأثير.
اجعل التغيير صغيرًا وسهل التراجع. إعادة الكتابة الكبيرة تُغمي النتيجة: إذا تحسّن الأداء، فلن تعرف لماذا. إذا ساء، يصبح الرجوع خطيرًا.
تغييرات جيدة من نوع "شيء واحد" تكون محددة وقابلة للاختبار. أمثلة: تأجيل أو إزالة سكربت طرف ثالث واحد يحجب العرض، ضغط صورة كبيرة واحدة في الصفحة البطيئة، إضافة تخزين مؤقت لاستعلام قاعدة بيانات مكلف واحد، تقسيم مكوّن واجهة ثقيل ليُعرض جزئيًا أولًا، أو تقليل العمل في حلقة ساخنة رصدتها في ملف التعريف.
قبل أن تلمس الكود، اكتب ما غيّرته ولماذا اخترت ذلك، وماذا تتوقع أن يتحسّن (مثلاً: "تقليل زمن الخيط الرئيسي" أو "خفض زمن DB للنصف").
إذا كان فريقك يستخدم منصة تدعم اللقطات والتراجع (مثل Koder.ai)، خذ لقطة مباشرة قبل التغيير حتى يصبح "صغيرًا وقابلًا للتراجع" حقيقة، لا مجرد أمنية.
غيّرت شيئًا. الآن اثبت أنه ساعد.
أعد تشغيل نفس إعداد الاختبار الذي استخدمته لخط الأساس: نفس الجهاز، نفس إصدار المتصفح، نفس المسار والتدفق، ونفس عدد التشغيلات. قارن قبل مقابل بعد باستخدام نفس المقاييس. لا تضف مقاييس جديدة في منتصف الطريق لأن نتائجها تبدو أفضل.
الضجيج هو السبب الأكثر شيوعًا لخلافات الفرق حول الأداء. راقب حالة الكاش (بارد مقابل دافئ)، الامتدادات أو العمليات الخلفية، اختلاف ظروف الشبكة أو إعدادات الـ VPN، تفاوت الخادم (دقيقة هادئة مقابل دقيقة مزدحمة)، والفرق بين "بعد النشر مباشرة" والحالة المستقرة.
إذا تحسن الوسيط لكن ساءت أسوأ حالة، فهذه تجارة حقيقية. قرر ما يهم لمستخدميك، ثم وثّق القرار: احتفظ بالتغيير، ارجع عنه، أو اكتب فرضية جديدة واختبر مجددًا.
عندما تقيس الشيء الخطأ أو تغيّر عدة أمور دفعة واحدة، يصبح عمل الأداء مربكًا. يمكنك حرق جهد كبير بدون فوز واضح، حتى لو كان التطبيق يتحسن.
خطأ شائع هو اعتبار نتيجة واحدة كهدف نهائي. قد تكون النتائج مفيدة، لكن المستخدمين لا يعيشون "رقم 92". هم يعيشون "الصفحة تظهر المحتوى خلال ثانيتين" أو "الزر يستجيب فورًا". اختر نتيجة مرئية للمستخدم وقِسها باستمرار.
فخ آخر هو الاختبار فقط على لابتوب قوي. العديد من البطء يظهر على هواتف متوسطة، شبكات متقطعة، أو عندما يكون المعالج مشغولًا. إذا اختبرت فقط على أفضل جهاز تملكه، قد تفوّت عنق الزجاجة.
الحيّر عادةً تأتي من أنماط مثل تحسين الأسهل بدل الأكثر استهلاكًا للوقت، دمج عدة تعديلات في تغيير واحد، تبديل المسار التجريبي في كل مرة، تخطي إعادة الاختبار لأن "يبدو أسرع"، أو إعلان النصر بدون إعادة تشغيل نفس خط الأساس.
إذا تبنيت التطبيق عبر منصة مدفوعة بالمحادثة مثل Koder.ai، تنطبق نفس الانضباط: تغيير واحد، ثم تحقق على نفس التدفق بالضبط حتى تثق في النتيجة.
إذا حافظت على عادة واحدة، فاجعلها هذه: قِس قبل أن تحسّن. الهدف ليس بيانات لا نهائية. الهدف حلقة قابلة للتكرار يمكنك الوثوق بها.
سَمِّ رحلة المستخدم الدقيقة التي تهتم بها. "الصفحة الرئيسية بطيئة" غامضة. "من صفحة المنتج إلى الضغط على شراء إلى رؤية التأكيد" يعطيك مسار نقر يمكن تكراره.
استخدم هذه القائمة:
النسخة الهادئة من عمل الأداء بسيطة: مسار واحد، إعداد واحد، تغيير واحد، نتيجة مثبتة واحدة.
شكوى شائعة: الخروج يبدو بطيئًا بعد أن يضغط العميل "دفع". الناس يبدأون بالتخمين (صور، خطوط، الزر). بدلًا من ذلك، عاملها كتجربة يمكنك تكرارها.
ضع خط أساس يمكنك إعادة تشغيله. اختر جهازًا واحدًا ومسارًا واحدًا (العربة → الخروج → دفع → التأكيد). فعّل تقييد الشبكة (مثلاً، Fast 3G) وحافظ عليه نفسًا في كل تشغيل. قِس رقمًا واحدًا بسيطًا: الوقت من الضغط على "دفع" إلى رؤية شاشة التأكيد.
ثم حلّل نفس اللحظة وابحث أين يذهب الوقت. عادةً تختار بين ثلاث دلائل: الشبكة (طلب طويل أو عدد كبير من الطلبات)، الخادم (نداء الدفع بطيء بينما المتصفح خامد)، أو الخيط الرئيسي (المتصفح مشغول بتشغيل جافاسكربت ولا يستطيع تحديث الواجهة).
تخيل أن الملف التعريفي يُظهر أنه بعد الضغط على "دفع" يطلق المتصفح طلب تحليل وأيضًا سكربت فحص احتيال، بينما طلب الدفع ينتظر خلفهما. هذه ليست مشكلة "اجعل كل شيء أسرع". إنها خطوة واحدة حارجة.
قم بتغيير واحد عن قصد. مثلاً، ابدأ طلب الدفع فورًا، وأرسل تحليلات فقط بعد عرض شاشة التأكيد.
تحقق بنفس الإعداد: نفس التقييد، نفس الخطوات، عدة تشغيلات. إذا انخفض وقت التأكيد ولم ترتفع الأخطاء، فحققت فوزًا حقيقيًا. افحص أيضًا أنك لم تُعطل عمليات الاسترداد أو المحاولات أو حماية الإرسال المزدوج.
يبقى الأداء منطقيًا عندما يصبح روتينًا، لا مهمة إنقاذ. اجعل القياس الإجراء الافتراضي، حتى عندما يبدو كل شيء على ما يرام.
اختر مجموعة صغيرة من المقاييس سيتتبعها فريقك دائمًا. اجعلها ثابتة حتى يسهل اكتشاف الاتجاهات:
ابنِ حلقة حول تلك المقاييس. فحص أساسي أسبوعي غالبًا يكفي. عندما ينحرف مقياس ما، يكون ذلك محرّكًا لإعادة إنتاج البطء، تحليله، عمل تغيير واحد، والتحقق من التأثير.
احتفظ بسجل أداء بسيط بأي صيغة يستخدمها فريقك فعليًا. سجّل ما قستَه (بما في ذلك الجهاز، الشبكة، والبناء)، ما الذي غيّرته، وماذا فعلت الأرقام بعد ذلك.
إذا بنت التطبيق باستخدام Koder.ai، يمكن أن تساعدك Planning Mode على كتابة رحلة المستخدم والمقياس الذي تهتم به قبل أي تغيير. ثم استخدم اللقطات والتراجع للحفاظ على التجارب آمنة: لقطة → تطبيق تغيير واحد → إعادة اختبار → التراجع إذا كانت النتيجة مضطربة أو أسوأ.
في التخطيط أو المراجعة، سؤال واحد يحافظ على صحة الثقافة: "ماذا قسنا، وماذا غير ذلك؟"
لأنك قد تقضي ساعات تحسن شيئًا لا يسبب التأخير فعليًا. ابدأ بإثبات أين يذهب الوقت (الشبكة، الخادم، الخيط الرئيسي، العرض)، ثم استهدف أكبر عنق زجاجة.
اكتب فعلًا واحدًا محددًا والظروف الدقيقة، ثم كرره:
إذا لم تستطع تكرار النتيجة، فلا يمكنك الوثوق بها.
اختر 1–3 مقاييس تتطابق مع ما يلاحظه المستخدمون:
بيانات المختبر تكون مسيطرة وقابلة للتكرار (ممتازة للتصحيح). بيانات المستخدم الحقيقية تعكس الأجهزة والشبكات الحقيقية (ممتازة للأولويات).
قواعد جيدة: استخدم بيانات المستخدم الحقيقية لاكتشاف أسوأ الرحلات، ثم استخدم ملفات تعريف المختبر لشرح لماذا هي بطيئة واختبار الإصلاحات بأمان.
عامِل الأمر كتقرير خطأ:
هذا ينقل النقاش من آراء ("لا بد أنها الصور") إلى دليل.
سجّل التفاعل البطيء في ملف تعريف وابحث عن أكبر كتلة زمنية:
ثم اكتب فرضية من جملة واحدة يمكنك اختبارها.
لأنه يحافظ على وضوح السبب والنتيجة. إذا غيرت خمسة أشياء ورُجِع الأداء أفضل، فلن تعرف ما هو الفاعل. إذا ساءت الأمور، فالرجوع يصبح معقدًا.
قاعدة عملية: تغيير واحد يمكنك تفسيره، ومقياس واحد تتوقع تحركه، ثم قِس مرة أخرى.
أعد نفس إعداد الاختبار وقارن قبل/بعد باستخدام نفس المقاييس.
لتقليل الضجيج:
احتفظ بالتغيير فقط إذا تحسّنت الأرقام في نفس الظروف.
الأخطاء الشائعة:
التزم برحلة واحدة، إعداد واحد، ونتيجة موثقة ومحققة.
استخدمها لجعل التجارب آمنة وقابلة للمقارنة:
الأدوات تساعد، لكن الفوز الحقيقي هو الحلقة القابلة للتكرار: خط أساس → تحليل → تغيير واحد → تحقق.
تجنّب تتبع الكثير من الأرقام دفعة واحدة حتى لا تختار النتائج المريحة.