لماذا يمكن أن تختلف بيانات المختبر عن البيانات الميدانية (وماذا تفعل حيال ذلك)

تعرَّف على الأسباب التي قد تؤدي إلى ظهور أرقام مختلفة في الأدوات التي تراقب مقاييس "مؤشرات أداء الويب الأساسية"، وكيفية تفسير هذه الاختلافات.

توفر Google عددًا من الأدوات لمساعدة مالكي المواقع على مراقبة نتائج Core Web Vitals تندرج هذه الأدوات في فئتين رئيسيتين وهما:

  • الأدوات التي تُبلغ عن بيانات المختبر، وهي البيانات التي يتم جمعها في بيئة خاضعة للرقابة باستخدام إعدادات الجهاز والشبكة المحددة مسبقًا.
  • الأدوات التي تُبلِغ عن البيانات الفعلية: البيانات التي يتم جمعها من المستخدمِين الفعليين الذين يزورون موقعك الإلكتروني موقعك الإلكتروني.

تكمن المشكلة في أنه في بعض الأحيان تكون البيانات التي يتم الإبلاغ عنها بواسطة الأدوات المعملية مختلفة مختلفة عن البيانات الواردة بواسطة الأدوات الميدانية! قد تشير بيانات المعمل أنّ موقعك الإلكتروني يقدم أداءً رائعًا، لكن البيانات الفعلية تشير إلى أنه يحتاج إلى التحسين. بدلاً من ذلك، قد تشير بيانات الحقول إلى أنّ جميع صفحاتك جيدة، ولكن فقد تشير بيانات المعمل إلى نتيجة منخفضة للغاية.

يعرض المثال الحقيقي التالي لتقرير "إحصاءات PageSpeed" من web.dev. أنه في بعض الحالات يمكن أن تختلف البيانات المعملية والميدانية عبر جميع مقاييس "مؤشرات أداء الويب":

لقطة شاشة لتقرير "إحصاءات PageSpeed" مع تعارُض بين بيانات التمرين المعملي والبيانات الميدانية

تعد الاختلافات بين الأدوات مصدرًا مفهومًا للالتباس المطورين. وتوضح هذه المشاركة الأسباب الرئيسية التي قد تجعل هذه الاختلافات مع أمثلة محددة تتناول كل مقياس من مقاييس "مؤشرات أداء الويب الأساسية" الإجراءات التي يمكنك اتخاذها عند العثور على اختلافات في صفحاتك.

البيانات المعملية مقابل البيانات الميدانية

لفهم سبب أن أدوات المختبر والأدوات الميدانية قد تعرض قيمًا مختلفة - حتى نفس صفحة الويب بالضبط — فأنت بحاجة إلى فهم الفرق بين التمرين المعملي والحقل البيانات.

بيانات التمرين المعملي

يتم تحديد البيانات المختبرية من خلال تحميل صفحة ويب في بيئة خاضعة للرقابة مجموعة محدَّدة مسبقًا من حالات الشبكة والجهاز. وتُعرف هذه الحالات باسم lab ويُشار إليها أحيانًا باسم البيئة الاصطناعية.

يتم بشكل عام تشغيل أدوات Chrome التي تُبلِغ عن البيانات الاختبارية. Lighthouse:

والغرض من الاختبار المعملي هو التحكم في أكبر عدد ممكن من العوامل، وبالتالي أن تكون النتائج متسقة (بقدر الإمكان) متسقة وقابلة للتكرار من التشغيل إلى التشغيل.

بيانات الحقول

يتم تحديد بيانات الحقول من خلال مراقبة جميع المستخدمين الذين يزورون الصفحة وقياس مجموعة معيّنة من مقاييس الأداء لكل واحد من هؤلاء المستخدمين فرد وخبراتهم. نظرًا لأن بيانات الحقل تستند إلى زيارات المستخدم الحقيقي، فإنها تعكس الأجهزة الفعلية وظروف الشبكة والمواقع الجغرافية للمستخدمين.

تُعرف بيانات الحقول أيضًا باسم مراقبة المستخدمين الحقيقيين بيانات (RUM)؛ المصطلحين وقابلة للتبديل.

بشكل عام، تحصل أدوات Chrome التي تُبلغ عن البيانات الفعلية على تلك البيانات من متصفّح Chrome تقرير تجربة المستخدم (CrUX): من الشائع أيضًا (ويُنصح به) لمالكي المواقع الإلكترونية جمع بيانات الحقول نفسها لأنها يمكن أن توفر إحصاءات أكثر قابلية للاستخدام من مجرد استخدام CrUX فقط

أهم شيء يجب فهمه بشأن بيانات المجال هو أنها ليست مجرد رقم واحد، إنه توزيع الأرقام. أي، بالنسبة لبعض الأشخاص الذين يزورون فقد يتم تحميله بسرعة كبيرة جدًا، بينما يتم تحميل صفحات أخرى ببطء شديد. بيانات الحقل لموقعك الإلكتروني هي مجموعة كاملة من بيانات الأداء التي يتم جمعها من المستخدمين.

على سبيل المثال، تُظهر تقارير CrUX توزيعًا لمقاييس الأداء من البيانات الفعلية مستخدمو Chrome خلال فترة 28 يومًا. إذا نظرت إلى أي تقرير CrUX تقريبًا، يمكنك أن يكون لدى بعض المستخدمين الذين يزورون أحد المواقع تجربة جيدة جدًا في حين أن فقد يكون لدى الآخرين تجربة سيئة للغاية.

إذا قامت الأداة بالإبلاغ عن رقم واحد لمقياس معين، فستقوم بشكل عام تمثل نقطةً معينة في التوزيع. الأدوات التي تُبلغ عن Core Web تشير نتائج الحقول الحيوية إلى باستخدام الرقم 75 النسبة المئوية.

بعد الاطّلاع على مقياس LCP من بيانات الحقل في لقطة الشاشة أعلاه، يمكنك ملاحظة مكان التوزيع:

  • شهدت نسبة 88% من الزيارات تحسُّنًا في سرعة عرض أكبر جزء من المحتوى على الصفحة (LCP) يبلغ 2.5 ثانية أو أقل (جيد).
  • شهدت 8% من الزيارات سرعة عرض أكبر جزء من المحتوى على الصفحة (LCP) بين 2.5 و4 ثوانٍ (بحاجة إلى تحسين).
  • شهدت 4% من الزيارات زيادة في سرعة عرض أكبر جزء من المحتوى على الصفحة (LCP) عن 4 ثوانٍ (ضعيفة).

وفي الشريحة المئوية الخامسة والسبعين، كانت سرعة LCP 1.8 ثانية:

توزيع درجات سرعة عرض أكبر محتوى مرئي (LCP) في الميدان

تُظهر البيانات الاختبارية من الصفحة نفسها قيمة LCP تبلغ 3.0 ثانية. في حين أن هذه القيمة أكبر من 1.8 ثانية الموضحة في بيانات الحقل، فلا تزال قيمة LCP صالحة الخاصة بهذه الصفحة — وهي واحدة من القيم العديدة التي تُشكل التوزيع الكامل تجارب التحميل

نتيجة LCP في التمرين المعملي

أسباب اختلاف البيانات المعملية عن البيانات الميدانية

وكما يوضح القسم أعلاه، تقيس البيانات المعملية والبيانات الميدانية مدى أشياء مختلفة.

تتضمن البيانات الميدانية مجموعة متنوعة من حالات الشبكة والأجهزة، فضلًا عن عدد لا يحصى من الأنواع المختلفة من سلوك المستخدم. كما تتضمن أي عوامل أخرى التي تؤثر في تجربة المستخدم، مثل تحسينات المتصفح مثل التخزين المؤقت للصفحات (bfcache)، أو تحسينات النظام الأساسي مثل ذاكرة التخزين المؤقت لصفحات AMP

وعلى النقيض من ذلك، تحدد البيانات المعملية عمدًا عدد المتغيرات المتضمنة. حاسمة الاختبار المعملي مما يلي:

  • جهاز واحد...
  • متصل بشبكة واحدة...
  • التشغيل من موقع جغرافي واحد.

إن تفاصيل أي اختبار معملي معين قد تمثل أو لا تمثل بدقة 75 بالمئة من بيانات الحقل لصفحة أو موقع إلكتروني معيّن.

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

بالإضافة إلى الانفصال المحتمل بين شروط المعمل والظروف من معظم المستخدمين في العالم الحقيقي، هناك أيضًا عدد من الاختلافات الطفيفة من المهم فهمها للاستفادة إلى أقصى حد من مختبرك وبيانات المجال، بالإضافة إلى أي اختلافات قد تجدها.

تتناول الأقسام القليلة التالية بالتفصيل الأسباب الأكثر شيوعًا وراء قد يكون هناك اختلافات بين البيانات المختبرية والبيانات الميدانية لكل موقع من مبادئ مقاييس المؤشرات الحيوية:

سرعة عرض أكبر جزء من المحتوى على الصفحة (LCP)

عناصر LCP المختلفة

إنّ عنصر LCP المحدّد في الاختبار المعملي قد لا يكون هو نفسه مقياس LCP نفسه. التي يراها المستخدمون عند زيارة صفحتك.

إذا شغّلت تقرير Lighthouse لصفحة معيّنة، سيعرض النتيجة نفسها عنصر LCP في كل مرة ولكن إذا نظرت إلى بيانات الحقل لنفس الصفحة، ستجد عادةً مجموعة متنوعة من عناصر LCP المختلفة التي تعتمد على عدد الحالات الخاصة بكل زيارة للصفحة.

على سبيل المثال، قد تساهم العوامل التالية في انخفاض سرعة عرض أكبر محتوى مرئي (LCP) مختلف. العنصر الذي يتم تحديده للصفحة نفسها:

  • تؤدي أحجام شاشات الجهاز المختلفة إلى ظهور عناصر مختلفة داخل إطار العرض.
  • فإذا قام المستخدم بتسجيل الدخول، أو إذا تم عرض محتوى مخصص في بعض قد يختلف عنصر LCP اختلافًا كبيرًا من مستخدم إلى آخر.
  • وعلى غرار النقطة السابقة، إذا تم إجراء اختبار A/B على الصفحة، فيمكن تؤدي إلى عرض عناصر مختلفة جدًا.
  • يمكن أن تؤثر مجموعة الخطوط المثبتة في نظام المستخدم على حجم النص الصفحة (وبالتالي أي عنصر هو عنصر LCP).
  • عادة ما يتم إجراء الاختبارات المعملية على "قاعدة" الصفحة عنوان URL - بدون أي معلَمات طلب بحث أو أجزاء علامة التجزئة المُضافة. لكن في العالم الحقيقي، غالبًا ما يشارك المستخدمون عناوين URL الذي يحتوي على معرّف جزء أو جزءًا من النص، وبالتالي قد لا يعمل عنصر LCP تكون في الواقع من منتصف الصفحة أو أسفلها (بدلاً من "أعلى طيّ").

بما أنّ مقياس LCP في الحقل يتم احتسابه على أنّه الشريحة المئوية الخامسة والسبعين من جميع زيارات المستخدمين. إلى إحدى الصفحات، إذا كان لدى نسبة كبيرة من هؤلاء المستخدمين عنصر LCP الذي تم تحميله بسرعة كبيرة — على سبيل المثال عرض فقرة من نص بخط نظام حتى إذا كان لدى بعض هؤلاء المستخدمين صورة كبيرة بطيئة التحميل تساوي مقياس LCP فقد لا يؤثر في نتيجة الصفحة إذا حدث ذلك بنسبة أقل من 25% الزوار.

بدلا من ذلك، قد يكون العكس صحيحًا. قد يحدد الاختبار المعملي كتلة النص كعنصر LCP لأنه يحاكي هاتف Moto G4 الذي يحتوي على إطار عرض صغير نسبيًا ويتم عرض الصورة الرئيسية لصفحتك في البداية خارج الشاشة. ومع ذلك، قد تتضمن بيانات الحقل في الغالب مستخدمي Pixel XL الذين لديهم الشاشات الأكبر حجمًا، لذا فإنّ صورة الجزء الرئيسي البطيئة التحميل هي عنصر LCP.

تأثيرات حالة ذاكرة التخزين المؤقت على سرعة عرض أكبر جزء من المحتوى على الصفحة (LCP)

عادةً ما تقوم الاختبارات المعملية بتحميل صفحة بواسطة ذاكرة تخزين مؤقت باردة، ولكن عندما يزور المستخدمون فمن المحتمل أن يكون قد تم تخزين بعض موارده مؤقتًا من قبل.

في المرة الأولى التي يحمّل فيها المستخدم إحدى الصفحات، قد يتم تحميلها ببطء، ولكن إذا كانت الصفحة تحتوي على ضبط التخزين المؤقت بشكل صحيح، في المرة التالية التي يعرض فيها المستخدم الصفحة على الفور.

وفي حين أن بعض الأدوات المعملية تدعم عمليات التشغيل المتعددة لنفس الصفحة (لمحاكاة الزوار العائدين)، فليس من الممكن لأداة المختبر معرفة النسبة المئوية للزيارات الفعلية من المستخدمين الجدد في مقابل المستخدمين المكرري الزيارة.

يمكن للمواقع الإلكترونية التي تحتوي على إعدادات لذاكرة التخزين المؤقت المحسَّنة بشكل جيد أن تجذب عددًا كبيرًا من الزوّار المتكرّرين أن سرعة عرض أكبر جزء من المحتوى على الصفحة في العالم الفعلي أسرع بكثير مما تشير إليه البيانات المختبرية.

تحسينات AMP أو Signed Exchange

المواقع التي تم إنشاؤها باستخدام AMP أو التي تستخدم Signed Exchange (SXG) يمكن تحميلها مسبقًا من خلال مجمّعي المحتوى مثل Google. شبكة البحث. قد يؤدي ذلك إلى تحسين أداء التحميل بشكل ملحوظ لدى المستخدمين. يزورون صفحاتك من تلك المنصات

بالإضافة إلى التحميل المُسبق من مصادر متعددة، يمكن للمواقع الإلكترونية نفسها التحميل المسبق للمحتوى للصفحات التالية في الموقع الإلكتروني ما قد يؤدي إلى تحسين سرعة عرض أكبر جزء من المحتوى على الصفحة (LCP) أيضًا لتلك الصفحات.

ولا تحاكي الأدوات المعملية المكاسب التي يتم تحقيقها من هذه التحسينات، وحتى إذا إلا أنهم لم يتمكّنوا من معرفة النسبة المئوية للزيارات الواردة من موقعك الإلكتروني المنصات مثل "بحث Google" مقارنةً بمصادر أخرى.

تأثيرات ميزة "التخزين المؤقت للصفحات" على سرعة عرض أكبر جزء من المحتوى على الصفحة (LCP)

عند استعادة الصفحات من ذاكرة التخزين المؤقت، تكاد تجربة التحميل تقترب لحظية، وأن يتم تضمين هذه الخبرات في مجال عملك .

ولا تأخذ الاختبارات المعملية في الاعتبار استخدام bfcache، لذا إذا كانت صفحاتك متوافقة مع bfcache، فمن المحتمل أن إلى نتائج سرعة LCP المُسجَّلة في هذا المجال.

تأثيرات تفاعل المستخدم على سرعة عرض أكبر جزء من المحتوى على الصفحة (LCP)

يحدد مقياس LCP وقت عرض أكبر صورة أو مقطع نصي في إطار العرض، ولكن هذا العنصر الأكبر يمكن أن يتغير أثناء تحميل الصفحة أو إذا كانت تتم إضافة المحتوى ديناميكيًا إلى إطار العرض.

في هذا التمرين المعملي، سينتظر المتصفح حتى يتم تحميل الصفحة بالكامل قبل لتحديد عنصر LCP. ولكن في الحقل، سيتوقف المتصفح المراقبة للعناصر الأكبر حجمًا بعد أن يقوم المستخدم بالتمرير أو التفاعل مع الصفحة.

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

إلا أنّ ذلك يتمثّل في أنّ بيانات الحقل الخاصة بإحدى الصفحات قد يتم الإبلاغ عنها بشكل أسرع. يتم تحديد أوقات سرعة عرض أكبر محتوى مرئي (LCP)، استنادًا إلى سلوك المستخدمين على تلك الصفحة.

مدى استجابة الصفحة لتفاعلات المستخدم (INP)

يتطلب مدى استجابة الصفحة لتفاعلات المستخدم (INP) تفاعلاً من المستخدم الفعلي.

يقيس مقياس INP مدى استجابة الصفحة لتفاعلات المستخدم، في الوقت الذي اختار فيه المستخدمون التفاعل معه

الجزء الثاني من تلك الجملة مهم لأن الفحوصات المخبرية، حتى تلك التي دعم سلوك المستخدم للنص البرمجي، ولا يمكنه التنبؤ بدقة بالوقت الذي سيختار فيه المستخدمون للتفاعل مع الصفحة، وبالتالي لا يمكنه قياس مقياس FID بدقة.

لا تراعي "TBT" سلوك المستخدم

يهدف المقياس المعملي إجمالي وقت الحظر (TBT) إلى المساعدة في تشخيص المشاكل المتعلّقة بمقياس INP لأنّه يحدّد مقدار حظر سلسلة التعليمات الرئيسية أثناء تحميل الصفحة.

والفكرة هي أن الصفحات التي تحتوي على الكثير من لغة JavaScript المتزامنة أو من المرجح أن تتضمن مهام العرض سلسلة محادثات رئيسية محظورة عندما يستخدم يتفاعل أولاً. ومع ذلك، إذا انتظر المستخدمون التفاعل مع الصفحة حتى انتهاء تنفيذ JavaScript، وبالتالي قد يكون مقياس INP منخفضًا جدًا.

يعتمد الوقت الذي سيختار فيه المستخدمون التفاعل مع صفحة إلى حد كبير على ما إذا كان تبدو تفاعلية، ولا يمكن قياسها باستخدام TBT.

لا يأخذ TBT في الاعتبار تأخير النقر

إذا لم يكن الموقع محسَّنًا للعرض على الأجهزة الجوّالة، ستضيف المتصفحات 300 ملي ثانية تأخير بعد أي نقرة قبل تشغيل معالِجات الأحداث. إنهم يفعلون ذلك لأنهم بحاجة إلى تحديد ما إذا كان المستخدم يحاول النقر نقرًا مزدوجًا للتكبير/التصغير قبل أن يتمكن من تنشيط أحداث الماوس أو النقر.

ويتم احتساب هذا التأخير ضمن مقياس "مدى استجابة الصفحة لتفاعلات المستخدم" (INP) للصفحة لأنّه يساهم في الوصول إلى البيانات الفعلية ووقت الاستجابة الذي يواجهه المستخدمون. ولكن بما أن هذا التأخير ليس من الناحية الفنية مدة طويلة المهمة، لا تؤثِّر في الوقت الذي يتم تحديده للصفحة. يعني ذلك أنّ مقياس "مدى استجابة الصفحة لتفاعلات المستخدم" (INP) منخفض على الصفحة على الرغم من حصوله على نتائج جيدة جدًا في "TBT".

تأثيرات حالة ذاكرة التخزين المؤقت وbfcache على INP

وبالطريقة نفسها التي يمكن أن يحسّن بها التخزين المؤقت المناسب سرعة عرض أكبر جزء من المحتوى على الصفحة، يمكن أيضًا لتحسين INP

في الواقع، قد يكون لدى المستخدم JavaScript لموقع إلكتروني ذاكرة التخزين المؤقت، لذا قد تستغرق معالجتها أقل الوقت وتؤدي إلى تأخيرات أصغر.

وينطبق ذلك أيضًا على الصفحات التي تمت استعادتها من ذاكرة التخزين المؤقت. في تلك الحالات تتم استعادة لغة JavaScript من الذاكرة، لذلك قد تكون المعالجة قليلة أو لا تكون على الإطلاق. على الإطلاق.

متغيّرات التصميم التراكمية (CLS)

تأثيرات تفاعل المستخدم على متغيّرات التصميم التراكمية (CLS)

لا تأخذ متغيّرات التصميم التراكمية التي يتم قياسها في التمرين المعملي إلا متغيرات التصميم التي تحدث أعلاه الجزء المرئي من الصفحة وأثناء التحميل، ولكن هذه ليست سوى مجموعة فرعية لما يحدثه متغيّرات التصميم التراكمية (CLS) التدابير.

في الحقل، تراعي CLS جميع التنسيقات غير المتوقعة والتغييرات التي تحدث في جميع مراحل عمر الصفحة، بما في ذلك المحتوى الذي يتغير أثناء تمرير المستخدم أو الاستجابة لطلبات الشبكة البطيئة بعد تفاعل المستخدم.

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

محتوى مخصص

يؤثر المحتوى المخصّص، بما في ذلك الإعلانات المستهدَفة واختبارات أ/ب، في العناصر. يتم تحميلها على إحدى الصفحات. كما أنه يؤثر في كيفية تحميلها نظرًا لتخصيص المحتوى غالبا ما يتم تحميله لاحقًا ويتم إدراجه في المحتوى الرئيسي للصفحة، مما يؤدي إلى متغيّرات التصميم.

في المختبر، عادةً ما يتم تحميل الصفحة إما بدون محتوى مخصص بمحتوى "مستخدم تجريبي" عام، ما قد يؤدي أو لا يؤدي إلى بدء التحولات التي يراها المستخدمون الحقيقيون.

نظرًا لأن البيانات الميدانية تتضمن تجارب جميع المستخدمين، فإن مقدار (ودرجة) من متغيّرات التصميم التي تتم ممارستها في أي صفحة تعتمد بشكل كبير على نوع المحتوى تحميل المشروع.

تأثيرات حالة ذاكرة التخزين المؤقت وbfcache على CLS

اثنان من أكثر الأسباب شيوعًا لمتغيرات التصميم أثناء التحميل هما الصور إطارات iframe بدون سمات (كما هو مذكور أعلاه) وبطء تحميل الويب والخطوط، ومن المرجح أن التأثير في التجربة في المرة الأولى التي يزور فيها المستخدم موقعًا إلكترونيًا، عندما تكون ذاكرة التخزين المؤقت فارغ.

إذا تم تخزين موارد الصفحة في ذاكرة التخزين المؤقت أو إذا تمت استعادة الصفحة نفسها من bfcache، يمكن للمتصفح عادةً عرض الصور والخطوط على الفور، بدون في انتظار تنزيلها. يمكن أن يؤدي ذلك إلى انخفاض قيم متغيّرات التصميم التراكمية (CLS) في الحقل. أكثر مما قد تبلغه أداة المختبر.

ما يجب فعله عند اختلاف النتائج

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

على الجانب الآخر، إذا كانت البيانات الميدانية لديك تظهر درجات جيدة عبر اللوحة، ولكن تشير بيانات المختبر إلى أنه لا يزال هناك مجال للتحسين، فإن الأمر يستحق وفهم التحسينات الإضافية التي يمكن إجراؤها.

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

بشكل عام، تعد كل من البيانات المعملية والبيانات الميدانية جزءًا مهمًا من قياس الأداء. لكل منهما نقاط قوته وقيوده، وإذا فأنت تستخدم واحدة فقط، فقد تفقد فرصة لتحسين تجربة المستخدم.

محتوى إضافي للقراءة