پاسخ به سوالات رایج در مورد SPAها، Core Web Vitals و نحوه برخورد Core Web Vitals با این موارد.
منتشر شده: ۱۴ سپتامبر ۲۰۲۱، آخرین بهروزرسانی: ۱۱ آگوست ۲۰۲۶
از زمان معرفی اولیهی طرح Web Vitals در ماه مه ۲۰۲۰، ما در تیم کروم سوالات و بازخوردهای بسیار خوبی در مورد این برنامه دریافت کردهایم.
شاید موضوعی که بیشترین سوالات را در مورد آن دریافت کردهایم، که احتمالاً سختترین سوال برای پاسخ دادن نیز هست، نحوه اندازهگیری Core Web Vitals در یک برنامه تک صفحهای (SPA) و همچنین چگونگی تأثیر معماریهای SPA بر نمرات Core Web Vitals است.
پاسخ به این سؤالات دشوار است زیرا مشکل کاملاً ظریف است، بنابراین در این پست تمام تلاش خود را میکنیم تا به رایجترین سؤالات پاسخ دهیم و تا حد امکان جزئیات و زمینه را ارائه دهیم.
قبل از پرداختن به جزئیات، لازم به ذکر است که گوگل هیچ ترجیحی در مورد معماری یا فناوری مورد استفاده برای ساخت یک سایت ندارد. ما معتقدیم که برنامههای تک صفحهای (SPA) و برنامههای چند صفحهای (MPA) هر دو قادر به ارائه تجربیات با کیفیت بالا به کاربران هستند و هدف ما از ابتکار Web Vitals ارائه معیارهایی است که تجربه را مستقل از فناوری اندازهگیری میکنند.
سوالات متداول
در ادامه به برخی از رایجترین سوالاتی که در این مورد از ما پرسیده میشود، اشاره شده است. ما خوشحال میشویم که در گروه بازخورد خود یا با طرح یک مشکل، بازخوردهای شما را برای افزودن به این سوالات متداول دریافت کنیم.
آیا معیارهای Core Web Vitals شامل انتقال مسیر SPA نیز میشوند؟
وقتی برای اولین بار معرفی شد، هر یک از معیارهای Core Web Vitals نسبت به ناوبری فعلی و سطح بالای صفحه اندازهگیری میشد. اگر یک صفحه به صورت پویا محتوای جدید را بارگذاری میکرد و URL صفحه را در نوار آدرس بهروزرسانی میکرد، هیچ تاثیری بر نحوه اندازهگیری معیارهای Core Web Vitals نداشت.
مقادیر معیارها بازنشانی نشدند و URL مرتبط با هر اندازهگیری معیار، همان URLای است که کاربر برای شروع بارگذاری صفحه به آن هدایت شده است.
کروم ۱۵۱ رابطهای برنامهنویسی کاربردی (API) جدیدی را معرفی کرد که امکان اندازهگیری Core Web Vitals را در طول انتقال مسیرهای SPA فراهم میکند. در زمان نگارش این مطلب (آگوست ۲۰۲۶)، این APIها تازه شروع به استفاده در کتابخانههای اندازهگیری مانند web-vitals ، راهحلهای RUM و ابزارهایی مانند Chrome DevTools کردهاند. کروم هنوز بازههای زمانی ادغام این موارد را در گزارش تجربه کاربری کروم (CrUX) منتشر نکرده است. علاوه بر این، موتورهای مرورگر دیگر هنوز از این APIهای جدید پشتیبانی نمیکنند و بنابراین Core Web Vitals فقط در طول بارگذاری کامل صفحه برای آن مرورگرها قابل اندازهگیری است.
چرا حل این مشکل سخت بود؟
امروزه هیچ روش استانداردی برای ساخت یک 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 در این موارد، دادهها را مبهم کرده و آنها را کمتر مفید یا نمایانگر تجربه واقعی کاربر در سایت میکند.
کار Soft Navigation با دو API جدید برای بهبود عملکرد، راه حلی برای این مشکل ارائه داده است:
-
PerformanceSoftNavigationکه زمانی را که تعامل کاربر منجر به تغییر رنگ و URL میشود، اندازهگیری میکند. ترکیب این سه مورد، صرف نظر از چارچوب مورد استفاده و برخی از تفاوتهای ذکر شده قبلی، تعریف استانداردی از "soft navigation" ارائه میدهد. این امر امکان تقسیم جدول زمانی عملکرد به "navigation"های جداگانه را فراهم میکند و امکان اندازهگیری CLS و INP را برای هر navigation فراهم میکند. -
InteractionContentfulPaintکه «رنگهای محتوایی» را پس از یک تعامل اندازهگیری میکند و امکان اندازهگیری FCP و LCP را برای این پیمایشهای نرم فراهم میکند.
ترکیب این دو API به Core Web Vitals اجازه میدهد تا هم در بارگذاری کامل صفحه و هم در پیمایشهای نرم افزاری اندازهگیری شوند.
آیا تغییرات مسیر SPA مانند بارگذاری کامل صفحه برای Core Web Vitals است؟
خیر، هنوز تفاوتهای زیادی بین این نوع پیمایشها وجود دارد که میتواند منجر به معیارهای مختلف Core Web Vital شود.
یک ناوبری نرم، محتوایی در صفحه دارد و بخشی یا تمام آن محتوا را برای نمایش «صفحه» جدید بهروزرسانی میکند. از بسیاری جهات، این شبیه به تفاوت بین بارگذاری کامل صفحه بدون کش در مقابل بارگذاری صفحهای است که برخی یا تمام منابع صفحه کش شدهاند، اما در حالت شدیدتری ممکن است برخی از محتوا رندر شوند.
در تئوری، تفاوت اصلی، پتانسیل ناوبری نرم برای بسیار سریعتر شدن خواهد بود. اما تفاوتهای ظریفتر دیگری نیز وجود دارد.
APIهای ناوبری نرم جدید فقط محتوای جدید را در نظر میگیرند. بنابراین صفحهای که <h1> و محتوای متن را بهروزرسانی میکند، اما تصویر قهرمان یکسانی را بین صفحات باقی میگذارد، اگر تصویر قهرمان را دوباره ترسیم نکرده باشد، آن را به عنوان کاندید LCP در نظر نمیگیرد. این امر منجر به تفاوتهایی در عناصر مورد استفاده برای محاسبه زمان LCP بر اساس اینکه آیا همان صفحه به عنوان بارگذاری کامل صفحه یا به عنوان یک ناوبری نرم از صفحه موجود دیگر بارگذاری میشود، خواهد شد.
به طور مشابه، INP ممکن است برای ناوبریهای نرم کمتر باشد زیرا بسیاری از جاوا اسکریپتهای مورد نیاز برای اجرای سایت از قبل بارگیری میشوند. به همین ترتیب، یک ناوبری نرم ممکن است CLS کمتر (یا بیشتری!) داشته باشد اگر همان محتوا باعث CLS در بارگذاری کامل صفحه شود اما نیازی به بارگیری یا رندر مجدد در یک ناوبری نرم نداشته باشد.
همچنین تفاوتهای اندکی در زمانی که اندازهگیریها از بارگذاری کامل صفحه (که پس از پردازش تعامل ناوبری اندازهگیری میشود) در مقابل ناوبریهای نرم (که از زمان شروع تعامل اندازهگیری میشود) گرفته میشوند، وجود دارد.
همانطور که قبلاً گفته شد، بسیاری از این تفاوتها مشابه صفحات کش نشده در مقابل صفحات کش شده هستند و مفهوم آنچه Core Web Vitals سعی در اندازهگیری آن دارد، همچنان پابرجاست. با این حال، درک این نکات ظریف هنگام بررسی مشکلات Core Web Vitals ارزشمند است.
آیا عملکرد خوب در Core Web Vitals برای SPA ها سخت تر از MPA ها است؟
هیچ چیز ذاتی در معماری SPA وجود ندارد که مانع از بارگیری سریع یک صفحه در SPA و کسب امتیاز مشابه در تمام معیارهای Core Web Vitals مانند یک صفحه مشابه در MPA شود.
با این حال، MPA های بهینه شده به درستی، مزایایی در برآورده کردن آستانههای Core Web Vitals دارند که SPA ها ندارند. این مشکل تا حد زیادی با کار ناوبری نرم که قبلاً مورد بحث قرار گرفت، کاهش یافته است، اما ممکن است هنوز هم زمانی که این API های جدید هنوز استفاده نشدهاند، وجود داشته باشد. دلیل آن این است که با معماری MPA، هر "صفحه" به عنوان یک ناوبری تمام صفحه بارگذاری میشود (به جای اینکه محتوا را به صورت پویا دریافت کرده و در صفحه موجود قرار دهد)، به این معنی که کاربرانی که از MPA بازدید میکنند، بیشتر احتمال دارد بیش از یک صفحه از سایت را بارگذاری کنند، که به نوبه خود به این معنی است که درصد بیشتری از توزیع کل بارگذاری صفحات برای MPA شامل ذخیره برخی یا تمام منابع فرعی خواهد بود.
البته، برای اینکه یک MPA در معیارهای Core Web Vitals عملکرد بهتری نسبت به یک SPA داشته باشد، باید چند نکته رعایت شود:
- MPA باید ذخیرهسازی زیرمنبع بهینهشدهای داشته باشد تا اطمینان حاصل شود که بارگذاری صفحات با مبدأ یکسان، در صدک ۷۵، واقعاً سریعتر از بارگذاری صفحات با مبدأ متفاوت است.
- کاربرانی که از MPAها بازدید میکنند، باید از چندین صفحه بازدید کنند تا سایت بتواند از مزایای ذخیرهسازی که منجر به بارگذاری سریعتر صفحات میشود، بهرهمند شود.
از آنجایی که ارزیابیهای Core Web Vitals صدک ۷۵ بازدید از صفحات را در نظر میگیرند ، داشتن بازدیدهای بیشتر و با عملکرد خوب از صفحات در مجموعه دادهها، احتمال اینکه بازدید در صدک ۷۵ توزیع در محدوده آستانههای توصیه شده باشد را افزایش میدهد.
توجه داشته باشید که نکته مهمی که هنگام مقایسه نمرات Core Web Vitals باید در نظر بگیرید، نحوه تجمیع دادهها است - یعنی اینکه آیا مجموعه دادهها در توزیع شامل تمام صفحات سایت یا مبدا شما میشود یا فقط بارگذاری صفحه برای یک URL خاص.
هنگام تجمیع امتیازات تمام صفحات یک مبدأ، صفحات سریع منفرد میتوانند ۷۵ درصد کل مبدأ را بهبود بخشند. با این حال، هنگام تجمیع امتیازات بر اساس صفحات منفرد، امتیازات یک صفحه بر امتیازات صفحه بعدی تأثیری نخواهد گذاشت. به عبارت دیگر، هنگام تجمیع امتیازات یک MPA بر اساس صفحه، بارگذاریهای سریع کش مشاهده شده در صفحه پرداخت، امتیازات بارگذاریهای اولیه کند تجربه شده در صفحه فرود سایت را بهبود نمیبخشند .
شما میتوانید امتیاز سایت خود را برای روشهای مختلف تجمیع با استفاده از PageSpeed Insights یا Chrome User Experience Report API بررسی کنید، که امتیازها را هم برای URLهای تک تک صفحات و هم برای کل مبدا گزارش میدهد.
یکی دیگر از راههایی که معماری SPA میتواند بر نمرات Core Web Vitals تأثیر بگذارد، معیارهایی است که طول عمر کامل یک صفحه را در نظر میگیرند. از آنجایی که کاربرانی که از SPAها بازدید میکنند، تمایل دارند در کل جلسه در همان "صفحه" بمانند، معیارهایی که با گذشت زمان جمع میشوند، میتوانند در SPAها نسبت به MPAها شدیدتر باشند.
با کار ناوبریهای نرم، ما معتقدیم که از نظر نحوه اندازهگیری Core Web Vitals، نباید هیچ نقصی در SPAها وجود داشته باشد. با این حال، ادغام کامل این APIها در تمام راهحلهای ابزار و گزارشدهی زمانبر خواهد بود.
اگر معماریهای SPA تجربه کاربری را بهبود میبخشند، آیا این بهبود نباید در معیارها منعکس شود؟
بله، باید همینطور باشد. با توجه به روشهای مختلفی که امروزه SPAها در وب پیادهسازی میشوند، تعیین میزان بهبود تجربه کاربری در مقیاس بزرگ دشوار بود. اکنون ما یک راهحل برای مشکل اندازهگیری داریم و وقتی از این APIهای جدید استفاده میشود، هرگونه پیشرفت ناشی از انتقال به SPAها باید در معیارها منعکس شود.
حقیقت این است که صنعت عملکرد وب (از جمله گوگل) از نظر تاریخی، به اندازهای که برای خود بارگذاری صفحه زمان و تلاش صرف کرده، برای توسعه معیارهای کاربرمحور برای عملکرد پس از بارگذاری یک صفحه، زمان و تلاش صرف نکرده است. این به این دلیل نیست که عملکرد پس از بارگذاری مهم نیست، بلکه به این دلیل است که تجربه کاربری و تعاملات پس از بارگذاری بسیار متنوعتر و کمتر تعریفشده هستند - که طراحی معیارها برای آنها را دشوار میکند.
اما حتی اکنون که معیارهای بیشتری پس از بارگذاری برای اندازهگیری عملکرد SPA داریم، نمیخواهیم تجربه بارگذاری را صرفاً به این دلیل که تجربه بارگذاری پس از بارگذاری بهتر شده است، نادیده بگیریم.
یکی از اهداف ابتکار Web Vitals، ترویج و تشویق تجربیات خوب کاربری در تمام جنبههای بارگذاری و استفاده از یک صفحه وب است. ما نمیخواهیم سناریوهایی را تشویق کنیم که در آنها تجربیات بد توجیهپذیر باشند، اگر بتوانید تجربیات خوب کافی برای جبران آنها داشته باشید. کاربران میخواهند صفحات سریع بارگذاری شوند و به سرعت به محتوای جدید منتقل شوند و ما سعی کردهایم معیارهایی را طراحی کنیم که از این نوع تجربیات حمایت کنند.
ما سایت خود را از MPA به SPA تغییر دادیم و امتیازات ما کاهش یافت. آیا این مورد قابل انتظار بود؟
بستگی دارد. دلایل زیادی وجود دارد که چرا امتیازات شما میتواند پس از یک مهاجرت بزرگ معماری تغییر کند، اما کاهش تعداد بارگذاریهای حافظه نهان گرم میتواند بخشی از این تغییر را توجیه کند.
یک راه سریع برای بررسی این است که هر دو نسخه MPA و SPA یکی از صفحات فرود خود را با Lighthouse آزمایش کنید. اگر امتیاز Lighthouse در هر یک از معیارهای Core Web Vitals برای نسخه SPA کمتر باشد، احتمالاً تجربه بارگذاری پس از بهروزرسانی بدتر شده است.
آیا باید سایتم را از SPA به MPA تغییر دهم تا در Core Web Vitals امتیاز بهتری کسب کنم؟
احتمالاً نه. شما فقط در صورتی باید از SPA به MPA تغییر دهید که از مجموعه SPA خود راضی نیستید و دلیلی دارید که باور کنید MPA تجربه کاربری بهتری را ارائه میدهد.
با کار ناوبری نرم، معتقدیم که مشکلات اندازهگیری را برطرف کردهایم، بنابراین جابجایی صرفاً به این دلیل منطقی نیست.
با این حال، اگر دلیلی دارید که نشان دهید عملکرد بهبود مییابد، نه فقط اندازهگیریها، آنگاه این میتواند دلیلی برای انتقال از SPA به MPA (یا برعکس!) باشد.
اگر نمرات Core Web Vitals فقط برای صفحات فرود یک SPA گزارش شود، چگونه میتوانم مشکلاتی را که در "صفحات" پس از انتقال مسیر رخ میدهد، اشکالزدایی کنم؟
ابزارهای گوگل که دادههای میدانی را برای معیار Core Web Vitals گزارش میدهند (مانند Search Console و PageSpeed Insights)، دادههای خود را از گزارش تجربه کاربری کروم (CrUX) دریافت میکنند. و CrUX دادهها را یا بر اساس مبدا یا بر اساس URL صفحه (یعنی URL صفحه در زمان بارگذاری) جمعآوری میکند.
ما در حال کار بر روی این هستیم که به CrUX اجازه دهیم دادهها را از طریق مسیر SPA در دادههای تجمیعشده خود لحاظ کند. با این حال، به عنوان صاحب سایت، اکنون میتوانید از APIهای جدید برای اندازهگیری Core Web Vitals از طریق مسیر SPA قبل از این کار استفاده کنید تا بفهمید که چگونه نمرات شما ممکن است تغییر کند.
برای جزئیات بیشتر و بهترین شیوهها در این مورد، به بخش اندازهگیری پیمایشهای نرم مراجعه کنید.
گوگل چه کاری انجام میدهد تا مطمئن شود که MPAها در مقایسه با SPAها مزیت ناعادلانهای ندارند؟
همانطور که قبلاً ذکر شد، با کار پیمایشهای نرم، معتقدیم کاری که اکنون انجام دادهایم به این معنی است که نباید هیچ نقصی برای SPAها در این زمینه وجود داشته باشد، اگرچه ادغام کامل در تمام راهحلهای ابزار و گزارشدهی زمان میبرد.
بازدیدهای صفحههای با مبدا مشترک و متقابل را جداگانه ارزیابی کنید
امروزه معیارهای Core Web Vitals تمام بازدیدهای صفحه را در یک سطل واحد جمع میکنند - آنها بین بازدیدهای جدید در مقابل بازدیدهای برگشتی یا صفحات فرود در مقابل صفحات پرداخت یا هر نوع تجمیع دیگری که وضعیت حافظه پنهان میتواند بر عملکرد تأثیر بگذارد، تفاوتی قائل نمیشوند.
یک راه برای عادیسازی تفاوتهای بین عملکرد SPA و MPA، اعمال وزندهی متفاوت به انواع مختلف بازدیدها، حتی با توصیههای آستانه کاملاً متفاوت، است.
اگرچه ما قطعاً میخواهیم به پیادهسازیهای مؤثر حافظه پنهان پاداش دهیم، اما نمیخواهیم پیمایشهای سریع درون سایتی بتوانند بارگذاری کند صفحات فرود را بپوشانند. همچنین نمیخواهیم سایتها را تشویق کنیم که صفحات طولانی را صرفاً به خاطر بهبود امتیازهای معیار، به مجموعهای از صفحات کوتاهتر تقسیم کنند.
با ارزیابی جداگانه بازدیدهای صفحات با منشأ متقابل و یکسان، میتوانیم اطمینان حاصل کنیم که هر دو نوع تجربه مهم هستند، بدون اینکه اجازه دهیم محبوبیت نسبی یک نوع در یک سایت خاص، توزیع هر معیار خاصی را تحت تأثیر قرار دهد.
افکار نهایی
گوگل عمیقاً متعهد به بهبود معیارهای Web Vitals و حصول اطمینان از اندازهگیری و تشویق تجربیات باکیفیتی است که برای کاربران مهم هستند. با این اوصاف، ما اذعان داریم که امروزه شکافهای اندازهگیری وجود دارد. این معیارها اکنون میتوانند انتقال مسیر SPA را پوشش دهند که یکی از شکافهای اصلی را برطرف میکند.
ما همچنین معتقدیم که این APIهای جدید (بهویژه InteractionContentfulPaint ) کاربردها و مزایای بالقوه بیشتری فراتر از اندازهگیری Core Web Vitals برای پیمایشهای نرم دارند. اکنون که دلیل اصلی معرفی آنها مشخص شده است، بسیار هیجانزدهایم که به توسعه آنها ادامه دهیم.
امیدوارم این پست به روشن شدن این موضوع پیچیده و ظریف کمک کرده باشد. مثل همیشه، اگر در مورد معیارهای فعلی یا آینده Web Vitals بازخوردی دارید، به آدرس web-vitals-feedback@googlegroups.com ایمیل بزنید.