بهبود 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 کردیم.

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):

بهبود Core Web Vitals

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

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

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

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

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

بازگشت SSR

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

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

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

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

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

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

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

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

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

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

نتایج

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

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

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

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

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

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

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

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

نتیجه

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

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