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