Teste cross-browser é verificar se um site aparece e funciona direito nos navegadores que os seus visitantes usam, nos aparelhos em que eles usam. Na prática, são três motores de renderização (Blink do Chromium, WebKit do Safari e Gecko do Firefox), no desktop e no celular. Dá para cobrir quase tudo de graça com navegadores instalados, Playwright e uma visualização mobile, e pagar por aparelhos na nuvem só quando você precisar de hardware real que não tem.
Quais navegadores testar
Comece pelo seu próprio analytics, não por um ranking mundial. Um dashboard B2B pode ser usado principalmente no Chrome e no Edge de desktop, enquanto uma loja para o consumidor final pode ter a maior parte do tráfego no Safari do iPhone. Veja os relatórios de navegadores e aparelhos dos últimos três meses e cubra tudo o que passar de alguns por cento das sessões.
Se você ainda não tem dados, este conjunto cobre os motores e a maior parte do tráfego real:
| Navegador | Motor | Por que importa |
|---|---|---|
| Chrome (desktop e Android) | Blink | Maior participação no desktop e no Android |
| Safari (iPhone, iPad, Mac) | WebKit | Todos os usuários de iPhone e a maioria dos bugs que “só acontecem no celular” |
| Edge | Blink | Padrão no Windows; normalmente se comporta como o Chrome |
| Firefox | Gecko | Motor próprio; revela suposições que na verdade são manias do Chromium |
| Samsung Internet | Blink | Vem instalado nos celulares Samsung, com ciclo de atualização e modo escuro próprios |
Dois motores merecem mais atenção: o WebKit, por causa do iPhone, e o Gecko, por ser o único motor relevante que não é nem da Apple nem do Google.
O que verificar em cada navegador
Bugs entre navegadores se concentram em lugares previsíveis. Passe por esta lista em cada página importante:
- Layout.
gapem flexbox e grid,position: sticky,aspect-ratioe container queries em versões antigas dos navegadores. - Fontes. As fontes web carregam, as fontes alternativas têm métricas parecidas e não há texto invisível durante o carregamento.
- Formulários. Seletores de data e hora, estilo do
select, cores do preenchimento automático, mensagens de validação e o tipo de teclado mobile de cada campo. - Mídia. Regras de autoplay de vídeo (a maioria dos navegadores mobile só permite sem som), formatos de imagem como AVIF e qual imagem o
srcsetescolhe. - Rolagem e unidades de viewport.
100vhcontra o100dvhdinâmico no celular, scroll snapping, rolagem suave e overscroll. - APIs de JavaScript. Qualquer coisa com menos de dois anos: confira o suporte antes de depender dela.
- Interação. Menus que só abrem no hover em telas de toque, contorno de foco para quem usa teclado e áreas de toque.
- Modo escuro e zoom. Páginas com zoom de 200% e com o modo escuro do sistema.
Ferramentas gratuitas que fazem a maior parte do trabalho
Instale os navegadores. Chrome, Edge e Firefox rodam em qualquer sistema de desktop. O Safari só roda no macOS, e esse é o principal motivo de quem não tem Mac precisar de ferramentas extras.
Confira o suporte antes de escrever código. O Baseline marca os recursos da web como “newly available” ou “widely available” nos principais navegadores, e o Can I use traz tabelas de suporte versão por versão. Consultar os dois antes evita a maioria dos bugs entre navegadores.
Automatize com Playwright. O Playwright roda o mesmo script de teste no Chromium, no Firefox e no WebKit, em Windows, macOS e Linux, e consegue emular aparelhos móveis. Um script curto que abre as dez páginas mais importantes nos três motores e salva prints pega a maioria das regressões em cada pull request.
Use visualizações mobile para checar a responsividade. Problemas de layout mobile costumam ser confundidos com problemas de navegador. Descarte isso rápido com o modo dispositivo do DevTools ou com uma extensão como o Mobile View Extension e só depois procure causas específicas do motor. A diferença entre as duas ferramentas está explicada em simulador mobile em extensão ou DevTools.
Use emuladores para os motores mobile. O Simulador do Xcode traz o Safari real do iOS num Mac (guia); o emulador do Android Studio traz o Chrome real do Android (guia).
Quando vale pagar por ferramentas de teste cross-browser
Serviços de teste na nuvem alugam aparelhos reais e muitas versões de navegador. Vale pagar quando:
- você não tem Mac e precisa testar o Safari do iPhone com frequência;
- seus clientes usam versões antigas de navegador que não dá para instalar lado a lado;
- um contrato exige testes em modelos específicos de celular;
- seus testes automatizados precisam rodar em hardware mobile real.
Para um site pequeno, um plano mensal usado na semana de lançamento costuma bastar; para verificações ocasionais, os testes grátis já ajudam bastante.
Uma rotina cross-browser enxuta
- Durante o desenvolvimento: consulte o Baseline antes de usar um recurso novo e confira a visualização mobile enquanto programa.
- Em cada pull request: rode prints do Playwright no Chromium, Firefox e WebKit.
- Antes do lançamento: percorra os fluxos principais no Safari (Mac ou simulador), no Firefox e no Chrome do Android.
- Depois do lançamento: acompanhe o monitoramento de erros e o analytics, com os erros agrupados por navegador.
A parte mobile da checagem de lançamento está detalhada no checklist de teste de site mobile.
Perguntas frequentes
Como testar meu site em vários navegadores de graça?
Instale Chrome, Edge e Firefox, use o Playwright para rodar o WebKit em qualquer sistema e use o DevTools ou uma extensão de visualização mobile para os tamanhos de celular. No Mac, o Simulador do Xcode acrescenta o Safari real do iOS.
Preciso testar no Edge se já testei no Chrome?
O Edge usa o mesmo motor do Chrome, então diferenças são raras. Uma passada rápida basta, a menos que seu público use recursos específicos do Edge ou políticas corporativas.
Qual é hoje a causa mais comum de bugs entre navegadores?
Usar um recurso de CSS ou JavaScript antes de ele ter suporte em todos os navegadores dos seus usuários. Checar o status no Baseline antes de adotar o recurso evita a maioria desses bugs.