نحو تحسين مقياس مدى استجابة الصفحات لتفاعلات المستخدمين

تعرَّف على أفكارنا حول قياس مدى الاستجابة وأرسِل إلينا ملاحظاتك.

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

سنتناول في هذه المشاركة موضوعَين أساسيَين:

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

ما هو "مهلة الاستجابة الأولى"؟

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

• click
• keydown
• mousedown
• pointerdown (فقط إذا كانت متبوعة بـ pointerup)

يوضّح المخطّط التالي مقياس FID:

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

لماذا اخترنا FID؟

نعتقد أنّه من المهم قياس تجربة المستخدم الفعلية للتأكّد من أنّ التحسينات التي يتم إجراؤها على المقياس تؤدي إلى فوائد حقيقية للمستخدم. اخترنا قياس FID لأنّه يمثّل جزءًا من تجربة المستخدم عندما يقرّر المستخدم التفاعل مع موقع إلكتروني تم تحميله للتو. ويلتقط FID بعض الوقت الذي يتعين على المستخدم انتظاره لرؤية رد من تفاعله مع الموقع الإلكتروني. بمعنى آخر، إنّ مقياس FID (مهلة الاستجابة الأولى) كحد أدنى على مقدار الوقت الذي ينتظره المستخدم بعد التفاعل.

وتستند مقاييس أخرى مثل إجمالي وقت الحظر (TBT) ووقت التفاعل (TTI) إلى المهام الطويلة، وتقيس أيضًا مدة حظر سلسلة التعليمات الرئيسية أثناء التحميل، مثل مقياس FID. ونظرًا لأنه يمكن قياس هذه المقاييس في المجال والمختبر، سأل العديد من المطورين عن سبب عدم تفضيلنا لأحد هذه المقاييس على FID.

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

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

ما هي التحسينات التي نأخذها في الاعتبار؟

نريد تطوير مقياس جديد يكمّل ما يقيسه مقياس FID اليوم، ومع ذلك لا يزال يحافظ على علاقته القوية بتجربة المستخدم.

نريد أن يستوفي المقياس الجديد ما يلي:

1. مراعاة مدى استجابة جميع إدخالات المستخدم (وليس الأولى فقط)
2. سجِّل المدة الكاملة لكل حدث (وليس التأخير فقط).
3. اجمع الأحداث معًا التي تحدث كجزء من تفاعل المستخدِم المنطقي نفسه وحدِّد وقت استجابة هذا التفاعل كأقصى مدة لجميع أحداثه.
4. إنشاء نتيجة مجمّعة لجميع التفاعلات التي تحدث على الصفحة خلال دورة حياتها الكاملة.

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

تسجيل مدة الحدث بالكامل

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

وهناك مراحل مختلفة في دورة حياة الحدث، كما هو موضّح في هذا الرسم التخطيطي:

في ما يلي الخطوات التي يتخذها Chrome لمعالجة أحد الإدخالات:

1. يحدث الإدخال من المستخدم. وقت حدوث ذلك هو timeStamp الخاص بالحدث.
2. يُجري المتصفح اختبار النتائج لتحديد إطار HTML (الإطار الرئيسي أو إطار iframe) الذي ينتمي إليه الحدث. ثم يرسل المتصفّح الحدث إلى عملية العارض المناسبة المسؤولة عن إطار HTML هذا.
3. يتلقى العارض الحدث ويضعه في قائمة الانتظار لتتمكن من معالجته عندما يصبح متاحًا لإجراء ذلك.
4. يعالج العارض الحدث من خلال تشغيل معالِجاته. وقد تضع هذه المعالِجات ضمن قائمة انتظار الأعمال الإضافية غير المتزامنة، مثل setTimeout وعمليات الاسترجاع التي تشكِّل جزءًا من معالجة الإدخال. ولكن في هذه المرحلة، يكون العمل المتزامن قد اكتمل.
5. يتم رسم إطار على الشاشة يعكس نتيجة تشغيل معالِجات الأحداث. تجدر الإشارة إلى أنّ أي مهام غير متزامنة تضعها معالِجات الأحداث قد تكون غير مكتملة.

يشير الوقت بين الخطوتين (1) و (3) أعلاه إلى تأخّر الحدث، وهو ما يقيسه مقياس FID.

الوقت بين الخطوتين (1) و (5) أعلاه هو مدة الحدث. هذا ما سيقيسه مقياسنا الجديد.

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

تجميع الأحداث في تفاعلات

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

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

أنواع التفاعل

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

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

لوحة المفاتيح

ويتكوّن تفاعل لوحة المفاتيح من جزأين: عندما يضغط المستخدم على المفتاح وعندما يحرره. هناك ثلاثة أحداث مرتبطة بتفاعل المستخدم هذا: keydown وkeyup وkeypress. يوضِّح الرسم البياني التالي حالات التأخير والمدد الخاصة بتفاعلَي keydown وkeyup لتفاعل لوحة المفاتيح:

في الرسم البياني أعلاه، تكون المدد منفصلة لأنّ الإطار من تحديثات keydown يتم تقديمه قبل حدوث keyup، ولكن ليس بالضرورة أن يكون هذا هو الحال دائمًا. يُرجى أيضًا ملاحظة أنّه يمكن عرض الإطار في منتصف المهمة في عملية العارض لأنّ الخطوات الأخيرة المطلوبة لإنتاج الإطار تتم خارج عملية العارض.

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

للحصول على الوقت الإجمالي الذي يستغرقه تفاعل لوحة المفاتيح، يمكننا احتساب الحدّ الأقصى لمدة حدثَي "keydown" و"keyup".

النقر

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

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

نريد تضمين مُدد الأحداث لكل هذه الفعاليات، ولكن بما أنّ العديد منها متداخل تمامًا، نحتاج إلى قياس مُدد pointerdown وpointerup وclick فقط لتغطية التفاعل الكامل.

السحب

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

ولا نفكّر أيضًا في تنفيذ عمليات السحب عبر واجهة برمجة تطبيقات السحب والإفلات لأنها تعمل على سطح المكتب فقط.

الانتقال

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

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

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

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

كيف يمكن تحديد وقت الاستجابة للتفاعل؟

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

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

قد تتداخل المدد keydown وkeyup أيضًا. قد يحدث هذا على سبيل المثال عندما يكون الإطار المقدم لكلا الحدثين هو ذاته، كما في الرسم التخطيطي التالي:

هناك إيجابيات وسلبيات لهذا المنهج المتبع في استخدام الحد الأقصى، ونحن مهتمون بالاطّلاع على ملاحظاتك:

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

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

تجميع كل التفاعلات في كل صفحة

بعد تحديد وقت استجابة التفاعل، سنحتاج إلى احتساب قيمة مجمّعة لتحميل صفحة، والذي قد ينطوي على العديد من تفاعلات المستخدم. ويتيح لنا الحصول على قيمة مجمّعة إجراء ما يلي:

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

ولإجراء هذا التجميع، نحتاج إلى حل سؤالين:

1. ما الأرقام التي نحاول تجميعها؟
2. كيف نجمع هذه الأرقام؟

نعمل حاليًا على استكشاف عدة خيارات وتقييمها. ونحن نرحب بآرائكِ بشأن هذه المجموعة.

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

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

كيف يبدو ذلك في واجهات برمجة تطبيقات أداء الويب؟

ما الذي ينقصك في "توقيت الحدث"؟

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

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

ما الذي يمكنك تجربته الآن؟

في الوقت الحالي، لا يزال من الممكن حساب الحدّ الأقصى لوقت الاستجابة للنقر/السحب وتفاعلات لوحة المفاتيح. وسينتج عن مقتطف الرمز التالي هذين المقياسَين.

let maxTapOrDragDuration = 0;
let maxKeyboardDuration = 0;
const observer = new PerformanceObserver(list => {
  list.getEntries().forEach(entry => {
    switch(entry.name) {
      case "keydown":
      case "keyup":
        maxKeyboardDuration = Math.max(maxKeyboardDuration,
            entry.duration);
        break;
      case "pointerdown":
      case "pointerup":
      case "click":
        maxTapOrDragDuration = Math.max(maxTapOrDragDuration,
            entry.duration);
        break;
    }
  });
});
observer.observe({type: "event", durationThreshold: 16, buffered: true});
// We can report maxTapDragDuration and maxKeyboardDuration when sending
// metrics to analytics.

إضافة ملاحظات

يُرجى إعلامنا برأيك في هذه الأفكار من خلال إرسال رسالة إلكترونية إلى: web-vitals-feedback@googlegroups.com.