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