بهبود تغییر چیدمان تجمعی در گروه رسانه ای تلگراف

در عرض چند ماه وب‌سایت خبری پیشرو بریتانیا موفق شد CLS صدک 75 خود را تا 250% از 0.25 به 0.1 بهبود بخشد.

Chris Boakes

توجه: کریس یک مهندس نرم افزار اصلی در تلگراف است.

چالش ثبات بصری

تغییر چیدمان می تواند بسیار مخرب باشد. در گروه رسانه تلگراف (TMG) ثبات بصری به ویژه مهم است زیرا خوانندگان عمدتاً از برنامه های ما برای مصرف اخبار استفاده می کنند. اگر در حین خواندن مقاله، چیدمان تغییر کند، احتمالاً خواننده جایگاه خود را از دست خواهد داد. این می تواند یک تجربه خسته کننده و منحرف کننده باشد.

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

در TMG، ما تیم‌های متعددی داریم که در سمت مشتری کد مشارکت می‌کنند:

• مهندسی هسته. پیاده سازی راه حل های شخص ثالث برای حوزه های قدرتمند مانند توصیه های محتوا و اظهار نظر.
• بازار یابی. اجرای تست های A/B برای ارزیابی نحوه تعامل خوانندگان ما با ویژگی ها یا تغییرات جدید.
• تبلیغات. مدیریت درخواست‌های آگهی و پیش‌مناقصه آگهی.
• سرمقاله. جاسازی کد در مقالاتی مانند توییت ها یا ویدیوها، و همچنین ویجت های سفارشی (به عنوان مثال، ردیاب پرونده کرونا).

اطمینان از اینکه هر یک از این تیم ها باعث ایجاد تکان در چیدمان صفحه نمی شود می تواند دشوار باشد. با استفاده از متریک تغییر چیدمان تجمعی برای اندازه‌گیری تعداد دفعات وقوع آن برای خوانندگان ما، تیم‌ها بینش بیشتری نسبت به تجربه واقعی کاربر و یک هدف واضح برای تلاش پیدا کردند. این منجر به بهبود صدک 75 CLS ما از 0.25 به 0.1 و رشد سطل عبور ما از 57٪ به 72٪ شد.

250 _%

بهبود صدک 75 CLS

15 _درصد

کاربران بیشتری با امتیاز CLS خوب

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

با استفاده از داشبوردهای CrUX توانستیم ثابت کنیم که صفحات ما بیشتر از آنچه می‌خواهیم تغییر می‌کنند.

نمرات تغییر چیدمان تجمعی ما بین ژوئن 2020 و فوریه 2021.

ما در حالت ایده‌آل می‌خواستیم حداقل ۷۵ درصد از خوانندگان ما یک تجربه «خوب» داشته باشند، بنابراین شروع به شناسایی علل بی‌ثباتی طرح‌بندی کردیم.

نحوه اندازه گیری تغییرات چیدمان

ما از ترکیبی از Chrome DevTools و WebPageTest استفاده کردیم تا تشخیص دهیم چه چیزی باعث تغییر طرح‌بندی شده است. در DevTools، از بخش Experience در برگه Performance برای برجسته کردن نمونه‌های فردی تغییر طرح و نحوه کمک آنها به امتیاز کلی استفاده کردیم.

شناسایی تغییر چیدمان ناشی از بارگیری آگهی در سمت سرویس گیرنده بالای سرصفحه با استفاده از بخش تجربه در ابزارهای توسعه دهنده Chrome.

WebPageTest هنگامی که "Highlight Layout Shifts" انتخاب می شود، به طور مفید جایی که تغییر طرح در نمای جدول زمانی رخ می دهد، برجسته می کند.

WebPageTest برجسته کردن جایی که طرح بندی تغییر کرده است.

پس از بررسی هر تغییر در قالب‌های پربازدیدمان، به فهرستی از ایده‌هایی رسیدیم که چگونه می‌توانیم پیشرفت کنیم.

کاهش تغییرات چیدمان

ما روی چهار حوزه تمرکز کردیم که می‌توانیم تغییرات طرح‌بندی را کاهش دهیم: - تبلیغات - تصاویر - هدرها - جاسازی‌ها

تبلیغات

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

بلوک "داستان های بیشتر" در زیر آگهی پس از بارگیری آگهی به پایین منتقل می شود.

اگرچه ارتفاع دقیق آن را نمی دانیم، می توانیم با استفاده از رایج ترین اندازه آگهی بارگذاری شده در اسلات، فضا را رزرو کنیم.

با رزرو فضا برای آگهی، بلوک «داستان‌های بیشتر» زیر قبل و بعد از بارگیری آگهی ثابت می‌ماند.

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

شکاف آگهی پس از بارگیری برای خوانندگان در دستگاه های اندازه رایانه لوحی از بین می رود.

ما شکاف را دوباره بررسی کردیم و ارتفاع را برای استفاده از رایج ترین اندازه تنظیم کردیم.

حصول اطمینان از اینکه فضایی که برای جایگاه آگهی در نظر گرفته‌ایم با متداول‌ترین ارتفاع آگهی مطابقت دارد.

تصاویر

بسیاری از تصاویر در سرتاسر وب سایت تنبل بارگذاری می شوند و فضای خود را برای آنها در نظر گرفته اند.

بارگذاری تنبل تصاویر بدون ایجاد اختلال در طرح.

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

تغییر چیدمان ناشی از تصویر اصلی مقاله.

به سادگی افزودن ویژگی های عرض و ارتفاع به تصاویر تضمین می کند که چیدمان تغییر نمی کند.

بارگیری تصویر مقاله اصلی بدون تغییر طرح.

سرتیتر

هدر زیر محتوای نشانه گذاری بود و با استفاده از CSS در بالای صفحه قرار می گرفت. ایده اصلی این بود که بارگذاری محتوا قبل از ناوبری اولویت بندی شود، اما این باعث شد که صفحه به طور لحظه ای جابجا شود.

هدر صفحه در حال بارگذاری نامناسب.

انتقال هدر به بالای نشانه گذاری به صفحه اجازه می دهد بدون این تغییر رندر شود.

طرح بندی دیگر با هدر بارگذاری صفحه مختل نمی شود.

جاسازی می کند

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

در حین بارگیری پخش‌کننده ویدیو، شکاف پخش‌کننده ویدیو یک تصویر کوچک با وضوح پایین بارگیری می‌کند.

اندازه گیری تاثیر

ما توانستیم به راحتی با استفاده از ابزار ذکر شده در ابتدای مقاله، تأثیر را در سطح ویژگی اندازه گیری کنیم. با این حال ما می خواستیم CLS را هم در سطح قالب و هم در سطح سایت اندازه گیری کنیم. به طور مصنوعی، ما از SpeedCurve برای تأیید تغییرات در پیش تولید و تولید استفاده کردیم.

ردیابی پیشرفت CLS به صورت مصنوعی با استفاده از SpeedCurve.

پس از اینکه کد به تولید رسید، می‌توانیم نتایج را در داده‌های RUM خود (ارائه شده توسط mPulse ) تأیید کنیم.

اعتبار سنجی بهبودهای CLS در سراسر سایت با داده های RUM mPulse قبل و بعد از ایجاد تغییرات.

بررسی داده‌های RUM سطح خوبی از اطمینان را به ما می‌دهد که تغییراتی که ایجاد می‌کنیم تأثیر مثبتی برای خوانندگان ما دارد.

اعداد نهایی که بررسی کردیم مربوط به داده های RUM است که گوگل جمع آوری می کند. این به ویژه در حال حاضر مرتبط است زیرا آنها به زودی بر رتبه بندی صفحه تأثیر خواهند گذاشت . برای شروع، از گزارش Chrome UX استفاده کردیم، هم در داده‌های سطح مبدأ ماهانه موجود از طریق داشبورد CrUX ، و هم با جستجوی BigQuery برای بازیابی داده‌های تاریخی p75. به این ترتیب ما به راحتی می‌توانستیم ببینیم که برای تمام ترافیک اندازه‌گیری شده توسط CrUX، صدک ۷۵ CLS ما ۲۵۰ درصد از ۰.۲۵ به ۰.۱ بهبود یافته و سطل عبور ما از ۵۷ درصد به ۷۲ درصد افزایش یافته است .

نتایج از داشبورد Crux.

BigQuery با نمایش مقادیر p75 از سال 2021 تا به امروز اجرا می شود.

علاوه بر این، ما توانستیم از Chrome UX Report API استفاده کنیم و داشبوردهای داخلی را به قالب‌هایی تقسیم کنیم.

داشبوردهای داخلی با استفاده از Chrome UX Report API که میانگین امتیاز ما و بدترین عملکرد صفحات را با استفاده از آن الگو برجسته می‌کند.

اجتناب از رگرسیون CLS

یکی از جنبه های مهم ایجاد بهبود عملکرد، اجتناب از رگرسیون است. ما برخی از بودجه‌های عملکرد پایه را برای معیارهای کلیدی خود تنظیم کرده‌ایم و CLS را در آن گنجانده‌ایم.

داشبورد بودجه عملکردی که چک‌های مصنوعی اندازه‌گیری CLS را در برخی از الگوهای پرترافیک ما نشان می‌دهد. بودجه در حال حاضر 0.025 تعیین شده است.

اگر تست بیش از بودجه باشد، پیامی به یک کانال Slack ارسال می‌کند تا بتوانیم علت را بررسی کنیم. ما همچنین گزارش‌های هفتگی را تنظیم کرده‌ایم، به طوری که حتی اگر الگوها در بودجه باقی بمانند، از تغییراتی که تأثیر منفی داشته است آگاه باشیم.

ما همچنین در حال برنامه ریزی برای گسترش بودجه خود برای استفاده از داده های RUM و همچنین داده های مصنوعی، با استفاده از mPulse برای تنظیم هشدارهای استاتیک و تشخیص ناهنجاری بالقوه هستیم که ما را از هرگونه تغییر غیرعادی آگاه می کند.

برای ما مهم است که با در نظر گرفتن CLS به ویژگی های جدید نزدیک شویم. بسیاری از تغییراتی که ذکر کردم، تغییراتی هستند که باید پس از انتشار برای خوانندگانمان اصلاح می‌کردیم. پایداری چیدمان برای طراحی راه حل هر ویژگی جدید در آینده مورد توجه قرار خواهد گرفت تا بتوانیم از ابتدا از تغییرات غیرمنتظره چیدمان جلوگیری کنیم.

نتیجه

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

هنوز مناطقی از سایت وجود دارد که باید آن را بهبود دهیم. ما در حال بررسی راه‌هایی هستیم که می‌توانیم کارهای بیشتری را در سمت سرور منطقی سمت کلاینت انجام دهیم که CLS را حتی بیشتر بهبود می‌بخشد. ما معیارهای خود را با هدف بهبود مداوم آنها و ارائه بهترین تجربه کاربری ممکن به خوانندگان خود ردیابی و نظارت خواهیم کرد.