چگونه معماری SPA بر Core Web Vitals تأثیر می گذارد

پاسخ به سؤالات رایج در مورد SPA، Core Web Vitals، و طرح Google برای رسیدگی به محدودیت‌های اندازه‌گیری فعلی.

فیلیپ والتون
یواو ویس

از زمانی که برای اولین بار ابتکار Web Vitals را در ماه می ۲۰۲۰ معرفی کردیم، ما در تیم Chrome سؤالات و بازخوردهای بسیار خوبی در مورد این برنامه دریافت کردیم.

شاید موضوعی که ما بیشترین سوالات را در مورد آن دریافت کرده‌ایم، که احتمالاً سخت‌ترین سوال برای پاسخ به آن است، چگونگی اندازه‌گیری Core Web Vitals در یک برنامه تک صفحه‌ای (SPA) و همچنین نحوه تأثیر معماری SPA بر امتیازات Core Web Vitals است. .

پاسخ به این سؤالات سخت است زیرا مشکل کاملاً ظریف است، بنابراین در این پست ما تمام تلاش خود را می کنیم تا به رایج ترین سؤالات پاسخ دهیم و تا آنجا که می توانیم جزئیات و زمینه را ارائه دهیم.

با این حال، قبل از پرداختن به جزئیات، مهم است که بیان کنیم که گوگل هیچ اولویتی در مورد معماری یا فناوری مورد استفاده برای ساخت یک سایت ندارد. ما معتقدیم که SPAها و برنامه های کاربردی چند صفحه ای (MPA) هر دو قادر به ارائه تجربیات با کیفیت بالا به کاربران هستند و هدف ما از ابتکار Web Vitals ارائه معیارهایی است که تجربه را مستقل از فناوری اندازه گیری می کند. در حالی که امروزه در همه موارد این امکان وجود ندارد (به دلیل محدودیت‌های موجود در پلتفرم وب)، ما فعالانه در حال کار بر روی بستن این شکاف‌ها هستیم.

سوالات متداول

آیا معیارهای Core Web Vitals شامل انتقال مسیر SPA است؟

خیر. هر یک از معیارهای Core Web Vitals نسبت به پیمایش صفحه فعلی و سطح بالا اندازه گیری می شود. اگر صفحه ای به صورت پویا محتوای جدید را بارگیری کند و URL صفحه را در نوار آدرس به روز کند، تأثیری بر نحوه اندازه گیری معیارهای Core Web Vitals نخواهد داشت. مقادیر متریک بازنشانی نمی‌شوند و URL مرتبط با هر اندازه‌گیری متریک، نشانی اینترنتی است که کاربر به آن پیمایش کرده و بارگیری صفحه را آغاز کرده است.

آیا معیارهای Core Web Vitals می‌توانند تغییرات مسیر SPA را همانند بارگذاری صفحات سنتی رفتار کنند؟

متاسفانه نه. به هر حال هنوز نه.

امروزه هیچ روش استانداردی برای ساخت SPA وجود ندارد، و حتی در میان SPA های محبوب و کتابخانه های مسیریابی، تجربه کاربر می تواند از برنامه ای به برنامه دیگر کاملاً متفاوت باشد:

  • برخی از SPA ها URL را فقط هنگام بارگیری محتوای "کامل صفحه" جدید به روز می کنند، در حالی که سایر سایت ها URL را برای تغییرات کوچک محتوای یا حتی تغییر حالت رابط کاربری به روز می کنند.
  • برخی از SPA ها URL را با استفاده از History API به روز می کنند، در حالی که برخی دیگر از تغییرات هش برای پشتیبانی از مرورگرهای قدیمی استفاده می کنند (و برخی دیگر اصلا URL را به روز نمی کنند).
  • برخی از SPA ها محتوا را بارگیری می کنند و سپس URL را به روز می کنند، در حالی که برخی دیگر URL را قبل از بارگیری محتوا به روز می کنند.
  • برخی از SPA ها محتوا را به طور همزمان و همزمان در یک کار جاوا اسکریپت بارگیری می کنند، در حالی که برخی دیگر محتوا را به صورت ناهمزمان در چندین کار (بدون رویداد پایان انتقال واضح) انتقال می دهند.
  • برخی از SPA ها همیشه محتوا را از شبکه بارگیری می کنند، در حالی که برخی دیگر همه محتوا را از قبل بارگذاری می کنند تا بارگذاری مسیر فوراً از حافظه تغییر کند.

این تفاوت‌ها، تعیین و شناسایی آنچه که تغییر مسیر SPA یا حتی خود SPA را تشکیل می‌دهد، در مقیاس بسیار دشوار می‌سازد.

در برخی موارد تغییر مسیر SPA از نظر منطقی با بارگذاری صفحه MPA یکسان است و در چنین مواردی اگر معیارهای Core Web Vitals موجود اعمال شود عالی خواهد بود.

با این حال، بدون اکتشافی مستحکم برای شناسایی قابل اعتماد تغییرات مسیر "واقعی" از سایر تغییرات URL - و همچنین سیگنال‌های واضحی که شروع و پایان چنین انتقال‌هایی را نشان می‌دهند - گزارش معیارهای Core Web Vitals در این موارد داده‌ها را گل‌آلود کرده و آن‌ها را کمتر مفید می‌کند. یا نماینده تجربه واقعی کاربر در سایت.

آیا برای SPAها کار کردن در Core Web Vitals سخت تر از MPAها است؟

هیچ چیز ذاتی در معماری SPA وجود ندارد که مانع از بارگیری یک صفحه در SPA به همان سرعت - و کسب امتیاز در تمام معیارهای Core Web Vitals - به عنوان صفحه مشابه در MPA شود.

با این حال، MPA های بهینه سازی شده به درستی دارای مزایایی در برآوردن آستانه های Core Web Vitals هستند که SPA ها در حال حاضر ندارند. دلیل آن این است که با معماری MPA، هر "صفحه" به عنوان یک ناوبری تمام صفحه بارگذاری می شود (به جای دریافت پویا محتوا و درج آن در صفحه موجود)، که به این معنی است که کاربرانی که از یک MPA بازدید می کنند، بیشتر احتمال دارد که بارگذاری کنند. یک صفحه از سایت، که به نوبه خود به این معنی است که درصد بیشتری از توزیع بارهای صفحه برای یک MPA شامل برخی یا همه منابع فرعی است که در حافظه پنهان ذخیره می شوند.

مسلماً، برای اینکه یک MPA در معیارهای Core Web Vitals بهتر از SPA عمل کند، برای درست بودن چند چیز لازم است:

  • MPA نیاز به ذخیره سازی منابع فرعی بهینه سازی شده دارد تا اطمینان حاصل شود که بارگذاری صفحات با منبع یکسان در واقع سریعتر از بارگیری صفحات متقاطع در صدک 75 است.
  • کاربرانی که از MPA بازدید می کنند باید چندین صفحه را بازدید کنند تا سایت بتواند مزایای ذخیره سازی را که منجر به بارگذاری سریعتر صفحه می شود، دریافت کند.

از آنجایی که ارزیابی‌های Core Web Vitals صدک 75 بازدید از صفحه را در نظر می‌گیرند ، داشتن بازدیدهای بیشتر از صفحه با عملکرد خوب در مجموعه داده، این احتمال را افزایش می‌دهد که بازدید در صدک 75 توزیع در آستانه‌های توصیه شده باشد.

توجه داشته باشید که نکته مهمی که هنگام مقایسه امتیازات Core Web Vitals باید در نظر گرفته شود این است که داده ها چگونه جمع می شوند - یعنی اینکه آیا مجموعه داده در توزیع شامل همه صفحات سایت یا مبدا شما می شود یا فقط صفحه برای یک URL صفحه خاص بارگیری می شود.

هنگام جمع آوری امتیازات همه صفحات در یک مبدا، صفحات سریع منفرد می توانند صدک 75 را برای کل مبدا بهبود بخشند. با این حال، هنگام تجمیع صفحات جداگانه، امتیازات یک صفحه بر امتیازات صفحه بعدی تأثیری نخواهد داشت. به عبارت دیگر، هنگام جمع‌آوری امتیازهای یک MPA بر اساس صفحه، بارگیری سریع حافظه پنهان که در صفحه پرداخت مشاهده می‌شود، نمرات بارگیری‌های اولیه کند تجربه شده در صفحه فرود سایت را بهبود نمی‌بخشد .

می‌توانید امتیاز سایت خود را برای روش‌های مختلف تجمیع با استفاده از PageSpeed ​​Insights یا Chrome User Experience Report API بررسی کنید، که امتیازات را هم برای URLهای صفحه جداگانه و هم برای کل مبدا گزارش می‌کند.

روش دیگری که معماری SPA می تواند بر امتیازات Core Web Vitals تأثیر بگذارد، معیارهایی است که طول عمر کامل یک صفحه را در نظر می گیرند. از آنجایی که کاربرانی که از SPA ها بازدید می کنند تمایل دارند برای کل جلسه در یک "صفحه" بمانند، معیارهایی که در طول زمان انباشته می شوند می توانند در SPA ها سخت تر از MPA ها باشند.

در آوریل 2021، تغییراتی را در معیار CLS اعلام کردیم که تا حدی این مشکل را برطرف کرد. قبلاً CLS در کل طول عمر صفحه جمع می شد، در حالی که اکنون فقط در یک پنجره زمانی خاص جمع می شود - اساساً بدترین تغییرات چیدمان در یک صفحه مشخص.

با این حال، حتی با تعریف جدید CLS، SPAها هنوز در یک نقطه ضعف قرار دارند زیرا مقدار CLS پس از انتقال مسیر مانند بارگذاری کامل صفحه در MPA "تنظیم مجدد" نمی شود. این همچنین می‌تواند منجر به سردرگمی شود، زیرا تغییرات طرح‌بندی که پس از انتقال مسیر رخ می‌دهد، به URL صفحه در زمان بارگیری آن نسبت داده می‌شود، نه URL موجود در نوار آدرس در زمان تغییر ( جزئیات بیشتر در زیر ).

اگر معماری SPA تجربه کاربر را بهبود بخشد، آیا این بهبود نباید در معیارها منعکس شود؟

بله، باید. اگرچه همانطور که قبلاً ذکر شد، با توجه به روش‌های مختلفی که امروزه SPAها در وب پیاده‌سازی می‌شوند، تعیین میزان بهبود تجربه در مقیاس دشوار است.

حقیقت این است که صنعت عملکرد وب (از جمله گوگل) از لحاظ تاریخی تقریباً به اندازه خود بارگذاری صفحه، زمان و تلاش زیادی را برای توسعه معیارهای کاربر محور برای عملکرد پس از بارگذاری یک صفحه صرف نکرده است. این به این دلیل نیست که عملکرد پس از بارگذاری مهم نیست، بلکه به این دلیل است که UX و تعاملات پس از بارگذاری بسیار متنوع‌تر و کمتر تعریف شده‌اند، که طراحی معیارها را برای آنها دشوار می‌کند.

اما حتی اگر معیارهای پس از بارگذاری به خوبی برای اندازه‌گیری عملکرد SPA داشته باشیم، نمی‌خواهیم تجربه بارگذاری را صرفاً به دلیل بهتر شدن تجربه بارگذاری نادیده بگیریم.

یکی از اهداف ابتکار Web Vitals ترویج و ایجاد انگیزه برای تجربیات خوب کاربر در بسیاری از جنبه‌های بارگذاری و استفاده از یک صفحه وب است. ما نمی خواهیم سناریوهایی را تشویق کنیم که در آن تجربیات بد توجیه می شوند، اگر بتوانید به اندازه کافی تجربیات خوب برای جبران آنها داشته باشید. کاربران می‌خواهند صفحات سریع بارگذاری شوند و سریع به محتوای جدید منتقل شوند، و ما سعی کرده‌ایم معیارهایی را طراحی کنیم که به نفع این نوع تجربه‌ها باشد.

بنابراین، اگرچه درست است که یک نسخه MPA از یک سایت ممکن است در معیارهای Core Web Vitals در صدک 75 بهتر از نسخه SPA از همان سایت باشد، نسخه SPA همچنان باید تلاش کند تا آستانه "خوب" را برآورده کند. اگر نسخه SPA آستانه "خوب" را برای اکثر کاربران برآورده نکند، احتمالاً تجربه بارگذاری اولیه هنوز خوب تلقی نمی شود - حتی اگر تجربه ناوبری بعدی در صفحه عالی باشد.

در آینده قصد داریم معیارهایی را توسعه دهیم که تجربیات عالی و پس از بارگذاری را تشویق می کند، و معتقدیم این بهترین راه برای ایجاد انگیزه در SPA های با کیفیت بالا است به گونه ای که تجربه بارگذاری اولیه را به خطر نیندازد. ما قبلاً یک معیار جدید به نام Interaction to Next Paint (INP) ارائه کرده‌ایم که تأخیر تعامل را در کل چرخه عمر صفحه اندازه‌گیری می‌کند، و ما فعالانه روی سایر معیارهای پس از بارگذاری نیز کار می‌کنیم، از جمله معیارهایی که انتقال مسیر SPA را اندازه‌گیری می‌کنند ( زیر را ببینید ).

ما سایت خود را از MPA به SPA تغییر دادیم و امتیازات ما پسرفت کردند. آیا این انتظار می رود؟

بستگی دارد. دلایل متعددی وجود دارد که نشان می دهد امتیازات شما پس از یک تغییر معماری عمده تغییر می کند، اما کاهش تعداد بارهای حافظه پنهان گرم می تواند بخشی از این تغییرات را ایجاد کند.

یک راه سریع برای بررسی این است که هر دو نسخه MPA و SPA یکی از صفحات فرود خود را با Lighthouse آزمایش کنید. اگر امتیاز Lighthouse در هر یک از معیارهای Core Web Vitals برای نسخه SPA کمتر باشد، احتمالاً تجربه بارگذاری پس از به‌روزرسانی بدتر شده است.

آیا باید سایت خود را از SPA به MPA تغییر دهم تا در Core Web Vitals امتیاز بهتری کسب کنم؟

احتمالا نه. فقط در صورتی باید از SPA به MPA تغییر دهید که از پشته SPA خود راضی نیستید و دلیلی دارید که معتقد باشید MPA تجربه کاربری بهتری را ارائه می دهد.

با گذشت زمان، همانطور که معیارهای Core Web Vitals بهبود می‌یابد و بیشتر تجربه مرور کامل را پوشش می‌دهد، تیم‌هایی با SPAهای خوش ساخت که UX عالی ارائه می‌دهند باید انتظار داشته باشند که نمرات Core Web Vitals خود را منعکس کنند.

اگر امتیازات Core Web Vitals فقط برای صفحات فرود SPA گزارش شود، چگونه می توانم مشکلاتی را که در "صفحات" پس از انتقال مسیر رخ می دهد، اشکال زدایی کنم؟

ابزارهای Google که داده‌های میدانی را برای معیار Core Web Vitals گزارش می‌کنند (مانند Search Console و PageSpeed ​​Insights) داده‌های خود را از گزارش تجربه کاربر Chrome (CrUX) دریافت می‌کنند. و CrUX داده ها را بر اساس مبدا یا بر اساس URL صفحه (یعنی URL صفحه در زمان بارگذاری) جمع می کند.

به دلیل تمام دلایل ذکر شده در بالا، CrUX قادر به جمع آوری داده ها از طریق مسیر SPA نیست. با این حال، به‌عنوان مالک سایت که با معماری خود آشنا هستید، می‌توانید این را خودتان اندازه‌گیری کنید، و بسیاری از ابزارهای تحلیلی به شما امکان می‌دهند زمانی که تغییر مسیر SPA در حال رخ دادن است سیگنال دهید و داده‌های اندازه‌گیری شما را بر این اساس به‌روزرسانی می‌کنند.

هنگام اندازه‌گیری معیارهای Web Vitals با ابزار تجزیه و تحلیل، مطمئن شوید که هم URL مسیر فعلی و هم URL صفحه اصلی را اندازه‌گیری می‌کنید. این به شما امکان می‌دهد هم مشکلات فردی را که در طول چرخه عمر صفحه رخ می‌دهد اشکال‌زدایی کنید و هم بر اساس URL صفحه اصلی جمع‌آوری کنید تا با نحوه اندازه‌گیری و گزارش ابزارهای Google معیارها مطابقت داشته باشید.

برای جزئیات بیشتر و بهترین شیوه ها در مورد این موضوع، نگاه کنید به: اشکال زدایی عملکرد در زمینه .

گوگل برای اطمینان از اینکه MPA ها در مقایسه با SPA ها مزیت ناعادلانه ای ندارند، چه می کند؟

همانطور که در بالا ذکر شد، یک MPA با بهینه سازی مناسب در برخی موارد می تواند امتیازات Web Vitals بهتری را در صدک 75 گزارش کند، زیرا احتمالاً درصد بیشتری از بازدیدهای صفحه کش را خواهد داشت. برعکس، پیشرفت‌های واقعی در تجربه کاربر در SPAهای بهینه‌سازی شده در حال حاضر توسط هیچ یک از معیارهای Core Web Vitals ثبت نشده است.

در Google، ما می‌دانیم که این انگیزه‌هایی ایجاد می‌کند که به طور کامل با اهداف ابتکار Web Vitals همخوانی ندارد، و ما فعالانه به دنبال راه‌هایی برای رفع این مشکل هستیم. در حال حاضر، ما در حال بررسی دو راه حل بالقوه، یکی کوتاه مدت و دیگری طولانی مدت هستیم:

  1. بازدیدهای صفحه با مبدأ متقاطع و یکسان را به طور جداگانه ارزیابی کنید.
  2. API های جدیدی طراحی کنید که اندازه گیری SPA بهتر را ممکن می کند.

بازدیدهای صفحه با مبدأ متقاطع و یکسان را به طور جداگانه ارزیابی کنید

امروزه معیارهای Core Web Vitals همه بازدیدهای صفحه را در یک سطل جمع می‌کند—این معیارها بین بازدیدهای جدید و بازگشتی یا صفحات فرود در مقابل صفحات پرداخت یا هر نوع تجمع دیگری که وضعیت کش می‌تواند بر عملکرد تأثیر بگذارد، تفاوتی قائل نمی‌شوند.

یکی از راه‌های عادی‌سازی تفاوت‌های بین عملکرد SPA و MPA، اعمال وزن‌های متفاوت برای انواع مختلف بازدیدها، حتی با توصیه‌های آستانه کاملاً متفاوت است.

در حالی که ما قطعاً می‌خواهیم به پیاده‌سازی‌های کش مؤثر پاداش دهیم، نمی‌خواهیم پیمایش‌های سریع درون سایتی بتوانند بارهای آهسته صفحه فرود را پوشش دهند. ما همچنین نمی‌خواهیم سایت‌ها را تشویق کنیم که صفحات طولانی را به مجموعه‌ای از صفحات کوتاه‌تر تقسیم کنند، فقط به خاطر بهبود امتیازات متریک.

با ارزیابی جداگانه بازدیدهای صفحه متقاطع و منشاء مشابه، می‌توانیم اطمینان حاصل کنیم که هر دو نوع تجربه مهم هستند، بدون اینکه اجازه دهیم محبوبیت نسبی یک نوع در یک سایت معین، توزیع هر معیار خاصی را تغییر دهد.

API های جدیدی طراحی کنید که اندازه گیری SPA بهتر را ممکن می کند

راه حل دیگری که به طور فعال روی آن کار می شود (به موازات موارد بالا) یک API تاریخچه برنامه جدید است که به استانداردسازی الگوهای فعلی SPA کمک می کند و اندازه گیری و درک استفاده از SPA را در مقیاس آسان تر می کند.

App History API یک رویداد navigate جدید را معرفی می کند که دارای دو ویژگی کلیدی مخصوص اندازه گیری SPA است:

  • یک پرچم userInitiated ، که تنها در صورتی روی true تنظیم می‌شود که پیمایش از طریق کلیک روی پیوند، ارسال فرم، یا رابط کاربری عقب یا جلو مرورگر آغاز شده باشد.
  • یک متد transitionWhile() ، که به توسعه‌دهنده اجازه می‌دهد تا زمانی که کاری که برای انجام ناوبری آغاز کرده‌اند، سیگنال دهد، یک قول می‌دهد.

پرچم userInitiated را می توان برای تعیین یک نقطه شروع معنایی برای انتقال مسیر SPA استفاده کرد که نشان دهنده هدف واضح کاربر است. حل وعده transitionWhile() می تواند به مرورگر کمک کند تا رنگ ها را با انتقال مسیر خاص مرتبط کند، به طوری که ممکن است بتواند بزرگترین رنگ محتوای مربوط به آن انتقال را تعیین کند.

با تکیه بر ایده ارائه شده در بخش قبل، حتی ممکن است بتوان زمان انتقال مسیر SPA را در همان سطل به عنوان بارهای صفحه با مبدا یکسان در یک MPA جمع کرد. این هیجان انگیز است زیرا به سایتی که از MPA به SPA مهاجرت می کند اجازه می دهد تا عملاً عملکرد قبل و بعد را مقایسه کند.

البته، قبل از اینکه بدانیم آیا می‌توانیم این تصمیمات را به درستی انجام دهیم، به تحقیقات بیشتری نیاز است. اگر پیشنهاد یا بازخوردی در مورد این پیشنهادها دارید، لطفاً به web-vitals-feedback@googlegroups.com ایمیل بزنید.

افکار نهایی

Google عمیقاً متعهد به بهبود معیارهای Web Vitals است و اطمینان حاصل می کند که آنها تجربیات با کیفیت بالا را که برای کاربران مهم هستند اندازه گیری و تشویق می کنند. همانطور که گفته شد، ما تصدیق می کنیم که شکاف های اندازه گیری امروزه وجود دارد. معیارها در حال حاضر همه جنبه‌های تجربه کاربر را پوشش نمی‌دهند، اما ما فعالانه در تلاش هستیم تا این شکاف‌ها را برطرف کنیم.

علیرغم محدودیت‌های فعلی، ما معتقدیم حوزه‌هایی که معیارهای موجود ثبت می‌کنند برای سلامت و موفقیت وب حیاتی هستند و تا جایی که سایت‌ها (صرف نظر از معماری) آستانه‌های توصیه‌شده را برآورده نمی‌کنند، ما معتقدیم که فضایی برای بهبود وجود دارد. .

امیدوارم این پست به روشن کردن این موضوع پیچیده و ظریف کمک کرده باشد. مثل همیشه، اگر بازخوردی در مورد معیارهای Web Vitals فعلی یا آینده دارید، لطفاً به web-vitals-feedback@googlegroups.com ایمیل بزنید.