Publicado em: 7 de novembro de 2025
Gerenciar a compatibilidade de navegadores para mais de 38 mil clientes empresariais no Japão não é uma tarefa simples. Quando o Kintone alimenta operações comerciais críticas para mais de 1,5 milhão de aplicativos diariamente, toda decisão de suporte a navegadores é importante.
A Cybozu, uma empresa líder de groupware no Japão, enfrentou um desafio fundamental: como manter padrões da Web consistentes em todos os produtos e evitar o trabalho de manutenção de matrizes de suporte a navegadores personalizados.
A solução? Adotar o Baseline como um padrão de desenvolvimento, uma mudança que transformou a abordagem deles para a adoção de recursos da plataforma da Web.
O desafio: suporte a navegadores com estimativas
Antes do Baseline, a Cybozu mantinha os próprios critérios de suporte a navegadores com base em registros de acesso e rastreamento manual de versões. O padrão era oferecer suporte a navegadores que cobriam os 98% principais dos registros de acesso, e os usuários em navegadores fora desse limite recebiam uma solicitação de atualização do navegador.
A cada trimestre, as equipes de engenharia da Cybozu gastavam aproximadamente uma hora no total para atualizações de critérios. Ainda assim, a integração dos critérios com a equipe de desenvolvimento não foi perfeita, e era bastante comum ter dúvidas: quando novos recursos de CSS poderiam ser usados? Quando os polyfills para novas APIs JavaScript podem ser removidos? E, na verdade, quais recursos podem ser usados agora?
Além de não serem fáceis de manter e usar para desenvolvedores, os critérios personalizados da Cybozu não acompanhavam a velocidade da evolução da Web moderna, já que eram baseados na detecção do user agent e no rastreamento manual de versões.
A string User-Agent pode ser confiável?
A abordagem anterior da Cybozu derivava nomes e versões de navegadores de strings User-Agent e agregava esses resultados como dados de "usuário". Mas isso reflete a realidade dos usuários?
User-Agent é um cabeçalho de solicitação HTTP, ou seja, informações que qualquer cliente pode alegar ser qualquer coisa. Os registros de acesso ao produto contêm grandes volumes de solicitações de bots, rastreadores, invasores e outras fontes. Alguns clientes enviam intencionalmente strings User-Agent antigas para várias finalidades, como verificação de vulnerabilidades. Portanto, os registros de acesso não podem representar os usuários que precisam de suporte.
O User-Agent não pode refletir os recursos disponíveis
As versões do navegador não são mapeadas para recursos. O mesmo número de versão pode ter recursos diferentes dependendo do canal (Stable/Beta/Dev/Canary), das flags de recursos, dos experimentos do Finch ou das políticas empresariais, por exemplo. Além disso, navegadores diferentes implementam recursos em cronogramas diferentes. O aninhamento de CSS foi lançado no Safari 16.5 (maio de 2023), mas no Chrome 112 (abril de 2023). A string User-Agent não indica a disponibilidade do recurso.
Responsabilidade de oferecer suporte às versões do navegador
As atualizações do navegador não são apenas sobre novos recursos. As versões regulares incluem patches de segurança essenciais e correções de bugs, além de novas funcionalidades. Quando versões desatualizadas são compatíveis, evitar o uso de novos recursos não é o único problema. É uma decisão que afeta diretamente a segurança do usuário. Em ambientes empresariais, alguns usuários podem enfrentar restrições legítimas. Exemplo:
- As organizações podem ter políticas de navegador rígidas que impedem atualizações.
- O hardware legado não é compatível com a atualização de navegadores modernos.
- Usuários em setores regulamentados com processos lentos de aprovação de mudanças.
No entanto, apoiar esses usuários também significa permitir que eles continuem vulneráveis.
Se um incidente de segurança ocorrer devido à exploração de uma vulnerabilidade conhecida em uma versão antiga do navegador, não seria uma explicação razoável dizer "esse navegador era compatível porque os usuários pediram". Se o ataque se espalhar para outros usuários que mantêm os navegadores atualizados, os desenvolvedores e outras partes interessadas do projeto serão responsáveis por não interromper o suporte a navegadores não seguros.
A Cybozu percebeu que essa abordagem cria riscos para a maioria dos usuários que mantêm os navegadores atualizados. A compatibilidade com navegadores com base apenas na contagem de registros não tem validação de segurança adequada. Isso não se trata apenas de perder novos recursos, mas de falhar na responsabilidade de proteger os usuários.
A pergunta muda de "Quantos usuários estão nessa versão?" para "Precisamos oferecer suporte aos usuários com base nas versões do navegador?"
Por que a Baseline é a resposta certa para a Cybozu
A Cybozu precisava de uma nova abordagem que abordasse não apenas o custo operacional de manter os critérios de suporte a navegadores, mas também as falhas fundamentais na metodologia antiga. A base forneceu exatamente isso à Cybozu.
Critérios em constante evolução e mantidos externamente
Em vez de reavaliar manualmente as versões do navegador a cada trimestre, a Baseline oferece uma meta móvel mantida pelo Grupo da comunidade WebDX do W3C, e não por empresas individuais que tomam decisões arbitrárias. Isso significa que os critérios evoluem automaticamente com a entrada de fornecedores de navegadores e órgãos de padrões.
O Kintone não precisou mais gerenciar os limites de versão por conta própria. O Baseline evolui sem nenhuma ação. O status de base para recursos responde a perguntas sobre disponibilidade de forma definitiva, e a resposta é atualizada conforme a plataforma evolui.
Precisão no nível do recurso
Em vez de tentar rastrear a situação de um navegador individual, a Baseline adota uma abordagem fundamentalmente diferente.
A Baseline amplamente disponível representa recursos da Web disponíveis há 30 meses ou mais nos principais navegadores. Esse período foi determinado para "aproximar indicadores de desenvolvedores, a adoção de lançamentos de navegadores ao longo do tempo, uma estimativa de suporte a alta participação total de mercado e o melhor julgamento do Grupo da Comunidade WebDX". Ao definir esse limite, a Baseline elimina a tarefa de rastrear situações individuais não observáveis do navegador.
Com o Baseline, os desenvolvedores recebem uma resposta direta sobre a disponibilidade desse recurso específico em todos os navegadores. "Podemos usar consultas de contêiner CSS?" agora é uma pergunta que pode ser respondida. Os desenvolvedores podem verificar o status da Baseline no MDN ou em outros documentos instantaneamente, sem fazer referências cruzadas em matrizes de compatibilidade.
Segurança incorporada ao design
Ao adotar o Baseline Widely available como nosso padrão, a Cybozu alinhou a política de suporte a um período que se correlaciona naturalmente com os ciclos de vida de suporte dos fornecedores de navegadores. Os navegadores que ainda recebem manutenção ativa são compatíveis com todos os recursos disponíveis e também recebem atualizações de segurança críticas.
Os critérios baseados em registros de acesso tinham o potencial de ancorar o suporte a navegadores desatualizados, o que remove o incentivo para os usuários atualizarem. Ao adotar a Baseline, não só podemos usar recursos modernos com confiança, mas os usuários em navegadores desatualizados naturalmente encontram a necessidade de atualizar à medida que a plataforma da Web avança.
A linha de base não exclui explicitamente navegadores vulneráveis. Ela oferece incentivos naturais para que os usuários mantenham os navegadores atualizados.
Como adotar o valor de referência
A adoção do Baseline exigiu uma mudança no gerenciamento de versões legadas da Cybozu. Isso significava que a Cybozu precisava ter certeza de que o Baseline funcionaria sem desvantagens significativas. Saber qual porcentagem de usuários seria afetada foi crucial para a adoção em nível empresarial.
O Google Analytics Baseline Checker é uma ferramenta que analisa os dados exportados do Google Analytics para mostrar qual porcentagem dos seus usuários é compatível com os recursos de cada ano de referência. Essa ferramenta ajudou a Cybozu a verificar o impacto real da escolha de uma meta de valor de referência nos usuários. Depois de executar o Baseline Checker, a Cybozu descobriu algo notável:
O Baseline Checker revelou que 98,8% dos usuários da Cybozu usavam navegadores compatíveis com o valor do Baseline amplamente disponível. Essa cobertura é mais ampla do que o padrão interno anterior da Cybozu, que era de pelo menos 98% dos usuários. Três pontos principais podem ser analisados com base nos dados fornecidos:
- Os navegadores com suporte anterior não serão afetados.
- Navegadores sem suporte anterior: representam aproximadamente 0,8% que atendem aos critérios do Baseline Widely available, mas não veem mais o comando de atualização do navegador.
- Os outros navegadores continuam recebendo a solicitação de atualização como antes.
Isso significa que os falsos positivos podem ser eliminados, ou seja, os 0,8% de usuários que receberam avisos desnecessários, mesmo usando navegadores compatíveis. Ao mesmo tempo, não é possível introduzir falsos negativos avisando usuários que tinham suporte antes.
Com esses dados, a Cybozu pôde adotar com confiança o Baseline amplamente disponível como uma meta.
O impacto do valor de referência na prática
Adotar o Baseline como uma política foi uma coisa, mas torná-lo operacional exigiu a criação de ferramentas e processos. Era necessário garantir que os desenvolvedores não usassem acidentalmente recursos sem suporte sem verificar manualmente o status da linha de base.
Análise estática com base na configuração do ESLint
@cybozu/eslint-config é uma configuração baseada em OSS usada em todos os produtos da Cybozu. Ele passou a ser compatível com a predefinição css-baseline, que verifica os recursos de CSS em relação ao Baseline no momento da criação:
// eslint.config.mjs
import cybozuEslintConfigBaseline from '@cybozu/eslint-config/flat/presets/css-baseline.js';
export default [
...cybozuEslintConfigBaseline.map((config) => ({
...config,
files: ['**/*.css']
})),
];
Quando os desenvolvedores usam recursos que ainda não estão disponíveis para todos, eles recebem feedback imediato do ESLint:
Isso evita que problemas de compatibilidade cheguem à produção. Os desenvolvedores podem tomar decisões fundamentadas no início do processo de desenvolvimento: esperar que o recurso fique disponível para todos ou implementar o aprimoramento progressivo sabendo exatamente quais usuários serão afetados. Saiba mais sobre o suporte do ESLint para CSS e Baseline.
Configurar transcompiladores para segmentar o Baseline amplamente disponível
As ferramentas de build modernas começaram a oferecer suporte ao Baseline como destino. Por exemplo, o Vite segmenta automaticamente a versão de produção do Baseline Widely Available sem configuração adicional. A Browserslist agora também é compatível com o Baseline.
Usar várias configurações de compilador garante que nosso JavaScript e CSS sejam transpilados apenas quando necessário, evitando transformações e polyfills desnecessários para recursos que já são amplamente compatíveis.
Eliminar a manutenção manual de critérios e o sistema de detecção de navegador para feedback do usuário
O maior benefício da manutenção foi a eliminação do rastreamento manual da versão do navegador. Em vez de reuniões trimestrais para debater quais versões de navegador oferecer suporte, a Cybozu agora usa o pacote @web-platform-dx/baseline-browser-mapping de manutenção aberta para responder a essas perguntas.
A Cybozu também criou uma detecção automática de navegador para mostrar solicitações de upgrade aos usuários em navegadores desatualizados.
A detecção de navegador busca versões compatíveis diretamente do pacote @web-platform-dx/baseline-browser-mapping.
Isso é executado durante nosso processo de build e gera banners de aviso que são compartilhados em todas as equipes de produtos. À medida que a janela de disponibilidade geral da linha de base se move para incluir navegadores mais recentes, nosso sistema detecta automaticamente as mudanças sem necessidade de intervenção manual.
Comunicação simplificada
Um dos benefícios mais significativos e inesperados foi como o Baseline simplificou a comunicação entre equipes. Antes, as discussões sobre compatibilidade de navegadores exigiam conhecimento específico do domínio da empresa, como quais navegadores e versões são compatíveis e quais recursos estão disponíveis. Os recém-chegados precisavam de tempo para aprender nossos padrões internos. Com a Baseline, agora fazemos referência aos mesmos critérios de compatibilidade amplamente reconhecidos na comunidade da Web.
Isso também cria um vocabulário compartilhado entre nossas equipes de engenharia e com a comunidade da Web em geral. Ao discutir a adoção de recursos, todos se referem aos mesmos dados da mesma fonte, eliminando a necessidade de explicar políticas internas ou traduzir entre diferentes frameworks de compatibilidade.
As ferramentas de desenvolvimento também foram atualizadas: o Visual Studio Code e o painel Estilo no Chrome DevTools agora mostram informações de compatibilidade com a linha de base diretamente. Os desenvolvedores não precisam mais verificar constantemente o MDN ou o Posso usar? para saber se um recurso é seguro. A ferramenta informa imediatamente.
Faça o produto funcionar para todos com confiança
Com a referência, podemos mudar fundamentalmente nossa maneira de pensar sobre a compatibilidade de navegadores, de um fardo que gerenciamos para uma base em que confiamos. Nossa estratégia de implementação se concentrou na automação em todas as etapas:
- Feedback durante o desenvolvimento: análise estática e card de status de base.
- Validação no momento da build: os transcompiladores segmentam automaticamente a linha de base amplamente disponível.
- Detecção no ambiente de execução: avisos para o usuário sobre navegadores não compatíveis usando
baseline-browser-mapping. - Atualizações contínuas: a sincronização automatizada com dados de comparativo elimina a manutenção manual.
Os resultados falam por si só:
- Zero horas gastas com a manutenção da versão do navegador.
- Mais de 98,8% da cobertura de usuários é mantida com certeza no nível do recurso.
- Respostas instantâneas e espontâneas a perguntas frequentes, que respondem à pergunta "Podemos usar esse recurso nesta versão do navegador?"
- Vocabulário compartilhado entre as equipes de engenharia.
- Caminho mais claro para a adoção de recursos: incentiva as equipes a discutir a integração de novos recursos e o momento de remover polyfills, se necessário.
Para organizações que estão considerando a adoção do Baseline, é fundamental saber como a mudança vai afetar os usuários. Ferramentas como o Verificador de valores de referência do Google Analytics tornam essa medição mais simples e explicativa. Quando você tiver confiança nos dados e decidir adotar o Baseline, poderá usar o ecossistema crescente dele para organizar seu fluxo de trabalho de desenvolvimento.
A plataforma da Web é mais potente, consistente, confiável e evolui mais rapidamente do que no passado. Com o Baseline, podemos aproveitar esse poder na produção com confiança.
Recursos
- Artigo original em japonês: プロダクト開発の基準に Baseline を取り入れるまで - Cybozu Inside Out
- Configuração do ESLint da Cybozu:
@cybozu/eslint-configno GitHub - Verificador de métricas de comparativo de mercado do Google Analytics: Verificador de métricas de comparativo de mercado do Google Analytics
- Mapeamento de navegador de referência:
@web-platform-dx/baseline-browser-mapping - Saiba mais sobre o Baseline: Baseline na MDN