بهبود Core Web Vitals در صفحه اصلی Mail.ru منجر به افزایش میانگین 10٪ در نرخ تبدیل شد.

چندین ماه کار برای بهبود Core Web Vitals در صفحه اصلی Mail.ru منجر به افزایش 60 درصدی در صدک 75 در تغییر چیدمان تجمعی (CLS) شد که میانگین زمان جلسه را 2.7 درصد و نرخ تبدیل بخش‌های اصلی را افزایش داد. بیش از 10 درصد

Denis Stasyev

Sven May

از جایی که شروع کردیم

Mail.ru یکی از خدمات پست الکترونیکی پیشرو در اینترنت روسی زبان است و از نظر ترافیک در 5 سایت برتر روسیه قرار دارد. Mail.ru یک منبع مهم برای بسیاری از مردم است. چند صد میلیون بازدیدکننده در ماه دریافت می‌کند و درگاهی است که از آن مردم می‌توانند به ایمیل، اخبار، رسانه‌های اجتماعی، جستجوهای اینترنتی عملکرد و موارد دیگر دسترسی داشته باشند.

Mail.ru می خواست تجربه کاربری با کیفیت بالایی را برای بازدیدکنندگان خود فراهم کند، بنابراین کار برای بهبود Core Web Vitals آغاز شد. قبل از بحث در مورد استراتژی بهینه سازی، ابتدا باید به چند جزئیات فنی صفحه اصلی Mail.ru اشاره کرد.

اگرچه این پروژه برای مدت طولانی با استفاده از موتور قالب داخلی Fest توسعه داده شده بود، ما در سال 2019 شروع به مهاجرت به Svelte 3 کردیم.

توجه: می‌توانید درباره Fest و دلایل ما برای تغییر پشته فناوری به Svelte در ارائه تیم ما در Svelte Russia Meetup شماره 1 اطلاعات بیشتری کسب کنید.

Svelte واکنش‌پذیری را به گونه‌ای پیاده‌سازی می‌کند که از Virtual DOM استفاده نمی‌کند ، که باعث می‌شود کمتر به منابع نیاز داشته باشد. رویکرد Svelte توابع استفاده نشده را از بسته‌های تولید حذف می‌کند زیرا در صورت عدم استفاده از توابع، کد پیاده‌سازی‌کننده آن‌ها توسط کامپایلر تولید نمی‌شود. کدهای استفاده نشده در حین کامپایل حذف می شوند و در نتیجه بسته های کوچکتری ایجاد می شود. این ممکن است به کاهش زمان مسدود کردن کل (TBT) در هنگام راه‌اندازی صفحه کمک کند.

ردیابی معیارهای عملکرد

قبل از بهینه سازی Core Web Vitals، ارزیابی عملکرد در این زمینه مفید است. قبل از Core Web Vitals، معیارهای دیگری مانند First Contentful Paint (FCP) را در داشبورد عملکرد داخلی خود ردیابی کردیم.

اسکریپت مجموعه معیارهای ما برای جمع‌آوری Core Web Vitals و انتقال آنها به داشبورد عملکرد ما برای تجسم اصلاح شد. مطابق با توصیه‌های Google، اسکریپت ما از PerformanceObserver API برای به دست آوردن معیارها استفاده می‌کند، که بخشی از "پلتفرم" جهانی در Mail.ru است.

داشبورد معیارهای زیر را برای کاربران نمایش داد (مقادیر میانگین برای هفته 15 تا 21 مارس 2021):

معیارهای هفته 15 تا 21 مارس 2021

نام گروه متریک		Core Web Vitals			سایر موارد حیاتی وب
نام متریک		LCP	FID	CLS	FCP	TBT	TTI
سهم کاربران مطابق با آستانه های Core Web Vitals	خوب	52%	92%	33%	35%	42%	43%
	به بهبود نیاز دارد	19%	5%	23%	38%	16%	25%
	فقیر	29%	3%	44%	27%	42%	32%

ارزش Web Vitals قبل از بهبود.

بهبود Core Web Vitals

در حالی که راهنمایی های زیادی برای بهبود Core Web Vitals وجود دارد، هر پروژه دارای چالش های منحصر به فردی است. برای صفحه اصلی Mail.ru، فرصت های زیر شناسایی شد:

• پیاده سازی متغیرهایی برای بنرهای تبلیغاتی برای کاهش CLS .
• استفاده از رندر سمت سرور (SSR) برای کاهش بزرگترین رنگ محتوایی (LCP) .
• تقسیم کد برای کاهش LCP و تاخیر ورودی اول (FID) .

اسکلت برای بهبود CLS

CLS یکی از بدترین معیارهای میدانی برای صفحه اصلی Mail.ru بود. نمایه سازی بعدی این صفحه در پنل عملکرد ابزارهای توسعه کروم نشان داد که تبلیغات منشا این مشکل هستند. برای بهبود پایداری طرح‌بندی، تیم ما تصمیم گرفت از متغیرهایی برای رزرو فضا برای تبلیغات قبل از بارگیری استفاده کند.

هنگام پیاده سازی متغیرهای مکان، اولین قدم تعیین ابعاد محتوایی است که جایگزین آنها می شود. خوشبختانه، نسخه دسکتاپ صفحه اصلی Mail.ru دارای اندازه های کاملاً مستند برای تبلیغات است. پس از صحبت با تیم طراحی، از اسکلت‌های UI متحرک SVG به عنوان مکان‌نما استفاده شد زیرا زمان بارگذاری درک شده محتوا را کاهش می‌دهد .

احتیاط: انیمیشن های SVG در اینترنت اکسپلورر 11 پشتیبانی نمی شوند، اگر پشتیبانی مرورگر قدیمی برای برنامه شما ضروری است، از CSS استفاده کنید.

بازگشت SSR

برای سهولت انتقال از Fest به Svelte، ما به‌جای شروع مجدد، پروژه موجود را به‌صورت تدریجی بازنویسی کردیم. تا مارس 2021، ما بیشتر قسمت جلویی را به Svelte منتقل کردیم و در نهایت SSR را پس از تریاژ و رفع مشکلات عملکرد باطن به برنامه تولید خود آوردیم.

توجه: SSR برای کل برنامه مورد استفاده قرار نگرفت، زیرا ممکن است فرآیند گران قیمتی باشد که می‌تواند زمان تا اولین بایت (TTFB) را به تاخیر بیندازد، که ممکن است بر LCP تأثیر بگذارد . ما تصمیم گرفتیم از SSR برای محتوای مهمی که کاربر در رندر اولیه می بیند استفاده کنیم و رندر محتوای مخفی را بر روی مشتری بارگذاری کنیم. در حال حاضر، Mail.ru در حال آزمایش با Islands Architecture است تا ببیند آیا می‌توان عملکرد بیشتری داشت یا خیر.

پس از اجرای SSR، تیم علت رگرسیون CLS را کشف کرد که در ابتدا مورد توجه قرار نگرفت: بخش اخبار در لحظه ارائه اولین محتوا در صفحه درج نشده بود. بین نقاشی اولیه نشانه گذاری صفحه ارائه شده توسط سرور و درج بخش اخبار روی مشتری تاخیر وجود داشت. این رفتار منجر به تغییر اسکلت تبلیغاتی شد که CLS را بدتر کرد.

اگرچه DevTools کروم رویدادهای Layout Shift را نشان می داد، اما در ابتدا نتوانستیم دلیل آن را پیدا کنیم. اگرچه خود SSR مشکلی نبود، اما بعداً به کشف راه حل کمک کرد. رفع کد مسئول تاخیر نقاشی، پایداری طرح‌بندی مولفه خبری را بهبود بخشید.

یافتن مشکل نقاشی خبری با جاوا اسکریپت غیرفعال است.

رفع مشکل نقاشی خبری با غیرفعال شدن جاوا اسکریپت.

اثر دیگری که SSR می تواند بر CLS داشته باشد، حرکت اجزاء قبل و بعد از هیدراتاسیون است که می تواند منجر به تغییرات بیشتر در چیدمان شود. ما به ویژه در نسخه موبایل با این مورد مواجه شدیم و نیاز به توجه ویژه به نشانه گذاری اجزای هیدراته داشت. یک راه حل خوب برای این مشکل، انتقال هر چه بیشتر منطق نمایش از جاوا اسکریپت به CSS در صورت امکان بود.

تقسیم کد و پلی پرهای استفاده نشده

برای بهبود سرعت بارگذاری صفحه درک شده، کار برای کاهش مقادیر LCP و FID لازم بود. یکی از راه‌های رسیدن به این هدف، تقسیم کد است. علاوه بر خود صفحه اصلی Mail.ru، تیم ما در حال توسعه یک ویجت برای ناوبری پورتال است. در حال حاضر در بسیاری از پروژه های شرکت ما تعبیه شده است.

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

ما تصمیم گرفتیم که الگوی module / nomodule را برای بارگیری بسته‌های جاوا اسکریپت برای مرورگرهای مدرن یا قدیمی مخالفت کنیم، زیرا ویژگی <script> عنصر type="module" مرورگرهایی را هدف قرار نمی‌دهد که به اندازه کافی مدرن برای نیازهای ما هستند. برای رفع این مشکل، Mail.ru از یک ابزار داخلی برای شناسایی نسخه‌های مرورگر مدرن در باطن استفاده می‌کند و می‌تواند بر این اساس با آن مرورگرها سازگار شود.

توجه: بسته Useragent مرورگرها یک جایگزین در دسترس عموم برای ابزار سفارشی برای مقایسه .browserslistrc پروژه با رشته User-Agent در یک برنامه کاربردی است. با این حال، تیم ما قویاً توصیه می‌کند که از راهنمایی‌های کاربر-عامل مشتری استفاده کنید (به عنوان مثال، هدر Sec-CH-UA ، همانطور که Mail.ru در ابزار داخلی ما انجام می‌دهد.

هنگامی که مرورگرها در backend شناسایی شدند، ما تقسیم کد را برای مرورگرهای مدرن و قدیمی پیاده سازی کردیم. نتیجه کاهش 43.3 درصدی در اندازه ویجت جاوا اسکریپت بارگذاری شده همزمان برای مرورگرهای مدرن بود. این عمل برای برخی از اسکریپت های پورتال دیگر نیز اعمال شده است.

علاوه بر کاهش اندازه بسته نرم افزاری و اثرات مثبت بر Core Web Vitals، تقسیم کد تجربه توسعه دهنده را نیز بهبود می بخشد. تنها 3.5 درصد از کاربران ما از مرورگرهای قدیمی استفاده می‌کنند و این سهم در روند نزولی قرار دارد، بنابراین اجرای تقسیم کد به توسعه‌دهندگان ما اجازه می‌دهد تا از آخرین API مرورگرها بدون معرفی polyfill bloat لازم برای مرورگرهای قدیمی به همه کاربران استفاده کنند.

نتایج

پس از تلاش بهینه‌سازی، مقادیر میانگین را برای هفته 24 تا 30 مه 2021 در داده‌های میدانی خود مشاهده کردیم:

معیارها برای هفته 24-30 مارس 2021

نام گروه متریک		Core Web Vitals			سایر موارد حیاتی وب
نام متریک		LCP	FID	CLS	FCP	TBT	TTI
سهم کاربران مطابق با آستانه های Core Web Vitals	خوب	58% (6+%)	93% (+1%)	93% (+60%)	43% (+8%)	49% (7+%)	51% (+8%)
	به بهبود نیاز دارد	18%	4%	3%	34%	17%	24%
	فقیر	24%	3%	4%	23%	34%	25%

مقایسه Web Vitals قبل و بعد (تغییر در گروه "خوب" در پرانتز نشان داده شده است).

نمودارهای زیر تغییرات در مقادیر معیارهای عملکرد صفحه وب را با توجه به "پلتفرم" نشان می دهد. به دو تاریخ مهم در نمودار توجه کنید:

• 23 مارس 2021: انتشار تکرار با آخرین بخش‌های صفحه به Svelte منتقل شد.
• 19 آوریل 2021: انتشار تکرار با SSR برگشتی و چیدمان اصلاح شده برای اصلاح رگرسیون CLS.

کاهش مقادیر از 1 می تا 10 می به دلیل تعطیلات ماه می در روسیه است.

نمودار LCP در "پلتفرم": 16 مارس تا 1 ژوئن 2021.

نمودار FID در "پلتفرم": 16 مارس تا 1 ژوئن 2021.

نمودار CLS در "پلتفرم": 16 مارس تا 1 ژوئن 2021.

نتایج به‌دست‌آمده با استفاده از «پلتفرم» مطابق با رشد مقادیر متریک در گزارش Chrome UX (CrUX) است.

تغییر متریک LCP در CrUX در سال 2021.

تغییر متریک FID در CrUX در سال 2021.

تغییر متریک CLS در CrUX در سال 2021.

مقایسه مقادیر میانگین مدت زمان جلسه کاربر یک هفته قبل از عرضه بهبودهای اولیه و یک هفته پس از عرضه، رشد 2.7 درصدی را نشان می دهد. علاوه بر این، به طور کلی افزایش قابل توجهی در تبدیل در بیشتر بخش های صفحه وجود دارد. به ویژه، تبدیل به برنامه ایمیل Mail.ru 11.6٪ افزایش یافته است، تبدیل بخش اخبار 13.5٪ افزایش یافته است.

181 _%

افزایش سهم آستانه CLS خوب

2.7 _٪

میانگین مدت جلسه بالاتر

13.5 _٪

افزایش نرخ تبدیل بخش اخبار

غیرمنتظره ترین نتیجه ما افزایش 17.4 درصدی در نرخ کلیک (CTR) بنر بازاریابی بود (زمان رندر آن به طور قابل توجهی با معرفی برچسب های SSR و پیش بارگذاری کاهش یافت).

توجه: یک پیامد ناخواسته کار ما این بود که شاهد کاهش نرخ تبدیل برخی از بخش‌های صفحه بودیم. بخش جستجو به طور خاص شاهد کاهش 6.7٪ بود. تیم ما این موضوع را با تغییر در رندر صفحه مرتبط می‌داند، زیرا قبلاً این مؤلفه یکی از اولین مواردی بود که رندر می‌شد. ما توانستیم با معرفی ویژگی‌های محصول جدید در این بخش، این کاهش را معکوس کنیم.

پس از تجزیه و تحلیل بقیه بخش های صفحه، ما متوجه بهبود عملکرد قابل توجهی در اکثریت قریب به اتفاق آنها شدیم. حتی برای بخش هایی مانند آب و هوا و کرونا - که در صفحه ما کلیدی نیستند - به ترتیب شاهد افزایش 9.6٪ و 9.5٪ در تبدیل هستیم.

نتیجه

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

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