قيّم رحلة العميل قبل تعديل الكود
اختر مساراً وتفاعلاً مهماً واحداً، مثل فتح القائمة، تصفية النتائج، أو إرسال نموذج. سجِّله في لوحة Performance في Chrome DevTools من حالة متصفح نظيفة. كرّر الإجراء والتقط تسجيلًا بتشغيل CPU مُقَيَّد وأيضاً بتشغيل على جهاز تطوير؛ آثار سطح المكتب قد تُخفي العمل الذي يُزعج على هاتف منخفض القوة.
استخدم التتبّع لاختبار فرضية محددة، لا لإلقاء اللوم على مكوّن استنادًا إلى تقرير الحزمة. في مخطط الشعلات Main flame chart، تعني الأشرطة الأعرض وقتًا أطول، وتُظهر الأشرطة المتراكبة مكدس الاستدعاءات. يشير مثلث أحمر على مهمة إلى احتمال كونها مهمة طويلة؛ حدّدها واتبع رابط الشيفرة التي بدأتها. احفظ تتبعات قبل وبعد للتغييرات المهمة.
سجِّل قبل الإجراء بقليل وأوقف بعد الوصول إلى النتيجة المرئية.
حافظ على المسار، حالة الحساب، وتسلسل الإجراءات ثابتة.
عيّن كل تكلفة عليا إلى الفريق أو البائع القادر على تغييرها.
اقرأ التتبع كقائمة انتظار للعمل
المهمة الطويلة هي عتبة للتحقيق، وليست تشخيصًا كاملاً. يبلّغ معيار W3C Long Tasks عن المهام التي تستغرق 50 ملّي ثانية أو أكثر. انظر تحت المهمة إلى تقييم JavaScript، معالج حدث، إعادة حساب الأنماط، التخطيط، أو الرسم. يحدد مكدس الاستدعاءات مكان البداية؛ وتُظهر التوقيتات ما إذا كانت المشكلة في الشيفرة، العرض، أو إطار طرف ثالث.
أعطِ الأولوية للتكاليف التي تتكرر أثناء تفاعل ذي قيمة. قد يبدو معالج قصير بطيئًا إذا أدى إلى تخطيط الصفحة أو انتظر خلف عمل سابق. التتبّع قياس مخبري؛ لذا أكّد الإصلاح على أجهزة ممثلة، واستخدم عند التوفر قياسات ميدانية تراعي الخصوصية.
تتطلب معالجة التحميل الأولي حلولًا مختلفة عن معالج ما بعد اللمس.
اعثر على أنماط كتابة أنماط متكررة وقراءة تخطيط قبل إعادة البناء.
أرفق التتبع، السيناريو، وأعلى التكاليف إلى عنصر العمل.
اشحن رمزًا أقل وقتما يهم
اجرد السكربتات بحسب المسار والغرض. أزل الحزم غير المستخدمة والمكررات والتجارب المتوقفة وشيفرة الميزات المنتهية. ثم قسّم الميزات الخاصة بمسار معين أو نادرة الاستخدام كي تُحمّل عند الحاجة بدلًا من تحميلها في المسار الأولي. يمكن للتحميل الديناميكي أن يقلل عمل بدء التشغيل، لكنه قد يسبب تأخرًا ملحوظًا عندما يحتاج المستخدم إلى الميزة فورًا.
اسأل إن كان المكوّن يحتاج إلى إطار عمل كامل على جهة العميل، أو إن كانت أداة ما تكرر قدرة موجودة، أو إن كان HTML ثابتًا مع تحسين بسيط كافيًا. اختبر الحالة الاحتياطية للموديول المؤجل. ينبغي أن تؤجل الصفحة الميزة الاختيارية بسلاسة بدلًا من إظهار عنصر تحكم غير فعّال.
وثّق السكربتات المسموح بها على المسار ولماذا.
فكّر في هذا للمحررات الاختيارية، الخرائط، المشغلات، أو شاشات التقارير.
اختبر المصادقة، الوصولية، الدفع، وإكمال النماذج؛ واحصل على مراجعة مؤهلة عندما تتأثر عناصر التحكم.
قسّم العمل حتى يتمكن المتصفح من الاستجابة
تسمية الدوال الصغيرة لا تخلق مهام متصفح منفصلة عندما تُشغّل متزامنًا. لِحَلقة طويلة، اقسم العمل إلى دفعات، حدّث الحالة المرئية الفورية، ثم امنح المتصفح فسحة قبل المتابعة. هذا يسمح للمتصفح بمعالجة المدخلات والرسم بين الدفعات.
عند توفر الدعم، تفسح scheduler.yield() المجال للخيط الرئيسي ثم تتابع العمل لاحقًا؛ تحقّق من دعمها برمجيًا واستخدم بديلًا في المتصفحات غير المدعومة. لا تفسح المجال بعد كل عملية صغيرة: فهذا يضيف كلفة وقد يزيد زمن الإكمال. اختر الحدود بناءً على القياسات، وحافظ على إمكانية الإلغاء، وامنع النتائج القديمة من استبدال حالة أحدث.
أظهر القبول أو التقدّم قبل العمل المتابع غير المرئي.
أفسح المجال للمتصفح قبل أن يصبح العمل المقاس طويلًا، بدلًا من فعل ذلك مرةً لكل عنصر.
لا توصي إرشادات web.dev الحالية باستراتيجية جديدة مبنية على isInputPending().
انقل الحِساب، لا الواجهة، إلى عامل ويب
Web Worker ينفّذ شيفرة على خيط خلفي منفصل عن خيط التنفيذ الرئيسي. يناسب التحليل المكثّف، تحويل البيانات، فهرسة البحث، وحسابات أخرى لا تحتاج وصولًا مباشرًا إلى الواجهة. أرسل مدخلًا معرفًا، أعد نتيجة معرفَة، وحافظ على العرض وتغييرات الحالة المرئية على الخيط الرئيسي.
لا تناسب Web Workers كل الحالات. فهي لا تستطيع التلاعب مباشرةً بـ DOM أو استخدام Window، وعادةً ما تنسخ الرسائل البيانات. وقد تفوق كلفة إنشاء عامل ونقل البيانات وتنسيق الأخطاء كلفةَ حساب صغير. قِس التفاعل كاملًا، وأنهِ العمال غير الضروريين، وصمّم حالة احتياطية إذا فشل عمل العامل.
ابدأ بحساب يمكن تسلسل مدخلاته ومخرجاته واختبارها.
تجاهل النتائج المُنشأة لمرشح أو مسار أو إجراء أقدم.
أبلغ عن تقدّم ذي معنى عبر الواجهة الاعتيادية.
أدِر JavaScript للجهات الخارجية بوصفه تبعية إنتاجية.
يمكن أن تضيف تحليلات، إعلانات، تجارب، محتوى اجتماعي مُضمّن، مشغلات فيديو، وأدوات الدعم طلبات، تقييم JavaScript، iframes، واعتمادات. قد يكون سكربت البائع ضروريًا، لكنه خارج السيطرة المباشرة لفريق التطبيق ويمكن أن يؤثر على الأداء والخصوصية والأمان والاستمرارية. اجمع غرضه، المسارات، شرط التحميل، الموافِق، متطلبات الموافقة، ومالك الإزالة.
عندما تسمح الشروط والعقود، قارن صفحة ممثلة بوجود مصدر طرف ثالث واحد وبدونه. تكشف أدوات الأداء التقييم المكلف والحمولات وإسناد المهام الطويلة. احتفظ بتكامل خفيف أو مؤجل فقط إذا كانت قيمته الموثقة تبرر كلفته المقيسة. تأكد من عمل المحتوى الأساسي والمعاملة الرئيسية عندما تكون تبعية اختيارية بطيئة أو غائبة.
حمِّل العلامة فقط على المسارات والظروف التي تحتاجها.
اشمل تغييرات tag-manager في مراجعة الأداء، الخصوصية، الأمان، وإجراءات التراجع.
وثّق واختبر كيفية تعطيل تكامل غير حرج.
اجعل الاستجابة حاجزًا لإصدار الإنتاج
حوّل التتبّع الذي حقق التحسن إلى فحص صغير للتراجع في الرحلة المهمة. حدّد التفاعلات المشمولة، والجهاز أو قيد CPU، والاستجابة المتوقعة، والمراجع. اربطه بمراجعة الحزمة وجرد الطرف الثالث حتى لا تعيد حزمة أو وسم جديد إدخال عمل على الخيط الرئيسي بصمت.
تستخدم Status Is UP هذه الأدلة للتحسين الاستباقي والإصلاح الآمن، لا كبديل عن مراقبة التوافر المباشرة. قبل تغيير عالي المخاطر، جهّز التراجع وتحقق من التدفق الحرج بعد الإصدار. تختلف النتائج باختلاف الجهاز والشبكة والمتصفح والمحتوى وحالة الحساب؛ لذا تعامل مع العتبات بوصفها حواجز أمان لا ضمانات.
اشترط تتبعات قبل وبعد للملاحة المشتركة، السلة، البحث، أو الحزم الكبيرة.
حدّد علامة الميزة أو إعداد الوسم أو إصدار النشر الذي يعيد السلوك المعروف بأنه جيد.
أعد القياس بعد الإصدارات الكبرى، تغييرات البائع، أو تغيّر مزيج الأجهزة.