A Web é um meio visual. A grande maioria dessa paisagem visual é graças aos arquivos de imagem. Embora muito seja possível com CSS e SVG embutido, a maioria dos sites ainda precisa de arquivos de imagem.
Em média, as imagens representaram mais da metade do tamanho da página no ano passado, e os tamanhos de imagem ano a ano aumentam; havia um 21% de crescimento em tamanho de imagem em 2014 sozinho.
Ao mesmo tempo, o número e a diversidade de dispositivos que acessam a Web continuam a crescer. As resoluções agora variam em qualquer lugar entre 72ppi (cada vez mais comum) e mais de 600ppi.
Criar uma imagem para a tela que será de qualidade suficiente para qualquer dispositivo é simples: salve-a em 1000ppi e chame-a por dia. A imagem resultante será nítida mesmo no mais alto dos dispositivos de alta resolução. Mas enquanto sua qualidade será alta, seu tamanho também será maior. Com o tempo de carregamento da página fator chave no UX cabe-nos garantir que os sites sejam entregues aos nossos usuários prontamente. Quando as imagens são de tão alta qualidade que demoram uma dúzia de segundos para serem baixadas em conexões de banda larga, sem falar nas conexões móveis, elas são efetivamente inutilizáveis.
O objetivo das imagens responsivas, portanto, não é fornecer uma imagem de maior qualidade para as telas que podem exibi-la (o que podemos fazer facilmente), o objetivo é oferecer a imagem da mais alta qualidade suportada e nada mais.
Este guia foi elaborado para ensinar o que funciona, onde estão os problemas e as armadilhas e como você pode usar imagens responsivas em sites hoje.
Eu sinto a necessidade, a necessidade de velocidade
Por que a velocidade é importante? Certamente ninguém está em uma conexão 3G por mais tempo? Ninguém usa dial-up. Se o alvo demográfico de seu cliente habitar Manhattan, por que você deveria se preocupar com o Lesoto rural? O fato é que é um mito que estamos todos em banda larga super-rápida, vendidos para nós por empresas que lucram com o desejo de velocidades cada vez maiores.
A maioria das pessoas passa pelo menos duas horas por dia em uma conexão inferior. Eu sempre me encontro com mais tempo para navegar quando viajo, quando até mesmo uma conexão 3G confiável soa como um sonho distante.
Em abril O Google anunciou que a compatibilidade com dispositivos móveis seria usada como um fator de classificação para pesquisas realizadas em dispositivos considerados "móveis". Mesmo antes disso, a velocidade foi um fator no ranking da página, explicitamente como parte dos cálculos do Google e, implicitamente, como um fator que contribui para sua taxa de rejeição.
Em dois sites com classificação idêntica, um extra de 1 Kb pode deixar você do terceiro lugar no Google, até o quarto ou o quinto. Poderia até deixá-lo do 10º ao 11º - em outras palavras, da página 1 para a página 2 - com todo o impacto associado na receita do seu cliente.
Você realmente precisa dessa imagem?
A imagem mais altamente otimizada que existe, não é imagem alguma. Se você tiver cinco imagens em seu site e você deixar uma, você economizou 20%, talvez o mais importante, você salvou uma solicitação http. Se descartássemos todas as imagens de nossos sites, economizaríamos 100% e todas as cinco solicitações de http. Então, por que não fazer isso?
Não descartamos imagens de nossos sites porque elas se comunicam de forma mais eficaz do que o texto a curto prazo. Eles criam uma conexão emocional que atrai os usuários para o conteúdo.
Nós sabemos isso usuários não lêem páginas da web . Muito poucas pessoas lêem conteúdos detalhados online. As imagens nos permitem conectar, comunicar e reforçar uma marca em uma fração do tempo que o texto pode gerenciar.
As imagens podem ser grandes e difíceis de baixar, mas, uma vez renderizadas no navegador, são muito mais eficientes do que o texto para estabelecer o engajamento do usuário e reforçar uma mensagem da marca.
As imagens responsivas nos ajudam a garantir que as imagens de conexão emocional não sejam perdidas quando o usuário impaciente acerta o botão Voltar.
Como cerca de SVG?
O SVG (Scalable Vector Graphics) é uma das verdadeiras tecnologias pioneiras da Web. Está tão à frente da curva que a maioria dos designers ainda não reconheceu seu verdadeiro potencial.
SVG - como o nome indica - é baseado em vetores. Isso significa que os gráficos SVG são construídos a partir de pontos, ângulos e distâncias. O SVG também é - como o nome indica - escalonável, o que significa que ele será exibido igualmente bem em um iMac de 5k ou em um smartphone Android, sem perda de qualidade e sem alteração no tamanho do arquivo.
Se você tiver uma ilustração plana, um ícone, um logotipo, qualquer coisa que possa ser exibida como um SVG, o SVG é o caminho a ser seguido.
A maioria das imagens na Web são bitmaps. De um modo geral, a maneira como um bitmap funciona é descrever cada pixel um de cada vez, sua cor (em RGB - valores vermelho, verde e azul) e, em alguns casos, sua transparência. Se você tem uma imagem que mede 100 px por 100 px, então você tem uma imagem com 10.000 pixels; Se cada pixel tiver 4 valores para descrevê-lo, a imagem terá 40.000 bits de dados associados a ele. Parece muito, não é? Às vezes, isso é menos que um gráfico vetorial.
Considere uma imagem de 1 px por 1 px; Isso exigiria 4 bits de dados para gravar como bitmap (valores vermelho, verde, azul e alfa). Agora considere o mesmo pixel quadrado registrado como vetor; Isso exigiria o x, y, largura e altura do retângulo, além dos valores RGBA.
Esses são exemplos grosseiros, mas são precisos. Freqüentemente, uma versão vetorial de uma imagem - se tivermos uma disponível para nós - excede o tamanho do arquivo do bitmap equivalente, e então o bitmap é a única escolha sensata.
(Mis) usando JavaScript
Como a maioria dos problemas da vida (se sua vida é on-line), as imagens responsivas podem ser resolvidas pelo JavaScript. De fato, por vários anos, o JavaScript foi a única maneira de resolver o problema. O JavaScript pode testar as habilidades de um agente do usuário, determinar o tipo de navegador e escrever uma tag de imagem HTML padrão, contendo a imagem apropriada.
Web designers que se opõem ao uso de JavaScript normalmente fazem isso porque algumas pessoas desligam . No entanto, esse não é mais o caso, especialmente na Web para dispositivos móveis, mas há alguns problemas persistentes: escrever uma imagem com JavaScript significa que a imagem não será analisada pelos robôs do mecanismo de pesquisa e só será processada após o script como executado, por exemplo.
O maior problema com o uso do JavaScript é que ele é um mau uso da finalidade principal do JavaScript. HTML contém dados, CSS manipula a apresentação, JavaScript manipula a funcionalidade. Quando nos separamos desses papéis estruturados, começamos a encontrar problemas que exigem hacks para corrigi-los. Imagens são dados e, portanto, devem ser manipuladas pelo HTML.
O problema com navegadores
Desde que a RWD foi inventada, as imagens têm sido o maior obstáculo. Mas agora estamos começando a encontrar maneiras de resolver os vários problemas. Técnicas que são endurecidas pela batalha e bem sucedidas o suficiente para serem consideradas as melhores práticas. Desenvolvedores dedicados deram seu tempo para fazer lobby no WC3 para soluções oficiais, e agora, pela primeira vez, imagens responsivas são práticas.
A chave para as imagens responsivas é que elas foram projetadas com uma plena consciência das falhas da Web. Foi tomado cuidado para garantir que as soluções de imagem responsiva não quebram os navegadores existentes, de modo que, mesmo em navegadores que não suportam imagens responsivas, o código falhará silenciosamente e sem resposta, as imagens padrão serão exibidas.
Neste artigo, veremos dois elementos HTML oficiais de imagem responsiva: srcset e picture.
Atualmente, o Safari Edge, Safari e iOS suporta apenas um subconjunto da especificação srcset . O Firefox, o Chrome, o Opera, o Navegador Android e as versões futuras do Safari e do iOS Safari oferecem suporte total a ele. (Vamos discutir as diferenças abaixo.)
Atualmente, o elemento picture é totalmente suportado pelo Firefox, Chrome, Opera e navegador Android. O Safari Edge, Safari e iOS não é compatível, e eles não anunciaram um cronograma para implementá-lo.
Mesmo entre os navegadores que suportam o novo código, há inconsistências, pois diferentes fabricantes de navegadores interpretam as especificações do W3C de maneiras diferentes. Por exemplo, ao especificar uma alteração de imagem de pequena para grande com base no tamanho da viewport, alguns navegadores mudam para a imagem grande quando a viewport é 1px maior que o tamanho preferido da imagem pequena, outros alternam para a imagem grande somente quando a viewport favorecido pela imagem grande é totalmente compatível.
Em resumo, os navegadores são divididos em dois campos: aqueles que preferem imagens de maior qualidade, quando possível, e aqueles que favorecem downloads menores, sempre que possível. Os fabricantes de navegadores ainda estão duvidando disso, eventualmente a implementação de alguém será mais popular - pessoalmente, espero que seja o último, porque, como observado acima, o desempenho é crucial para a experiência do usuário.
Por enquanto, a melhor opção para os web designers é seguir a especificação e não tentar adivinhar o navegador. Afinal, a experiência padrão no navegador (alta qualidade ou downloads mais rápidos) é parte do que um usuário seleciona um navegador padrão, portanto, se o usuário está ciente das diferentes abordagens, a preferência do navegador é provavelmente a preferência do usuário também .
Melhor prática de imagem responsiva (2015)
Ao longo da história da Web, usamos um elemento para indicar uma imagem, o elemento img . Em HTML5, o elemento img sofreu uma mudança sutil em sua função, que é projetada para permitir imagens responsivas: o elemento img não representa mais uma imagem, é agora um espaço reservado para uma imagem.
Essa distinção é importante porque, embora um elemento img tenha anteriormente um único conjunto de dados de imagem - seja bitmap ou vetor -, agora uma imagem pode conter vários conjuntos de dados.
O elemento img (para recapitular para qualquer não codificador) se parece com isto:
A versão da imagem responsiva do elemento img se parece com isso:
Quase nenhuma mudança em tudo. Olhando para este código, você percebe uma coisa importante: o código é compatível com versões anteriores. Se ocorrer um navegador que não entenda o atributo srcset , ele simplesmente o ignorará e renderizará a imagem de acordo com a especificação original de 1993.
O que isso significa é que agora podemos usar imagens responsivas em nossa marcação, sem a necessidade de detecção de recursos.
No novo elemento img responsivo, src é usado principalmente como uma imagem padrão e para navegadores que não reconhecem srcset, enquanto srcset contém todas as imagens de formato de alta resolução disponíveis para esse espaço reservado.
Ao renderizar o elemento img , o navegador determinará qual arquivo de imagem é o mais adequado.
Usando o srcset
Agora que sabemos que srcset falhará silenciosamente em navegadores que não suportam, estamos livres para adicionar uma imagem extra:
Nesse caso, qualquer navegador que suporte srcset exibirá image-b.jpg e qualquer navegador que não suporte srcset exibirá image-a.jpg.
É importante observar que o navegador só baixará a imagem que decidir exibir, não baixará as duas imagens e depois escolherá uma.
Infelizmente isso não nos leva muito longe, porque a menos que estejamos demonstrando o suporte a srcset , não há aplicação prática para alternar imagens com base apenas no suporte a srcset .
A solução é fornecer informações adicionais ao navegador sobre qual imagem deve ser escolhida. Para fazer isso, precisamos fornecer informações sobre o espaço disponível ou a densidade de pixels.
Usando o descritor x
O descritor-x diz ao navegador quão densos são os pixels de uma imagem.
Se, por exemplo, você quisesse fornecer uma imagem de grau de retina com o dobro do número de pixels que uma imagem padrão, você especificaria a imagem de retina no srcset, seguida de um espaço e depois a palavra-chave "2x".
Nós temos a nossa imagem:
Para adicionar uma opção de retina ao navegador, adicionamos o seguinte srcset:
Neste caso, existem três resultados possíveis:
se o navegador não suportar srcset, ele usará o arquivo de imagem especificado no atributo src ;
se o navegador suportar srcset e tiver uma tela capaz de uma resolução dupla, ele usará a imagem especificada no atributo srcset;
se o navegador suportar srcset, mas não tiver uma tela de alta resolução, ele usará a imagem especificada no atributo src (quando nenhuma imagem “1x” é especificada no atributo srcset , o atributo src é considerado como aquela imagem opção).
O suporte do navegador é bom e está melhorando rapidamente. Com um atributo, resolvemos o enigma das imagens responsivas, sim, nós!
Uma última coisa a se notar sobre o descritor x: a escolha de qual imagem carregar baseia-se na densidade de pixels, portanto, se um usuário aplicar zoom em 200% (diminuindo efetivamente o tamanho da imagem e dobrando a densidade de pixels), o 2x a imagem será carregada. Isso pode ter um efeito prejudicial na acessibilidade - nós certamente não queremos ver sites carregando mais devagar para os deficientes visuais, simplesmente porque eles optam por ampliar o navegador.
Usando o descritor w
O descritor w é um pouco mais avançado que o descritor x. O descritor w funciona informando ao navegador quantos pixels reais existem no eixo x (a largura) de uma opção de imagem específica.
O Safari Edge, Safari e iOS não suporta o descritor w no momento da escrita, portanto, sua utilidade é um pouco reduzida.
Vamos voltar para a nossa imagem original:
Se esta imagem tiver nativamente 1600 pixels de largura e se quisermos adicionar uma imagem de retina, como fizemos com o descritor x acima, especificaríamos uma imagem no atributo srcset que tem 3200 pixels de largura:
Há uma pegadinha importante com o descritor w: embora o atributo src seja tratado como o padrão ao especificar imagens usando o descritor-x, ele é totalmente ignorado pelos navegadores que suportam srcset se você usar o descritor-w. Ao usar o descritor w , temos que especificar o padrão explicitamente adicionando uma segunda opção de imagem srcset , com seu próprio descritor w, e separando-os com uma vírgula:
O que nos leva para…
Usando várias imagens
Ser capaz de especificar uma opção de imagem de alta resolução para o navegador em nosso código HTML é decididamente legal, mas como você provavelmente adivinhou, fica ainda mais frio quando especificamos várias imagens.
O objetivo das imagens responsivas é fornecer a melhor qualidade de imagem utilizável pelo dispositivo de acesso, mas nada mais. Portanto, simplesmente fornecer uma imagem de retina não é adequada, precisamos fornecer imagens em, por exemplo, 1x, 1,5x, 2x, 2,5x e 3x.
Mais uma vez, aqui está a nossa marcação de imagem original:
Aqui está uma imagem de grau de retina fornecida como uma opção para o navegador:
Aqui está, desta vez com opções extras no srcset, separadas por vírgulas:
Como as palavras-chave significam coisas diferentes para pessoas diferentes, acho aconselhável nomear minhas imagens de acordo com o descritor x ao qual elas pertencem, tanto como um auxiliar de memória pessoal quanto para garantir que os diferentes tamanhos sejam claros para outros membros da equipe:
Lembre-se, não estamos dizendo ao navegador qual imagem exibir, estamos informando as opções disponíveis e permitindo que ele selecione por si mesmo. O navegador só baixará uma dessas imagens.
Uma pegadinha com várias imagens: nunca especifique duas imagens no atributo srcset com um descritor x correspondente e um descritorw, por exemplo:
O atributo sizes é uma adição particularmente interessante para a especificação, porque o atributo sizes toma seus valores relativos à viewport, não à imagem.
Usando o valor vw (largura da viewport), especificamos a área da imagem em relação à largura do navegador - lembre-se, o elemento img agora é efetivamente apenas um espaço reservado, então não estamos especificando o tamanho real da imagem, estamos especificando tamanho do espaço reservado que conterá a imagem.
100vw é 100% da largura da viewport, 50vw é 50% da largura da viewport, 25vw é 25% da largura da viewport, etc.
Se quiséssemos definir a largura img para metade da largura do navegador, usaríamos:
Isso não é particularmente útil, até combiná-lo com consultas de mídia ...
Usando consultas de mídia
O atributo tamanhos torna-se muito mais poderoso quando o combinamos com consultas de mídia. Podemos separar várias larguras de viewport usando vírgulas e informar ao navegador qual usar usando uma consulta de mídia de estilo CSS.
Por exemplo, imagine que queremos que uma imagem represente 80% da largura de nossa viewport na maioria dos dispositivos, mas em dispositivos pequenos (como telefones) com uma largura de 380 px ou menos, queremos aproveitar ao máximo espaço disponível, perfazendo 100% da largura, escreveríamos assim:
Seguindo essa lógica, qualquer navegador com uma viewport de 380px ou menos definirá a largura da imagem para 100% da viewport. Qualquer outro navegador fará com que a consulta de mídia retorne false e o navegador passará para o próximo valor do atributo sizes , que nesse caso é 80vw.
Como regra geral, fico desconfortável usando consultas de mídia em HTML. Assim como os dados de imagem responsivos pertencem ao HTML (não ao JavaScript), as consultas de mídia pertencem ao CSS (não ao HTML). No entanto, a opção está lá para você, se você precisar.
Melhor prática prática de imagens responsivas (2016?)
Eu não sei sobre você, mas estou muito animado com as possibilidades do srcset. É uma solução simples para um problema difícil e parece entregar tudo o que precisamos.
Mas, como os ônibus, você espera 20 anos por uma solução oficial para imagens responsivas e, em seguida, duas aparecem de uma só vez. Assim como o atributo srcset do elemento img , também temos o elemento picture .
O elemento de imagem é outro marcador de posição, ainda que mais tradicional. Ele foi projetado para imitar os elementos de vídeo e áudio em HTML5, portanto, sua sintaxe será familiar para a maioria. O elemento picture destina-se a ser usado quando você precisar de mais controle do que o srcset pode fornecer.
Infelizmente, o elemento picture tem muito menos suporte a navegador que o srcset e nem sempre falha silenciosamente.
Usando o elemento de imagem
Aqui está nosso elemento de imagem original:
Aqui está a nossa imagem aninhada dentro de um elemento de imagem:
Nós também podemos especificar um srcset para um elemento img dentro de um elemento de imagem :
Usando o elemento de origem
O elemento de imagem não ganha vida até adicionarmos o elemento de origem :
Ao selecionar o arquivo a ser usado, o navegador iniciará com o primeiro elemento de origem e percorrerá os elementos até encontrar um cujo atributo de mídia seja verdadeiro. Ele usará o srcset desse elemento de origem.
Por exemplo, poderíamos especificar imagens diferentes para os formatos retrato e paisagem:
Também podemos especificar várias imagens usando o descritor-x e o descritor-w:
Como com o uso de consultas de mídia no atributo sizes , questionaria a sabedoria de controlar as versões de imagem com base no estilo, na marcação em vez de uma folha de estilo. No entanto, a opção de usar o atributo de mídia está lá, se você precisar.
Usando o tipo
O elemento de imagem realmente se destaca quando usado para trocar diferentes tipos de imagens.
Imagine que temos um arquivo PNG padrão, mas queremos usar um Arquivo WebP, que normalmente é 26% menor - lembre-se de que as imagens responsivas são sobre fornecer a melhor qualidade de imagem, no menor tamanho - mas, atualmente, só são suportadas pelo Chrome, pelo Opera e pelo navegador Android. Nós precisaremos usar o atributo type para determinar se o WebP é suportado:
Nesse caso, o navegador verificará se o formato de imagem do WebP é suportado. Se for, determinará se a tela tem densidade de pixels suficiente para exibir a imagem retina-image.webp , caso contrário, exibirá a imagem image.webp . Se o WebP não for suportado, o navegador irá direto para o elemento img e trabalhará com as opções srcset e src da maneira que já estamos familiarizados.
O atributo type significa que podemos fornecer formatos de imagem muito menores quando suportados, resultando em um tamanho de arquivo menor.
Problemas Conhecidos
IE9 tem um problema conhecido que impede que o elemento da imagem falhe silenciosamente. Para lidar com o IE9, você precisa enganar o IE9 para pensar que os elementos de origem fazem parte de um elemento de vídeo :
< !—[if IE 9]>< ![endif]—>
É uma solução feia, mas melhor do que nenhuma solução. Só podemos esperar que o lançamento do Windows 10 apresse o fim do IE9, porque embora o Edge ainda não suporte o elemento picture , ele não o suporta da maneira correta (ignorando-o).
tem polyfills que pode ajudar você a suportar o elemento picture no IE, mas minha preferência é evitá-los. Eu desconfio de corrigir problemas com JavaScript, isso afeta o desempenho e leva a um código menos sustentável.
Por esse motivo, recomendo evitar o elemento picture por enquanto. A menos que você esteja executando um site de comércio eletrônico em larga escala, é improvável que a economia extra em tempo de download que o formato WebP ofereça supere a inconveniência de corrigir sua marcação com o script.
Uma vez que o IE9 cai abaixo de 1%, o que deve acontecer em algum momento no próximo ano, o elemento de imagem se tornará viável. Se você está lendo isso em 2016, você provavelmente está pronto para ir.
Criando imagens responsivas
Ao contrário do SVG, as imagens de bitmap não são dimensionadas. Nossa estratégia para lidar com eles, seja usando o srcset ou o elemento de imagem , é fornecer uma imagem diferente com base nos recursos do navegador. Para lidar com isso, precisamos fornecer vários tamanhos de imagem diferentes.
A maioria dos aplicativos de edição de imagem automatizou o processo de exportação de várias versões de uma única imagem. Não importa qual aplicativo você usa, desde que você tenha vários tamanhos de imagem sem ter que redimensionar e salvar cada um manualmente.
O Adobe Photoshop é o editor de bitmap de fato. Não é uma ótima opção para o trabalho de design, mas seu fluxo de trabalho de processamento de imagens é suave e confiável. Gerar várias resoluções de imagem no Photoshop é relativamente simples:
Abra a imagem para a qual você deseja gerar várias versões e coloque-a em sua própria camada.
Renomeie a camada como o nome do arquivo que você deseja gerar (incluindo a extensão).
Selecione Arquivo> Gerar> Recursos da imagem e uma pasta com sua nova imagem será salva ao lado do seu PSD.
Renomeie a camada, especificando cada imagem que você deseja gerar precedida pela escala pretendida. Você não precisa repetir o passo 3, depois de renomear a camada, as imagens serão geradas automaticamente.
O crédito pela imagem vai paraPhilip Collier.
Para mais informações sobre como gerar imagens no Photoshop, Veja aqui.
Com base nessas imagens, podemos oferecer ao navegador cinco opções diferentes:
Conclusão
O elemento img percorreu um longo caminho em 20 anos. Ou, para ser mais preciso, o elemento img foi inadequado por 18 anos, depois correu para a linha nos últimos dois anos, a ponto de ser agora relativamente sofisticado.
O importante é que chegamos à (s) solução (ões).
Das duas opções disponíveis, srcset e picture, a primeira é de longe a mais suportada. Se você está criando 95% dos sites, o suporte superior e a implementação mais simples do atributo srcset é sua melhor opção.
Se você estiver executando um grande site de comércio eletrônico, com milhares de imagens de produtos, o trabalho extra para servir o formato WebP pode valer a pena, especialmente porque o suporte para o elemento de imagem aumenta nos próximos dois anos.
A maior fraqueza nas opções atuais é que os navegadores não têm atualmente uma maneira de selecionar uma imagem com base na sua velocidade de conexão. Somos forçados a confiar que dispositivos mais capazes também estão em conexões superiores.
Por fim, podemos finalmente oferecer imagens da mais alta qualidade praticamente possíveis, no menor tamanho possível. Isso significa uma experiência melhor, em um tempo mais curto, que só pode ser algo para abraçar.
Usos da imagem em destaque,imagem da montanhaeimagem do dispositivovia Shutterstock.
