چگونه Zalando زمان بازخورد عملکرد را از 1 روز به 15 دقیقه با Lighthouse CI کاهش داد

تیم وب در Zalando دریافتند که ادغام Lighthouse CI یک رویکرد پیشگیرانه برای عملکرد را فعال می کند، با بررسی خودکار وضعیت قادر به مقایسه تعهد فعلی با شاخه اصلی برای جلوگیری از رگرسیون عملکرد است.

یان براکمایر
Jan Brockmeyer
جرمی کالین
Jeremy Colin

Zalando با بیش از 35 میلیون مشتری فعال، پلتفرم مد آنلاین پیشرو در اروپا است. در این پست توضیح می دهیم که چرا شروع به استفاده از Lighthouse CI کردیم، سهولت پیاده سازی و مزایای تیم ما.

در Zalando، ما رابطه بین عملکرد وب سایت و درآمد را می دانیم. در گذشته، ما آزمایش کردیم که چگونه افزایش مصنوعی زمان بارگذاری در صفحات کاتالوگ بر نرخ پرش، نرخ تبدیل و درآمد هر کاربر تأثیر می گذارد. نتایج واضح بود. بهبود 100 میلی ثانیه ای زمان بارگذاری صفحه منجر به افزایش تعامل با نرخ پرش کمتر و افزایش 0.7 درصدی درآمد در هر جلسه شد.

100 میلی‌ثانیه

بهبود زمان بارگذاری صفحه

0.7 ٪

افزایش درآمد در هر جلسه

خرید شرکت همیشه به عملکرد ترجمه نمی شود

علیرغم خرید عملکرد قوی در داخل شرکت، اگر عملکرد به عنوان معیار تحویل محصول تنظیم نشود، می تواند به راحتی از بین برود. هنگامی که در سال 2020 وب سایت Zalando را بازطراحی می کردیم، بر ارائه ویژگی های جدید با حفظ تجربه کاربری عالی و اعمال یک تغییر چهره در وب سایت با فونت های سفارشی و رنگ های زنده تر تمرکز کردیم. با این حال، زمانی که وب‌سایت و برنامه بازطراحی‌شده برای انتشار آماده شد، معیارهای اولیه پذیرش نشان داد که نسخه جدید کندتر است. First Contentful Paint تا 53% کندتر بود و Time to Interactive اندازه‌گیری شده ما تا 59% کندتر گزارش شد.

وب در Zalando

وب سایت Zalando توسط یک تیم اصلی در حال توسعه یک چارچوب ایجاد شده است، با بیش از 15 تیم ویژگی که در میکروسرویس های frontend مشارکت دارند . در حالی که از نسخه جدید پشتیبانی می کنیم، بخشی از وب سایت خود را نیز به معماری متمرکزتر تغییر دادیم.

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

Web Vitals و Lighthouse برای نجات

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

به منظور بهبود عملکرد قبل از انتشار، ما نیاز به ایجاد یک محیط آزمایشگاهی مناسب داشتیم. این علاوه بر شرایط آزمایشی که صدک 90 داده‌های میدانی ما را نشان می‌دهد، اندازه‌گیری‌های تکرارپذیر را فراهم کرد. اکنون، مهندسانی که روی بهبود عملکرد کار می‌کنند، می‌دانستند که تلاش‌های خود را برای ایجاد بیشترین تأثیر در کجا متمرکز کنند. ما قبلاً از گزارش های ممیزی Lighthouse به صورت محلی استفاده می کردیم. بنابراین اولین تکرار ما توسعه یک سرویس مبتنی بر ماژول گره Lighthouse بود که در آن تغییرات را می‌توان از محیط مرحله‌بندی آزمایش کرد. این یک حلقه بازخورد عملکرد قابل اعتماد در حدود یک ساعت به ما داد، که ما را قادر ساخت تا عملکرد را در یک سطح قرار دهیم و انتشار خود را ذخیره کنیم!

ارائه بازخورد عملکرد به توسعه دهندگان در مورد درخواست های کششی

ما نمی‌خواستیم در همین جا متوقف شویم، زیرا می‌خواستیم از فرصت استفاده کنیم و نه تنها نسبت به عملکرد واکنش نشان دهیم، بلکه فعال باشیم. پرش از ماژول گره Lighthouse به سرور Lighthouse CI (LHCI) خیلی سخت نبود. ما راه حل خود میزبانی را انتخاب کردیم تا به ما یکپارچگی بهتری با خدمات شرکت موجود بدهد. برنامه سرور LHCI ما به عنوان یک تصویر Docker ساخته می شود، که سپس به همراه یک پایگاه داده PostgreSQL در خوشه Kubernetes ما مستقر می شود و به GitHub ما گزارش می دهد.

چارچوب ما قبلاً بازخورد عملکردی را برای توسعه‌دهندگان ارائه می‌کرد – اندازه‌های دسته‌بندی مؤلفه‌ها با مقادیر آستانه در هر commit مقایسه می‌شد. اکنون ما می توانیم معیارهای Lighthouse را به عنوان بررسی وضعیت GitHub گزارش کنیم. اینها باعث می شوند خط لوله CI در صورتی که آستانه عملکرد را برآورده نکنند، با پیوندی به گزارش های دقیق Lighthouse همانطور که در تصاویر زیر نشان داده شده است، از کار بیفتد.

تصویر رابط کاربری GitHub که خطوطی از بررسی های موفق را نشان می دهد.
بررسی وضعیت Lighthouse CI GitHub درک رگرسیون و رسیدگی به آن را قبل از رسیدن به تولید برای توسعه دهندگان آسان می کند.
تصویر مقایسه ای در Lighthouse CI که نشان می دهد چگونه commit با شاخه اصلی مقایسه می شود
گزارش تعهد تفصیلی Lighthouse CI در مقایسه با شعبه اصلی.

گسترش پوشش عملکرد

ما با یک رویکرد بسیار عملگرا شروع کردیم. در حال حاضر Lighthouse فقط در دو مورد از مهمترین صفحات ما اجرا می شود: صفحه اصلی و صفحه جزئیات محصول. خوشبختانه Lighthouse CI گسترش تنظیمات اجرا را آسان می کند. تیم‌های ویژه که در صفحات خاصی از وب‌سایت ما کار می‌کنند، می‌توانند الگوی URL منطبق و ادعاهای خود را تنظیم کنند. با وجود این، ما کاملاً مطمئن هستیم که پوشش عملکرد ما افزایش خواهد یافت.

ما اکنون هنگام ساخت نسخه های بزرگتر بسیار مطمئن هستیم و توسعه دهندگان می توانند از یک حلقه بازخورد بسیار کوتاه تر در مورد عملکرد کد خود لذت ببرند.