Cara Cybozu menghilangkan overhead kompatibilitas browser dengan Baseline

Sakura Adachi
Sakura Adachi
Yuriko Hirota
Yuriko Hirota

Dipublikasikan: 7 November 2025

Mengelola kompatibilitas browser untuk lebih dari 38.000 pelanggan perusahaan di seluruh Jepang bukanlah hal yang mudah. Saat Kintone mendukung operasi bisnis penting untuk lebih dari 1,5 juta aplikasi setiap hari, setiap keputusan dukungan browser menjadi penting.

Cybozu, perusahaan groupware terkemuka di Jepang, menghadapi tantangan mendasar: Bagaimana cara mempertahankan standar web yang konsisten di seluruh produk sekaligus menghindari beban pemeliharaan matriks dukungan browser kustom.

Solusinya? Mengadopsi Baseline sebagai standar pengembangan—langkah yang mengubah pendekatan mereka terhadap adopsi fitur platform web.

Tantangan: Dukungan browser tanpa menebak-nebak

Sebelum Baseline, Cybozu mempertahankan kriteria dukungan browser mereka sendiri berdasarkan log akses dan pelacakan versi manual. Standar mereka adalah mendukung browser yang mencakup 98% teratas log akses—dan pengguna di browser di luar batas tersebut akan melihat dialog update browser.

Setiap kuartal, tim engineering Cybozu menghabiskan waktu sekitar satu jam untuk pembaruan kriteria. Namun, integrasi kriteria ke tim pengembangan tidak lancar, dan cukup sering muncul pertanyaan: Kapan fitur CSS baru dapat digunakan? Kapan polyfill untuk JavaScript API baru dapat dihapus? Dan sebenarnya, fitur apa yang dapat digunakan sekarang?

Tidak hanya kriteria kustom Cybozu yang kurang dapat dipertahankan dan digunakan oleh developer, mereka juga menyadari bahwa pengembangan berdasarkan deteksi agen pengguna dan pelacakan versi manual tidak dapat mengimbangi kecepatan evolusi web modern.

Dapatkah string User-Agent diandalkan

Pendekatan Cybozu sebelumnya memperoleh nama dan versi browser dari string User-Agent, lalu menggabungkan hasil ini sebagai data "pengguna"—tetapi apakah hal ini benar-benar mencerminkan realitas pengguna?

User-Agent adalah header permintaan HTTP—informasi yang dapat diklaim oleh klien mana pun sebagai apa pun. Log akses produk berisi volume permintaan yang sangat besar dari bot, crawler, penyerang, dan sumber lainnya. Beberapa klien sengaja mengirim string User-Agent lama untuk berbagai tujuan, seperti pemindaian kerentanan. Oleh karena itu, log akses tidak dapat merepresentasikan pengguna yang harus didukung.

User-Agent tidak dapat mencerminkan fitur yang tersedia

Versi browser tidak dipetakan ke fitur. Nomor versi yang sama mungkin memiliki kemampuan yang berbeda, bergantung pada saluran (Stabil/Beta/Dev/Canary), flag fitur, eksperimen Finch, atau kebijakan perusahaan, misalnya. Selain itu, browser yang berbeda menerapkan fitur pada jadwal yang berbeda—CSS Nesting dikirimkan di Safari 16.5 (Mei 2023), tetapi Chrome 112 (April 2023). String User-Agent tidak menunjukkan ketersediaan fitur.

Tanggung jawab untuk mendukung versi browser sendiri

Update browser bukan hanya tentang fitur baru—rilis browser reguler mencakup patch keamanan penting dan perbaikan bug bersama dengan kemampuan baru. Jika versi yang sudah usang didukung, masalahnya bukan hanya menghindari penggunaan fitur baru, tetapi juga keputusan yang secara langsung memengaruhi keamanan pengguna. Di lingkungan perusahaan, beberapa pengguna dapat menghadapi batasan yang sah. Contoh:

  • Organisasi mungkin memiliki kebijakan browser ketat yang mencegah update.
  • Hardware lama tidak mendukung update browser modern.
  • Pengguna di industri yang diatur dengan proses persetujuan perubahan yang lambat.

Namun, mendukung pengguna tersebut juga berarti membuat mereka tetap rentan.

Jika insiden keamanan terjadi dengan mengeksploitasi kerentanan yang diketahui dalam versi browser lama, tidak akan ada penjelasan yang masuk akal untuk mengatakan "browser ini didukung karena pengguna memintanya". Jika serangan menyebar ke pengguna lain yang memelihara browser yang diupdate dengan benar, developer dan pemangku kepentingan project lainnya memikul tanggung jawab karena gagal menghentikan dukungan untuk browser yang tidak aman.

Cybozu menyadari bahwa pendekatan ini menimbulkan risiko bagi sebagian besar pengguna yang selalu mengupdate browser mereka. Mendukung browser hanya berdasarkan jumlah log tidak memiliki validasi keamanan yang tepat. Hal ini bukan hanya tentang tidak mendapatkan fitur baru, tetapi juga tentang kegagalan dalam tanggung jawab untuk melindungi pengguna.

Pertanyaannya berubah dari "Berapa banyak pengguna yang menggunakan versi ini?" menjadi "Apakah kita harus mendukung pengguna berdasarkan versi browser?"

Mengapa Baseline adalah jawaban yang tepat untuk Cybozu

Cybozu memerlukan pendekatan baru yang tidak hanya mengatasi beban operasional dalam mempertahankan kriteria dukungan browser, tetapi juga kekurangan mendasar dalam metodologi lama. Baseline memberikan hal itu kepada Cybozu.

Kriteria yang dikelola secara eksternal dan terus berkembang

Daripada menilai ulang versi browser secara manual setiap kuartal, Baseline menyediakan target bergerak yang dikelola oleh Grup Komunitas WebDX W3C—bukan oleh perusahaan perorangan yang membuat keputusan secara sewenang-wenang. Artinya, kriteria akan otomatis berkembang dengan masukan dari vendor browser dan badan standar.

Kintone tidak lagi perlu mengelola sendiri batas versi—Dasar akan berkembang tanpa tindakan apa pun. Status Dasar untuk fitur menjawab pertanyaan ketersediaan secara pasti, dan jawaban diperbarui sendiri seiring berkembangnya platform.

Presisi tingkat fitur

Daripada mencoba melacak situasi browser tertentu, Baseline menggunakan pendekatan yang sangat berbeda.

Baseline Tersedia luas menunjukkan fitur web yang tersedia selama 30 bulan atau lebih di berbagai browser utama. Jangka waktu ini ditentukan untuk "memperkirakan sinyal developer, adopsi rilis browser dari waktu ke waktu, perkiraan dukungan pangsa pasar total yang tinggi, dan penilaian terbaik dari WebDX Community Group". Dengan menetapkan nilai minimum ini, Baseline menghilangkan tugas melacak situasi browser individual yang tidak dapat diamati.

Dengan Baseline, developer mendapatkan jawaban langsung tentang ketersediaan fitur tertentu di berbagai browser. "Dapatkah kita menggunakan kueri penampung CSS?" kini menjadi pertanyaan yang dapat dijawab. Developer dapat memeriksa status Dasar di MDN atau dokumen lain secara instan, tanpa merujuk silang matriks kompatibilitas.

Didesain dengan mempertimbangkan keamanan

Dengan mengadopsi Baseline Widely available sebagai standar kami, Cybozu menyelaraskan kebijakan dukungan kami dengan jangka waktu yang secara alami berkorelasi dengan siklus proses dukungan vendor browser. Browser yang masih dipertahankan secara aktif akan mendukung semua fitur yang Tersedia luas sekaligus menerima update keamanan penting.

Kriteria berbasis log akses berpotensi mengarahkan dukungan ke browser yang sudah usang, sehingga menghilangkan insentif bagi pengguna untuk mengupdate browser. Dengan mengadopsi Baseline, kita tidak hanya dapat menggunakan fitur modern dengan percaya diri, tetapi pengguna di browser yang sudah tidak berlaku secara alami akan menghadapi kebutuhan untuk mengupdate saat platform web berkembang.

Baseline tidak secara eksplisit mengecualikan browser yang rentan—baseline memberikan insentif alami bagi pengguna untuk terus mengupdate browser mereka.

Mengadopsi Dasar Pengukuran

Mengadopsi Baseline memerlukan peralihan dari pengelolaan versi lama Cybozu. Artinya, Cybozu memerlukan keyakinan bahwa Baseline akan berfungsi tanpa kekurangan yang signifikan. Mengetahui persentase pengguna yang akan terpengaruh sangat penting untuk adopsi tingkat perusahaan.

Pemeriksa Dasar Google Analytics adalah alat yang menganalisis data yang diekspor dari Google Analytics untuk menunjukkan persentase pengguna Anda yang mendukung fitur dari setiap tahun Dasar. Alat ini membantu Cybozu memeriksa dampak sebenarnya dari memilih target Dasar terhadap pengguna mereka. Setelah menjalankan Baseline Checker, Cybozu menemukan sesuatu yang luar biasa:

Alat Pemeriksa Dasar Google Analytics menggunakan ekspor TSV dari Google Analytics dan memberikan data dukungan untuk setiap nilai minimum Dasar.

Pemeriksa Dasar menunjukkan bahwa 98,8% pengguna Cybozu menggunakan browser yang mendukung target Tersedia luas di Baseline. Cakupan ini lebih luas daripada standar internal Cybozu sebelumnya, yaitu minimal 98% pengguna. Tiga poin utama yang dapat dianalisis berdasarkan data yang diberikan:

  • Browser yang sebelumnya didukung tidak terpengaruh.
  • Browser yang sebelumnya tidak didukung: mewakili sekitar 0,8% yang memenuhi kriteria Tersedia luas Baseline, tetapi tidak lagi melihat dialog update browser.
  • Browser yang tersisa akan terus menerima perintah update browser seperti sebelumnya.

Khususnya, hal ini berarti positif palsu dapat dihilangkan—sekitar 0,8% pengguna yang tidak perlu ditampilkan peringatan meskipun menggunakan browser yang kompatibel. Pada saat yang sama, negatif palsu tidak dapat terjadi karena peringatan kepada pengguna yang sebelumnya didukung.

Dengan data ini, Cybozu dapat dengan yakin mengadopsi Baseline Tersedia luas sebagai target.

Dampak Baseline dalam praktik

Menerapkan Baseline sebagai kebijakan adalah satu hal, tetapi menjadikannya operasional memerlukan pembuatan alat dan proses. Hal ini diperlukan untuk memastikan developer tidak secara tidak sengaja menggunakan fitur yang tidak didukung tanpa memeriksa status Dasar secara manual.

Analisis statis berdasarkan konfigurasi ESLint

@cybozu/eslint-config adalah konfigurasi berbasis OSS yang digunakan di seluruh produk Cybozu. Fitur ini didukung mulai dari preset css-baseline yang memeriksa fitur CSS terhadap Baseline pada waktu build:

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

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

Saat developer menggunakan fitur yang belum tersedia secara Luas dan merupakan Dasar, mereka akan mendapatkan masukan langsung dari ESLint:

Penyusunan CSS tidak tersedia secara luas di Baseline, tetapi digunakan dalam kode produksi. Di sini, ESLint memperingatkan agar tidak menggunakannya.

Hal ini mencegah masalah kompatibilitas mencapai produksi. Developer dapat membuat keputusan yang tepat di awal proses pengembangan: Menunggu hingga fitur tersedia Secara luas, atau menerapkan peningkatan progresif dengan mengetahui secara pasti pengguna mana yang akan terpengaruh. (Pelajari lebih lanjut dukungan CSS dan Baseline ESLint.)

Mengonfigurasi transpiler untuk menargetkan Baseline yang Tersedia Luas

Alat build modern telah mulai mendukung Baseline sebagai target. Misalnya, Vite secara otomatis menargetkan Baseline Widely Available dalam produksi tanpa konfigurasi tambahan. Browserslist kini juga mendukung Baseline.

Penggunaan berbagai setelan compiler memastikan bahwa JavaScript dan CSS kami ditranspilasi hanya jika diperlukan, sehingga menghindari transformasi dan polyfill yang tidak perlu untuk fitur yang sudah didukung secara luas.

Menghilangkan pemeliharaan kriteria manual dan sistem deteksi browser untuk masukan pengguna

Keuntungan pemeliharaan terbesar berasal dari penghapusan pelacakan versi browser secara manual. Daripada mengadakan rapat setiap tiga bulan untuk mendebatkan versi browser mana yang akan didukung, Cybozu kini mengandalkan paket @web-platform-dx/baseline-browser-mapping yang dikelola secara terbuka untuk menjawab pertanyaan ini.

Cybozu juga membuat deteksi browser otomatis untuk menampilkan perintah upgrade kepada pengguna di browser yang sudah usang.

Upgrade browser akan muncul untuk pengguna Kintone yang menggunakan browser di bawah Baseline Tersedia Luas.

Deteksi browser mereka mengambil versi browser yang kompatibel langsung dari paket @web-platform-dx/baseline-browser-mapping.

Pemeriksaan ini berjalan selama proses build kami, dan membuat banner peringatan yang dibagikan ke semua tim produk. Saat jendela Tersedia luas untuk Dasar Pengukuran berpindah untuk menyertakan browser yang lebih baru, sistem kami akan otomatis mengambil perubahan tanpa memerlukan intervensi manual.

Komunikasi yang lancar

Salah satu manfaat yang paling signifikan namun tidak terduga adalah bagaimana Baseline menyederhanakan komunikasi antar-tim. Sebelumnya, diskusi kompatibilitas browser memerlukan pengetahuan domain khusus perusahaan—browser mana yang kami dukung, versi mana, dan fitur apa yang tersedia sekarang. Karyawan baru memerlukan waktu untuk mempelajari standar internal kami. Dengan Baseline, kami kini merujuk pada kriteria kompatibilitas yang sama yang diakui secara luas di seluruh komunitas web.

Hal ini juga menciptakan kosakata bersama dalam tim engineering kami dan dengan komunitas web yang lebih luas. Saat membahas adopsi fitur, semua orang mereferensikan data yang sama dari sumber yang sama, sehingga tidak perlu menjelaskan kebijakan internal atau menerjemahkan antara framework kompatibilitas yang berbeda.

Alat pengembangan juga telah diperbarui: Visual Studio Code dan panel Gaya di Chrome DevTools kini menampilkan informasi kompatibilitas Baseline secara langsung. Developer tidak perlu lagi terus-menerus memeriksa MDN atau Can I use untuk memverifikasi apakah suatu fitur aman digunakan. Alat ini akan langsung memberi tahu mereka.

Memastikan produk berfungsi dengan baik untuk semua orang dengan percaya diri

Dengan Dasar Pengukuran, kita dapat mengubah cara berpikir kita tentang kompatibilitas browser secara mendasar, dari beban yang kita kelola menjadi fondasi yang kita percayai. Strategi penerapan kami berpusat pada otomatisasi di setiap tahap:

  1. Masukan waktu pengembangan: Analisis statis dan kartu status Dasar.
  2. Validasi waktu build: Transpiler secara otomatis menargetkan Baseline yang Tersedia Luas.
  3. Deteksi runtime: Peringatan yang ditampilkan kepada pengguna untuk browser yang tidak didukung menggunakan baseline-browser-mapping.
  4. Update berkelanjutan: Sinkronisasi otomatis dengan data Dasar menghilangkan pemeliharaan manual.

Hasilnya bisa dilihat sendiri:

  • Nol jam yang dihabiskan untuk pemeliharaan versi browser.
  • Lebih dari 98,8% cakupan pengguna dipertahankan dengan kepastian tingkat fitur.
  • Jawaban instan dan spontan untuk FAQ, yang menjawab pertanyaan "dapatkah kita menggunakan fitur ini di versi browser ini?"
  • Kosakata bersama di seluruh tim engineering.
  • Jalur yang lebih jelas untuk adopsi fitur mendorong tim untuk mendiskusikan integrasi fitur baru dan waktu penghapusan polyfill, jika perlu.

Untuk organisasi yang mempertimbangkan adopsi Baseline, sangat penting untuk mengetahui bagaimana peralihan ini akan memengaruhi pengguna Anda. Alat seperti Pemeriksa Dasar Google Analytics membuat pengukuran ini lebih mudah dan jelas. Setelah yakin dengan data dan memutuskan untuk menggunakan Baseline, Anda dapat menggunakan ekosistem Baseline yang terus berkembang untuk mengatur alur kerja pengembangan Anda.

Platform web kini lebih canggih, lebih konsisten, lebih andal, dan berkembang lebih cepat dibandingkan sebelumnya. Dengan Baseline, kita dapat memanfaatkan kemampuan tersebut dalam produksi dengan percaya diri.

Resource