الوحدة 12 · اختبار تطبيقات الويب

أداء الويب

بقلم فريق ضمان الجودة في متقن سوفت · · 18 دقيقة · مبتدئ

أداء الويب هو مدى سرعة ظهور المحتوى الرئيسي للصفحة، ومدى سرعة استجابتها حين ينقر المستخدم أو يكتب، ومدى ثباتها أثناء التحميل. ويُقاس في المتصفح، من جهة المستخدم: فواجهة برمجية تجيب في ⁦150⁩ مللي ثانية قد تقف خلف صفحة لا تظهر صورتها الرئيسية إلا بعد أربع ثوانٍ.

وتسمّي مؤشرات أداء الويب الأساسية من Google ‏(Core Web Vitals) هذه التجارب الثلاث وتضع لها حدوداً: أكبر عرض للمحتوى (Largest Contentful Paint, LCP) للتحميل، والتفاعل حتى العرض التالي (Interaction to Next Paint, INP) للاستجابة، والإزاحة التراكمية للتخطيط (Cumulative Layout Shift, CLS) للثبات البصري. فزر «ادفع» الذي يقفز إلى الأسفل لحظة لمسه مشكلة في الثبات البصري، ويحوّلها CLS إلى رقم.

لماذا يهم

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

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

مؤشرات Core Web Vitals الثلاثة وحدودها

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

  • LCP ‏(أكبر عرض للمحتوى)، للتحميل: الزمن من بدء الانتقال إلى الصفحة حتى عرض أكبر صورة أو كتلة نص أو فيديو داخل منفذ العرض (viewport). جيد: ⁦2.5⁩ ثانية أو أقل. ضعيف: أكثر من ⁦4.0⁩ ثوانٍ.
  • INP ‏(التفاعل حتى العرض التالي)، للاستجابة: التأخير من النقر أو اللمس أو ضغط مفتاح حتى الإطار التالي الذي يرسمه المتصفح؛ وعلى امتداد الزيارة يُحتسب أبطأ تفاعل مع تجاهل القيم الشاذة النادرة. جيد: ⁦200⁩ مللي ثانية أو أقل. ضعيف: أكثر من ⁦500⁩ مللي ثانية. وقد حلّ INP محل تأخير الإدخال الأول (First Input Delay, FID) في عام ⁦2024⁩.
  • CLS ‏(الإزاحة التراكمية للتخطيط)، للثبات البصري: درجة بلا وحدة للمحتوى الذي يتحرك على نحو غير متوقع، تُؤخذ من أكبر دفعة متتالية من إزاحات التخطيط؛ ولا تُحتسب الإزاحات التي تلي إدخال المستخدم نفسه مباشرةً. جيد: ⁦0.1⁩ أو أقل. ضعيف: أكثر من ⁦0.25⁩.
  • الحكم على الصفحة: يُقرأ كل مؤشر عند المئين الخامس والسبعين (p75) من الزيارات، أي القيمة التي تبلغها 75% من الزيارات أو تقل عنها، للهاتف ولسطح المكتب كلٌّ على حدة، ولا تجتاز الصفحة التقييم إلا إذا كانت المؤشرات الثلاثة جيدة. والحدود هنا فاصلة بدقة: قيمة LCP البالغة ⁦2500⁩ مللي ثانية جيدة، أما ⁦2501⁩ فليست كذلك.
  • مثال: عند p75، صفحة منتج قيمها LCP ‏⁦3.1⁩ ثانية وINP ‏⁦180⁩ مللي ثانية وCLS ‏⁦0.18⁩ لا تجتاز التقييم، لأن LCP وCLS يحتاجان إلى تحسين مع أن INP جيد.
فئات مؤشرات Core Web Vitals عند المئين الخامس والسبعين: صفحة المنتج في المثال جيدة في INP ‏(⁦180⁩ مللي ثانية) لكنها تحتاج إلى تحسين في LCP ‏(⁦3.1⁩ ثانية) وCLS ‏(⁦0.18⁩)، فلا تجتاز التقييم.

LCP: التحميل، بالثواني

المحور من 0 s إلى 6 s
  • ≤ 2.5 sجيد
  • 2.5–4.0 sيحتاج إلى تحسين
  • > 4.0 sضعيف
  1. 13.1 s صفحة المنتج في المثال، p75أكثر من ⁦2.5⁩ ثانية: يحتاج إلى تحسين.تنبيه

INP: الاستجابة، بالمللي ثانية

المحور من 0 ms إلى 700 ms
  • ≤ 200 msجيد
  • 200–500 msيحتاج إلى تحسين
  • > 500 msضعيف
  1. 1180 ms صفحة المنتج في المثال، p75⁦200⁩ مللي ثانية أو أقل: جيد.نجاح

CLS: الثبات البصري، درجة بلا وحدة

المحور من 0 إلى 0.4
  • ≤ 0.1جيد
  • 0.1–0.25يحتاج إلى تحسين
  • > 0.25ضعيف
  1. 10.18 صفحة المنتج في المثال، p75أكثر من ⁦0.1⁩: يحتاج إلى تحسين.تنبيه

الحدود من web.dev، وتُقرأ للهاتف ولسطح المكتب كلٌّ على حدة؛ ولا تجتاز الصفحة التقييم إلا إذا كانت المؤشرات الثلاثة جيدة.

بيانات المختبر والبيانات الميدانية

تُقاس بيانات المختبر (lab data) في بيئة مضبوطة: ملف تعريف جهاز واحد، وإعداد شبكة واحد، وذاكرة تخزين مؤقت فارغة عادةً. وأهم أداتين مخبريتين هما لوحة الأداء (Performance) في أدوات المطوّرين، وLighthouse، وهي أداة التدقيق المدمجة في أدوات المطوّرين في Chrome، تحمّل الصفحة في ظروف محاكاة لهاتف أو لسطح مكتب وتعرض المقاييس ودرجة إجمالية. وبيانات المختبر قابلة للتكرار، ومتاحة قبل الإصدار، وتُظهر السبب: عنصر LCP، والسكربت الذي حجب الخيط الرئيسي (main thread)، والعنصر الذي تحرّك.

أما البيانات الميدانية (field data) فتأتي من مستخدمين حقيقيين على أجهزتهم وشبكاتهم، وتُسمّى أيضاً مراقبة المستخدمين الحقيقيين (Real User Monitoring, RUM). ويجمعها تقرير تجربة مستخدمي Chrome ‏(CrUX) للصفحات العامة التي تصلها زيارات كافية من Chrome، ويعرض قيمة p75 خلال آخر ⁦28⁩ يوماً؛ وتعرضها صفحة PageSpeed Insights من Google لعنوان URL معيّن بجانب تشغيل مخبري لـLighthouse، ويمكن للفريق جمع بياناته الخاصة بمكتبة web-vitals المفتوحة المصدر. تُظهر البيانات الميدانية ما يحصل عليه المستخدمون فعلاً، لكنها تصل متأخرة، ولا توجد لبيئة Staging، ونادراً ما تشرح السبب.

  • يحتاج INP إلى تفاعلات حقيقية، لذا لا تستطيع أداة مخبرية تكتفي بتحميل الصفحة أن تقيسه. ويعرض Lighthouse زمن الحجب الكلي (Total Blocking Time, TBT)، أي مجموع الوقت الذي حجبت فيه المهام الطويلة الخيط الرئيسي أثناء تحميل الصفحة، بديلاً مخبرياً: فارتفاعه ينبّه إلى أن التفاعلات قد تكون بطيئة، لكنه ليس INP.
  • تختلف قيم المختبر والميدان للصفحة نفسها عادةً: فلدى المستخدمين الحقيقيين أجهزة أخرى، وملفات محفوظة مسبقاً في ذاكرة التخزين المؤقت، وأحجام شاشات أخرى، ومن ثمّ عناصر LCP أخرى، وهم يمرّرون الصفحة وينقرون.
  • استخدم البيانات الميدانية لتقرّر هل توجد مشكلة وما حجمها، واستخدم بيانات المختبر لتجد السبب، ولتقارن نسخ البناء قبل الإصدار، ولتؤكد الإصلاح. ودرجة Lighthouse ‏(من ⁦0⁩ إلى ⁦100⁩) ملخّص مخبري، وليست تقييم Core Web Vitals.

اختبار سرعة الصفحة خطوة بخطوة

تعامل مع فحص الأداء كأي اختبار آخر: صفحات وتفاعلات مختارة (البحث والمنتج والدفع؛ والتصفية والإضافة إلى السلة)، وظروف ثابتة، ونتيجة متوقعة، وأدلة. واختبر الهاتف وسطح المكتب كلاً على حدة.

  • ثبّت الظروف: نافذة تصفح متخفٍّ بلا إضافات، ونسخة بناء (build) وبيئة محددتان، وإعداد الهاتف في Lighthouse أو إبطاء (throttling) محدد للمعالج والشبكة، وتحميل بذاكرة تخزين مؤقت فارغة وآخر بعد أن حُفظت فيها ملفات الصفحة.
  • شغّل Lighthouse عدة مرات واعتمد الوسيط (القيمة الوسطى بعد ترتيب النتائج)، لأن النتائج تتفاوت بين التشغيلات. وسجّل قيم المقاييس وعنصر LCP، لا الدرجة وحدها.
  • سجّل التفاعلات الأساسية في لوحة الأداء مع إبطاء المعالج: تُظهر المهام الطويلة (long tasks) على الخيط الرئيسي ما الذي تنتظره النقرة البطيئة، ويُظهر مسار إزاحات التخطيط (Layout shifts) العنصر الذي تحرّك. ومن الأسباب الشائعة لإزاحات التخطيط صور بلا أبعاد، وشرائط إعلانية متأخرة، وخطوط الويب.
  • في لوحة الشبكة، افحص أكبر الملفات، والضغط (Content-Encoding)، وترويسات التخزين المؤقت للملفات الثابتة، والزمن الذي يستغرقه وصول مستند HTML، لأن زمن الخادم جزء من LCP.
  • قارن بخط أساس (baseline): نسخة البناء السابقة في الظروف نفسها، أو ميزانية اتفق عليها الفريق، مثل LCP لا يتجاوز ⁦2.5⁩ ثانية بإعداد الهاتف. والفرق هو النتيجة التي تُبلغ عنها.

جرّبها: محلّل زمن الاستجابة جرّبها: محلّل حجم الاستجابة جرّبها: محلّل ترويسات التخزين المؤقت

مثال تطبيقي: صفحة منتج لا تجتاز Core Web Vitals

تعرض PageSpeed Insights بيانات ميدانية لصفحة منتج في متجر إلكتروني على الهاتف: LCP ‏⁦3.1⁩ ثانية، وINP ‏⁦180⁩ مللي ثانية، وCLS ‏⁦0.18⁩. ولتجد المختبِرة الأسباب، تشغّل Lighthouse خمس مرات على بيئة Staging وتسجّل تتبّعاً (trace) في لوحة الأداء:

  • قيمة LCP في المختبر (⁦4.4⁩ ثانية) أسوأ منها في الميدان (⁦3.1⁩ ثانية) بسبب الإبطاء وذاكرة التخزين المؤقت الفارغة؛ والمهم أن القيمتين تشيران إلى الاتجاه نفسه.
  • النتيجة الأولى: صورة LCP بحجم ⁦2.4⁩ ميغابايت وعليها loading="lazy"، فيطلبها المتصفح متأخراً. الأدلة: عنصر LCP ومخطط الشلال (waterfall).
  • النتيجة الثانية: يُدرج الشريط الإعلاني فوق السعر بعد العرض الأول دون حجز مساحة له، فيدفع المحتوى إلى الأسفل. الأدلة: التتبّع وتسجيل للشاشة.
  • قيمة INP جيدة في الميدان، لذا لا يكفي TBT وحده لتبرير عيب في الاستجابة؛ بل يُسجَّل خطراً يُعاد فحصه.
  • بعد الإصلاحات، يكرّر اختبار التأكيد (confirmation testing) التشغيلات المخبرية نفسها (LCP ‏⁦2.2⁩ ثانية، وCLS ‏⁦0.02⁩). أما القيم الميدانية فتتحسّن تدريجياً، لأن CrUX يغطي آخر ⁦28⁩ يوماً.
Product page /p/1042, staging, build 5.8.0
Lighthouse in DevTools, mobile, incognito, 5 runs, median

  Metric   Median   Good up to   Observation
  LCP      4.4 s    2.5 s        LCP element: hero image, 2.4 MB
  TBT      620 ms   -            lab proxy for INP, no CWV threshold
  CLS      0.21     0.1          shift when the promo banner appears

Network  hero.jpg  2.4 MB  loading="lazy"  request starts at 1.9 s
Trace    layout shift at 2.6 s: banner inserted above the price

أخطاء شائعة

  • الاختبار على حاسوب محمول سريع وشبكة المكتب السريعة فقط، ثم الحكم بأن الصفحة سريعة.
  • الإبلاغ عن تشغيل واحد لـLighthouse، أو عن الدرجة وحدها، بدلاً من وسيط عدة تشغيلات مع قيم المقاييس والظروف.
  • توقّع تطابق أرقام المختبر والميدان، أو معاملة قيم المختبر على أنها ما يعيشه المستخدمون.
  • فحص التحميل وإهمال الاستجابة: فقد تُحمَّل الصفحة بسرعة ثم تستجيب ببطء لكل لمسة.
  • استخدام مقاييس قديمة مثل FID، أو حدود منقولة من مقالات قديمة، دون الرجوع إلى web.dev.
  • الإبلاغ بأن «الصفحة بطيئة» دون ذكر الصفحة وإعداد الجهاز والإبطاء ونسخة البناء وخط الأساس، فلا يستطيع أحد إعادة إنتاج المشكلة أو التحقق من الإصلاح.

من منظور ضمان الجودة

في الفريق الحقيقي، ينتمي الأداء إلى معايير القبول للصفحات التي يراها المستخدم. اسأل أثناء تنقيح قائمة المهام (refinement): أيّ الصفحات لها ميزانية، ولأيّ فئة من الأجهزة، وهل تأتي البيانات الميدانية من CrUX أم من مراقبة الفريق الخاصة؟ والأداء متطلب غير وظيفي (non-functional requirement)، أي متطلب يحدد مدى جودة عمل الصفحة لا ما تفعله، والمتطلب القابل للاختبار منه يذكر المقياس والمئين وفئة الجهاز والحد.

قبل الإصدار، قارن الإصدار المرشّح (release candidate) بنسخة البناء السابقة في ظروف المختبر نفسها؛ وبعد الإصدار، راجع البيانات الميدانية مع المطوّرين. ويذكر تقرير عيب الأداء المقياس وقيمته، والظروف، وخط الأساس أو الحد، والعنصر أو السكربت المسؤول، والأدلة.

تمرين عملي

صنّف نتائج Core Web Vitals وأبلغ عنها

المطلوب

فيما يلي النتائج الميدانية والمخبرية لصفحة نتائج بحث. صنّف كل قيمة ميدانية، وقرّر هل تجتاز الصفحة تقييم Core Web Vitals على الهاتف وعلى سطح المكتب، واشرح لماذا تختلف قيمة LCP بين المختبر والميدان.

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

المادة
Search results page /search

Field data (CrUX), 75th percentile
            LCP      INP      CLS
  Mobile    2.4 s    380 ms   0.05
  Desktop   1.6 s    120 ms   0.02

Lighthouse in DevTools, /search?q=shoes, mobile, incognito, same staging build
  Run 1   LCP 3.0 s   TBT 900 ms   CLS 0.04   Score 61
  Run 2   LCP 2.7 s   TBT 760 ms   CLS 0.04   Score 68
  Run 3   LCP 2.9 s   TBT 820 ms   CLS 0.05   Score 64
الخطوات
  1. صنّف القيم الميدانية الست.
  2. قرّر النجاح أو الفشل لكل فئة أجهزة.
  3. خذ وسيط كل مقياس مخبري، وقارن LCP بين المختبر والميدان.
  4. اكتب الملخص والأدلة والقياس التالي.
إظهار الإجابة النموذجية
الإجابة النموذجية

الهاتف: LCP ‏⁦2.4⁩ ثانية جيد، وINP ‏⁦380⁩ مللي ثانية يحتاج إلى تحسين (أكثر من ⁦200⁩ وليس أكثر من ⁦500⁩ مللي ثانية)، وCLS ‏⁦0.05⁩ جيد، فلا تجتاز الصفحة التقييم على الهاتف. سطح المكتب: المؤشرات الثلاثة جيدة، فتجتازه.

الوسيط المخبري: LCP ‏⁦2.9⁩ ثانية، وTBT ‏⁦820⁩ مللي ثانية، وCLS ‏⁦0.04⁩. وقيمة LCP المخبرية أعلى لأن إعداد الهاتف يبطئ المعالج والشبكة ويبدأ بذاكرة تخزين مؤقت فارغة، بينما لدى كثير من المستخدمين الحقيقيين هواتف أسرع أو ملفات مخزّنة مؤقتاً.

يتّسق ارتفاع TBT مع بطء INP الميداني: فالخيط الرئيسي مشغول، فتنتظر اللمسات. الملخص: «نتائج البحث، الهاتف: INP ‏⁦380⁩ مللي ثانية عند p75، والجيد ⁦200⁩ مللي ثانية أو أقل؛ وTBT المخبري ⁦820⁩ مللي ثانية». الأدلة: البيانات الميدانية في PageSpeed Insights، وتقارير Lighthouse الثلاثة مع نسخة البناء والإعدادات، وتتبّع من لوحة الأداء.

القياس التالي: سجّل في لوحة الأداء، مع إبطاء المعالج، التفاعلات الحقيقية في الصفحة، مثل فتح المرشّحات أو تغيير الترتيب، لتجد المهمة الطويلة وراء التأخير. أما درجة Lighthouse نفسها فليست العيب.

أسئلة شائعة

هل درجة الأداء في Lighthouse نتيجة لـCore Web Vitals؟

لا. الدرجة من ⁦0⁩ إلى ⁦100⁩ ملخّص موزون لمقاييس مخبرية من تشغيل واحد في ظروف محاكاة. أما تقييم Core Web Vitals فيستخدم البيانات الميدانية عند المئين الخامس والسبعين، ويتطلب أن تكون LCP وINP وCLS كلها جيدة. استخدم الدرجة لمقارنة نسخ البناء في ظروف متساوية، لا معياراً للنجاح.

لماذا تبدو الصفحة جيدة في Lighthouse لكنها لا تجتاز التقييم في البيانات الميدانية؟

لأنهما يقيسان أشياء مختلفة. يحمّل Lighthouse الصفحة مرة واحدة في المختبر دون تفاعلات حقيقية، فلا يستطيع قياس INP، وتفوته الإزاحات التي تحدث أثناء تمرير المستخدمين للصفحة. أما البيانات الميدانية فتغطي ⁦28⁩ يوماً من الزيارات الحقيقية على أجهزة كثيرة. اعتمد على البيانات الميدانية في الحكم، وعلى المختبر في التحقيق.

هل يمكنني اختبار Core Web Vitals على بيئة Staging؟

نعم، بل ينبغي أن تقيس القيم المخبرية على Staging لتكشف الانحدار قبل الإصدار. لكن لا توجد لبيئة Staging بيانات ميدانية في CrUX لأن المستخدمين الحقيقيين لا يزورونها؛ فالقيم الميدانية لا تظهر إلا بعد الإصدار، عبر CrUX أو مراقبة الفريق الخاصة.

ما الفرق بين أداء الويب واختبار الحمل؟

أداء الويب كما في هذا الدرس هو ما يعيشه متصفح مستخدم واحد: التحميل والاستجابة والثبات. أما اختبار الحمل (load testing)، الذي تتناوله وحدة اختبار الأداء، فيقيس سلوك الخادم حين يصل عدد كبير من المستخدمين في وقت واحد. وقد تكون مؤشرات Core Web Vitals جيدة لمستخدم واحد، ثم تبطؤ الصفحة تحت الحمل حين يزداد زمن استجابة الخادم.

المراجع

  • Web VitalsGoogle (web.dev)مؤشرات Core Web Vitals (LCP وINP وCLS): ما تقيسه والحدود المطلوبة لتجربة مستخدم جيدة.
  • What are browser developer tools? — MDNMDN Web Docs (Mozilla)مقدمة لأدوات المطوّرين المدمجة في المتصفحات — المفتّش ووحدة تحكم JavaScript ومصحّح الأخطاء — لفحص الصفحة أثناء اختبارها.
الأدوات

تدرّب بأدوات متقن

محلّل زمن الاستجابة

قِس زمن استجابة نقطة نهاية عبر عدة عيّنات: الحد الأدنى والأقصى والمتوسط والوسيط وp95.

الأداء

محلّل حجم الاستجابة

حلّل حجم الاستجابة: البايتات الخام مقابل المضغوطة، وحجم الترويسات، ووزن بنية JSON، وأكبر الحقول.

الأداء

للتعمّق أكثر

تقدّمك في هذا الموضوع

جزء من مسار تعلم ضمان الجودة

الموضوعات التالية