Fazendo sites responsivos funcionarem
Houve um tempo em que você podia diferenciar com segurança entre uma página da web para desktop e uma página da web para celular. Tanto assim, de fato, que toda uma indústria cresceu em torno do reaproveitamento de sites de desktop para dispositivos móveis.
Por um tempo, você não era ninguém se não tivesse um site móvel separado em um domínio separado. Então as coisas começaram a mudar.
Os monitores móveis melhoraram além de qualquer reconhecimento. O mesmo aconteceu com os navegadores móveis. Os tablets lançaram outro elemento na equação. 4G veio junto. As telas Retina ofereciam novos níveis de clareza para os usuários finais.
De repente, a linha entre desktop e mobile parecia tênue.
Ao mesmo tempo, havia uma diversidade crescente no tamanho e na resolução dos monitores de desktop.
E uma dor de cabeça crescente para web designers.
Já se foram os dias em que você só precisava atender a um punhado de tamanhos de viewport. As coisas estavam ficando complicadas.
Felizmente, a ajuda estava disponível na forma de consultas de mídia e no conceito de design responsivo.
Graças às consultas de mídia, tornou-se possível variar estilos e layout – até mesmo conteúdo – dependendo da largura da janela de visualização do usuário e da resolução da tela. É claro que as consultas de mídia não são de forma alguma a única ferramenta na bolsa de truques do designer responsivo, mas é justo dizer que elas formam a base da técnica.
Esta foi uma ótima notícia para celular. O design responsivo significava que você poderia fornecer efetivamente diferentes versões do mesmo site para diferentes dispositivos. Tudo sem desenvolver um site móvel separado em um domínio diferente.
E quanto ao desempenho?
Os proprietários de sites estão começando a perceber que os usuários finais se preocupam com o desempenho. Os varejistas, em particular, estão começando a perceber que a redução de milissegundos no tempo de carregamento pode se traduzir em milhões no balanço.
Felizmente, os sites responsivos oferecem um claro benefício de desempenho em relação aos seus primos móveis dedicados: o redirecionamento para um domínio móvel é eliminado.
No entanto, apesar disso, o design responsivo conseguiu adquirir uma reputação de baixo desempenho.
De certa forma, isso é bastante injusto, mas vale a pena olhar para os desafios extras de desempenho que o design responsivo oferece aos incautos…
Imagens
Os arquivos de imagem são grandes. E por serem grandes, geralmente são os culpados pelos tempos de carregamento lentos. Eles são, portanto, um bom ponto de partida para qualquer pessoa que esteja tentando otimizar o desempenho de um site.
Infelizmente, uma das primeiras soluções para fornecer imagens de forma responsiva não era boa para o desempenho.
A técnica é maravilhosamente simples. Basta usar max-width: 100% para garantir que as imagens sejam dimensionadas para a largura do elemento que as contém:
img
{
max-width: 100%;
}À medida que o contêiner encolhe para caber em viewports menores, todas as imagens dentro dele encolherão. Fácil!
Mas há um problema. O tamanho da imagem pode diminuir na tela, mas o tamanho do arquivo permanece o mesmo. Isso está longe de ser ideal do ponto de vista do desempenho. Você pode estar enviando uma imagem de 800 x 800 pixels pelo fio, apenas para ser exibida em 80 x 80 pixels: em outras palavras, você pode estar transmitindo centenas (ou milhares) de bytes desnecessários. Além de a imagem demorar muito para carregar, todos esses bytes redundantes podem esgotar o valioso subsídio de dados do usuário final.
No entanto, esta não é a única – nem mesmo a melhor – maneira de entregar imagens responsivas. Por um lado, uma imagem que funciona com 800 pixels de largura não funcionará necessariamente tão bem em várias frações desse tamanho.
Para lidar com isso, você pode usar uma consulta de mídia para exibir diferentes versões da imagem, dependendo do tamanho da janela de visualização, usando uma consulta de mídia e exibição: nenhum.
CSS:
@media (min-width: 601px) {
#croppedImage
{
display:none;
}
}
@media (max-width: 600px) {
#largeImage
{
display:none;
}
}HTML:
<img id="largeImage" width="400" height="400" alt="" src="images/largeImage.webp">
<img id="croppedImage" width="200" height="200" alt="" src="images/croppedImage.webp">Isso permite que você exiba diferentes versões de uma imagem, em vez de apenas a mesma imagem em tamanhos diferentes. No entanto, não reduz o número de bytes. Na verdade, o tamanho geral da página será maior, pois todas as imagens serão carregadas, sejam elas exibidas ou não.
Uma alternativa melhor – se for prática – é usar imagens de fundo em <divs>vez de <img>elementos. Isso é preferível porque as imagens referenciadas em CSS são carregadas apenas se forem usadas (desde que não sejam URIs de dados):
@media (min-width: 601px) {
#largeImage
{
width:400px;
height:400px;
background-image:url(/images/largeImage.webp);
}
#croppedImage
{
display:none;
}
}
@media (max-width: 600px) {
#croppedImage
{
width:200px;
height:200px;
background-image:url(/images/croppedImage.webp);
}
#largeImage
{
display:none;
}
}Isso funciona bem: os visitantes baixam apenas as imagens de que precisam, como e quando precisam. O problema é que é desordenado, tratando efetivamente o conteúdo como estilo. Como tal, potencialmente cria um problema de manutenção e também pode resultar em imagens importantes sendo ignoradas pelos mecanismos de pesquisa.
Em vez disso, por que não usar SVG (gráficos vetoriais escaláveis): um formato de imagem que é dimensionado por sua própria natureza? As imagens SVG também têm a vantagem de serem facilmente estilizadas com CSS (veja este ótimo tutorial sobre como tornar SVGs responsivos com CSS). Isso é perfeito para ícones e logotipos, mas infelizmente você não poderá usar SVGs para fotos – para isso você terá que recorrer a formatos raster, como JPEG.
Outra opção é usar uma das várias soluções JavaScript para fornecer imagens responsivas. Essa é uma maneira popular de fazer isso, mas acrescenta outra camada de complexidade. Além disso, como o JavaScript bloqueia a construção do DOM, qualquer solução que envolva JavaScript tem o potencial de atrasar a renderização. Portanto, embora existam alguns plug-ins muito inteligentes por aí, apenas introduzindo o JavaScript na equação, você está, até certo ponto, resignando-se ao menor dos dois males.
Até recentemente, essas eram as únicas opções.
Agora, no entanto, os elementos <picture>e <source>e os atributos srcset e tamanhos estão finalmente trazendo imagens verdadeiramente responsivas para a web. A nova especificação também está começando a ganhar suporte ao navegador, com suporte total no Chrome e no Opera, e suporte para troca de resolução no Safari. Até que outros navegadores o alcancem, há um excelente polyfill de JavaScript .
Neste admirável mundo novo, você pode usar srcset para definir uma lista de imagens candidatas para o navegador escolher. Você pode usar uma consulta de mídia no atributo de tamanhos para ditar o tamanho no qual a imagem será exibida. Usando o <picture>elemento junto com consultas de mídia dentro de um ou mais elementos, você pode especificar um intervalo diferente de imagens para diferentes condições (por exemplo, para viewports até uma certa largura, use image a, b ou c, e para viewports maiores use image x, y ou z). Isso é útil se você precisar fornecer uma versão cortada de uma imagem para usuários com telas pequenas.
Os detalhes precisos de como usar a nova sintaxe estão fora do escopo deste artigo, mas você pode encontrar um excelente tutorial em alistapart.
Talvez a única desvantagem dessa nova especificação seja que ela é bastante prolixo, o que pode significar HTML inchado em páginas com muitas imagens. No entanto, os benefícios superam em muito as desvantagens.
Carregando CSS que você não precisa (necessariamente)
Embora as consultas de mídia permitam que você aplique diferentes regras de CSS, dependendo dos critérios definidos, não há como fugir do fato de que os usuários finais terão que baixar todo o CSS aplicável. Isso é verdade mesmo se você colocar seu CSS em arquivos separados e colocar sua consulta de mídia no <link>elemento.
Por exemplo, ambas as folhas de estilo a seguir serão carregadas, independentemente da largura da viewport:
<link rel="stylesheet" media="(max-width: 600px)" href="css/style1.css">
<link rel="stylesheet" media="(min-width: 601px)" href="css/style2.css">Este não é um bug do navegador. Os critérios usados nas consultas de mídia geralmente se relacionam a coisas que mudam durante uma visita a uma página. Por exemplo, um visitante pode decidir redimensionar a janela do navegador ou girar seu tablet/dispositivo móvel. A alteração resultante na exibição deve ser perfeita e disparar uma solicitação para outro arquivo CSS estaria longe de ser o ideal. Isso é especialmente verdadeiro para dispositivos móveis, que procuram fechar links de rádio na primeira oportunidade para preservar a energia da bateria. Ter que restabelecer potencialmente esse link quando o tamanho da janela de visualização mudar pode ser uma má notícia para a duração da bateria.
No entanto, o Chrome se esforça para lidar com esses diferentes arquivos de maneira inteligente. Embora todos os arquivos sejam baixados, apenas aquele com a consulta de mídia correspondente no momento bloqueará a renderização. Quaisquer outros serão carregados com prioridade mais baixa.
Infelizmente, outros navegadores não são tão prestativos. No Firefox, por exemplo, arquivos CSS não utilizados não apenas bloqueiam a renderização – eles também bloqueiam o carregamento de outros objetos na página.
O gráfico em cascata abaixo ilustra o ponto. As imagens nesta página não começam a carregar até que o arquivo CSS não utilizado tenha sido baixado completamente:
Você pode contornar isso usando JavaScript para carregar CSS condicionalmente, mas, como já vimos, o JavaScript vem com seus próprios custos de desempenho.
O que tudo isso significa para o desempenho de um site responsivo em comparação com um site móvel?
Bem, usuários móveis e usuários de desktop em um site responsivo terão que baixar o mesmo CSS.
E haverá mais do que em um site projetado apenas para desktop ou celular.
Além disso, é mais provável que um site móvel dedicado use uma versão mais leve e simplificada do CSS para desktop (embora isso seja menos verdadeiro agora, pois os usuários esperam uma experiência mais rica em telas móveis cada vez mais sofisticadas).
Portanto, outras coisas sendo iguais, parece que há algo no argumento de que um site responsivo provavelmente será mais lento do que um site móvel por causa do CSS extra necessário. No entanto, desde que os designers estejam cientes das possíveis armadilhas, eles devem ser capazes de criar folhas de estilo de carregamento rápido para um site responsivo. Em particular, é uma boa ideia:
- evite usar URIs de dados para imagens – imagens binárias de fundo serão (normalmente) carregadas apenas se/quando forem necessárias, mas todas as URIs de dados serão carregadas independentemente.
- seja leve – já que todo o CSS precisa ser baixado, é importante ser eficiente. Isso significa evitar a duplicação e garantir que as regras globais sejam definidas fora do CSS direcionado à consulta de mídia.
RESS (Responsive Web Design + Server Side Components)
O RESS é um híbrido entre design responsivo e adaptativo, que envolve o sniffing do agente do usuário no servidor para observar as características do dispositivo cliente e fornecer conteúdo apropriado a ele.
Se uma das objeções ao design responsivo é que ele envolve a entrega de todo o conteúdo para todos os dispositivos, por que não mitigar isso cortando parte desse conteúdo sempre que possível?
Isso pode fazer muito sentido. Se houver uma imagem que você sabe que nunca deseja exibir em dispositivos cuja tela está abaixo de um determinado tamanho, é melhor não enviá-la para esses dispositivos, economizando largura de banda e reduzindo o tempo de carregamento.
Além do mais, se você estiver usando consultas de mídia que você sabe que não poderiam ser atendidas em determinados dispositivos, há pelo menos um argumento para separar seu CSS em arquivos diferentes e carregá-los condicionalmente.
Vale lembrar que todo esse processo não é ‘gratuito’ em termos de performance. Obviamente, algum trabalho precisa ser realizado no servidor, o que leva tempo – provavelmente não o suficiente para compensar os benefícios, mas é algo a ser observado.
O veredito
Sites responsivos são lentos?
Depende do que você entende por lento.
É provável que o site responsivo mais rápido que você poderia criar seja mais lento do que o site móvel dedicado mais rápido que você poderia criar?
Provavelmente.
Também vimos que existem algumas armadilhas. Se você não for cuidadoso, é fácil acabar forçando os usuários a baixar muitas imagens e CSS redundantes, tornando seu site responsivo muito mais lento do que o necessário.
No entanto, não precisa ser assim. É perfeitamente possível criar um site responsivo que seja tão rápido quanto necessário e proporcione uma excelente experiência ao usuário. E como os padrões e os navegadores começam a acompanhar o que os desenvolvedores desejam oferecer, deve começar a ficar mais fácil.