Cybozu ने Baseline की मदद से, अलग-अलग ब्राउज़र पर काम करने की सुविधा से जुड़ी समस्याओं को कैसे हल किया

Sakura Adachi

Yuriko Hirota

पब्लिश होने की तारीख़: 7 नवंबर, 2025

जापान में 38,000 से ज़्यादा एंटरप्राइज़ ग्राहकों के लिए, ब्राउज़र के साथ काम करने की सुविधा को मैनेज करना आसान नहीं है. Kintone हर दिन 15 लाख से ज़्यादा ऐप्लिकेशन के लिए, कारोबार से जुड़ी अहम कार्रवाइयां करता है.इसलिए, हर ब्राउज़र के साथ काम करने से जुड़ा फ़ैसला अहम होता है.

जापान की एक लीडिंग ग्रुपवेयर कंपनी, Cybozu को एक बुनियादी समस्या का सामना करना पड़ा: सभी प्रॉडक्ट में एक जैसे वेब स्टैंडर्ड कैसे बनाए रखें. साथ ही, कस्टम ब्राउज़र सपोर्ट मैट्रिक्स को बनाए रखने की ज़िम्मेदारी से कैसे बचें.

इसका समाधान क्या है? डेवलपमेंट स्टैंडर्ड के तौर पर बेसलाइन को अपनाना. इससे वेब प्लैटफ़ॉर्म की सुविधाओं को अपनाने के उनके तरीके में बदलाव आया!

चुनौती: अनुमान के आधार पर ब्राउज़र के साथ काम करने की सुविधा

Baseline से पहले, Cybozu ने ब्राउज़र के साथ काम करने से जुड़ी अपनी शर्तें तय की थीं. ये शर्तें, ऐक्सेस लॉग और मैन्युअल वर्शन ट्रैकिंग पर आधारित थीं. उनका स्टैंडर्ड यह था कि वे ऐसे ब्राउज़र के साथ काम करते थे जो 98% ऐक्सेस लॉग को कवर करते थे. साथ ही, उस थ्रेशोल्ड से बाहर के ब्राउज़र इस्तेमाल करने वाले लोगों को ब्राउज़र अपडेट करने का प्रॉम्प्ट दिखाया जाता था.

हर तिमाही में, Cybozu की इंजीनियरिंग टीमें, शर्तों को अपडेट करने के लिए कुल मिलाकर करीब एक घंटा खर्च करती हैं. इसके बावजूद, डेवलपमेंट टीम के साथ मानदंड को इंटिग्रेट करना आसान नहीं था. साथ ही, यह सवाल पूछना आम बात थी कि सीएसएस की नई सुविधाओं का इस्तेमाल कब किया जा सकता है? JavaScript के नए एपीआई के लिए पॉलीफ़िल कब हटाए जा सकते हैं? और वाकई, किन सुविधाओं का इस्तेमाल अब किया जा सकता है?

Cybozu के कस्टम मानदंड, डेवलपर के लिए न सिर्फ़ रखरखाव और इस्तेमाल करने में मुश्किल थे, बल्कि उन्हें यह भी पता चला कि उपयोगकर्ता एजेंट का पता लगाने और मैन्युअल वर्शन ट्रैकिंग के आधार पर काम करने से, आधुनिक वेब के विकास की रफ़्तार के साथ तालमेल नहीं बिठाया जा सकता.

क्या User-Agent स्ट्रिंग पर भरोसा किया जा सकता है

Cybozu, ब्राउज़र के नाम और वर्शन का पता लगाने के लिए, User-Agent स्ट्रिंग का इस्तेमाल करता था. इसके बाद, इन नतीजों को "उपयोगकर्ता" डेटा के तौर पर इकट्ठा करता था. हालांकि, क्या इससे उपयोगकर्ताओं की सही जानकारी मिलती है?

User-Agent एक एचटीटीपी अनुरोध हेडर है. यह ऐसी जानकारी होती है जिसे कोई भी क्लाइंट किसी भी तरह की जानकारी के तौर पर दावा कर सकता है. प्रॉडक्ट ऐक्सेस लॉग में, बॉट, क्रॉलर, हमलावरों, और अन्य सोर्स से मिले अनुरोधों की संख्या बहुत ज़्यादा होती है. कुछ क्लाइंट जान-बूझकर अलग-अलग कामों के लिए पुरानी User-Agent स्ट्रिंग भेजते हैं. जैसे, सुरक्षा से जुड़ी कमियों का पता लगाना. इसलिए, ऐक्सेस लॉग उन उपयोगकर्ताओं के बारे में जानकारी नहीं दे सकते जिन्हें सहायता मिलनी चाहिए.

User-Agent, उपलब्ध सुविधाओं के बारे में जानकारी नहीं दे सकता

ब्राउज़र के वर्शन, सुविधाओं के साथ मैप नहीं किए जाते. एक ही वर्शन नंबर में अलग-अलग सुविधाएं हो सकती हैं. ऐसा चैनल (स्टेबल/बीटा/डेव/कैनरी), सुविधा के फ़्लैग, फ़िंच एक्सपेरिमेंट या एंटरप्राइज़ नीतियों के आधार पर हो सकता है. इसके अलावा, अलग-अलग ब्राउज़र अलग-अलग समय पर सुविधाएं लागू करते हैं. सीएसएस नेस्टिंग की सुविधा Safari 16.5 (मई 2023) में उपलब्ध कराई गई थी, जबकि Chrome 112 (अप्रैल 2023) में उपलब्ध कराई गई थी. User-Agent स्ट्रिंग से, सुविधा की उपलब्धता के बारे में पता नहीं चलता.

ब्राउज़र के वर्शन के साथ काम करने की ज़िम्मेदारी हमारी है

ब्राउज़र के अपडेट में सिर्फ़ नई सुविधाएं शामिल नहीं होती हैं. ब्राउज़र की नियमित रिलीज़ में, नई सुविधाओं के साथ-साथ सुरक्षा से जुड़े ज़रूरी पैच और गड़बड़ियों को ठीक करने से जुड़े अपडेट भी शामिल होते हैं. जब पुराने वर्शन के साथ काम करने की सुविधा उपलब्ध होती है, तो नई सुविधाओं का इस्तेमाल न करना ही एकमात्र समस्या नहीं होती. यह एक ऐसा फ़ैसला है जो सीधे तौर पर उपयोगकर्ता की सुरक्षा पर असर डालता है. बड़े कारोबारों के माहौल में, कुछ लोगों को कानूनी तौर पर पाबंदियों का सामना करना पड़ सकता है. उदाहरण के लिए:

• ऐसा हो सकता है कि संगठनों की ब्राउज़र से जुड़ी नीतियां सख्त हों. इस वजह से, अपडेट नहीं हो पाते.
• लेगसी हार्डवेयर पर, नए ब्राउज़र अपडेट नहीं किए जा सकते.
• ऐसे कारोबार जो रेगुलेटेड इंडस्ट्री में आते हैं और जिनके लिए बदलावों को मंज़ूरी मिलने में समय लगता है.

हालांकि, इन उपयोगकर्ताओं की मदद करने का मतलब यह भी है कि वे जोखिम में बने रहेंगे.

अगर ब्राउज़र के पुराने वर्शन में मौजूद किसी ज्ञात कमज़ोरी का फ़ायदा उठाकर सुरक्षा से जुड़ी कोई घटना हुई है, तो यह कहना सही नहीं होगा कि "इस ब्राउज़र को इसलिए सपोर्ट किया गया, क्योंकि उपयोगकर्ताओं ने इसका अनुरोध किया था". अगर यह हमला उन अन्य उपयोगकर्ताओं तक पहुंच जाता है जो अपडेट किए गए ब्राउज़र का इस्तेमाल करते हैं, तो डेवलपर और प्रोजेक्ट के अन्य हितधारकों की यह ज़िम्मेदारी बनती है कि वे असुरक्षित ब्राउज़र के लिए सहायता बंद करें.

Cybozu को पता चला कि इस तरीके से, उन ज़्यादातर उपयोगकर्ताओं के लिए जोखिम पैदा होता है जो अपने ब्राउज़र को अपडेट रखते हैं. सिर्फ़ लॉग की संख्या के आधार पर काम करने वाले ब्राउज़र में, सुरक्षा की पुष्टि करने की सुविधा सही तरीके से काम नहीं करती. सिर्फ़ नई सुविधाओं का इस्तेमाल न कर पाना ही समस्या नहीं है, बल्कि उपयोगकर्ताओं की सुरक्षा करने की ज़िम्मेदारी को पूरा न कर पाना भी एक समस्या है.

सवाल "इस वर्शन पर कितने उपयोगकर्ता हैं?" से बदलकर "क्या हमें ब्राउज़र वर्शन के आधार पर उपयोगकर्ताओं को सहायता देनी चाहिए?" हो जाता है

Cybozu के लिए, आधारभूत सिद्धांत सही जवाब क्यों है

Cybozu को एक नए तरीके की ज़रूरत थी. इससे न सिर्फ़ ब्राउज़र सपोर्ट की शर्तों को पूरा करने में आने वाली मुश्किलों को दूर किया जा सकता था, बल्कि पुराने तरीके की बुनियादी कमियों को भी ठीक किया जा सकता था. बेसलाइन ने Cybozu को ठीक यही सुविधा दी.

बाहर से बनाए गए और समय के साथ बदलते रहने वाले मानदंड

हर तिमाही में ब्राउज़र के वर्शन की मैन्युअल तरीके से फिर से जांच करने के बजाय, Baseline एक बदलता हुआ टारगेट उपलब्ध कराता है. इसे W3C WebDX कम्यूनिटी ग्रुप मैनेज करता है. इसे कोई कंपनी अपनी मर्ज़ी से मैनेज नहीं करती. इसका मतलब है कि ब्राउज़र बनाने वाली कंपनियों और स्टैंडर्ड तय करने वाली संस्थाओं के सुझावों के आधार पर, ये शर्तें अपने-आप अपडेट होती रहती हैं.

Kintone को अब वर्शन थ्रेशोल्ड को खुद मैनेज करने की ज़रूरत नहीं है. Baseline में बिना किसी कार्रवाई के बदलाव हो जाता है. सुविधाओं के लिए बेसलाइन स्टेटस से, उनकी उपलब्धता के बारे में सटीक जानकारी मिलती है. साथ ही, प्लैटफ़ॉर्म में बदलाव होने पर यह जानकारी अपने-आप अपडेट हो जाती है.

फ़ीचर-लेवल पर सटीक जानकारी

किसी ब्राउज़र की स्थिति को ट्रैक करने के बजाय, Baseline एक अलग तरीका अपनाता है.

ज़्यादातर ब्राउज़र पर 30 या इससे ज़्यादा महीनों से उपलब्ध वेब सुविधाओं को 'ज़्यादातर ब्राउज़र पर उपलब्ध बेसलाइन' के तौर पर दिखाया जाता है. इस समयसीमा को "डेवलपर सिग्नल, समय के साथ ब्राउज़र रिलीज़ को अपनाने की दर, कुल मार्केट शेयर के लिए सहायता का अनुमान, और WebDX कम्यूनिटी ग्रुप के सबसे सही फ़ैसले के आधार पर तय किया गया है". इस थ्रेशोल्ड को सेट करने पर, Baseline को उन ब्राउज़र की स्थितियों को ट्रैक करने की ज़रूरत नहीं होती जिन्हें देखा नहीं जा सकता.

Baseline की मदद से, डेवलपर को किसी खास सुविधा के बारे में सीधे तौर पर यह जानकारी मिलती है कि वह सुविधा किन ब्राउज़र पर उपलब्ध है. "क्या हम सीएसएस कंटेनर क्वेरी का इस्तेमाल कर सकते हैं?" अब एक ऐसा सवाल है जिसका जवाब दिया जा सकता है. डेवलपर, MDN या अन्य दस्तावेज़ों पर, Baseline की स्थिति तुरंत देख सकते हैं. इसके लिए, उन्हें कंपैटिबिलिटी मैट्रिक्स की क्रॉस-रेफ़रंसिंग करने की ज़रूरत नहीं है.

सुरक्षा को ध्यान में रखकर डिज़ाइन किया गया

Baseline Widely available को अपना स्टैंडर्ड बनाने के बाद, Cybozu ने अपनी सहायता नीति को एक ऐसे समयसीमा के साथ अलाइन किया जो ब्राउज़र वेंडर की सहायता की लाइफ़साइकल से मेल खाती है. जिन ब्राउज़र को अब भी अपडेट किया जा रहा है उनमें, सभी सुविधाएं काम करती रहेंगी. साथ ही, उन्हें सुरक्षा से जुड़े अहम अपडेट भी मिलते रहेंगे.

ऐक्सेस लॉग पर आधारित शर्तों की वजह से, सहायता को पुराने ब्राउज़र से जोड़ा जा सकता था. इससे उपयोगकर्ताओं को ब्राउज़र अपडेट करने के लिए प्रोत्साहन नहीं मिलता था. बेसलाइन को अपनाने से, हम आधुनिक सुविधाओं का इस्तेमाल भरोसे के साथ कर सकते हैं. साथ ही, वेब प्लैटफ़ॉर्म के आगे बढ़ने के साथ-साथ, पुराने ब्राउज़र इस्तेमाल करने वाले लोगों को अपडेट करने की ज़रूरत अपने-आप महसूस होती है.

बेसलिन में, असुरक्षित ब्राउज़र को साफ़ तौर पर शामिल नहीं किया जाता. इसमें उपयोगकर्ताओं को अपने ब्राउज़र अपडेट रखने के लिए, स्वाभाविक तौर पर प्रोत्साहन दिया जाता है.

बेसलाइन को अपनाना

बेसलाइन को अपनाने के लिए, Cybozu के लेगसी वर्शन मैनेजमेंट से माइग्रेट करना ज़रूरी था. इसका मतलब है कि Cybozu को यह भरोसा होना चाहिए कि Baseline बिना किसी बड़ी समस्या के काम करेगा. यह जानना ज़रूरी था कि इससे कितने प्रतिशत उपयोगकर्ताओं पर असर पड़ेगा, ताकि एंटरप्राइज़-लेवल पर इसे अपनाया जा सके.

Google Analytics Baseline Checker एक ऐसा टूल है जो Google Analytics से एक्सपोर्ट किए गए डेटा का विश्लेषण करता है. इससे यह पता चलता है कि आपके कितने प्रतिशत उपयोगकर्ता, हर बेसलाइन साल की सुविधाओं का इस्तेमाल करते हैं. इस टूल की मदद से Cybozu ने यह पता लगाया कि उपयोगकर्ताओं पर, बेसलाइन टारगेट चुनने का क्या असर पड़ा. बेसलाइन चेकर चलाने के बाद, Cybozu को एक अहम जानकारी मिली:

बेसलाइन चेकर से पता चला कि Cybozu के 98.8% उपयोगकर्ताओं ने ऐसे ब्राउज़र इस्तेमाल किए जो टारगेट करने के लिए, ज़्यादातर लोगों के लिए उपलब्ध बेसलाइन का इस्तेमाल करते हैं. यह कवरेज, Cybozu के पिछले इंटरनल स्टैंडर्ड से ज़्यादा है. पिछले इंटरनल स्टैंडर्ड के मुताबिक, कम से कम 98% उपयोगकर्ताओं को कवर किया जाता था. दिए गए डेटा के आधार पर, तीन मुख्य बिंदुओं का विश्लेषण किया जा सकता है:

• पहले काम करने वाले ब्राउज़र पर इसका कोई असर नहीं पड़ेगा.
• पहले काम न करने वाले ब्राउज़र: ये ऐसे ब्राउज़र हैं जो Baseline Widely available के तौर पर उपलब्ध होने की ज़रूरी शर्तें पूरी करते हैं. इनकी संख्या करीब 0.8% है. हालांकि, अब इनमें ब्राउज़र अपडेट करने का अनुरोध नहीं दिखता.
• अन्य ब्राउज़र पर, ब्राउज़र अपडेट करने का प्रॉम्प्ट पहले की तरह ही मिलता रहेगा.

खास तौर पर, इसका मतलब यह था कि गलत पॉज़िटिव को हटाया जा सकता है. यानी, 0.8% उपयोगकर्ताओं को बिना किसी वजह के चेतावनी दिखाई गई थी, जबकि वे ऐसे ब्राउज़र का इस्तेमाल कर रहे थे जिनमें यह सुविधा काम करती है. साथ ही, पहले से ही सहायता पाने वाले उपयोगकर्ताओं को चेतावनी देकर, फ़ॉल्स नेगेटिव नहीं दिखाए जा सकते.

इस डेटा की मदद से, Cybozu ने Baseline Widely available को टारगेट के तौर पर अपनाया.

बेसलाइन का इस्तेमाल करने से मिलने वाले फ़ायदे

नीति के तौर पर बेसलाइन को अपनाना एक बात थी, लेकिन इसे लागू करने के लिए टूल और प्रोसेस बनाना ज़रूरी था. यह ज़रूरी था कि डेवलपर, बेसलाइन की स्थिति की मैन्युअल तरीके से जांच किए बिना, गलती से ऐसी सुविधाओं का इस्तेमाल न कर पाएं जो काम नहीं करती हैं.

ESLint कॉन्फ़िगरेशन के आधार पर स्टैटिक विश्लेषण

@cybozu/eslint-config एक ओएसएस-आधारित कॉन्फ़िगरेशन है. इसका इस्तेमाल Cybozu के सभी प्रॉडक्ट में किया जाता है. यह सुविधा, css-baseline प्रीसेट से काम करती है. यह प्रीसेट, बिल्ड टाइम पर सीएसएस सुविधाओं की जांच करता है:

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

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

जब डेवलपर ऐसी सुविधाओं का इस्तेमाल करते हैं जो अभी तक Baseline Widely available नहीं हैं, तो उन्हें ESLint से तुरंत सुझाव मिलते हैं:

इससे, प्रोडक्शन में कंपैटिबिलिटी से जुड़ी समस्याएं नहीं आती हैं. डेवलपर, डेवलपमेंट प्रोसेस के शुरुआती चरण में ही सोच-समझकर फ़ैसले ले सकते हैं: या तो वे इस सुविधा के ज़्यादातर लोगों के लिए उपलब्ध होने का इंतज़ार करें या प्रोग्रेसिव एन्हांसमेंट को लागू करें. इससे उन्हें यह पता चल जाएगा कि किन उपयोगकर्ताओं पर इसका असर पड़ेगा. (ESLint के सीएसएस और बेसलाइन सपोर्ट के बारे में ज़्यादा जानें.)

ट्रांसपाइलर को, 'बेसलिन वाइडली अवेलेबल' को टारगेट करने के लिए कॉन्फ़िगर करना

मॉडर्न बिल्ड टूल, अब बेसलाइन को टारगेट के तौर पर इस्तेमाल करने की सुविधा देते हैं. उदाहरण के लिए, Vite, प्रोडक्शन में बिना किसी अतिरिक्त कॉन्फ़िगरेशन के, Baseline Widely Available को अपने-आप टारगेट करता है. Browserslist अब Baseline के साथ भी काम करता है.

कंपाइलर की अलग-अलग सेटिंग का इस्तेमाल करने से यह पक्का होता है कि हमारी JavaScript और CSS को सिर्फ़ तब ट्रांसपाइल किया जाए, जब इसकी ज़रूरत हो. इससे उन सुविधाओं के लिए गैर-ज़रूरी ट्रांसफ़ॉर्म और पॉलीफ़िल से बचा जा सकता है जो पहले से ही बड़े पैमाने पर काम करती हैं.

उपयोगकर्ता से मिले सुझाव/राय/शिकायत के आधार पर, मैन्युअल तरीके से शर्तों को बनाए रखने और ब्राउज़र का पता लगाने वाले सिस्टम को बंद करना

ब्राउज़र के वर्शन को मैन्युअल तरीके से ट्रैक करने की प्रोसेस को बंद करने से, रखरखाव के काम में सबसे ज़्यादा बचत हुई. Cybozu अब इन सवालों के जवाब देने के लिए, @web-platform-dx/baseline-browser-mapping पैकेज का इस्तेमाल करता है. यह पैकेज, ओपन सोर्स के तौर पर उपलब्ध है. इससे पहले, कंपनी को हर तीन महीने में मीटिंग करनी पड़ती थी, ताकि यह तय किया जा सके कि ब्राउज़र के किन वर्शन के साथ काम करना है.

Cybozu ने ब्राउज़र का अपने-आप पता लगाने की सुविधा भी बनाई है, ताकि पुराने ब्राउज़र इस्तेमाल करने वाले लोगों को अपग्रेड करने के लिए सूचनाएं दिखाई जा सकें.

ब्राउज़र का पता लगाने की सुविधा, सीधे @web-platform-dx/baseline-browser-mapping पैकेज से काम करने वाले ब्राउज़र वर्शन फ़ेच करती है.

यह हमारी बिल्ड प्रोसेस के दौरान चलता है. साथ ही, चेतावनी वाले बैनर जनरेट करता है. इन बैनर को सभी प्रॉडक्ट टीमों के साथ शेयर किया जाता है. ब्राउज़र के नए वर्शन के लिए, 'बड़े पैमाने पर उपलब्ध' स्थिति में आने की समयसीमा बढ़ने पर, हमारा सिस्टम अपने-आप बदलावों को लागू कर देता है. इसके लिए, आपको कुछ भी करने की ज़रूरत नहीं होती.

आसानी से बातचीत करने की सुविधा

सबसे अहम और अप्रत्याशित फ़ायदा यह था कि बेसलाइन की मदद से, अलग-अलग टीमों के बीच बातचीत करना आसान हो गया. पहले, ब्राउज़र के साथ काम करने की सुविधा के बारे में चर्चा करने के लिए, कंपनी के डोमेन के बारे में खास जानकारी की ज़रूरत होती थी. जैसे, हम किन ब्राउज़र और उनके किन वर्शन के साथ काम करते हैं और अब कौनसी सुविधाएं उपलब्ध हैं. नए लोगों को हमारे इंटरनल स्टैंडर्ड सीखने में समय लगता है. बेसलाइन के साथ, अब हम कंपैटिबिलिटी से जुड़ी उसी शर्त का हवाला देते हैं जिसे वेब कम्यूनिटी में बड़े पैमाने पर मान्यता मिली हुई है.

इससे हमारी इंजीनियरिंग टीमों और वेब कम्यूनिटी के बीच एक जैसी शब्दावली तैयार होती है. सुविधा को अपनाने के बारे में चर्चा करते समय, सभी लोग एक ही सोर्स से एक ही डेटा का रेफ़रंस देते हैं. इससे, आंतरिक नीतियों के बारे में बताने या अलग-अलग कंपैटिबिलिटी फ़्रेमवर्क के बीच अनुवाद करने की ज़रूरत नहीं पड़ती.

डेवलपमेंट टूल भी अब इस सुविधा के साथ काम करते हैं: Visual Studio Code और Chrome DevTools में मौजूद स्टाइल पैनल अब सीधे तौर पर, बेसलाइन के साथ काम करने की जानकारी दिखाते हैं. डेवलपर को अब यह देखने के लिए, MDN या Can I use को बार-बार देखने की ज़रूरत नहीं है कि कोई सुविधा इस्तेमाल करने के लिए सुरक्षित है या नहीं. टूलिंग से उन्हें तुरंत पता चल जाता है.

सभी के लिए भरोसेमंद तरीके से प्रॉडक्ट को काम करने लायक बनाना

बेसलाइन की मदद से, हम ब्राउज़र के साथ काम करने की सुविधा को लेकर अपनी सोच को पूरी तरह से बदल पाए. अब हम इसे एक ऐसी सुविधा मानते हैं जिस पर हम भरोसा कर सकते हैं. हमने हर चरण में ऑटोमेशन पर फ़ोकस किया. इसके लिए, हमने यह रणनीति अपनाई:

1. डेवलपमेंट के दौरान मिलने वाले सुझाव: स्टैटिक विश्लेषण और बेसलाइन की स्थिति बताने वाला कार्ड.
2. बिल्ड-टाइम की पुष्टि: ट्रांसपाइलर, Baseline Widely available को अपने-आप टारगेट करते हैं.
3. रनटाइम में पहचान करना: baseline-browser-mapping का इस्तेमाल करने वाले ऐसे ब्राउज़र के लिए उपयोगकर्ताओं को चेतावनियां दिखाना जिनमें यह सुविधा काम नहीं करती.
4. लगातार अपडेट होना: बेसलाइन डेटा के साथ अपने-आप सिंक होने की सुविधा से, मैन्युअल तरीके से रखरखाव करने की ज़रूरत नहीं पड़ती.

नतीजे खुद ही सब कुछ बता रहे हैं:

• ब्राउज़र वर्शन को बनाए रखने में शून्य घंटे लगे.
• सुविधा के लेवल पर 98.8% से ज़्यादा उपयोगकर्ताओं को टारगेट करने की सुविधा मिलती है.
• अक्सर पूछे जाने वाले सवालों के जवाब तुरंत और अपने-आप मिल जाते हैं. इससे "क्या हम इस सुविधा का इस्तेमाल इस ब्राउज़र वर्शन पर कर सकते हैं?" सवाल का जवाब मिल जाता है
• इंजीनियरिंग टीमों के बीच शेयर किया गया शब्दावली.
• सुविधा को अपनाने का बेहतर तरीका टीमों को नई सुविधा को इंटिग्रेट करने और पॉलीफ़िल हटाने के समय के बारे में चर्चा करने के लिए कहता है. हालांकि, ऐसा तब करना होता है, जब ज़रूरी हो.

अगर आपका संगठन Baseline को अपनाने के बारे में सोच रहा है, तो यह जानना ज़रूरी है कि इस बदलाव का आपके उपयोगकर्ताओं पर क्या असर पड़ेगा. Google Analytics Baseline Checker जैसे टूल की मदद से, इस मेज़रमेंट को ज़्यादा आसान और समझने लायक बनाया जा सकता है. जब आपको डेटा पर भरोसा हो जाए और आपने बेसलाइन को अपनाने का फ़ैसला कर लिया हो, तब अपने डेवलपमेंट वर्कफ़्लो को व्यवस्थित करने के लिए, बेसलाइन के बढ़ते हुए इकोसिस्टम का इस्तेमाल किया जा सकता है.

वेब प्लैटफ़ॉर्म अब पहले से ज़्यादा बेहतर, ज़्यादा भरोसेमंद, और ज़्यादा तेज़ी से विकसित हो रहा है. Baseline की मदद से, हम प्रोडक्शन में उस पावर का इस्तेमाल पूरे भरोसे के साथ कर सकते हैं.

संसाधन

• जापानी भाषा में मूल लेख: プロダクト開発の基準に Baseline を取り入れるまで - Cybozu Inside Out
• Cybozu ESLint config: @cybozu/eslint-config on GitHub
• Google Analytics Baseline Checker: Google Analytics Baseline Checker
• ब्राउज़र की बेसलाइन मैपिंग: @web-platform-dx/baseline-browser-mapping
• बेसलाइन के बारे में जानें: MDN पर बेसलाइन