إجابات عن الأسئلة الشائعة حول التطبيقات المُنشِئة للصفحات الواحدة و"مؤشرات أداء الويب الأساسية" وخطة Google لحلّ القيود الحالية في القياس
منذ إطلاق مبادرة مؤشرات الأداء في الويب لأول مرة في أيار (مايو) 2020، تلقّينا نحن في فريق Chrome الكثير من الأسئلة والملاحظات الرائعة حول البرنامج.
إنّ الموضوع الذي تلقّينا أكبر عدد من الأسئلة حوله، والذي يُعدّ أيضًا من المحتمل أن يكون السؤال الأصعب للإجابة عنه، هو كيفية قياس "مؤشرات أداء الويب الأساسية" في تطبيق صفحة واحدة (SPA)، بالإضافة إلى كيفية تأثير تصاميم SPA في نتائج "مؤشرات أداء الويب الأساسية".
من الصعب الإجابة عن هذه الأسئلة لأنّ المشكلة معقّدة جدًا، لذا سنبذل قصارى جهدنا في هذا المنشور للإجابة عن الأسئلة الأكثر شيوعًا، مع تقديم أكبر قدر ممكن من التفاصيل والسياق.
قبل الخوض في التفاصيل، من المهم الإشارة إلى أنّ Google ليس لديها أيّ تفضيل بشأن البنية أو التكنولوجيا المستخدَمة لإنشاء موقع إلكتروني. نعتقد أنّ التطبيقات المُشغّلة على صفحات ويب واحدة والتطبيقات المتعدّدة الصفحات (MPA) قادرة على تقديم تجارب عالية الجودة للمستخدمين، ونهدف من خلال مبادرة Web Vitals إلى توفير مقاييس تقيس التجربة بغض النظر عن التكنولوجيا. على الرغم من أنّ هذا ليس ممكنًا في كل الحالات حاليًا (بسبب قيود منصة الويب)، فإنّنا نعمل جاهدين على سدّ هذه الثغرات.
الأسئلة الشائعة
هل تشمل مقاييس "مؤشرات أداء الويب الأساسية" عمليات النقل إلى مسارات التطبيقات المُنشِئة للصفحات الواحدة؟
لا، يتم قياس كل مقياس من مقاييس "مؤشرات أداء الويب الأساسية" استنادًا إلى عملية التنقّل الحالية في الصفحة على مستوى القمة. إذا كانت الصفحة تحمّل محتوًى جديدًا بشكل ديناميكي وتُعدّل عنوان URL للصفحة في شريط العناوين، لن يكون لذلك أي تأثير على كيفية قياس مقاييس Core Web Vitals. لا تتم إعادة ضبط قيم المقاييس، وعنوان URL المرتبط بكل قياس مقياس هو عنوان URL الذي تنقّل إليه المستخدِم وبدأ تحميل الصفحة.
هل يمكن لمقاييس "مؤشرات أداء الويب الأساسية" التعامل مع تغييرات مسار التطبيقات المُنشِئة لصفحات ويب ديناميكية بالطريقة نفسها التي تتعامل بها مع عمليات تحميل الصفحات التقليدية؟
لا، ليس بعد.
لا تتوفّر طريقة موحّدة لإنشاء تطبيق متعدّد الصفحات اليوم، وحتى بين مكتبات التطبيقات المتعدّدة الصفحات ومكتبات التوجيه الرائجة، يمكن أن تختلف تجربة المستخدم اختلافًا كبيرًا من تطبيق إلى آخر:
- لا تعدّل بعض التطبيقات المُشغّلة على صفحات ويب واحدة عنوان URL إلا عند تحميل محتوى جديد "للصفحة الكاملة"، في حين تعديل المواقع الإلكترونية الأخرى لعنوان URL عند إجراء تغييرات صغيرة على المحتوى أو حتى عند إجراء تغييرات على حالة واجهة المستخدم فقط.
- تعدّل بعض تطبيقات SPA عنوان URL باستخدام History API، في حين تستخدم تطبيقات أخرى علامات الهاشتاغ للتوافق مع المتصفّحات القديمة (ولا تعدّل تطبيقات أخرى عنوان URL إطلاقًا).
- تحمّل بعض التطبيقات المُنشِئة للصفحات الواحدة المحتوى ثم تعدّل عنوان URL، في حين تعدّل تطبيقات أخرى عنوان URL قبل تحميل المحتوى.
- تحمّل بعض التطبيقات المُنشِئة للصفحات الواحدة المحتوى بالكامل في آنٍ واحد بشكل متزامن في مهمة واحدة مكتوبة بلغة JavaScript، في حين تنقل تطبيقات أخرى المحتوى بشكل غير متزامن في عدة مهمة (بدون حدث واضح لإنهاء عملية النقل).
- تحمّل بعض التطبيقات المزوّدة بواجهة مستخدم موحّدة المحتوى دائمًا من الشبكة، في حين تحمّل تطبيقات أخرى كل المحتوى مقدمًا لكي يتم تحميل تغييرات المسار على الفور من الذاكرة.
تجعل هذه الاختلافات من الصعب جدًا تحديد ومعرفة ما يشكّل مسار ملف برمجي متعدّد الصفحات أو تغييره، أو حتى ملف برمجي متعدّد الصفحات نفسه على نطاق واسع.
في بعض الحالات، يكون تغيير مسار تطبيق SPA مطابقًا منطقيًا لتحميل صفحة MPA، وفي هذه الحالات، سيكون من الرائع تطبيق مقاييس "مؤشرات أداء الويب الأساسية" الحالية.
ومع ذلك، في حال عدم توفّر أساليب ارشادية قوية لتحديد التغييرات "الحقيقية" في المسار بشكل موثوق من بين جميع تغييرات عناوين URL الأخرى، بالإضافة إلى إشارات واضحة تشير إلى بداية هذه التحولات ونهايتها، سيؤدي إعداد تقارير مقاييس Core Web Vitals في هذه الحالات إلى تشويش البيانات وجعلها أقل فائدة أو تمثيلًا لتجربة المستخدم الفعلية على الموقع الإلكتروني.
هل من الصعب على التطبيقات المُنشأة باستخدام إطار عمل تطوير البرامج (SPA) تحقيق نتائج جيدة في "مؤشرات أداء الويب الأساسية" مقارنةً بالتطبيقات المُنشأة باستخدام إطار عمل تطوير التطبيقات (MPA)؟
لا تتضمّن بنية التطبيقات من صفحة واحدة أيّ ميزة أساسية تمنع صفحة في هذه التطبيقات من التحميل بسرعة مماثلة، وتحقيق نتائج مماثلة في جميع مقاييس مؤشرات أداء الويب الأساسية، مقارنةً بصفحة مشابهة في تطبيق متعدّد الصفحات.
ومع ذلك، فإنّ المواقع الإلكترونية المتوافقة مع الأجهزة الجوّالة التي تم تحسينها بشكل صحيح تتمتع ببعض المزايا في استيفاء الحدود الدنيا لمؤشرات أداء الويب الأساسية التي لا تمتلكها المواقع الإلكترونية المتوافقة مع الأجهزة الجوّالة التي تعمل بالاستضافة الساكنة حاليًا. ويعود السبب في ذلك إلى أنّه في بنية MPA، يتم تحميل كل "صفحة" كتنقّل في الصفحة بالكامل (بدلاً من جلب المحتوى ديناميكيًا وإدراجه في الصفحة الحالية)، ما يعني أنّه من المرجّح أن يحمّل المستخدمون الذين يزورون MPA أكثر من صفحة واحدة من الموقع الإلكتروني، ما يعني بدوره أنّ نسبة أكبر من توزيع كل عمليات تحميل الصفحات في MPA ستتضمّن بعض الموارد الفرعية أو كلها التي يتم تخزينها مؤقتًا.
من المعلوم أنّ تحقيق أداء أفضل لمواقع MPA في مقاييس "مؤشرات أداء الويب الأساسية" مقارنةً بمواقع SPA يتطلب توفّر بعض الشروط:
- يجب أن يكون لدى MPA ميزة تخزين مؤقت محسّن للموارد الفرعية لضمان أنّ سرعة تحميل الصفحات من المصدر نفسه تكون أسرع من سرعة تحميل الصفحات من مصادر مختلفة عند الاطّلاع على الشريحة المئوية الـ 75.
- يحتاج المستخدمون الذين يزورون المواقع الإلكترونية التي تعرض إعلانات متعددة إلى الانتقال إلى صفحات متعددة لكي يستفيد الموقع الإلكتروني من مزايا التخزين المؤقت التي تؤدي إلى تحميل الصفحات بشكل أسرع.
بما أنّ تقييمات "مؤشرات أداء الويب الأساسية" تأخذ في الاعتبار القيمة المئوية الخامسة والسبعين لزيارات الصفحات، سيؤدي توفّر المزيد من زيارات الصفحات التي تحقّق أداءً جيدًا في مجموعة البيانات إلى زيادة احتمال أن تكون الزيارة التي تقع في القيمة المئوية الخامسة والسبعين من التوزيع ضمن الحدود المقترَحة.
يُرجى العِلم أنّ من الأمور المهمة التي يجب مراعاتها عند مقارنة نتائج "مؤشرات أداء الويب الأساسية" هي كيفية تجميع البيانات، أي ما إذا كانت مجموعة البيانات في التوزيع تضمّن جميع الصفحات من موقعك الإلكتروني أو مصدرك، أو مجرد عمليات تحميل الصفحات لعنوان URL معيّن لصفحة.
عند تجميع نتائج جميع الصفحات في مصدر، يمكن للصفحات السريعة الفردية تحسين الشريحة المئوية التسعون للمصدر ككل. ومع ذلك، عند التجميع حسب الصفحات الفردية، لن تؤثّر نتائج صفحة واحدة في نتائج الصفحات التالية. بعبارة أخرى، عند تجميع نتائج اختبار MPA حسب الصفحة، لن تؤدي عمليات تحميل محتوى التخزين المؤقت السريعة التي تظهر في صفحة الدفع إلى تحسين نتائج عمليات التحميل الأولي البطيئة التي تحدث في الصفحة المقصودة للموقع الإلكتروني.
يمكنك التحقّق من نتيجة موقعك الإلكتروني لطرق تجميع مختلفة باستخدام إحصاءات PageSpeed أو واجهة برمجة التطبيقات لخدمة "تقرير تجربة مستخدمي Chrome"، التي تُبلغ عن النتائج لكلّ من عناوين URL للصفحات الفردية والمصدر بالكامل.
هناك طريقة أخرى يمكن أن تؤثّر بها بنية التطبيقات المُشغّلة على صفحات الويب في نتائج "مؤشرات أداء الويب الأساسية"، وهي المقاييس التي تأخذ في الاعتبار الفترة الكاملة لظهور الصفحة. بما أنّ المستخدِمين الذين يزورون المواقع الإلكترونية التي تستخدم تطبيقات مزوّدة بواجهة برمجة تطبيقات يميلون إلى البقاء على "الصفحة" نفسها طوال الجلسة، يمكن أن تكون المقاييس التي تتراكم بمرور الوقت أكثر قسوة على المواقع الإلكترونية التي تستخدم تطبيقات مزوّدة بواجهة برمجة تطبيقات مقارنةً بالمواقع الإلكترونية التي تستخدم تطبيقات مزوّدة بواجهة برمجة تطبيقات.
في نيسان (أبريل) 2021، أعلنّا عن تغييرات في مقياس CLS أدّت إلى حلّ هذه المشكلة جزئيًا. في السابق، كان يتم تجميع متغيّرات التصميم التراكمية (CLS) على مدار فترة تشغيل الصفحة بالكامل، في حين أنّه يتم تجميعها الآن خلال فترة زمنية محدّدة، وهي أساسًا أسوأ ذروة لمتغيّرات التصميم في صفحة معيّنة.
ومع ذلك، حتى مع التعريف الجديد لمتغيّر التصميم التراكمية (CLS)، لا تزال التطبيقات المُنشأة باستخدام إطار عمل تفاعلي في وضعٍ غير مُفيد مقارنةً بالتطبيقات المُنشأة باستخدام إطار عمل متعدّد الصفحات، لأنّ قيمة متغيّر التصميم التراكمية (CLS) لا "تتم إعادة ضبطها" بعد انتقال المسار كما يحدث عند تحميل الصفحة بالكامل في التطبيقات المُنشأة باستخدام إطار عمل متعدّد الصفحات. ويمكن أن يؤدي ذلك أيضًا إلى حدوث التباس لأنّ التحولات في التنسيق التي تحدث بعد انتقال المسار ستُنسَب إلى عنوان URL للصفحة عند تحميلها، وليس عنوان URL في شريط العناوين في وقت التحويل (مزيد من التفاصيل أدناه).
إذا كانت تصاميم التطبيقات المُدمجة في صفحة واحدة تحسِّن تجربة المستخدم، ألا من المفترض أن يظهر هذا التحسين في المقاييس؟
نعم، من المفترض أن يظهر. على الرغم من أنّه، كما ذكرنا سابقًا، من الصعب تحديد مدى تحسُّن التجربة على نطاق واسع، نظرًا لجميع الاختلافات في طرق تنفيذ التطبيقات المتوافقة مع معايير الويب المتجاوبة على الويب اليوم.
في الواقع، لم تُخصّص صناعة أداء الويب (بما في ذلك Google) في السابق سوى وقت وجهد محدودَين تقريبًا لتطوير مقاييس تركّز على المستخدِم لأداء التحميل بعد loading الصفحة، مقارنةً بالوقت والجهد المخصّصَين لتحميل الصفحة نفسها. لا يرجع ذلك إلى عدم أهمية الأداء بعد التحميل، بل لأنّ تجربة المستخدم والتفاعلات بعد التحميل تكون متنوعةً بشكلٍ أكبر وأقل تحديدًا، ما يجعل من الصعب تصميم مقاييس لها.
ولكن حتى لو كانت لدينا مقاييس محدّدة جيدًا بعد التحميل لقياس أداء التطبيقات المُنشِئة للصفحات، لن نتجاهل تجربة التحميل فقط لأنّ تجربة ما بعد التحميل تحسّنت.
أحد أهداف مبادرة "مؤشرات أداء الويب" هو الترويج لتجارب المستخدِمين الجيدة وتحفيز أصحاب المواقع الإلكترونية على تحسينها في أكبر عدد ممكن من جوانب تحميل صفحات الويب واستخدامها. لا نريد تشجيع سيناريوهات تُبرر التجارب السيئة إذا كان بإمكانك الحصول على تجارب جيدة كافية لتعويضها. يريد المستخدمون أن يتم تحميل الصفحات بشكل سريع وللانتقال إلى المحتوى الجديد بسرعة، وقد حاولنا تصميم مقاييس تفيد هذه الأنواع من التجارب.
على الرغم من أنّه من الصحيح أنّ إصدار MPA لموقع إلكتروني قد يحقّق أداءً أفضل في مقاييس Core Web Vitals عند بلوغ الشريحة المئوية الـ 75 مقارنةً بإصدار SPA لموقع إلكتروني مماثل تمامًا، يجب أن يسعى إصدار SPA إلى استيفاء الحدّ الأدنى "الجيد". إذا لم يستوفِ إصدار SPA الحدّ الأدنى لقيمة "جيد" لمعظم المستخدمين، من المرجّح أنّ تجربة التحميل المبدئية لا تزال غير جيدة، حتى إذا كانت تجربة التنقّل التالية داخل الصفحة ممتازة.
ونخطّط في المستقبل لإنشاء مقاييس تشجع على تقديم تجارب رائعة بعد التحميل، ونعتقد أنّ هذا هو أفضل مسار لتشجيع استخدام تطبيقات SPA العالية الجودة بطريقة لا تؤثر سلبًا في تجربة التحميل الأولي. لقد طرحنا سابقًا مقياسًا جديدًا باسم مدى استجابة الصفحة لتفاعلات المستخدم (INP) يقيس وقت استجابة التفاعلات على مدار دورة حياة الصفحة بالكامل، ونحن نعمل بنشاط على تطوير مقاييس أخرى بعد التحميل أيضًا، بما في ذلك المقاييس التي تقيس عمليات النقل بين مسارات التطبيقات المُنشأة باستخدام إطار عمل SPA (راجِع المعلومات أدناه).
لقد بدّلنا موقعنا الإلكتروني من MPA إلى SPA وتراجعت نتائجنا. هل هذا متوقّع؟
يعتمد ذلك على بعض العوامل. هناك عدد من الأسباب التي قد تؤدي إلى تغيير نتائجك بعد نقل بيانات بنية أساسية رئيسية، ولكن قد يرجع بعض هذا التغيير إلى انخفاض عدد عمليات تحميل ذاكرة التخزين المؤقت المتوفّرة.
ويمكنك التحقّق من ذلك بسرعة من خلال اختبار كلّ من إصدار MPA وإصدار SPA لأحد صفحاتك المقصودة باستخدام Lighthouse. إذا كانت نتيجة Lighthouse أقل في أيّ من مقاييس "مؤشرات أداء الويب الأساسية" لإصدار التطبيق المتوافق مع واجهة برمجة التطبيقات (SPA)، من المرجّح أنّ تجربة التحميل قد ساءت بعد التحديث.
هل عليّ تبديل موقعي الإلكتروني من تطبيق متعدّد الصفحات إلى تطبيق متعدّد المواقع لتحسين النتيجة في "مؤشرات أداء الويب الأساسية"؟
على الأرجح أنّ هذه المطالبات لن تسبّب لك أي مشكلة. يجب عدم التبديل من تطبيق SPA إلى تطبيق MPA إلا إذا لم تكن راضيًا عن حِزمة SPA وكان لديك سبب للاعتقاد بأنّ تطبيق MPA سيقدّم تجربة أفضل للمستخدم.
بمرور الوقت، ومع تحسين مقاييس Core Web Vitals وتغطيتها لعدد أكبر من تجارب التصفّح الكاملة، من المفترض أن تلاحظ الفِرق التي تستخدم تطبيقات صفحات ويب متقدّمة (SPA) مصمّمة جيدًا وتقدّم تجربة مستخدم رائعة أن تعكس نتائج Core Web Vitals ذلك.
إذا كانت نتائج "مؤشرات أداء الويب الأساسية" لا يتم تسجيلها إلا للصفحات المقصودة لموقع إلكتروني مزوّد بتطبيق برمجي لواجهة مستخدم، كيف يمكنني تصحيح الأخطاء التي تحدث في "الصفحات" بعد انتقال المسار؟
تحصل أدوات Google التي تسجّل بيانات الاستخدام الفعلي لمقياس "مؤشرات أداء الويب الأساسية" (مثل Search Console وPageSpeed Insights) على بياناتها من تقرير تجربة مستخدم Chrome (أو CrUX). ويجمّع "تقرير تجربة المستخدِم على Chrome" البيانات إما حسب المصدر أو حسب عنوان URL للصفحة (أي عنوان URL للصفحة في وقت التحميل).
لكل الأسباب المذكورة أعلاه، لا يمكن لخدمة CrUX تجميع البيانات حسب مسار معالجة طلب البحث على الصفحة (SPA). ومع ذلك، بصفتك مالك موقع إلكتروني على دراية بتصميمك، من الممكن قياس ذلك بنفسك، وتسمح لك العديد من أدوات الإحصاءات بتسجيل التغييرات التي تطرأ على مسار SPA وتعديل بيانات القياس وفقًا لذلك.
عند قياس مقاييس "مؤشرات أداء الويب" باستخدام أداة إحصاءات، تأكّد من قياس عنوان URL الحالي للمسار بالإضافة إلى عنوان URL الأصلي للصفحة. سيتيح لك ذلك تصحيح الأخطاء الفردية التي تحدث خلال دورة حياة الصفحة، بالإضافة إلى التجميع حسب عنوان URL الأصلي للصفحة لمطابقة الطريقة التي تقيس بها أدوات Google المقاييس وإعداد التقارير عنها.
لمزيد من التفاصيل وأفضل الممارسات حول هذا الموضوع، يُرجى الاطّلاع على مقالة تصحيح أخطاء الأداء في الميدان.
ما هي الإجراءات التي تتّخذها Google لضمان عدم حصول "الإعلانات المتجاوبة على شبكة البحث" على ميزة غير عادلة مقارنةً بـ "الإعلانات المتجاوبة على شبكة Google الإعلانية"؟
كما ذكرنا أعلاه، يمكن أن تُظهر صفحات AMP المحسّنة بشكلٍ سليم في بعض الحالات نتائج أفضل في قياسات Web Vitals عند نسبة %75 من القيم، وذلك لأنّه من المرجّح أن تحقّق هذه الصفحات نسبة أعلى من زيارات الصفحات المخزّنة مؤقتًا. في المقابل، لا يتم حاليًا تسجيل أي تحسينات حقيقية في تجربة المستخدم في تطبيقات SPA المحسّنة بشكل صحيح باستخدام أيّ من مقاييس Core Web Vitals.
ندرك في Google أنّ ذلك يخلق حوافز لا تتوافق تمامًا مع أهداف مبادرة Web Vitals، ونحن نبحث بنشاط عن طرق لحلّ هذه المشكلة. نحن نستكشف حاليًا حلّين محتمَلين، أحدهما قصير المدى والآخر طويل المدى:
- تقييم زيارات الصفحات من مصادر مختلفة ومن مصادر مماثلة بشكل منفصل
- تصميم واجهات برمجة تطبيقات جديدة تتيح قياس أداء الإعلانات المتجاوبة على شبكة البحث بشكل أفضل
تقييم زيارات الصفحات من مصادر مختلفة ومن مصادر مماثلة بشكل منفصل
في الوقت الحالي، تجمع مقاييس "مؤشرات أداء الويب الأساسية" جميع زيارات الصفحة في مجموعة واحدة، ولا يفرّق بين الزيارات الجديدة والزائرين المتكرّرين أو الصفحات المقصودة مقارنةً بصفحات الدفع أو أي نوع آخر من عمليات التجميع التي يمكن أن تؤثّر فيها حالة ذاكرة التخزين المؤقت في الأداء.
من بين الطرق التي يمكن من خلالها توحيد الاختلافات بين أداء SPA وMPA هي تطبيق وزن مختلف لأنواع الزيارات المختلفة، وقد يكون ذلك مع اقتراحات حدود مختلفة تمامًا.
على الرغم من أنّنا نريد بالتأكيد مكافأة عمليات تنفيذ ذاكرة التخزين المؤقت الفعّالة، إلا أنّنا لا نريد أن تكون عمليات التنقّل السريعة داخل الموقع الإلكتروني قادرة على التعويض عن بطء تحميل الصفحة المقصودة. لا نريد أيضًا أن نشجّع المواقع الإلكترونية على تقسيم الصفحات الطويلة إلى مجموعة من الصفحات الأقصر بهدف تحسين نتائج المقاييس فقط.
من خلال تقييم زيارات الصفحات من مصادر مختلفة ومن مصدر واحد بشكل منفصل، يمكننا المساعدة في ضمان أهمية كلا النوعَين من التجارب بدون السماح للنسبة المئوية المتغيرة لنوع واحد على موقع إلكتروني معيّن بتشويه توزيع أي مقياس معيّن.
تصميم واجهات برمجة تطبيقات جديدة تتيح قياس أداء المواقع الإلكترونية المتجاوبة بشكل أفضل
هناك حلّ آخر نعمل عليه بنشاط (بالتوازي مع الحلّ أعلاه) وهو App History API الجديدة، التي ستساعد في توحيد نماذج SPA الحالية وتسهيل قياس استخدام SPA وفهمه على نطاق واسع.
تقدّم واجهة برمجة التطبيقات App History API حدثًا جديدًا هو
navigate، والذي
يتضمّن ميزتَين رئيسيتين خاصتَين بقياس التطبيقات المتعدّدة الصفحات:
- علامة
userInitiatedلن يتم ضبطها على true إلا إذا تم بدء التنقّل من خلال النقر على رابط أو إرسال نموذج أو واجهة مستخدم الرجوع أو التقديم في المتصفّح. transitionWhile()طريقة تأخذ وعدًا يسمح للمطوّر بإرسال إشارة عند اكتمال العمل الذي بدأه لتنفيذ التنقّل
يمكن استخدام العلامة userInitiated لتحديد نقطة بداية دلالية ل
انتقال مسار تطبيق متعدّد الصفحات (SPA)، ما يشير إلى نية واضحة للمستخدم. يمكن أن يساعد transitionWhile()
حلّ الوعد المتّصل في ربط المتصفّح بين عمليات الرسم وحالة انتقال مسار محدّد، ما قد يساعده في تحديد أكبر عملية رسم لجزء من المحتوى مرتبطة بهذه الحالة.
استنادًا إلى الفكرة التي تم تقديمها في القسم السابق، قد يكون من الممكن تجميع وقت انتقال مسار SPA في المجموعة نفسها التي يتم فيهاتحميل الصفحة من مصدر مماثل في MPA. وهذا أمر مثير للاهتمام لأنّه سيسمح لموقع إلكتروني يقترب من نقل بياناته من "حملة إعلانية على شبكة البحث" إلى "حملة إعلانية على شبكة المواقع" بمقارنة الأداء قبل نقل البيانات وبعده.
بالطبع، نحتاج إلى إجراء المزيد من الأبحاث قبل أن نعرف ما إذا كان بإمكاننا تحديد هذه العوامل بدقة. إذا كانت لديك اقتراحات أو ملاحظات حول هذين الاقتراحين، يُرجى إرسال رسالة إلكترونية إلى عنوان web-vitals-feedback@googlegroups.com.
ملاحظات أخيرة
تلتزم Google تمامًا بتحسين مقاييس "مؤشرات أداء الويب"، وضمان قياسها للتجارب العالية الجودة التي تهمّ المستخدمين وتقديم حوافز لها. ومع ذلك، ندرك أنّ هناك فجوات في القياس في الوقت الحالي. لا تشمل المقاييس حاليًا كل جوانب تجربة المستخدم، ولكنّنا نعمل بنشاط على سدّ هذه الفجوات.
على الرغم من القيود الحالية، نعتقد أنّ الجوانب التي ترصدها المقاييس الحالية مهمة لصحة الويب ونجاحه، وإلى الحدّ الذي لا تستوفي فيه المواقع الإلكترونية (بغض النظر عن البنية) الحدود الدنيا المُقترَحة، نعتقد أنّ هناك مجالًا للتحسين.
نأمل أن تكون هذه المشاركة قد ساعدت في إلقاء بعض الضوء على هذا الموضوع المعقّد والمتعدّد التفاصيل. كما هو الحال دائمًا، إذا كانت لديك ملاحظات حول مقاييس "مؤشرات أداء الويب" الحالية أو المستقبلية، يُرجى إرسال رسالة إلكترونية إلى عنوان web-vitals-feedback@googlegroups.com.