Como testar a responsividade de um site: um método que acha bugs de verdade

Para testar bem um design responsivo, faça três passadas: varra devagar a largura do viewport de uns 320 px até 1920 px para achar onde o layout quebra, confira aparelhos específicos com user agent e densidade de pixels reais, e force o layout com conteúdo longo e zoom de 200%. A maioria dos bugs de responsividade mora entre os breakpoints e em conteúdo para o qual ninguém desenhou, e é por isso que conferir três tamanhos fixos (“celular, tablet, desktop”) deixa eles passarem.

Por que conferir três tamanhos não basta

Um layout é desenhado em poucas larguras, mas é usado em todas. Um título que cabe em 375 px pode quebrar feio em 344 px (alguns celulares dobráveis fechados). Uma barra de navegação que cabe em 1024 px pode estourar em 1100 px quando um item do menu fica mais comprido. Os bugs se concentram:

• logo abaixo e logo acima de cada breakpoint;
• em larguras para as quais ninguém desenhou, como 600–700 px (tablets pequenos, janelas em tela dividida);
• com conteúdo real mais longo que o do mockup.

Passada 1: a varredura de larguras

1. Abra o Chrome DevTools, ative a barra de dispositivos (Ctrl + Shift + M, ou Cmd + Shift + M no Mac) e escolha Responsive.
2. Defina a largura em 320 px e arraste devagar a borda direita até o maior tamanho que você suporta.
3. Observe: barras de rolagem horizontal, textos sobrepostos, botões quebrando em duas linhas, imagens esticadas, grids com um card órfão e elementos pulando quando um breakpoint muda.
4. Quando algo quebrar, anote a largura exata mostrada na barra.

Ative Show media queries no menu da barra de dispositivos para ver seus breakpoints como barras coloridas acima do viewport. Clicar numa barra leva para aquela largura. A ajuda passo a passo do modo dispositivo está no guia do emulador mobile do Chrome.

Um bom hábito: teste cada breakpoint no valor exato e um pixel abaixo. Erros de um pixel entre max-width: 768px e min-width: 768px são muito comuns.

Passada 2: perfis de aparelhos reais

A largura é só parte do que um celular informa. Os aparelhos também enviam um user agent mobile, têm densidade de pixels 2 ou 3 e podem disparar um comportamento diferente no servidor ou no JavaScript. Confira as páginas principais em perfis específicos:

• um celular pequeno (uns 360–375 px de largura);
• um iPhone atual (393–402 px) e um iPhone grande (430–440 px); os valores estão na tabela de tamanhos de tela do iPhone;
• um celular Android (360–412 px);
• um tablet nas duas orientações (guia de iPad e tablets).

Os presets de aparelhos do DevTools servem para isso. Uma extensão de teste de responsividade como o Mobile View Extension é mais rápida quando você precisa navegar por muitas páginas: ela recarrega a aba com o user agent, o tamanho de tela e a densidade de pixels do aparelho, mantém o aparelho enquanto você navega e deixa comparar lado a lado visualizações da mesma página.

Passada 3: force o conteúdo

Mockups usam conteúdo perfeito. Sites reais, não. Teste:

• Palavras e textos longos: um nome de produto enorme, uma tradução em alemão, um e-mail ou uma URL numa coluna estreita. Adicione overflow-wrap: anywhere onde for preciso.
• Mais ou menos itens: um menu com oito itens em vez de cinco, um grid com sete cards em vez de seis.
• Imagens ausentes: como fica o card quando a imagem falha ou ainda está carregando?
• Texto grande: defina o tamanho de fonte padrão do navegador em 20 px ou mais. Layouts feitos com rem devem escalar; caixas de altura fixa vão cortar o texto.
• Zoom de 200% e 400% no desktop: o zoom estreita o viewport CSS, então em 400% uma janela de 1280 px se comporta como uma tela de 320 px. A WCAG 2.2 exige que, nesse tamanho, o conteúdo se reorganize sem rolagem em duas direções, com exceção de conteúdos como mapas e tabelas de dados.

Passada 4: automatize os prints

Passadas manuais acham um bug uma vez, e um print mobile anexado a um chamado mostra a largura exata em que algo quebrou. Prints automáticos pegam o bug quando ele volta. Com uma ferramenta como o Playwright, um script curto pode abrir as páginas principais em, por exemplo, 360, 768, 1024 e 1440 px no Chromium, Firefox e WebKit e comparar os prints com a versão anterior em cada pull request. Esse tipo de teste de regressão visual combina bem com design systems e páginas de marketing que mudam com frequência.

Testadores de responsividade online

Sites que mostram sua URL em várias molduras ao mesmo tempo ajudam numa visão rápida. Eles têm limites: carregam a página a partir dos servidores deles ou em iframes, então não alcançam localhost nem páginas atrás de login; muitos sites bloqueiam ser exibidos em iframe; e as molduras normalmente mudam só a largura, não o user agent. Use para dar uma olhada, não para aprovar.

Checklist de teste de responsividade

Para as verificações mais amplas antes do lançamento, além do layout (formulários, velocidade, SEO), use o checklist de teste de site mobile.

Perguntas frequentes

Como testar rápido a responsividade de um site?

Abra o Chrome DevTools, escolha o modo Responsive na barra de dispositivos e arraste a largura a partir de 320 px. Tudo o que estourar ou se sobrepuser é um bug de responsividade.

Quais tamanhos de tela testar no design responsivo?

Varra todas as larguras a partir de 320 px e depois confira 360, 375, 390–402, 412 e 430–440 px para celulares, cerca de 768–834 px e 1024 px para tablets, e 1280–1920 px para desktop.

Redimensionar a janela do navegador é um teste de responsividade válido?

É um teste válido dos breakpoints de CSS, mas navegadores de desktop param de encolher por volta de 500 px e não enviam user agent mobile. Para larguras de celular, use o modo dispositivo ou uma extensão de visualização mobile.