إجابات عن الأسئلة الشائعة حول التطبيقات ذات الصفحة الواحدة (SPA) ومؤشرات أداء الويب الأساسية وكيفية تعامل "مؤشرات أداء الويب الأساسية" مع هذه التطبيقات
تم النشر في: 14 سبتمبر 2021، آخر تعديل: 11 أغسطس 2026
منذ أن طرحنا مبادرة Web Vitals لأول مرة في مايو 2020، تلقّينا الكثير من الأسئلة والملاحظات الرائعة حول البرنامج من فريق Chrome.
ربما يكون الموضوع الذي تلقّينا عنه أكبر عدد من الأسئلة، وهو أيضًا على الأرجح السؤال الأصعب للإجابة عنه، هو كيفية قياس Core Web Vitals في تطبيق من صفحة واحدة (SPA)، بالإضافة إلى كيفية تأثير بُنى تطبيقات من صفحة واحدة على نتائج Core Web Vitals.
من الصعب الإجابة عن هذه الأسئلة لأنّ المشكلة دقيقة جدًا، لذا سنبذل قصارى جهدنا في هذا المنشور للإجابة عن الأسئلة الأكثر شيوعًا، مع تقديم أكبر قدر ممكن من التفاصيل والسياق.
قبل الخوض في التفاصيل، من المهم الإشارة إلى أنّ Google لا تفضّل أي بنية أو تكنولوجيا معيّنة لإنشاء موقع إلكتروني. نحن نؤمن بأنّ التطبيقات ذات الصفحة الواحدة والتطبيقات المتعدّدة الصفحات قادرة على تقديم تجارب عالية الجودة للمستخدمين، وهدفنا من مبادرة "مؤشرات أداء الويب" هو توفير مقاييس تقيس التجربة بغض النظر عن التكنولوجيا المستخدمة.
الأسئلة الشائعة
في ما يلي بعض الأسئلة الأكثر شيوعًا التي نتلقّاها حول هذا الموضوع. يسرّنا تلقّي ملاحظاتك لإضافتها إلى هذه الأسئلة الشائعة في مجموعة الملاحظات أو من خلال طرح مشكلة.
هل تتضمّن مقاييس Core Web Vitals عمليات الانتقال بين مسارات التطبيقات ذات الصفحة الواحدة؟
عند طرح كل مقياس من مقاييس Core Web Vitals لأول مرة، كان يتم قياسه بالنسبة إلى عملية التنقّل الحالية في الصفحة ذات المستوى الأعلى. إذا حمّلت صفحة محتوًى جديدًا بشكل ديناميكي وعدّلت عنوان URL للصفحة في شريط العناوين، لن يؤثر ذلك في كيفية قياس مقاييس "مؤشرات أداء الويب الأساسية".
لم تتم إعادة ضبط قيم المقاييس، وعنوان URL المرتبط بكل قياس هو عنوان URL الذي انتقل إليه المستخدم والذي بدأ تحميل الصفحة.
أطلق Chrome 151 واجهات برمجة تطبيقات جديدة تتيح قياس Core Web Vitals خلال عمليات الانتقال بين مسارات التطبيقات ذات الصفحة الواحدة. في وقت كتابة هذا المنشور (أغسطس 2026)، بدأت هذه الواجهات في الاستخدام في مكتبات القياس، مثل web-vitals، وحلول مراقبة المستخدمين الفعليين، وأدوات مثل "أدوات مطوّري البرامج في Chrome". لم ينشر Chrome بعدُ الأطر الزمنية لدمج هذه الواجهات في تقرير تجربة المستخدم على Chrome (CrUX). بالإضافة إلى ذلك، لا تتيح محركات المتصفحات الأخرى بعدُ استخدام واجهات برمجة التطبيقات الجديدة هذه، لذا لا يمكن قياس Core Web Vitals في هذه المتصفحات إلا خلال عمليات تحميل الصفحة الكاملة.
لماذا كان حلّ هذه المشكلة صعبًا؟
لا توجد طريقة موحّدة لإنشاء تطبيق ذي صفحة واحدة اليوم، وحتى بين مكتبات التطبيقات ذات الصفحة الواحدة والتوجيه الشائعة، يمكن أن تختلف تجربة المستخدم اختلافًا كبيرًا من تطبيق إلى آخر:
- لا تعدّل بعض التطبيقات ذات الصفحة الواحدة عنوان URL إلا عند تحميل محتوى جديد "بملء الصفحة"، بينما تعدّل مواقع أخرى عنوان URL لتغييرات صغيرة في المحتوى أو حتى لتغييرات في حالة واجهة المستخدم فقط.
- تعدّل بعض التطبيقات ذات الصفحة الواحدة عنوان URL باستخدام History API، بينما تستخدم تطبيقات أخرى تغييرات التجزئة لدعم المتصفحات القديمة (ولا تعدّل تطبيقات أخرى عنوان URL على الإطلاق).
- تحمّل بعض التطبيقات ذات الصفحة الواحدة المحتوى ثم تعدّل عنوان URL، بينما تعدّل تطبيقات أخرى عنوان URL قبل تحميل المحتوى.
- تحمّل بعض التطبيقات ذات الصفحة الواحدة المحتوى مرة واحدة بشكل متزامن في مهمة JavaScript واحدة، بينما تنقل تطبيقات أخرى المحتوى بشكل غير متزامن خلال مهام متعددة (بدون حدث واضح لنهاية عملية الانتقال).
- تحمّل بعض التطبيقات ذات الصفحة الواحدة المحتوى دائمًا من الشبكة، بينما تحمّل تطبيقات أخرى كل المحتوى مسبقًا حتى يتم تحميل تغييرات المسار على الفور من الذاكرة.
تؤدي هذه الاختلافات إلى صعوبة تحديد وتعريف ما يشكّل تغييرًا في مسار التطبيق ذي الصفحة الواحدة، أو حتى التطبيق ذي الصفحة الواحدة نفسه، على نطاق واسع.
في بعض الحالات، يكون تغيير مسار التطبيق ذي الصفحة الواحدة مطابقًا منطقيًا لتحميل صفحة تطبيق متعدّد الصفحات، وفي هذه الحالات، سيكون من الرائع تطبيق مقاييس Core Web Vitals الحالية.
ومع ذلك، بدون إحصاءات قوية لتحديد عمليات تغيير المسار "الحقيقية" بشكل موثوق من جميع تغييرات عناوين URL الأخرى، بالإضافة إلى إشارات واضحة تحدّد بداية ونهاية عمليات الانتقال هذه، سيؤدي الإبلاغ عن مقاييس Core Web Vitals في هذه الحالات إلى تشويه البيانات وجعلها أقل فائدة أو تمثيلاً لتجربة المستخدم الحقيقية على الموقع الإلكتروني.
قدّم العمل على عمليات التنقّل السلسة حلاً لهذه المشكلة من خلال واجهتَي برمجة تطبيقات جديدتَين للأداء:
PerformanceSoftNavigationالتي تقيس متى يؤدي تفاعل المستخدم إلى عملية عرض وتغيير عنوان URL. يوفّر الجمع بين هذه العناصر الثلاثة تعريفًا موحّدًا لـ "عملية التنقّل السلسة" بغض النظر عن الإطار المستخدَم وبعض الاختلافات المذكورة سابقًا. يسمح ذلك بتقسيم المخطط الزمني للأداء إلى "عمليات تنقّل" منفصلة، ما يتيح قياس مقياسَي CLS وINP لكل عملية تنقّل.InteractionContentfulPaintالتي تقيس "عمليات العرض التي تتضمّن محتوًى" بعد التفاعل، ما يتيح قياس مقياسَي FCP وLCP لعمليات التنقّل السلسة هذه.
يسمح الجمع بين واجهتَي برمجة التطبيقات هاتَين بقياس "مؤشرات أداء الويب الأساسية" خلال عمليات تحميل الصفحة الكاملة وعمليات التنقّل السلسة.
هل عمليات الانتقال بين مسارات التطبيقات ذات الصفحة الواحدة هي نفسها عمليات تحميل الصفحة الكاملة في Core Web Vitals؟
لا، لا تزال هناك العديد من الاختلافات بين هذَين النوعَين من عمليات التنقّل، ما قد يؤدي إلى اختلاف مقاييس "مؤشرات أداء الويب الأساسية".
تحتوي عملية التنقّل السلسة على محتوى في الصفحة وتعدّل بعض هذا المحتوى أو كله لعرض "الصفحة" الجديدة. يشبه ذلك إلى حد كبير الفرق بين عملية تحميل صفحة كاملة غير مخزّنة مؤقتًا وعملية تحميل صفحة عندما يتم تخزين بعض موارد الصفحة أو كلها مؤقتًا، ولكن في حالة أكثر تطرفًا، قد يظل بعض المحتوى معروضًا.
من الناحية النظرية، سيكون الاختلاف الرئيسي هو إمكانية أن تكون عمليات التنقّل السلسة أسرع بكثير. ولكن هناك اختلافات أخرى أكثر دقة.
لا تأخذ واجهات برمجة التطبيقات الجديدة لعمليات التنقّل السلسة في الاعتبار سوى المحتوى الجديد. لذا، لن تعتبر الصفحة التي تعدّل <h1> والمحتوى النصي، ولكنها تترك الصورة الرئيسية نفسها بين الصفحات، الصورة الرئيسية مرشّحة لمقياس LCP إذا لم تتم إعادة عرضها. سيؤدي ذلك إلى اختلافات في العناصر المستخدَمة لحساب وقت LCP استنادًا إلى ما إذا كانت الصفحة نفسها يتم تحميلها كعملية تحميل صفحة كاملة أو كعملية تنقّل سلسة من صفحة أخرى حالية.
وبالمثل، قد يكون مقياس INP أقل لعمليات التنقّل السلسة لأنّ الكثير من JavaScript اللازمة لتشغيل الموقع الإلكتروني سيتم تحميلها مسبقًا. وبالطريقة نفسها، قد يكون مقياس CLS لعملية التنقّل السلسة أقل (أو أكثر!) إذا كان المحتوى نفسه يؤدي إلى CLS في عملية تحميل الصفحة الكاملة ولكن لا يحتاج إلى تحميله أو إعادة عرضه في عملية التنقّل السلسة.
هناك أيضًا اختلافات طفيفة في وقت أخذ القياسات من عمليات تحميل الصفحة الكاملة (يتم قياسها بعد معالجة تفاعل التنقّل) مقابل عمليات التنقّل السلسة (يتم قياسها من وقت بدء التفاعل).
كما ذكرنا سابقًا، يشبه العديد من هذه الاختلافات الصفحات غير المخزّنة مؤقتًا مقابل الصفحات المخزّنة مؤقتًا، ولا يزال مفهوم ما تحاول Core Web Vitals قياسه ساريًا. ومع ذلك، من المفيد فهم هذه التفاصيل الدقيقة عند التحقيق في مشاكل "مؤشرات أداء الويب الأساسية".
هل من الصعب على التطبيقات ذات الصفحة الواحدة تحقيق أداء جيد في Core Web Vitals مقارنةً بالتطبيقات المتعدّدة الصفحات؟
لا يوجد أي شيء متأصل في بنية التطبيق ذي الصفحة الواحدة يمنع تحميل صفحة في تطبيق ذي صفحة واحدة بالسرعة نفسها، وتحقيق الأداء نفسه في جميع مقاييس "مؤشرات أداء الويب الأساسية"، مثل صفحة مشابهة في تطبيق متعدّد الصفحات.
ومع ذلك، تتمتّع التطبيقات المتعدّدة الصفحات المحسّنة بشكل صحيح ببعض المزايا في استيفاء الحدود القصوى لمؤشرات أداء الويب الأساسية التي لا تتوفّر في التطبيقات ذات الصفحة الواحدة. تم تخفيف ذلك إلى حد كبير من خلال العمل على عمليات التنقّل السلسة التي تمت مناقشتها سابقًا، ولكن قد يظل ذلك صحيحًا عندما لا يتم استخدام واجهات برمجة التطبيقات الجديدة بعدُ. والسبب هو أنّه باستخدام بنية التطبيق المتعدّد الصفحات، يتم تحميل كل "صفحة" كعملية تنقّل بملء الصفحة (بدلاً من جلب المحتوى بشكل ديناميكي وإدراجه في الصفحة الحالية)، ما يعني أنّ المستخدمين الذين يزورون تطبيقًا متعدّد الصفحات من المرجّح أن يحمّلوا أكثر من صفحة واحدة من الموقع الإلكتروني، ما يعني بدوره أنّ نسبة مئوية أكبر من توزيع جميع عمليات تحميل الصفحات لتطبيق متعدّد الصفحات ستتضمّن بعض الموارد الفرعية أو كلها مخزّنة مؤقتًا.
صحيح أنّ أداء التطبيق المتعدّد الصفحات بشكل أفضل في مقاييس Core Web Vitals من التطبيق ذي الصفحة الواحدة يتطلب استيفاء بعض الشروط:
- يجب أن يتضمّن التطبيق المتعدّد الصفحات تخزينًا مؤقتًا محسّنًا للموارد الفرعية لضمان أنّ عمليات تحميل الصفحات من المصدر نفسه أسرع بالفعل من عمليات تحميل الصفحات من مصادر مختلفة عند النسبة المئوية الخامسة والسبعين.
- على المستخدمين الذين يزورون التطبيقات المتعدّدة الصفحات زيارة صفحات متعددة لكي يحصل الموقع الإلكتروني على مزايا التخزين المؤقت التي تؤدي إلى عمليات تحميل أسرع للصفحات.
بما أنّ تقييمات "مؤشرات أداء الويب الأساسية" تأخذ في الاعتبار النسبة المئوية الخامسة والسبعين لزيارات الصفحات، فإنّ زيادة عدد زيارات الصفحات ذات الأداء الجيد في مجموعة البيانات ستزيد من احتمالية أن تكون الزيارة عند النسبة المئوية الخامسة والسبعين من التوزيع ضمن الحدود القصوى المقترَحة.
يُرجى العِلم أنّ من الأمور المهمة التي يجب مراعاتها عند مقارنة نتائج Core Web Vitals هي كيفية تجميع البيانات، أي ما إذا كانت مجموعة البيانات في التوزيع تتضمّن جميع الصفحات من موقعك الإلكتروني أو المصدر، أو عمليات تحميل الصفحات لعنوان URL معيّن فقط.
عند تجميع نتائج جميع الصفحات في مصدر، يمكن أن تحسّن الصفحات الفردية السريعة النسبة المئوية الخامسة والسبعين للمصدر ككل. ومع ذلك، عند التجميع حسب الصفحات الفردية، لن تؤثر نتائج صفحة واحدة في نتائج الصفحة التالية. بعبارة أخرى، عند تجميع نتائج تطبيق متعدّد الصفحات حسب الصفحة، لن تحسّن عمليات تحميل ذاكرة التخزين المؤقت السريعة التي تظهر في صفحة الدفع نتائج عمليات التحميل الأولية البطيئة التي تحدث في الصفحة المقصودة للموقع الإلكتروني.
يمكنك الاطّلاع على نتيجة موقعك الإلكتروني لطُرق التجميع المختلفة باستخدام إحصاءات PageSpeed أو تقرير تجربة المستخدم على Chrome API، الذي يقدّم نتائج عناوين URL للصفحات الفردية والمصدر بأكمله.
هناك طريقة أخرى يمكن أن تؤثر بها بنية التطبيق ذي الصفحة الواحدة في نتائج Core Web Vitals، وهي المقاييس التي تأخذ في الاعتبار العمر الكامل للصفحة. بما أنّ المستخدمين الذين يزورون التطبيقات ذات الصفحة الواحدة يميلون إلى البقاء على "الصفحة" نفسها طوال الجلسة، يمكن أن تكون المقاييس التي تتراكم بمرور الوقت أكثر صرامة على التطبيقات ذات الصفحة الواحدة من التطبيقات المتعدّدة الصفحات.
من خلال العمل على عمليات التنقّل السلسة، نعتقد أنّه لن تكون هناك أي عيوب للتطبيقات ذات الصفحة الواحدة من حيث كيفية قياس Core Web Vitals. ومع ذلك، سيستغرق الدمج الكامل لواجهات برمجة التطبيقات هذه في جميع حلول الأدوات وإعداد التقارير وقتًا.
إذا كانت بُنى التطبيقات ذات الصفحة الواحدة تحسّن تجربة المستخدم، ألا يجب أن يظهر هذا التحسين في المقاييس؟
نعم، يجب أن يظهر ذلك. كان من الصعب تحديد مقدار التحسين في التجربة على نطاق واسع، نظرًا إلى الطرق المختلفة التي يتم بها تنفيذ التطبيقات ذات الصفحة الواحدة على الويب اليوم. لدينا الآن حلّ لمشكلة القياس، وعند استخدام واجهات برمجة التطبيقات الجديدة هذه، يجب أن تظهر أي تحسينات ناتجة عن الانتقال إلى التطبيقات ذات الصفحة الواحدة في المقاييس.
الحقيقة هي أنّ مجال أداء الويب (بما في ذلك Google) لم يستثمر تاريخيًا وقتًا وجهدًا كبيرَين في تطوير مقاييس تتمحور حول المستخدم لأداء الصفحة بعد التحميل، مقارنةً بعملية تحميل الصفحة نفسها. ليس ذلك لأنّ الأداء بعد التحميل ليس مهمًا، بل لأنّ تجربة المستخدم والتفاعلات بعد التحميل أكثر تنوعًا وأقل تحديدًا، ما يجعل من الصعب تصميم مقاييس لها.
ولكن حتى الآن بعد أن أصبح لدينا المزيد من المقاييس بعد التحميل لقياس أداء التطبيقات ذات الصفحة الواحدة، لا نريد تجاهل تجربة التحميل لمجرّد أنّ التجربة بعد التحميل أصبحت أفضل.
أحد أهداف مبادرة Web Vitals هو تعزيز التجارب الجيدة للمستخدمين وتحفيزها في أكبر عدد ممكن من جوانب تحميل صفحة الويب واستخدامها. لا نريد تشجيع السيناريوهات التي يتم فيها تبرير التجارب السيئة إذا كان بإمكانك تقديم عدد كافٍ من التجارب الجيدة للتعويض عنها. يريد المستخدمون تحميل الصفحات بسرعة والانتقال إلى المحتوى الجديد بسرعة، وقد حاولنا تصميم مقاييس تفضّل هذه الأنواع من التجارب.
نقلنا موقعنا الإلكتروني من تطبيق متعدّد الصفحات إلى تطبيق ذي صفحة واحدة وتراجعت نتائجنا. هل هذا متوقّع؟
يعتمد ذلك على بعض العوامل. هناك عدد من الأسباب التي قد تؤدي إلى تغيير نتائجك بعد نقل بنية رئيسية، ولكن قد يفسّر انخفاض عدد عمليات تحميل ذاكرة التخزين المؤقت السريعة بعض هذا التغيير.
إحدى الطرق السريعة للتحقّق من ذلك هي اختبار كل من إصدار التطبيق المتعدّد الصفحات والإصدار ذي الصفحة الواحدة لإحدى صفحاتك المقصودة باستخدام Lighthouse. إذا كانت نتيجة Lighthouse أقل في أي من مقاييس Core Web Vitals للإصدار ذي الصفحة الواحدة، فمن المحتمل أنّ تجربة التحميل قد أصبحت أسوأ بعد التحديث.
هل يجب نقل موقعي الإلكتروني من تطبيق ذي صفحة واحدة إلى تطبيق متعدّد الصفحات لتحقيق نتائج أفضل في Core Web Vitals؟
على الأرجح أنّ هذه المطالبات لن تسبّب لكم أي مشكلة. يجب ألا تنتقل من تطبيق ذي صفحة واحدة إلى تطبيق متعدّد الصفحات إلا إذا لم تكن راضيًا عن مجموعة التطبيق ذي الصفحة الواحدة وكان لديك سبب للاعتقاد بأنّ التطبيق المتعدّد الصفحات سيقدّم تجربة أفضل للمستخدم.
من خلال العمل على عمليات التنقّل السلسة، نعتقد أنّنا عالجنا مشاكل القياس، لذا فإنّ الانتقال لهذا السبب وحده ليس منطقيًا.
ومع ذلك، إذا كان لديك سبب لإظهار أنّ الأداء سيتحسّن، بدلاً من تحسّن القياسات فقط، فقد يكون ذلك سببًا للانتقال من تطبيق ذي صفحة واحدة إلى تطبيق متعدّد الصفحات (أو العكس).
إذا لم يتم الإبلاغ عن نتائج Core Web Vitals إلا للصفحات المقصودة لتطبيق من صفحة واحدة، كيف يمكنني تصحيح المشاكل التي تحدث في "الصفحات" بعد عملية الانتقال بين المسارات وحلّها؟
تستمد أدوات Google التي تبلّغ عن بيانات الاستخدام الفعلي لمقياس "مؤشرات أداء الويب الأساسية" (مثل Search Console وإحصاءات PageSpeed) بياناتها من تقرير تجربة المستخدم في Chrome (CrUX). ويجمّع CrUX البيانات إما حسب المصدر أو حسب عنوان URL للصفحة (أي عنوان URL للصفحة في مدّة التحميل).
نحن نعمل على السماح لـ CrUX بتضمين البيانات حسب مسار التطبيق ذي الصفحة الواحدة في بياناته المجمَّعة. ومع ذلك، يمكنك الآن بصفتك مالك موقع إلكتروني استخدام واجهات برمجة التطبيقات الجديدة لقياس Core Web Vitals حسب مسار التطبيق ذي الصفحة الواحدة قبل ذلك لفهم كيفية تغيُّر نتائجك.
لمزيد من التفاصيل وأفضل الممارسات حول ذلك، يُرجى الاطّلاع على: قياس عمليات التنقّل السلسة.
ما هي الإجراءات التي تتّخذها Google لضمان عدم حصول التطبيقات المتعدّدة الصفحات على ميزة غير عادلة مقارنةً بالتطبيقات ذات الصفحة الواحدة؟
كما ذكرنا سابقًا، من خلال العمل على عمليات التنقّل السلسة، نعتقد أنّ العمل الذي أجريناه الآن يعني أنّه لن تكون هناك أي عيوب للتطبيقات ذات الصفحة الواحدة في هذا الصدد، على الرغم من أنّ الدمج الكامل في جميع حلول الأدوات وإعداد التقارير سيستغرق وقتًا.
تقييم زيارات الصفحات متعدّدة المصادر ومن المصدر نفسه بشكل منفصل
في الوقت الحالي، تجمّع مقاييس Core Web Vitals جميع زيارات الصفحات في مجموعة واحدة، ولا تفرّق بين الزيارات الجديدة والزيارات المتكرّرة أو الصفحات المقصودة وصفحات الدفع أو أي نوع تجميع آخر يمكن أن تؤثر فيه حالة ذاكرة التخزين المؤقت في الأداء.
إحدى طرق تسوية الاختلافات بين أداء التطبيق ذي الصفحة الواحدة والتطبيق المتعدّد الصفحات هي تطبيق ترجيح مختلف على أنواع الزيارات المختلفة، وربما حتى باستخدام اقتراحات مختلفة تمامًا للحدود القصوى.
في حين أنّنا نريد بالتأكيد مكافأة عمليات تنفيذ ذاكرة التخزين المؤقت الفعّالة، لا نريد أن تكون عمليات التنقّل السريعة داخل الموقع الإلكتروني قادرة على تغطية عمليات تحميل الصفحات المقصودة البطيئة. لا نريد أيضًا تحفيز المواقع الإلكترونية على تقسيم الصفحات الطويلة إلى مجموعة من الصفحات الأقصر لمجرّد تحسين نتائج المقاييس.
من خلال تقييم زيارات الصفحات متعدّدة المصادر ومن المصدر نفسه بشكل منفصل، يمكننا المساعدة في ضمان أهمية كلا النوعَين من التجارب بدون السماح للشعبية النسبية لأحد النوعَين على موقع إلكتروني معيّن بتشويه توزيع أي مقياس معيّن.
الأفكار الختامية
تلتزم Google بشدة بتحسين مقاييس Web Vitals، وضمان قياسها وتحفيزها للتجارب عالية الجودة التي تهم المستخدمين. ومع ذلك، نعترف بوجود فجوات في القياس اليوم. أصبحت المقاييس الآن قادرة على تغطية عمليات الانتقال بين مسارات التطبيقات ذات الصفحة الواحدة، ما يعالج إحدى الفجوات الرئيسية.
نعتقد أيضًا أنّ واجهات برمجة التطبيقات الجديدة هذه (خاصةً InteractionContentfulPaint) لها استخدامات ومزايا محتمَلة أخرى تتجاوز قياس "مؤشرات أداء الويب الأساسية" لعمليات التنقّل السلسة. نحن متحمّسون جدًا لمواصلة البناء على هذه الواجهات الآن بعد معالجة السبب الرئيسي لطرحها.
نأمل أن يكون هذا المنشور قد ساعد في إلقاء بعض الضوء على هذا الموضوع المعقّد والدقيق. كما هو الحال دائمًا، إذا كان لديك ملاحظات حول مقاييس "مؤشرات أداء الويب" الحالية أو المستقبلية، يُرجى إرسالها عبر البريد الإلكتروني إلى web-vitals-feedback@googlegroups.com.