O teste de compatibilidade entre navegadores verifica se os recursos e o layout de um site funcionam de forma consistente em todos os navegadores, versões de navegador, sistemas operacionais e dispositivos que você suporta, e inclui corrigir o que quebra. O teste entre navegadores em geral trata do processo e das ferramentas de teste; o teste de compatibilidade trata das diferenças em si: um recurso de CSS que um navegador ainda não lançou, um seletor de datas que se comporta de modo diferente no Android ou um login que falha quando cookies de terceiros são bloqueados.
O que é teste de compatibilidade entre navegadores?
Um navegador é compatível com o seu site quando todos os recursos de que ele depende são suportados e renderizados como você planejou. O teste de compatibilidade, muitas vezes abreviado como CBT, responde a três perguntas:
- Quais navegadores e versões nós suportamos?
- Todos os recursos que usamos funcionam em todos eles, ou têm uma alternativa adequada onde não funcionam?
- O último lançamento de navegador ou a nossa última implantação quebrou alguma coisa?
O teste de compatibilidade mais amplo também pode abranger sistemas operacionais, hardware, leitores de tela e redes lentas, mas, em sites, é no lado do navegador que surge a maioria dos problemas.
Por que a compatibilidade ainda importa em 2026
- Seu público está dividido entre motores. Os números do StatCounter de setembro de 2026 dão ao Chrome 66,4% do uso mundial de navegadores, ao Safari 18,3%, ao Edge 6,0%, ao Firefox 2,8% e ao Samsung Internet 2,3%. No celular, o Safari tem 24,7%, e nos Estados Unidos tem 30,4% considerando todos os dispositivos.
- Todo navegador do iPhone roda WebKit. Chrome, Firefox e Edge no iOS usam o motor da Apple (com uma exceção limitada na UE), então um bug do Safari atinge todos os usuários de iPhone, qualquer que seja o navegador escolhido.
- Os recursos chegam em momentos diferentes. Novidades de CSS e JavaScript chegam a cada navegador em seu próprio ritmo, e versões antigas persistem em dispositivos que não recebem mais atualizações.
- Busca e conversões. O Google indexa a versão mobile das suas páginas, então um layout que quebra em celulares prejudica tanto os visitantes quanto a visibilidade.
Passo 1: defina sua matriz de suporte de navegadores
Você não consegue suportar tudo, então anote o que realmente suporta. Parta dos seus dados de análise e agrupe os navegadores em níveis:
| Nível | Navegadores típicos | Compromisso |
|---|---|---|
| A: suporte completo | Versões atuais de Chrome, Safari (Mac e iPhone), Edge e Firefox; Samsung Internet se você tiver tráfego Android | Tudo funciona e aparece como projetado; testes automatizados rodam a cada alteração |
| B: funcional | Versões mais antigas que ainda aparecem nos seus dados de análise | Os fluxos principais funcionam; pequenas diferenças visuais são aceitáveis |
| C: básico | Todo o resto | O conteúdo é legível e os formulários são enviados |
Guarde a matriz como uma configuração do Browserslist para que ferramentas de build como Autoprefixer e Babel mirem os mesmos navegadores. O Baseline é um atalho útil: um recurso marcado como "Baseline widely available" funciona em todos os navegadores principais (Chrome, Edge, Firefox e Safari no desktop e no celular) há pelo menos 30 meses, então a maioria dos sites pode usá-lo sem alternativa.
Como encontrar e corrigir problemas de compatibilidade
- Verifique o suporte antes de construir. Consulte os novos recursos no MDN, cujas páginas mostram tabelas de compatibilidade de navegadores e o status no Baseline, ou no Can I use. O projeto Baseline explica como o status é definido.
- Detecte recursos, não navegadores. Envolva o CSS mais novo em
@supportse verifique se uma API existe em JavaScript antes de chamá-la, em vez de adivinhar pela string do user agent. - Construa com aprimoramento progressivo. Faça o conteúdo e os formulários funcionarem primeiro com HTML e CSS básicos, e depois adicione os recursos mais novos por cima.
- Automatize as correções de rotina. O Autoprefixer adiciona prefixos de fornecedor, Babel e polyfills cobrem motores JavaScript mais antigos, e linters como o eslint-plugin-compat avisam quando o código usa algo que os alvos do seu Browserslist não suportam.
- Teste nos três motores. O Playwright executa os mesmos testes em Chromium, Firefox e WebKit, e suas comparações de capturas de tela detectam desvios de layout.
- Confirme em dispositivos reais. Emuladores e modos de design responsivo servem para uma primeira passada, mas teclados na tela, toque, rolagem e vídeo se comportam de forma diferente em celulares reais. Use seus próprios dispositivos ou uma grade em nuvem como BrowserStack, TestMu AI (antes LambdaTest), Sauce Labs ou BitBar.
- Teste com as proteções de privacidade ativadas. A prevenção de rastreamento do Safari, o modo estrito do Firefox e o Shields do Brave podem bloquear scripts, cookies e incorporações de que o seu site depende.
Problemas de compatibilidade comuns em 2026
| Problema | Onde aparece | Correção típica |
|---|---|---|
| Seções de altura total pulam ou ficam escondidas atrás da barra de ferramentas | Navegadores mobile, especialmente o Safari no iPhone | Use unidades de viewport dinâmicas, como dvh, em vez de vh |
| Recursos mais novos de CSS ignorados | Navegadores que ainda não lançaram o recurso, dispositivos mais antigos | Verifique o status no Baseline e adicione alternativas com @supports |
| Campos de data, hora e seleção têm aparência e comportamento diferentes | Todos os navegadores, que usam seus próprios seletores nativos | Aceite os controles nativos ou use uma biblioteca de componentes bem testada |
| O vídeo não inicia automaticamente ou não é reproduzido dentro da página | Navegadores mobile e Safari | Use reprodução automática apenas com vídeo sem som e adicione playsinline para o iPhone |
| Logins, pagamentos ou widgets de chat incorporados falham | Safari, Firefox e Brave, que restringem cookies de terceiros | Prefira fluxos no próprio site ou a Storage Access API, e teste com as configurações de privacidade padrão |
| O texto quebra de forma diferente e os botões transbordam | Fontes e renderização de fontes diferentes no Windows, macOS e Android | Defina fontes alternativas e deixe folga em botões e menus |
Checklist de compatibilidade entre navegadores
- Matriz de suporte documentada e guardada como configuração do Browserslist.
- Novos recursos verificados no MDN, no Can I use ou no Baseline antes do uso.
- Alternativas implementadas para tudo o que não seja Baseline widely available.
- Testes automatizados passando em Chromium, Firefox e WebKit.
- Formulários, vídeo e rolagem verificados em um iPhone real e em um celular Android real.
- Logins, pagamentos e incorporações testados com as proteções de privacidade padrão ativadas.
- Páginas específicas por região e verificações de bots testadas a partir de outros locais e com outras impressões digitais de navegador (veja como testá-los).
- Testes executados novamente após cada lançamento importante de navegador.
Perguntas frequentes
Preciso de testes de compatibilidade se meu site está bom no Chrome?
Sim. O Chrome responde por cerca de dois terços do uso mundial de navegadores, mas só o Safari representa quase um terço das visitas nos EUA, e todo navegador do iPhone roda no motor do Safari. Testar apenas no Chrome deixa uma grande parcela dos visitantes sem verificação.
Com que frequência devo testar a compatibilidade?
Execute verificações automatizadas a cada alteração de código e após os lançamentos importantes de navegadores, e faça uma rodada manual em dispositivos reais antes de grandes lançamentos ou redesigns.
Testar compatibilidade é caro?
Não precisa ser. Playwright, Selenium e Cypress são gratuitos, assim como os dados do MDN, do Can I use e do Baseline. As grades em nuvem pagas servem principalmente para você não ter de comprar e manter o seu próprio laboratório de dispositivos.
Qual é a diferença entre teste entre navegadores e teste de compatibilidade?
O teste entre navegadores é o processo geral de testar em vários navegadores, abordado em nosso guia de teste entre navegadores. O teste de compatibilidade foca em saber se os recursos e o código específicos que você usa são suportados e em como corrigir ou contornar as lacunas.
