چگونه سایبوزو با Baseline سربار سازگاری مرورگر را حذف کرد

Sakura Adachi

Yuriko Hirota

منتشر شده: ۷ نوامبر ۲۰۲۵

مدیریت سازگاری مرورگر برای بیش از ۳۸۰۰۰ مشتری سازمانی در سراسر ژاپن کار ساده‌ای نیست. وقتی Kintone روزانه بیش از ۱.۵ میلیون برنامه کاربردی را در عملیات حیاتی کسب و کار پشتیبانی می‌کند، تصمیم‌گیری در مورد پشتیبانی از هر مرورگر اهمیت پیدا می‌کند.

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

راه حل؟ پذیرش Baseline به عنوان یک استاندارد توسعه - حرکتی که رویکرد آنها را به پذیرش ویژگی‌های پلتفرم وب متحول کرد!

چالش: پشتیبانی مرورگر با حدس و گمان

قبل از Baseline، Cybozu معیارهای پشتیبانی مرورگر خود را بر اساس گزارش‌های دسترسی و ردیابی دستی نسخه حفظ می‌کرد. استاندارد آنها پشتیبانی از مرورگرهایی بود که ۹۸٪ بالای گزارش‌های دسترسی را پوشش می‌دادند - و به کاربرانی که از مرورگرهای خارج از این آستانه استفاده می‌کردند، اعلان به‌روزرسانی مرورگر نشان داده می‌شد.

هر سه ماه، تیم‌های مهندسی سایبوزو تقریباً یک ساعت را صرف به‌روزرسانی معیارها می‌کردند. با این حال، ادغام معیارها با تیم توسعه یکپارچه نبود و این سؤالات کاملاً رایج بود: چه زمانی می‌توان از ویژگی‌های جدید CSS استفاده کرد؟ چه زمانی می‌توان پلی‌فیل‌ها را برای APIهای جدید جاوا اسکریپت حذف کرد؟ و واقعاً، اکنون از کدام ویژگی‌ها می‌توان استفاده کرد؟

معیارهای سفارشی Cybozu نه تنها فاقد قابلیت نگهداری و کاربردپذیری برای توسعه‌دهندگان بودند، بلکه آنها همچنین متوجه شدند که ساختن بر اساس تشخیص عامل کاربر و ردیابی دستی نسخه نمی‌تواند با سرعت تکامل وب مدرن همگام باشد.

آیا می‌توان به رشته‌ی User-Agent اعتماد کرد؟

رویکرد قبلی سایبوزو نام‌ها و نسخه‌های مرورگر را از رشته‌های User-Agent استخراج می‌کرد، سپس این نتایج را به عنوان داده‌های "کاربر" تجمیع می‌کرد - اما آیا این واقعاً منعکس‌کننده واقعیت کاربران است؟

User-Agent یک هدر درخواست HTTP است - اطلاعاتی که هر کلاینتی می‌تواند ادعا کند هر چیزی است. گزارش‌های دسترسی به محصول حاوی حجم عظیمی از درخواست‌ها از ربات‌ها، خزنده‌ها، مهاجمان و سایر منابع است. برخی از کلاینت‌ها عمداً رشته‌های قدیمی User-Agent را برای اهداف مختلف، مانند اسکن آسیب‌پذیری، ارسال می‌کنند. بنابراین، گزارش‌های دسترسی نمی‌توانند نمایانگر کاربرانی باشند که باید پشتیبانی شوند.

عامل کاربر نمی‌تواند ویژگی‌های موجود را منعکس کند

نسخه‌های مرورگر به ویژگی‌ها نگاشت نمی‌شوند. یک شماره نسخه یکسان ممکن است بسته به کانال (پایدار/بتا/توسعه/Canary)، پرچم‌های ویژگی ، آزمایش‌های Finch یا سیاست‌های سازمانی ، قابلیت‌های متفاوتی داشته باشد. علاوه بر این، مرورگرهای مختلف ویژگی‌ها را در جدول زمانی متفاوتی پیاده‌سازی می‌کنند - CSS Nesting در Safari 16.5 (مه 2023) اما Chrome 112 (آوریل 2023) ارائه شد. رشته User-Agent نشان‌دهنده در دسترس بودن ویژگی نیست.

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

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

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

با این حال، حمایت از این کاربران همچنین به این معنی است که آنها را قادر می‌سازد تا آسیب‌پذیر باقی بمانند .

اگر یک حادثه امنیتی با سوءاستفاده از یک آسیب‌پذیری شناخته‌شده در یک نسخه قدیمی مرورگر رخ داده باشد، گفتن اینکه «این مرورگر به دلیل درخواست کاربران پشتیبانی شده است» توضیح معقولی نخواهد بود. اگر حمله به سایر کاربرانی که مرورگرهای به‌روز شده را به درستی نگهداری می‌کنند، گسترش یابد، توسعه‌دهندگان و سایر ذینفعان پروژه مسئولیت عدم قطع پشتیبانی از مرورگرهای ناامن را بر عهده دارند.

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

سوال از «چند کاربر از این نسخه استفاده می‌کنند؟» به «آیا اصلاً باید از کاربران بر اساس نسخه مرورگر پشتیبانی کنیم؟» تغییر می‌کند.

چرا Baseline پاسخ مناسبی برای Cybozu است؟

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

معیارهای در حال تکامل و تحت نظارت خارجی

به جای ارزیابی مجدد دستی نسخه‌های مرورگر در هر سه ماه، Baseline یک هدف متحرک ارائه می‌دهد که توسط گروه جامعه W3C WebDX نگهداری می‌شود - نه توسط شرکت‌های منفرد که تصمیمات خودسرانه می‌گیرند. این بدان معناست که معیارها به طور خودکار با ورودی از فروشندگان مرورگر و نهادهای استاندارد تکامل می‌یابند.

دیگر نیازی نبود Kintone آستانه‌های نسخه را خودش مدیریت کند—Baseline بدون هیچ اقدامی تکامل می‌یابد. وضعیت Baseline برای ویژگی‌ها به طور قطعی به سوالات مربوط به در دسترس بودن پاسخ می‌دهد و این پاسخ با تکامل پلتفرم، خود به خود به‌روزرسانی می‌شود.

دقت در سطح ویژگی

Baseline به جای تلاش برای ردیابی وضعیت یک مرورگر خاص، رویکردی اساساً متفاوت را در پیش می‌گیرد.

«پایه به‌طور گسترده در دسترس» نشان‌دهنده ویژگی‌های وب موجود برای ۳۰ ماه یا بیشتر در مرورگرهای اصلی است. این بازه زمانی برای « تقریبی از سیگنال‌های توسعه‌دهنده، میزان پذیرش نسخه مرورگر در طول زمان، تخمینی از پشتیبانی از سهم بازار بالا و بهترین قضاوت گروه جامعه WebDX » تعیین شده است. با تعیین این آستانه، پایه وظیفه ردیابی موقعیت‌های غیرقابل مشاهده مرورگرهای منفرد را از بین می‌برد.

با Baseline، توسعه‌دهندگان پاسخ مستقیمی در مورد در دسترس بودن آن ویژگی خاص در مرورگرها دریافت می‌کنند. "آیا می‌توانیم از کوئری‌های CSS container استفاده کنیم؟" اکنون یک سوال قابل پاسخ است. توسعه‌دهندگان می‌توانند وضعیت Baseline را در MDN یا سایر اسناد، بدون ارجاع متقابل به ماتریس‌های سازگاری، فوراً بررسی کنند.

طراحی آگاهانه از نظر امنیتی

با اتخاذ «پایه به طور گسترده در دسترس» به عنوان استاندارد خود، سایبوزو سیاست پشتیبانی خود را با یک بازه زمانی که به طور طبیعی با چرخه عمر پشتیبانی فروشندگان مرورگر مرتبط است، هماهنگ کرد. مرورگرهایی که هنوز به طور فعال پشتیبانی می‌شوند، از تمام ویژگی‌های «به طور گسترده در دسترس» پشتیبانی می‌کنند و در عین حال به‌روزرسانی‌های امنیتی حیاتی را نیز دریافت می‌کنند.

معیارهای مبتنی بر گزارش دسترسی، این پتانسیل را داشتند که پشتیبانی را به مرورگرهای قدیمی محدود کنند، که این امر انگیزه کاربران برای به‌روزرسانی را از بین می‌برد. با اتخاذ Baseline، نه تنها می‌توانیم با اطمینان از ویژگی‌های مدرن استفاده کنیم، بلکه کاربران مرورگرهای قدیمی نیز به طور طبیعی با پیشرفت پلتفرم وب، نیاز به به‌روزرسانی پیدا می‌کنند.

Baseline صراحتاً مرورگرهای آسیب‌پذیر را مستثنی نمی‌کند—این کار انگیزه‌های طبیعی برای کاربران ایجاد می‌کند تا مرورگرهای خود را به‌روز نگه دارند.

اتخاذ خط پایه

پذیرش Baseline نیازمند تغییر در مدیریت نسخه‌های قدیمی Cybozu بود. این به آن معنا بود که Cybozu نیاز به اطمینان از عملکرد Baseline بدون اشکالات قابل توجه داشت. دانستن اینکه این نسخه چه درصد از کاربران را تحت تأثیر قرار می‌دهد، برای پذیرش در سطح سازمانی بسیار مهم بود.

ابزار بررسی‌کننده‌ی خط پایه‌ی گوگل آنالیتیکس (Google Analytics Baseline Checker ) ابزاری است که داده‌های خروجی از گوگل آنالیتیکس را تجزیه و تحلیل می‌کند تا نشان دهد چه درصدی از کاربران شما از ویژگی‌های هر سال خط پایه پشتیبانی می‌کنند. این ابزار به سایبوزو (Cybozu) کمک کرد تا تأثیر واقعی انتخاب یک هدف خط پایه بر کاربران خود را بررسی کند. سایبوزو پس از اجرای ابزار بررسی‌کننده‌ی خط پایه، نکته‌ی قابل توجهی را کشف کرد:

بررسی‌کننده‌ی خط پایه نشان داد که ۹۸.۸٪ از کاربران Cybozu از مرورگرهایی استفاده می‌کنند که از هدف Baseline Widely available پشتیبانی می‌کنند . این پوشش گسترده‌تر از استاندارد داخلی قبلی Cybozu است که حداقل ۹۸٪ از کاربران را پوشش می‌داد. سه نکته‌ی کلیدی را می‌توان بر اساس داده‌های ارائه شده تحلیل کرد:

• مرورگرهای پشتیبانی‌شده قبلی تحت تأثیر قرار نمی‌گیرند.
• مرورگرهای پشتیبانی نشده قبلی : تقریباً 0.8٪ را نشان می‌دهند که معیارهای پایه «به‌طور گسترده در دسترس» را برآورده می‌کنند، اما دیگر پیام به‌روزرسانی مرورگر را مشاهده نمی‌کنند.
• مرورگرهای باقی‌مانده مانند قبل، همچنان پیام به‌روزرسانی مرورگر را دریافت می‌کنند.

نکته قابل توجه این است که این امر به این معنی بود که می‌توان از نتایج مثبت کاذب - حدود ۰.۸ درصد از کاربرانی که با وجود استفاده از مرورگرهای توانمند، هشدارهای غیرضروری دریافت کرده بودند - جلوگیری کرد. در عین حال، با هشدار دادن به کاربرانی که قبلاً پشتیبانی می‌شدند، نمی‌توانستیم نتایج منفی کاذب ایجاد کنیم.

با این داده‌ها، سایبوزو می‌تواند با اطمینان Baseline Widely available را به عنوان یک هدف بپذیرد.

تأثیر خط پایه در عمل

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

تحلیل استاتیک بر اساس پیکربندی ESLint

@cybozu/eslint-config یک پیکربندی مبتنی بر OSS است که در محصولات Cybozu استفاده می‌شود. این پیکربندی با شروع از تنظیمات پیش‌فرض css-baseline که ویژگی‌های CSS را در زمان ساخت با Baseline بررسی می‌کند، پشتیبانی می‌شد:

// eslint.config.mjs
import cybozuEslintConfigBaseline from '@cybozu/eslint-config/flat/presets/css-baseline.js';

export default [
  ...cybozuEslintConfigBaseline.map((config) => ({
    ...config,
    files: ['**/*.css']
  })),
];

وقتی توسعه‌دهندگان از ویژگی‌هایی استفاده می‌کنند که هنوز به صورت گسترده در دسترس نیستند، بلافاصله از ESLint بازخورد دریافت می‌کنند:

این امر از رسیدن مشکلات سازگاری به مرحله تولید جلوگیری می‌کند. توسعه‌دهندگان می‌توانند در مراحل اولیه توسعه، تصمیمات آگاهانه‌ای بگیرند: یا منتظر بمانند تا این ویژگی به طور گسترده در دسترس قرار گیرد، یا با دانستن اینکه دقیقاً کدام کاربران تحت تأثیر قرار خواهند گرفت، بهبود تدریجی را پیاده‌سازی کنند. (درباره پشتیبانی CSS و Baseline در ESLint بیشتر بدانید.)

پیکربندی ترانسپایلرها برای هدف قرار دادن Baseline به طور گسترده در دسترس است

ابزارهای ساخت مدرن شروع به پشتیبانی از Baseline به عنوان یک هدف کرده‌اند. برای مثال، Vite به طور خودکار Baseline Widely Available را در محیط تولید و بدون پیکربندی اضافی هدف قرار می‌دهد. Browserslist اکنون از Baseline نیز پشتیبانی می‌کند .

استفاده از تنظیمات مختلف کامپایلر تضمین می‌کند که جاوا اسکریپت و CSS ما فقط در صورت لزوم transpile می‌شوند و از تبدیل‌ها و polyfillهای غیرضروری برای ویژگی‌هایی که از قبل به طور گسترده پشتیبانی می‌شوند، جلوگیری می‌شود.

حذف معیارهای دستی نگهداری و سیستم تشخیص مرورگر برای بازخورد کاربر

بزرگترین برد در زمینه نگهداری، حذف ردیابی دستی نسخه مرورگر بود. به جای جلسات فصلی برای بحث در مورد اینکه از کدام نسخه مرورگر پشتیبانی شود، Cybozu اکنون برای پاسخ به این سؤالات به بسته @web-platform-dx/baseline-browser-mapping که به صورت باز نگهداری می‌شود، متکی است.

سایبوزو همچنین تشخیص خودکار مرورگر را برای نمایش پیام‌های ارتقاء به کاربران در مرورگرهای قدیمی ایجاد کرده است.

تشخیص مرورگر آنها نسخه‌های مرورگر سازگار را مستقیماً از بسته‌ی @web-platform-dx/baseline-browser-mapping دریافت می‌کند.

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

ارتباطات ساده و روان

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

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

ابزارهای توسعه نیز به این قابلیت‌ها مجهز شده‌اند: ویژوال استودیو کد و پنل استایل در Chrome DevTools اکنون اطلاعات سازگاری Baseline را مستقیماً نمایش می‌دهند. توسعه‌دهندگان دیگر نیازی ندارند که دائماً MDN یا Can I use را برای تأیید ایمن بودن استفاده از یک ویژگی بررسی کنند. این ابزار بلافاصله به آنها اطلاع می‌دهد.

کاری کنید که محصول با اطمینان برای همه کار کند

با Baseline، می‌توانیم اساساً تفکر خود را در مورد سازگاری مرورگر از یک بار اضافی که مدیریت می‌کنیم به یک پایه و اساس قابل اعتماد تغییر دهیم. استراتژی پیاده‌سازی ما بر اتوماسیون در هر مرحله متمرکز بود:

1. بازخورد زمان توسعه : تحلیل استاتیک و کارت وضعیت پایه.
2. اعتبارسنجی زمان ساخت : Transpilerها به طور خودکار Baseline را هدف قرار می‌دهند. به طور گسترده در دسترس است.
3. تشخیص زمان اجرا : هشدارهای کاربر برای مرورگرهای پشتیبانی نشده با استفاده از baseline-browser-mapping .
4. به‌روزرسانی‌های مداوم : همگام‌سازی خودکار با داده‌های پایه، نیاز به تعمیر و نگهداری دستی را از بین می‌برد.

نتایج خودشان گویای همه چیز هستند:

• صفر ساعت صرف نگهداری نسخه مرورگر نشد.
• پوشش بیش از ۹۸.۸٪ کاربران با اطمینان در سطح ویژگی‌ها حفظ می‌شود.
• پاسخ‌های فوری و خودجوش به سوالات متداول ، که به این سوال پاسخ می‌دهند که "آیا می‌توانیم از این ویژگی در این نسخه مرورگر استفاده کنیم؟"
• واژگان مشترک در بین تیم‌های مهندسی.
• مسیر واضح‌تر برای پذیرش ویژگی‌ها، تیم‌ها را بر آن می‌دارد تا در صورت لزوم، ادغام ویژگی‌های جدید و زمان حذف پلی‌فیل‌ها را مورد بحث قرار دهند.

برای سازمان‌هایی که در حال بررسی پذیرش Baseline هستند، بسیار مهم است که بدانند این تغییر چگونه بر کاربران آنها تأثیر خواهد گذاشت. ابزارهایی مانند Google Analytics Baseline Checker این اندازه‌گیری را ساده‌تر و واضح‌تر می‌کنند. هنگامی که به داده‌ها اطمینان پیدا کردید و تصمیم به پذیرش Baseline گرفتید، می‌توانید از اکوسیستم رو به رشد Baseline برای سازماندهی گردش کار توسعه خود استفاده کنید.

پلتفرم وب قدرتمندتر، سازگارتر، قابل اعتمادتر و سریع‌تر از گذشته در حال تکامل است. با Baseline، می‌توانیم با اطمینان از این قدرت در تولید استفاده کنیم.

منابع

• مقاله اصلی به زبان ژاپنی:プロダクト開発の基準に Baseline を取り入れるまで - Cybozu Inside Out
• پیکربندی ESLint سایبوزو: @cybozu/eslint-config در گیت‌هاب
• بررسی‌کننده‌ی خط پایه‌ی گوگل آنالیتیکس: بررسی‌کننده‌ی خط پایه‌ی گوگل آنالیتیکس
• نگاشت مرورگر پایه: @web-platform-dx/baseline-browser-mapping
• درباره Baseline بیشتر بدانید: Baseline در MDN