MD
Geralmente 768px de largura.
Antes de basear decisões de design em meia dúzia de breakpoints rígidos, leve em conta a enorme fragmentação de tamanhos de tela e de viewports dos navegadores.
Foi feito um experimento informal para responder: “quão fragmentados são os tamanhos de viewport?”. Foram reunidos mais de 120.000 registros, com mais de 2.300 tamanhos de viewport únicos. Os dados vieram principalmente de pessoas nos EUA e na Europa, então não representam necessariamente um público global, mas ainda servem para este artigo.
O experimento durou só 48 horas, mas os dados obtidos são bem interessantes. Vamos dar uma olhada.
É importante entender o tamanho de 120.000 em termos relativos. Para comparar, vamos supor que cada registro é uma pessoa.
O estádio de Wembley tem capacidade para 90.000 pessoas, então os registros lotariam Wembley uma vez e ainda ocupariam mais um terço da capacidade.
A população de Cheltenham, na Inglaterra, é de cerca de 116.000 pessoas, então os registros dariam para povoar mais do que a cidade inteira!
Se separarmos as 20 viewports únicas mais registradas, a maioria é de tamanhos pequenos. Dá para supor que sejam dispositivos móveis (principalmente as 10 primeiras), mas também vale lembrar que a viewport varia conforme as condições.
Mesmo num único dispositivo iOS, há no mínimo 3 ambientes em que um site pode aparecer, dependendo do estado do sistema operacional.
Isso não é problema se você constrói de forma fluida e flexível, como mostra este diagrama. Mas se você costuma construir com breakpoints muito específicos e valores fixos para tipografia, dimensionamento e espaçamento, pode descobrir que, mesmo com as melhores intenções, não está oferecendo a melhor experiência a quem usa.
Pegue como exemplo uma interface “pixel perfect” com cabeçalho e/ou rodapé fixos. Ela pode ficar ótima quando você encolhe o navegador de desenvolvimento, mas como fica nas condições descritas acima? Como fica numa viewport minúscula, como a de um relógio inteligente? E num celular na horizontal?
Pelas combinações de proporção e dimensões, dá para afirmar com confiança que esses casos estavam representados nos dados. Além disso, teve gente que confirmou.
Antes de se comprometer com cabeçalhos e/ou rodapés fixos, pense em quanto conteúdo as pessoas vão conseguir ver de fato em condições nada ideais.
Neste experimento, foram registradas só a largura e a altura de cada acesso, medidas com window.innerWidth e window.innerHeight. Qualquer largura acima de 800px foi tratada como “desktop” ou, como também dá para chamar, uma viewport grande.
Talvez você esteja pensando “800px é pequeno demais para desktop”, e, se a medição fosse de telas, você teria razão. Mas aqui a medição é de viewports. A viewport é o tamanho da janela do navegador, não o da tela.
Se você está lendo isto num computador, quantas janelas ocupam a tela inteira? Quanto da tela ocupa o navegador em que você está lendo?
O mais seguro é supor que quem usa desktop ou notebook não ocupa a tela inteira com o navegador. Até quem usa tablet não ocupa a tela inteira com o navegador, então leve isso em conta ao pensar nos layouts para viewports maiores, principalmente se você esconde conteúdo em telas pequenas e o mostra para “quem usa desktop”. Pergunte-se: se esse conteúdo pode sumir nas telas pequenas e não nas grandes, ele é mesmo tão necessário quanto você pensava?
Pense também na enorme fragmentação das viewports “desktop” ao trabalhar com layouts. Sim, configurar layouts e tamanhos de fonte com media queries pode fazer sentido se você usa os clássicos breakpoints de 768px, 1024px e 1280px, mas e toda a variedade de tamanhos entre eles?
Pronto, os conselhos já foram dados, mas, sejamos sinceros, você veio aqui para ver uma visualização das viewports, não é? Seu desejo é uma ordem.
Inspiradas no relatório de 2015 da OpenSignal sobre a fragmentação de telas no Android, as 100 primeiras estão organizadas num layout em alvenaria (masonry). Você também pode ver todas as 2.300, no site original.
Geralmente 768px de largura.
Registros: 501
Percentual: 0,42%
Geralmente 1024px de largura.
Registros: 367
Percentual: 0,31%
Geralmente entre 1200px e 1300px de largura.
Registros: 2.566
Percentual: 2,14%
1440px x 1024px
Registros: 20
Percentual: 0,02%
390px x 844px
Registros: 36
Percentual: 0,03% (mas isso é em tela cheia)
Só pela largura (390px), o cenário é bem diferente.
Registros: 14.742
Percentual: 12,29%
375px x 812px
Registros: 0
Percentual: 0%
Só pela largura (375px), o cenário é bem diferente.
Registros: 14.557
Percentual: 12,13%
A principal mensagem aqui é que você simplesmente não sabe como as pessoas vão acessar o seu site ou a sua aplicação web. Em vez de tomar decisões de design com base em breakpoints rígidos e limitados, tenha em mente o tamanho da fragmentação de viewports.
A recomendação é sempre ser o mentor do navegador, não o seu microgerente. Crie regras flexíveis e deixe o navegador fazer o que faz de melhor: calcular o melhor resultado com base nas condições em que ele se encontra.
Isso vale desde o planejamento dos projetos. Ao mapear o conteúdo das páginas, pergunte-se como ele vai ficar nos tamanhos de viewport esquisitos, que fogem do padrão. Sempre tente simplificar e condensar o conteúdo para que ele seja útil para todo mundo.
E, por fim, lembre-se sempre de que você não sabe em que condições o seu site vai ser acessado e tem pouco ou nenhum controle sobre isso. Aceite essa falta de controle e use as limitações para estimular a criatividade e, também, focar de verdade o seu trabalho de UX.
Para ir além dos breakpoints de viewport, veja por que container queries não são media queries.
Desde 2006, o dpw publica artigos, tutoriais e traduções sobre front-end, sempre em português: HTML, CSS, UI, UX, acessibilidade e performance para fazer sites que funcionam para todo mundo.
Se este conteúdo foi útil, tem muito mais de onde ele veio. Que tal conhecer o resto do blog?