Jak firma Cybozu wyeliminowała problemy ze zgodnością przeglądarek dzięki Baseline

Sakura Adachi
Sakura Adachi
Yuriko Hirota
Yuriko Hirota

Data publikacji: 7 listopada 2025 r.

Zarządzanie zgodnością przeglądarek w przypadku ponad 38 tys. klientów korporacyjnych w Japonii nie jest łatwe. Kintone obsługuje kluczowe operacje biznesowe w ponad 1,5 miliona aplikacji dziennie, dlatego każda decyzja dotycząca obsługi przeglądarki ma znaczenie.

Cybozu, wiodąca japońska firma zajmująca się oprogramowaniem grupowym, stanęła przed zasadniczym wyzwaniem: jak utrzymać spójne standardy internetowe w różnych produktach, unikając przy tym obciążenia związanego z obsługą niestandardowych macierzy obsługi przeglądarek.

Rozwiązanie? Wprowadzenie Baseline jako standardu tworzenia stron – to posunięcie zmieniło podejście zespołu do wdrażania funkcji platformy internetowej.

Wyzwanie: obsługa przeglądarek bez zgadywania

Przed wprowadzeniem Baseline firma Cybozu stosowała własne kryteria obsługi przeglądarek na podstawie dzienników dostępu i ręcznego śledzenia wersji. Standardem było obsługiwanie przeglądarek, które obejmowały 98% najpopularniejszych logów dostępu, a użytkownikom korzystającym z przeglądarek spoza tego progu wyświetlano prośbę o zaktualizowanie przeglądarki.

Co kwartał zespoły inżynierów Cybozu poświęcały łącznie około godziny na aktualizację kryteriów. Integracja kryteriów z zespołem deweloperów nie przebiegała jednak bezproblemowo i często pojawiały się pytania: kiedy można używać nowych funkcji CSS? Kiedy można usunąć elementy polyfill dla nowych interfejsów JavaScript API? I właściwie z których funkcji można korzystać teraz?

Niestandardowe kryteria Cybozu nie tylko były trudne w utrzymaniu i użytkowaniu dla deweloperów, ale też firma zdała sobie sprawę, że oparcie się na wykrywaniu klienta użytkownika i ręcznym śledzeniu wersji nie nadąży za tempem rozwoju nowoczesnego internetu.

Czy można polegać na ciągu znaków User-Agent?

Wcześniejsze podejście Cybozu polegało na wyodrębnianiu nazw i wersji przeglądarek z User-Agent ciągów, a następnie agregowaniu tych wyników jako danych „użytkownika”. Czy jednak odzwierciedla to rzeczywistość użytkowników?

User-Agent to nagłówek żądania HTTP, czyli informacja, którą każdy klient może podać w dowolnej formie. Dzienniki dostępu do usługi zawierają ogromne ilości żądań pochodzących od botów, robotów indeksujących, atakujących i innych źródeł. Niektórzy klienci celowo wysyłają stare ciągi znaków User-Agent w różnych celach, np. w celu skanowania pod kątem luk w zabezpieczeniach. Dlatego dzienniki dostępu nie mogą reprezentować użytkowników, którzy powinni być obsługiwani.

Ciąg User-Agent nie może odzwierciedlać dostępnych funkcji

Wersje przeglądarki nie są mapowane na funkcje. Ten sam numer wersji może mieć różne możliwości w zależności od kanału (stabilny, beta, deweloperski, Canary), flag funkcji, eksperymentów Finch lub zasad dla przedsiębiorstw. Ponadto różne przeglądarki wdrażają funkcje w różnym czasie – zagnieżdżanie CSS zostało wprowadzone w Safari 16.5 (maj 2023 r.), ale w Chrome 112 (kwiecień 2023 r.). Ciąg znaków User-Agent nie wskazuje dostępności funkcji.

Odpowiedzialność za samodzielne obsługiwanie wersji przeglądarek

Aktualizacje przeglądarki to nie tylko nowe funkcje – regularne wersje przeglądarki zawierają krytyczne poprawki zabezpieczeń i błędów oraz nowe funkcje. Gdy obsługiwane są starsze wersje, problemem nie jest tylko unikanie nowych funkcji – to decyzja, która bezpośrednio wpływa na bezpieczeństwo użytkowników. W środowiskach firmowych niektórzy użytkownicy mogą napotkać uzasadnione ograniczenia. Na przykład:

  • Organizacje mogą mieć ścisłe zasady dotyczące przeglądarek, które uniemożliwiają aktualizacje.
  • Starsze urządzenia nie obsługują aktualizowania nowoczesnych przeglądarek.
  • Użytkownicy z branż podlegających regulacjom, w których proces zatwierdzania zmian jest powolny.

Jednak wspieranie tych użytkowników oznacza również, że pozostają oni podatni na zagrożenia.

Jeśli incydent związany z bezpieczeństwem nastąpił w wyniku wykorzystania znanej luki w zabezpieczeniach w starej wersji przeglądarki, nie byłoby rozsądne stwierdzenie, że „ta przeglądarka była obsługiwana, ponieważ użytkownicy o to prosili”. Jeśli atak rozprzestrzeni się na innych użytkowników, którzy dbają o aktualizowanie przeglądarek, deweloperzy i inne osoby zaangażowane w projekt ponoszą odpowiedzialność za brak wycofania obsługi niebezpiecznych przeglądarek.

Firma Cybozu zdała sobie sprawę, że takie podejście stwarza ryzyko dla większości użytkowników, którzy dbają o aktualność przeglądarek. Obsługa przeglądarek oparta wyłącznie na liczbie logów nie zapewnia odpowiedniej weryfikacji zabezpieczeń. Nie chodzi tylko o brak dostępu do nowych funkcji, ale też o niewywiązywanie się z obowiązku ochrony użytkowników.

Pytanie zmienia się z „Ilu użytkowników korzysta z tej wersji?” na „Czy w ogóle powinniśmy obsługiwać użytkowników na podstawie wersji przeglądarki?”.

Dlaczego Baseline jest odpowiednim rozwiązaniem dla firmy Cybozu

Firma Cybozu potrzebowała nowego podejścia, które rozwiązałoby nie tylko problem związany z kosztami operacyjnymi utrzymywania kryteriów obsługi przeglądarek, ale też podstawowe wady starej metodologii. Baseline dostarczyło firmie Cybozu dokładnie to, czego potrzebowała.

Kryteria utrzymywane zewnętrznie i ulegające zmianom

Zamiast ręcznie oceniać wersje przeglądarek co kwartał, Baseline zapewnia zmienne kryterium utrzymywane przez grupę społecznościową WebDX W3C, a nie przez poszczególne firmy podejmujące arbitralne decyzje. Oznacza to, że kryteria automatycznie zmieniają się w zależności od informacji dostarczanych przez dostawców przeglądarek i organizacje normalizacyjne.

Kintone nie musi już samodzielnie zarządzać progami wersji – linia bazowa rozwija się bez żadnych działań. Stan podstawowy funkcji zawiera jednoznaczną odpowiedź na pytania dotyczące dostępności, która jest aktualizowana wraz z rozwojem platformy.

Precyzja na poziomie funkcji

Zamiast śledzić sytuację poszczególnych przeglądarek, Baseline stosuje zupełnie inne podejście.

Baseline Widely available to funkcje internetowe dostępne od co najmniej 30 miesięcy w głównych przeglądarkach. Ten przedział czasowy został określony na podstawie „przybliżonych sygnałów od deweloperów, tempa wprowadzania nowych wersji przeglądarek, szacunkowego wysokiego łącznego udziału w rynku i najlepszej oceny grupy społecznościowej WebDX”. Ustawiając ten próg, Baseline eliminuje konieczność śledzenia sytuacji w poszczególnych przeglądarkach, których nie można zaobserwować.

Dzięki Baseline deweloperzy mogą uzyskać bezpośrednią odpowiedź na pytanie o dostępność danej funkcji w różnych przeglądarkach. „Czy możemy używać zapytań o kontener CSS?” to teraz pytanie, na które można odpowiedzieć. Deweloperzy mogą natychmiast sprawdzić stan Baseline w MDN lub innych dokumentach bez sprawdzania macierzy zgodności.

Bezpieczeństwo przede wszystkim

Przyjęcie jako standardu wersji Baseline Widely available pozwoliło nam dostosować zasady pomocy do okresu, który jest naturalnie powiązany z cyklami pomocy technicznej dostawców przeglądarek. Przeglądarki, które są nadal aktywnie rozwijane, będą obsługiwać wszystkie powszechnie dostępne funkcje, a także otrzymywać ważne aktualizacje zabezpieczeń.

Kryteria oparte na logach dostępu mogłyby sprawić, że pomoc byłaby powiązana z nieaktualnymi przeglądarkami, co zniechęcałoby użytkowników do aktualizacji. Dzięki Baseline możemy nie tylko bez obaw korzystać z nowoczesnych funkcji, ale też sprawić, że użytkownicy starszych przeglądarek będą musieli je zaktualizować, gdy platforma internetowa będzie się rozwijać.

Baseline nie wyklucza wprost przeglądarek podatnych na ataki, ale daje użytkownikom naturalne zachęty do aktualizowania przeglądarek.

Przyjmowanie punktu odniesienia

Wprowadzenie Baseline wymagało zmiany dotychczasowego systemu zarządzania wersjami w firmie Cybozu. Oznaczało to, że Cybozu musiało mieć pewność, że Baseline będzie działać bez większych wad. Znajomość odsetka użytkowników, których dotyczy problem, miała kluczowe znaczenie dla wdrożenia na poziomie przedsiębiorstwa.

Google Analytics Baseline Checker to narzędzie, które analizuje dane wyeksportowane z Google Analytics, aby pokazać, jaki odsetek użytkowników obsługuje funkcje z każdego roku Baseline. To narzędzie pomogło firmie Cybozu sprawdzić rzeczywisty wpływ wyboru docelowej wartości podstawowej na użytkowników. Po uruchomieniu narzędzia Baseline Checker firma Cybozu odkryła coś niezwykłego:

Narzędzie Google Analytics Baseline Checker pobiera wyeksportowany z Google Analytics plik TSV i udostępnia dane pomocnicze dla każdego progu wartości bazowych.

Narzędzie Baseline Checker wykazało, że 98,8% użytkowników Cybozu korzysta z przeglądarek obsługujących szeroko dostępny cel Baseline. Jest to szerszy zakres niż poprzedni wewnętrzny standard Cybozu, który wynosił co najmniej 98% użytkowników. Na podstawie podanych danych można przeanalizować 3 kluczowe kwestie:

  • Nie będzie to miało wpływu na wcześniej obsługiwane przeglądarki.
  • Wcześniej nieobsługiwane przeglądarki: stanowią około 0,8% przeglądarek, które spełniają kryteria podstawowe dotyczące powszechnej dostępności, ale nie wyświetlają już monitu o aktualizację przeglądarki.
  • Pozostałe przeglądarki nadal będą wyświetlać prośbę o aktualizację.

Oznaczało to, że można było wyeliminować fałszywe alarmy – około 0,8% użytkowników, którym niepotrzebnie wyświetlano ostrzeżenia, mimo że korzystali z odpowiednich przeglądarek. Jednocześnie nie można wprowadzać fałszywych negatywów przez ostrzeganie użytkowników, którzy byli wcześniej obsługiwani.

Dzięki tym danym firma Cybozu mogła z pewnością przyjąć jako cel podstawową wersję powszechnie dostępną.

Wpływ wartości podstawowej w praktyce

Przyjęcie zasad podstawowych to jedno, ale wdrożenie ich w praktyce wymagało stworzenia odpowiednich narzędzi i procesów. Było to konieczne, aby programiści nie mogli przypadkowo używać nieobsługiwanych funkcji bez ręcznego sprawdzania stanu linii bazowej.

Analiza statyczna na podstawie konfiguracji ESLint

@cybozu/eslint-config to konfiguracja oparta na OSS, która jest używana w usługach Cybozu. Była ona obsługiwana od css-baseline, czyli ustawienia wstępnego, które sprawdza funkcje CSS pod kątem Baseline w czasie kompilacji:

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

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

Gdy deweloperzy używają funkcji, które nie są jeszcze powszechnie dostępne w Baseline, ESLint od razu przekazuje im informacje zwrotne:

Zagnieżdżanie CSS nie było powszechnie dostępne, ale było używane w kodzie produkcyjnym. ESLint ostrzega przed używaniem tego narzędzia.

Zapobiega to występowaniu w wersji produkcyjnej problemów ze zgodnością. Deweloperzy mogą podejmować świadome decyzje na wczesnym etapie procesu tworzenia: poczekać, aż funkcja będzie powszechnie dostępna, lub wdrożyć progresywne ulepszanie, wiedząc dokładnie, których użytkowników to dotyczy. (Więcej informacji o obsłudze CSS i Baseline w ESLint).

Konfigurowanie transpilatorów pod kątem funkcji Baseline Widely available

Nowoczesne narzędzia do kompilacji zaczęły obsługiwać Baseline jako cel. Na przykład Vite automatycznie kieruje reklamy na wersję Baseline Widely Available w środowisku produkcyjnym bez dodatkowej konfiguracji. Browserslist obsługuje teraz również Baseline.

Używanie różnych ustawień kompilatora zapewnia, że nasz kod JavaScript i CSS jest transpilowany tylko wtedy, gdy jest to konieczne, co pozwala uniknąć niepotrzebnych przekształceń i elementów polyfill w przypadku funkcji, które są już powszechnie obsługiwane.

Eliminowanie ręcznego utrzymywania kryteriów i systemu wykrywania przeglądarek w przypadku opinii użytkowników

Największą korzyścią w zakresie konserwacji było wyeliminowanie ręcznego śledzenia wersji przeglądarki. Zamiast organizować kwartalne spotkania, aby dyskutować o tym, które wersje przeglądarek obsługiwać, Cybozu korzysta teraz z publicznie utrzymywanego @web-platform-dx/baseline-browser-mappingpakietu, aby uzyskać odpowiedzi na te pytania.

Firma Cybozu opracowała też automatyczne wykrywanie przeglądarki, aby wyświetlać użytkownikom korzystającym z przestarzałych przeglądarek prośby o uaktualnienie.

Użytkownicy Kintone, którzy korzystają z przeglądarek poniżej poziomu Baseline Widely Available, zobaczą prośbę o uaktualnienie przeglądarki.

Wykrywanie przeglądarki pobiera zgodne wersje przeglądarki bezpośrednio z pakietu @web-platform-dx/baseline-browser-mapping.

Jest on uruchamiany podczas procesu kompilacji i generuje banery z ostrzeżeniami, które są udostępniane wszystkim zespołom produktowym. Gdy okres „Baseline Widely available” obejmie nowsze przeglądarki, nasz system automatycznie wykryje te zmiany bez konieczności ręcznej interwencji.

Usprawniona komunikacja

Jedną z najważniejszych, ale nieoczekiwanych korzyści było uproszczenie komunikacji między zespołami. Wcześniej dyskusje na temat zgodności z przeglądarkami wymagały wiedzy o domenie konkretnej firmy – które przeglądarki obsługujemy, które wersje i jakie funkcje są obecnie dostępne. Nowi pracownicy potrzebowali czasu, aby poznać nasze wewnętrzne standardy. W przypadku Baseline odwołujemy się teraz do tych samych kryteriów zgodności, które są powszechnie uznawane w społeczności internetowej.

W ten sposób tworzymy wspólne słownictwo zarówno w naszych zespołach inżynieryjnych, jak i w szerszej społeczności internetowej. Podczas omawiania wdrożenia funkcji wszyscy odwołują się do tych samych danych z tego samego źródła, co eliminuje konieczność wyjaśniania wewnętrznych zasad lub tłumaczenia między różnymi ramami zgodności.

Narzędzia deweloperskie również zostały zaktualizowane: Visual Studio Code i panel Style w Narzędziach deweloperskich w Chrome wyświetlają teraz bezpośrednio informacje o zgodności z Baseline. Deweloperzy nie muszą już stale sprawdzać MDN ani Can I use, aby sprawdzić, czy dana funkcja jest bezpieczna w użyciu. Narzędzia od razu ich o tym poinformują.

Zadbaj o to, aby produkt był odpowiedni dla wszystkich użytkowników

Dzięki Baseline możemy zasadniczo zmienić nasze podejście do zgodności przeglądarek z obciążenia, którym zarządzamy, na podstawę, której ufamy. Nasza strategia wdrażania opierała się na automatyzacji na każdym etapie:

  1. Opinie w trakcie tworzenia: analiza statyczna i karta stanu linii bazowej.
  2. Weryfikacja w czasie kompilacji: transpilatory automatycznie kierują reklamy na wersję podstawową powszechnie dostępną.
  3. Wykrywanie w środowisku wykonawczym: ostrzeżenia dla użytkowników, którzy korzystają z nieobsługiwanych przeglądarek, wyświetlane za pomocą elementu baseline-browser-mapping.
  4. Ciągłe aktualizacje: automatyczna synchronizacja z danymi podstawowymi eliminuje konieczność ręcznego zarządzania.

Wyniki mówią same za siebie:

  • 0 godzin poświęconych na konserwację wersji przeglądarki.
  • Ponad 98,8% użytkowników jest objętych ochroną z pewnością na poziomie funkcji.
  • Natychmiastowe i spontaniczne odpowiedzi na najczęstsze pytania, które odpowiadają na pytanie „czy możemy używać tej funkcji w tej wersji przeglądarki?”.
  • Wspólne słownictwo w zespołach inżynierów.
  • Wyraźniejsza ścieżka wdrażania funkcji zachęca zespoły do omówienia integracji nowych funkcji i w razie potrzeby terminu usunięcia polyfilli.

Organizacje, które rozważają wdrożenie wersji podstawowej, muszą wiedzieć, jak ta zmiana wpłynie na użytkowników. Narzędzia takie jak Google Analytics Baseline Checker ułatwiają i wyjaśniają ten pomiar. Gdy będziesz mieć pewność co do danych i zdecydujesz się na wdrożenie Baseline, możesz użyć rosnącego ekosystemu Baseline do uporządkowania procesu programowania.

Platforma internetowa jest bardziej wydajna, spójna i niezawodna, a także rozwija się szybciej niż w przeszłości. Dzięki Baseline możemy wykorzystać tę moc w środowisku produkcyjnym.

Zasoby