1. حدد النتيجة والحدود
سجّل اسم مالك واحد واكتب النتيجة قبل فتح أداة التدقيق. اذكر الجمهور، الرحلة، الصفحات أو المسارات، نافذة زمنية، والقرار الذي ينبغي أن تدعمه الأعمال. هدف مفيد يصف مهمة، مثل إكمال تدفّق المنتج إلى السلة على الهاتف المحمول، لا أمنية غامضة لجعل الموقع "أسرع".
سرد ما لا يقبل التفاوض: تدفّق الشراء أو الاستفسار العامل، وصول الحساب، سلوك الموافقة، إمكانية الوصول، قدرة البحث على الزحف، والمحتوى المعتمد. ليست مكسبًا حقيقيًا إذا تحسّن مؤشر اصطناعي بينما يفشل نموذج، أو يُخفى المحتوى عن البحث، أو تصبح تجربة لوحة المفاتيح أصعب.
اكتب صفحة البداية والإجراء الذي يقوم به المستخدم وحالة النهاية الناجحة في جملة واحدة.
اختر نتيجة لا ينبغي أن تسوء، مثل نجاح الإرسال أو عدم ظهور عائق جديد لإمكانية الوصول.
2. سجّل حالة أساسية قابلة للمقارنة
قبل تغيير الكود أو المحتوى أو التهيئة أو العلامات، احفظ قائمة عناوين URL، والتاريخ، وشروط الاختبار، وإصدار النشر، والتقارير أو التتبعات، ونتيجة المهمة اليدوية. توصي web.dev بتسجيل حالة الموقع قبل التغييرات واختبار أنواع صفحات متعددة؛ بالنسبة إلى تطبيقات الصفحة الواحدة، ضمّن المسارات والمكوّنات والتدفّقات بدلًا من تحميل الصفحة الأولى فقط.
استخدم أكثر من عدسة واحدة. يوفر Lighthouse فحوصات آلية للأداء، وإمكانية الوصول، وSEO، وغيرها. اختبر التحميل الأول مع مسح التخزين أو ملف تعريف نظيف، ثم أكمل المهمة المستهدفة. حيثما تتوفر بيانات فعلية كافية من المستخدمين، قارن مجموعات الصفحات المهمة وفئات الأجهزة. تشكل Core Web Vitals قياسات من الحقل: LCP يغطي التحميل، INP التفاعلية، وCLS الاستقرار البصري.
تعكس بيانات الحقل الزيارات الحقيقية؛ يجعل الاختبار المخبري المشكلة أسهل للتكرار. استخدم كليهما عند التوفر.
تحميل محاكي لا يمكنه قياس INP لأن المستخدم لا يتفاعل؛ زمن الحظر الكلي (Total Blocking Time) في المختبر هو مجرد بديل تقريبي.
3. فحص الرحلة من البداية إلى النهاية
جمّع النتائج حسب الرحلة والآلية. راجع حجم الطلبات، أوقاتها، والتبعيات لملفات الصفحة والجهات الخارجية. تفقد نافذة العرض على الهاتف المحمول، مسار لوحة المفاتيح، التركيز الظاهر، التسميات، الأخطاء، العناوين، غرض الروابط، التكبير/التصغير، وماذا يحدث إذا كانت صورة أو سكربت أو خدمة تعتمد على الموافقة بطيئة أو غير متاحة.
اعتبر مخرجات أدوات إمكانية الوصول الآلية فرزًا أوليًا. تقول W3C إنه لا توجد أداة يمكنها وحدها تحديد ما إذا كان الموقع يفي بمعايير إمكانية الوصول؛ فالتقييم البشري الخبير مطلوب. ولأغراض البحث، تأكد من بقاء الموارد المهمة المُصيَّرة متاحة للزواحف وللمستخدمين. أدرج عمليات إعادة التوجيه، ووسوم الرابط الأساسي (canonical)، والروابط الداخلية، وتوجيهات robots، وخرائط الموقع، والبيانات المنظمة حين يؤثر التغيير فيها.
سرد مدراء العلامات، التحليلات، الدردشة، الدفع، الخطوط، شبكات التوصيل (CDNs)، واجهات برمجة التطبيقات، وأدوات الموافقة التي تعتمد عليها المهمة.
بالنسبة للدفع، والمصادقة، وبيانات المستخدم، والرؤوس، أو ضوابط الأمان، احصل على مراجعة مؤهلة للأمن والدفع.
4. أنشئ قائمة أعمال مرتبة حسب الأولوية
اكتب فرضية صغيرة لكل عنصر: في هذه الصفحة أو هذا التدفق، غيّر هذه الآلية لأن الأدلة تشير إلى أنها تسبب هذه المشكلة؛ قِس النتيجة المتوقعة واحمِ حواجز الأمان المُحدَّدة. حافظ على التمييز بين الملاحظة والتشخيص. يمكن أن يُظهر تتبّع محفوظ أن صورة كبيرة تؤخّر المحتوى، لكن العلاج لا يزال يحتاج إلى مراجعة التصميم والمحتوى.
رُتّب العناصر حسب الأثر، والثقة، والجهد، والمخاطر. الأثر هو الرحلة ذات الأولوية المتأثرة. الثقة هي ما إذا كانت الأدلة المخبرية والحقولية واليدوية متوافقة. يشمل الجهد التنسيق، وليس الشفرة فحسب. تتضمن المخاطر التبعيات، والأمن، وتعقيد النشر، وقابلية الرجوع. يمكن أن تتجاوز التعرضات الوظيفية أو الأمنية الحرجة هذا النموذج وتحتاج إلى فرز متخصص.
احتفظ بالمالك، رابط الأدلة، الفرضية، الصفحات، المقياس، حواجز الأمان، التبعيات، طريقة النشر، ومؤشر التراجع.
لا تجمع عمليات إعادة هيكلة غير ذات صلة في تغيير مقاس ما لم تتطلبها الحاجة إلى الأمان.
5. انشر بأمان واحتفظ بطريقة للعودة
قبل النشر، سجّل ما يتغير، والموافق، ونافذة الإصدار، ومالك التحقق، شرط النجاح، مؤشر التراجع، وطريقة الاستعادة. اختبر في بيئة غير إنتاجية ممثلة إن أمكن، بما في ذلك المحتوى، والأذونات، والتكاملات، وإعادة التوجيه، وخيارات الموافقة، ومسارات الفشل الشائعة. لا يزال الإنتاج قد يختلف بسبب البيانات، والذاكرة المؤقتة، والتهيئة، والجهات الخارجية.
استخدم نشرًا تدريجيًا صغيرًا، أو علم ميزة (feature flag)، أو ملف مورد ذو إصدار، أو تهيئة قابلة للعودة حيث يدعمها النظام الأساسي. أكد سلوك التخزين المؤقت وCDN قبل مقارنة النتائج. تعالج OWASP التهيئة وإدارة النشر كمجال اختبار أمني؛ لا ينبغي أن تكون الرؤوس، والأذونات، وكشف الملفات، وإعدادات النطاق أو السحابة تغييرات تحسين تجرى عفويًا.
حدد مُحفِّزًا مرئيًا، مثل فشل الدفع، تكسّر التنقّل، خطأ عميل غير متوقع، أو تراجع في إمكانية الوصول.
خطة الاسترجاع يمكن أن تقلل زمن الاسترداد لكنها لا تزيل كل المخاطر؛ اختبر الاستعادة قبل الاعتماد عليها.
6. تحقق وقرّر وكرر
بعد الإصدار، كرّر فحوصات الوظائف الأساسية والاختبارات المخبرية القابلة للمقارنة. أعد فحص الأجهزة والمتصفحات والحالات والتكاملات ذات الصلة. قارن المتشابه بالمشابه: عنوان URL، حالة التخزين المؤقت، فئة الجهاز، المنطقة حيث أمكن، ونافذة القياس. أكد حواجز الأمان وكذلك المقياس المستهدف.
امنح الأدلة وقتًا للنضوج. تذكر ملاحظة Google أن تغييرات البحث قد تستغرق ساعات إلى أشهر للظهور وتقترح الانتظار أسابيع لتقييم ما إذا نجحت. بيانات الأداء الحقيقية هي دليل مجمّع، وليست حكم إصدار فوري. سجّل الاحتفاظ، أو التعديل، أو التحقيق، أو التراجع، ثم أعد أخذ خط أساس بعد تغييرات ذات مغزى في القالب، أو المنصة، أو العلامات، أو المحتوى، أو التبعيات.
نتيجة الرحلة المتوقعة تتحسّن وتظل حواجز الأمان المتفق عليها سليمة.
تصرّف عندما تتعارض الأدلة الحقلية أو المهمة مع نتيجة المختبر، أو يتراجع حاجز أمني حرج.