ابدأ بالرحلات، لا بمتوسط الموقع العام
سرد ثلاثة إلى خمسة رحلات حيث للتأخير تكلفة واضحة على العميل أو على العمليات: الهبوط على صفحة حملة، العثور على منتج، إرسال نموذج اهتمام، تسجيل الدخول، أو إكمال طلب دعم. لكل منها، اكتب نقطة البداية، النتيجة المفيدة، فئة الجهاز الرئيسية، والصفحة أو التفاعل الذي يجب أن يعمل بشكل جيد.
اعطِ كل رحلة صف ميزانية خاص بها. قد تحمل لوحة تحكم مزيدًا من الكود مقارنة بمقال عام، لكن إجراء الفلترة فيها يحتاج هدف استجابة. قد تقبل صفحة منتج غنية بالوسائط صورًا أكبر، لكنها تحتاج إلى حد للصورة المرئية الرئيسية. هذا يمنع اختفاء مسار حرج ضعيف داخل متوسط مصدري واسع.
سَمِّ ما يستطيع الزائر رؤيته أو فعله، مثل قراءة العرض، رؤية نتيجة، أو استلام تأكيد النموذج.
يمكن أن يغير التخزين المؤقت (caching) تكلفة الموارد مادياً، لذا سجّل ما إذا كانت الميزانية تغطي الزيارة الأولى أو الزيارة المتكررة أو كليهما.
اختر النتائج والمدخلات القابلة للسيطرة
استخدم كلًا من مقاييس النتيجة وحدود المدخلات. تصف Google Largest Contentful Paint أو LCP أداء التحميل؛ وInteraction to Next Paint أو INP استجابة التفاعل؛ وCumulative Layout Shift أو CLS الاستقرار البصري. عتباتها الموصى بها الجيدة هي LCP أقل من أو يساوي 2.5 ثانية، وINP أقل من أو يساوي 200 مللي ثانية، وCLS أقل من أو يساوي 0.1 عند الرتبة المئوية الـ75، ويُنظر إليها بشكل منفصل للجوال وسطح المكتب.
أضف حدودًا تكشف السبب مبكرًا: JavaScript الابتدائي، الصور المطلوبة قبل المحتوى الرئيسي، إجمالي النقل للمسار، طلبات الجهات الخارجية، وودجت معروف باستهلاكه العالي. تتبع أحجام النقل المضغوطة بشكل متسق. يمكن أن يساعد تشخيص مثل Time to First Byte في التحقيق في بطء التحميل، لكنه ليس مقياس نتيجة العميل بحد ذاته.
استخدم LCP عندما تعتمد الرحلة على ظهور المحتوى الرئيسي.
استخدم INP الحقلية للمسارات مثل البحث، والفرز، والقوائم، وسلة الشراء؛ واستخدم بديلًا مختبريًا فقط قبل وجود بيانات حقل.
حدد سقفًا للمسار الابتدائي والمساهمين الأكبر حتى يعرف المالكون ما الذي يجب تغييره بعد خرق الحد.
حدد الأرقام بناءً على الخط الأساسي لديك
التقط خطًا أساسياً لكل رحلة. في PageSpeed Insights، ميز بيانات الحقل في Chrome User Experience Report (CrUX)، التي تجمع تجارب مستخدمي Chrome الحقيقية، عن بيانات Lighthouse المختبرية، التي تمثل اختبارًا متحكمًا. تتحقق بيانات الحقل من التجربة التي تصل إلى المستخدمين؛ بينما تجعل الاختبارات المختبرية التغيير قابلًا للتكرار قبل الإصدار.
قسّم على الأقل حسب الجوال وسطح المكتب وحيثما أمكن حسب القالب أو عنوان URL الحرج. يمكن أن يرجع PageSpeed Insights إلى بيانات الأصل إذا غابت بيانات URL، وبعض الصفحات لا تملك بيانات CrUX. ساّمِ تلك الحالة كأساس مختبري وأضف قياس مستخدم حقيقي للرحلات المهمة. احتفظ بعنوان الاختبار، وجهاز وملف تعريف الشبكة، وحالة التخزين المؤقت، والتاريخ، وإصدار الأداة مع كل خط أساسي.
اختر هدفًا يحسّن الخط الأساسي بخطوة مخططة، ثم اختبره في ظروف تمثيلية. الميزانية التي تمنع الإصدارات العادية سيتم تجاوزها؛ والميزانية الأعلى من تجربة اليوم لا تحمي أحدًا.
الرتبة المئوية الـ75 هي القيمة التي يقع عندها أو تحتها 75% من التجارب الملاحظة؛ فهي ليست متوسطًا.
اجعل الميزانية قاعدة لإصدار السوفتوير
احتفظ بالميزانية في مكان مُؤرّخ وقابل للمراجعة بجانب الكود أو قائمة التحقق من الإصدار. يحتاج كل صف إلى الرحلة، والمقياس، وملف الاختبار أو السكان، وعتبة التحذير، وعتبة الخطأ، والمالك، وطريقة القياس، ومسار الاستثناء. توصي MDN بمستويات تحذير وخطأ: التحذير يدعم التخطيط الاستباقي، بينما الخطأ هو حد علوي له تأثير سلبي ملحوظ.
أتمتة الفحوصات الموثوقة. يمكن لأداة التجميع (bundler) رفض أصل كبير الحجم أو نقطة دخول ابتدائية؛ يدعم webpack حدودًا قصوى للحزم ونقاط الدخول وتلميحات خطأ للإنتاج. شغّل اختبارات مختبرية قابلة للتكرار للرحلة المتأثرة في طلبات السحب (pull requests) أو مرشحات الإصدار. احتفظ بمقاييس الحقل للتحقق ما بعد الإصدار ولأولويات العمل بدلًا من بوابة بنية غير موثوقة.
عندما يفشل حد، قلل أصلًا، أجل رمزًا غير ضروري، غيّر التجربة، قسّم الإصدار، أو وافق على استثناء. لا ترفع الحد بصمت لتمرير البناء.
سجل مالكًا منتجياً وتقنياً، وتأثيرًا على العملاء، وتاريخ انتهاء، ومهمة تصحيح قبل الإصدار.
حظر عتبة خطأ قابلة لإعادة الإنتاج على رحلة محمية؛ أبلغ وتحقق من عتبات التحذير.
تحقق وصحح بعد الإطلاق
لا يتنبأ وزن الصفحة بالتجربة الكاملة. ترتيب الطلبات، والعمل الذي يعطل العرض (render-blocking)، وقدرة الجهاز، وظروف الشبكة، والتخزين المؤقت، والجهات الخارجية تؤثر أيضًا. احتفظ بحدود المدخلات لالتقاط النمو ومقاييس النتيجة لاختبار ما إذا كان المسار قابلاً للاستخدام. تكشف واجهة W3C Resource Timing توقيتات الموارد والحجم المنقول والمشفر والمفكوك لمزيد من التشخيص. قد تقيد أذونات التوقيت تفاصيل التوقيت عبر المصادر، لذا فإن شلال تحميل غير مكتمل لا يثبت عدم وجود تكلفة من طرف ثالث.
راجع نتائج الحقل بعد تغييرات مادية في القالب، أو المنصة، أو علامات التسويق، أو المرور. إذا ساءت LCP، فافحص استجابة الخادم، وموارد LCP، والعمل المعطل للعرض. إذا ساءت INP، فافحص التفاعلات الفعلية؛ لا يستطيع Lighthouse قياس INP لأنه لا يمتلك إدخال مستخدم، رغم أن Total Blocking Time هو بديل مختبري. استخدم سير عمل التحسين الاستباقي في SIU لفرز خرق الميزانية، وتثبيت المسار الحرج، والتحقق من الإصلاح في نفس سياق القياس.
تكشف الاستثناءات المنتهية سريعًا عن دين أداء مؤقت أصبح دائمًا.