So hat Cybozu den Aufwand für die Browserkompatibilität mit Baseline reduziert

Sakura Adachi

Yuriko Hirota

Veröffentlicht am 7. November 2025

Die Browserkompatibilität für über 38.000 Unternehmenskunden in ganz Japan zu verwalten,ist nicht einfach. Wenn Kintone täglich kritische Geschäftsabläufe für über 1,5 Millionen Anwendungen unterstützt, ist jede Entscheidung zur Browserunterstützung wichtig.

Cybozu, ein führendes Groupware-Unternehmen in Japan, stand vor einer grundlegenden Herausforderung: Wie können einheitliche Webstandards für alle Produkte beibehalten werden, ohne dass der Wartungsaufwand für benutzerdefinierte Browserunterstützungsmatrizen entsteht?

Die Lösung? Baseline als Entwicklungsstandard eingeführt – ein Schritt, der ihren Ansatz für die Einführung von Webplattformfunktionen verändert hat.

Die Herausforderung: Browserunterstützung ohne Raten

Vor Baseline hatte Cybozu eigene Kriterien für die Browserunterstützung, die auf Zugriffslogs und der manuellen Versionsverfolgung basierten. Ihr Standard war, Browser zu unterstützen, die die obersten 98% der Zugriffslogs abdeckten. Nutzern mit Browsern, die diesen Schwellenwert nicht erreichten, wurde eine Aufforderung zur Browseraktualisierung angezeigt.

Die Engineering-Teams von Cybozu haben pro Quartal insgesamt etwa eine Stunde für die Aktualisierung der Kriterien aufgewendet. Die Integration der Kriterien in das Entwicklungsteam verlief jedoch nicht reibungslos und es gab häufig Fragen: Wann können neue CSS-Funktionen verwendet werden? Wann können Polyfills für neue JavaScript-APIs entfernt werden? Und welche Funktionen können jetzt verwendet werden?

Die benutzerdefinierten Kriterien von Cybozu waren nicht nur schwer zu pflegen und für Entwickler nicht benutzerfreundlich, sondern das Unternehmen erkannte auch, dass die Erkennung von User-Agents und die manuelle Versionsverfolgung nicht mit der Geschwindigkeit der Entwicklung des modernen Webs mithalten konnten.

Kann der User-Agent-String verwendet werden?

Beim bisherigen Ansatz von Cybozu wurden Browsernamen und ‑versionen aus User-Agent-Strings abgeleitet und dann als Nutzerdaten zusammengefasst. Aber spiegeln diese Daten wirklich die Realität der Nutzer wider?

User-Agent ist ein HTTP-Anfrageheader – Informationen, die jeder Client für sich in Anspruch nehmen kann. Produktzugriffsprotokolle enthalten eine große Anzahl von Anfragen von Bots, Crawlern, Angreifern und anderen Quellen. Einige Clients senden absichtlich alte User-Agent-Strings für verschiedene Zwecke, z. B. für das Scannen auf Sicherheitslücken. Daher können Zugriffslogs nicht die Nutzer darstellen, die unterstützt werden sollten.

Der User-Agent kann verfügbare Funktionen nicht widerspiegeln.

Browserversionen werden nicht Features zugeordnet. Dieselbe Versionsnummer kann je nach Channel (Stabil/Beta/Entwickler/Canary), Funktionsflags, Finch-Tests oder Unternehmensrichtlinien unterschiedliche Funktionen haben. Außerdem werden Funktionen in verschiedenen Browsern zu unterschiedlichen Zeitpunkten implementiert. CSS-Nesting wurde in Safari 16.5 (Mai 2023) eingeführt, aber in Chrome 112 (April 2023). Der User-Agent-String gibt nicht an, ob eine Funktion verfügbar ist.

Verantwortung für die Unterstützung von Browserversionen

Bei Browserupdates geht es nicht nur um neue Funktionen. Regelmäßige Browser-Releases enthalten neben neuen Funktionen auch wichtige Sicherheitspatches und Fehlerkorrekturen. Wenn veraltete Versionen unterstützt werden, ist die Vermeidung der Verwendung neuer Funktionen nicht das einzige Problem. Es ist eine Entscheidung, die sich gleichzeitig direkt auf die Sicherheit der Nutzer auswirkt. In Unternehmensumgebungen können für einige Nutzer berechtigte Einschränkungen gelten. Beispiel:

• Organisationen haben möglicherweise strenge Browserrichtlinien, die Updates verhindern.
• Bei älterer Hardware ist es nicht möglich, moderne Browser zu aktualisieren.
• Nutzer in regulierten Branchen mit langsamen Genehmigungsverfahren für Änderungen.

Die Unterstützung dieser Nutzer macht sie jedoch auch weiterhin anfällig.

Wenn ein Sicherheitsvorfall durch Ausnutzung einer bekannten Sicherheitslücke in einer alten Browserversion aufgetreten ist, wäre es keine angemessene Erklärung zu sagen: „Dieser Browser wurde unterstützt, weil Nutzer ihn angefordert haben.“ Wenn sich der Angriff auf andere Nutzer ausweitet, die ihre Browser ordnungsgemäß aktualisieren, tragen Entwickler und andere Projektbeteiligte die Verantwortung dafür, dass sie die Unterstützung für unsichere Browser nicht eingestellt haben.

Cybozu hat erkannt, dass dieser Ansatz Risiken für die Mehrheit der Nutzer birgt, die ihre Browser auf dem neuesten Stand halten. Die Unterstützung von Browsern, die nur auf der Anzahl der Logs basiert, bietet keine angemessene Sicherheitsvalidierung. Es geht nicht nur darum, dass Nutzer neue Funktionen nicht nutzen können, sondern auch darum, dass wir unserer Verantwortung, Nutzer zu schützen, nicht nachkommen.

Die Frage verschiebt sich von „Wie viele Nutzer verwenden diese Version?“ zu „Sollten wir Nutzer überhaupt auf Grundlage von Browserversionen unterstützen?“

Warum Baseline die richtige Antwort für Cybozu ist

Cybozu benötigte einen neuen Ansatz, der nicht nur den betrieblichen Aufwand für die Einhaltung der Browserunterstützungskriterien, sondern auch die grundlegenden Mängel der alten Methodik berücksichtigte. Baseline hat Cybozu genau das ermöglicht.

Extern verwaltete, sich entwickelnde Kriterien

Anstatt Browserversionen jedes Quartal manuell neu zu bewerten, bietet Baseline ein dynamisches Ziel, das von der WebDX Community Group des W3C verwaltet wird und nicht von einzelnen Unternehmen, die willkürliche Entscheidungen treffen. Das bedeutet, dass sich die Kriterien automatisch mit Beiträgen von Browseranbietern und Normungsgremien weiterentwickeln.

Kintone muss Versionsschwellenwerte nicht mehr selbst verwalten. Die Baseline wird ohne weiteres Zutun weiterentwickelt. Der Baseline-Status für Funktionen beantwortet Verfügbarkeitsfragen endgültig und die Antwort wird aktualisiert, wenn sich die Plattform weiterentwickelt.

Präzision auf Funktionsebene

Anstatt die Situation eines einzelnen Browsers zu verfolgen, verfolgt Baseline einen grundlegend anderen Ansatz.

„Weit verbreitet“ steht für Webfunktionen, die seit mindestens 30 Monaten in den wichtigsten Browsern verfügbar sind. Dieser Zeitraum wurde festgelegt, um Entwicklersignale, die Akzeptanz von Browserversionen im Laufe der Zeit, eine Schätzung der Unterstützung eines hohen Gesamtmarktanteils und die beste Einschätzung der WebDX Community Group zu berücksichtigen. Durch Festlegen dieses Schwellenwerts entfällt die Aufgabe, nicht beobachtbare einzelne Browsersituationen zu erfassen.

Mit Baseline erhalten Entwickler eine direkte Antwort auf die Frage, ob eine bestimmte Funktion in verschiedenen Browsern verfügbar ist. Die Frage „Können wir CSS-Containerabfragen verwenden?“ kann jetzt beantwortet werden. Entwickler können den Baseline-Status sofort auf MDN oder in anderen Dokumenten prüfen, ohne Kompatibilitätsmatrizen abgleichen zu müssen.

Von Grund auf sicher

Durch die Einführung von „Baseline Widely available“ als Standard hat Cybozu seine Supportrichtlinie an einen Zeitraum angepasst, der natürlich mit den Support-Lebenszyklen der Browseranbieter korreliert. Browser, die weiterhin aktiv gewartet werden, unterstützen alle allgemein verfügbaren Funktionen und erhalten außerdem wichtige Sicherheitsupdates.

Auf Zugriffsprotokollen basierende Kriterien hatten das Potenzial, den Support an veraltete Browser zu binden, was den Anreiz für Nutzer, ihre Browser zu aktualisieren, verringert. Durch die Einführung von Baseline können wir nicht nur moderne Funktionen sicher nutzen, sondern Nutzer mit veralteten Browsern werden auch automatisch aufgefordert, ihren Browser zu aktualisieren, wenn sich die Webplattform weiterentwickelt.

Baseline schließt anfällige Browser nicht explizit aus, sondern bietet Nutzern natürliche Anreize, ihre Browser auf dem neuesten Stand zu halten.

Baseline übernehmen

Die Einführung von Baseline erforderte eine Umstellung der bisherigen Versionsverwaltung von Cybozu. Cybozu musste also darauf vertrauen können, dass Baseline ohne wesentliche Nachteile funktionieren würde. Für die Einführung auf Unternehmensebene war es entscheidend zu wissen, wie viel Prozent der Nutzer betroffen wären.

Der Google Analytics Baseline Checker ist ein Tool, mit dem Daten analysiert werden, die aus Google Analytics exportiert wurden. Es zeigt, wie viel Prozent Ihrer Nutzer Funktionen aus den einzelnen Baseline-Jahren unterstützen. Mit diesem Tool konnte Cybozu die tatsächlichen Auswirkungen der Auswahl eines Baseline-Ziels auf die Nutzer prüfen. Nachdem Cybozu den Baseline Checker ausgeführt hatte, wurde etwas Bemerkenswertes festgestellt:

Der Baseline Checker hat ergeben, dass 98,8% der Nutzer von Cybozu Browser verwendet haben, die das Ziel „Weit verbreitete Baseline“ unterstützen. Das ist eine breitere Abdeckung als der bisherige interne Standard von Cybozu von mindestens 98% der Nutzer. Anhand der bereitgestellten Daten können drei wichtige Punkte analysiert werden:

• Bisher unterstützte Browser sind davon nicht betroffen.
• Bisher nicht unterstützte Browser: Diese machen etwa 0,8% aus und erfüllen die Kriterien für „Weitgehend verfügbar“ von Baseline, sehen aber nicht mehr die Aufforderung zur Browseraktualisierung.
• Die übrigen Browser erhalten weiterhin die Aufforderung, den Browser zu aktualisieren.

Das bedeutete vor allem, dass Falschmeldungen eliminiert werden konnten – die etwa 0,8% der Nutzer, denen unnötigerweise Warnungen angezeigt wurden, obwohl sie geeignete Browser verwendeten. Gleichzeitig durften keine fälschlicherweise negativen Ergebnisse durch Warnungen für Nutzer entstehen, die zuvor unterstützt wurden.

Mit diesen Daten konnte Cybozu Baseline Widely available als Ziel festlegen.

Die Auswirkungen von Baseline in der Praxis

Die Einführung von Baseline als Richtlinie war das eine, aber die Umsetzung erforderte die Entwicklung von Tools und Prozessen. Es war notwendig, um zu verhindern, dass Entwickler versehentlich nicht unterstützte Funktionen verwenden, ohne den Baseline-Status manuell zu prüfen.

Statische Analyse basierend auf der ESLint-Konfiguration

@cybozu/eslint-config ist eine OSS-basierte Konfiguration, die in allen Cybozu-Produkten verwendet wird. Sie wurde ab dem css-baseline-Preset unterstützt, mit dem CSS-Funktionen zur Build-Zeit mit Baseline verglichen werden:

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

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

Wenn Entwickler Funktionen verwenden, die noch nicht allgemein verfügbar sind, erhalten sie sofortiges Feedback von ESLint:

So wird verhindert, dass Kompatibilitätsprobleme in der Produktion auftreten. Entwickler können frühzeitig im Entwicklungsprozess fundierte Entscheidungen treffen: Entweder warten sie, bis die Funktion allgemein verfügbar ist, oder sie implementieren Progressive Enhancement und wissen genau, welche Nutzer betroffen sein werden. Weitere Informationen zur Unterstützung von CSS und Baseline durch ESLint

Transpiler für die Zielgruppe „Baseline Widely available“ konfigurieren

Moderne Buildtools unterstützen Baseline als Ziel. Vite zielt beispielsweise ohne zusätzliche Konfiguration automatisch auf „Baseline Widely Available“ in der Produktion ab. Browserslist unterstützt jetzt auch Baseline.

Durch die Verwendung verschiedener Compilereinstellungen wird sichergestellt, dass unser JavaScript und CSS nur bei Bedarf transpiliert werden. So werden unnötige Transformationen und Polyfills für Funktionen vermieden, die bereits weitgehend unterstützt werden.

Manuelle Kriterienpflege und Browsererkennungssystem für Nutzerfeedback eliminieren

Die größte Wartungseinsparung ergab sich durch den Wegfall der manuellen Browserversionsverfolgung. Anstelle von vierteljährlichen Besprechungen, in denen diskutiert wird, welche Browserversionen unterstützt werden sollen, verlässt sich Cybozu jetzt auf das öffentlich verwaltete @web-platform-dx/baseline-browser-mapping-Paket, um diese Fragen zu beantworten.

Cybozu hat außerdem eine automatische Browsererkennung entwickelt, um Nutzern mit veralteten Browsern Upgrade-Aufforderungen anzuzeigen.

Die Browsererkennung ruft kompatible Browserversionen direkt aus dem @web-platform-dx/baseline-browser-mapping-Paket ab.

Diese wird während des Build-Prozesses ausgeführt und generiert Warnbanner, die für alle Produktteams freigegeben werden. Wenn sich das Zeitfenster „Weit verbreitete Baseline“ verschiebt, um neuere Browser einzuschließen, werden die Änderungen automatisch von unserem System übernommen. Es ist kein manuelles Eingreifen erforderlich.

Optimierte Kommunikation

Einer der wichtigsten, aber unerwarteten Vorteile war, dass Baseline die teamübergreifende Kommunikation vereinfacht hat. Bisher waren für Diskussionen zur Browserkompatibilität unternehmensspezifische Fachkenntnisse erforderlich – welche Browser wir unterstützen, welche Versionen und welche Funktionen jetzt verfügbar sind. Neue Mitarbeiter benötigten Zeit, um unsere internen Standards zu lernen. Mit Baseline beziehen wir uns jetzt auf dieselben Kompatibilitätskriterien, die in der Web-Community weit verbreitet sind.

So wird auch ein gemeinsames Vokabular sowohl in unseren Entwicklungsteams als auch in der gesamten Web-Community geschaffen. Bei der Erörterung der Einführung von Funktionen beziehen sich alle auf dieselben Daten aus derselben Quelle. Es ist also nicht erforderlich, interne Richtlinien zu erläutern oder zwischen verschiedenen Kompatibilitäts-Frameworks zu übersetzen.

Auch die Entwicklungstools haben aufgeholt: Visual Studio Code und der Bereich „Stile“ in den Chrome-Entwicklertools zeigen jetzt direkt Informationen zur Baseline-Kompatibilität an. Entwickler müssen nicht mehr ständig auf MDN oder Can I use nachsehen, ob eine Funktion sicher verwendet werden kann. Das Tooling informiert sie sofort.

Das Produkt für alle nutzbar machen

Mit Baseline konnten wir unsere Denkweise in Bezug auf die Browserkompatibilität grundlegend ändern – von einer Belastung, die wir bewältigen, zu einer Grundlage, der wir vertrauen. Unsere Implementierungsstrategie basiert auf Automatisierung in jeder Phase:

1. Feedback während der Entwicklung: Statische Analyse und Statuskarte für die Baseline.
2. Validierung zur Build-Zeit: Transpiler zielen automatisch auf „Baseline Widely Available“ ab.
3. Laufzeiterkennung: Nutzerorientierte Warnungen für nicht unterstützte Browser mit baseline-browser-mapping.
4. Kontinuierliche Updates: Durch die automatische Synchronisierung mit den Baseline-Daten entfällt die manuelle Wartung.

Diese Ergebnisse sprechen für sich.

• Keine Stunden für die Wartung der Browserversion.
• Über 98,8% der Nutzerabdeckung werden mit Gewissheit auf Funktionsebene beibehalten.
• Sofortige und spontane Antworten auf häufig gestellte Fragen, die die Frage beantworten, ob diese Funktion in der jeweiligen Browserversion verwendet werden kann.
• Gemeinsames Vokabular für alle Entwicklungsteams.
• Deutlichere Anleitung zur Einführung von Funktionen: Teams werden aufgefordert, die Integration neuer Funktionen und den Zeitpunkt für das Entfernen von Polyfills zu besprechen, falls erforderlich.

Für Organisationen, die die Einführung von Baseline in Erwägung ziehen, ist es wichtig zu wissen, wie sich die Umstellung auf ihre Nutzer auswirken wird. Tools wie Google Analytics Baseline Checker machen diese Analyse einfacher und nachvollziehbarer. Wenn Sie sich von den Daten überzeugt haben und sich für Baseline entscheiden, können Sie das wachsende Ökosystem von Baseline nutzen, um Ihren Entwicklungs-Workflow zu organisieren.

Die Webplattform ist leistungsstärker, konsistenter, zuverlässiger und entwickelt sich schneller als in der Vergangenheit. Mit Baseline können wir diese Leistung in der Produktion zuverlässig nutzen.

Ressourcen

• Originalartikel auf Japanisch: プロダクト開発の基準に Baseline を取り入れるまで - Cybozu Inside Out
• Cybozu ESLint-Konfiguration: @cybozu/eslint-config auf GitHub
• Google Analytics Baseline Checker: Google Analytics Baseline Checker
• Baseline-Browserzuordnung: @web-platform-dx/baseline-browser-mapping
• Weitere Informationen zu Baseline: Baseline bei MDN