No momento, as imagens são os maiores recursos da Web em termos de tamanho total de transferência e o número de solicitações por página. O tamanho total médio da transferência da página da Web é de aproximadamente 2 MB, em junho de 2022, apenas imagens representando quase metade disso. Não é exagero para dizer que otimizar solicitações de imagem pode ser a maior otimização de desempenho que pode ser feita.
Mais tarde, você aprenderá como as imagens responsivas evoluíram para ajudar com os problemas criados ao tentar exibir uma imagem para todas as eventualidades. Nesta seção, descubra as principais métricas de desempenho relacionadas às imagens e como melhorá-las.
Como adiar solicitações de imagem
Embora você esteja prestes a aprender várias maneiras de garantir que suas solicitações de imagem sejam as menores e eficientes possíveis, a solicitação de imagem mais rápida
sempre será aquela que nunca será feita. Então, logo de início, quero compartilhar qual pode ser a mudança de maior impacto que você pode fazer na maneira
você envia recursos de imagem aos usuários: o atributo loading="lazy".
<img src="image.jpg" loading="lazy" alt="…">
Esse atributo garante que as solicitações de imagens não sejam feitas até que cheguem perto da janela de visualização do usuário, adiando-as do ponto de carregamento da página, ou seja, o momento em que o navegador está mais ocupado, e removendo essas solicitações do caminho crítico de renderização.
Simples como pode ser na prática, o uso desse atributo pode ter um enorme impacto positivo no desempenho: uma imagem que nunca se enquadra a janela de visualização do usuário nunca será solicitada, e a largura de banda não será desperdiçada em imagens que o usuário nunca verá.
Porém, há um problema: adiar essas solicitações significa não aproveitar os recursos processos hiperotimizados para solicitar
imagens o mais cedo possível. Se loading="lazy" for usado em elementos img na parte de cima do layout e, portanto, com maior probabilidade
estejam na janela de visualização do usuário quando a página for carregada pela primeira vez. Essas imagens podem parecer significativamente mais lentas para o usuário final.
Buscar prioridade
O atributo loading é um exemplo de uma iniciativa maior de padrões da Web para oferecer aos desenvolvedores mais controle sobre os navegadores da Web
e priorizar as solicitações.
Você provavelmente conhece os navegadores abordagens básicas para buscar prioridade:
por exemplo, uma solicitação de um arquivo CSS externo no <head> de um documento é considerada essencial o suficiente para bloquear a renderização, enquanto a solicitação de um
o arquivo JavaScript externo logo acima de </body> será adiado até que a renderização seja concluída. Se o valor de um atributo loading em uma <img> for "lento",
a solicitação de imagem associada será adiada até que o navegador determine que ela será mostrada a um usuário. Caso contrário, a imagem terá o mesmo
prioridade que qualquer outra imagem na página.
O atributo fetchpriority oferece
dos desenvolvedores tem um controle mais detalhado sobre a prioridade dos recursos, o que permite sinalizar recursos
como "alto" e "baixa" prioridade relativa aos recursos do mesmo tipo. Os casos de uso de fetchpriority são semelhantes aos de loading
atributo, embora muito mais amplo. Por exemplo, é possível usar fetchpriority="low" em uma imagem revelada apenas após a interação do usuário
(se a imagem está na janela de visualização do usuário ou não) para priorizar imagens visíveis em outros lugares da página ou fetchpriority="high"
para priorizar uma imagem que você sabe que ficará imediatamente visível na janela de visualização assim que a página for renderizada.
Observe que fetchpriority é diferente de loading porque não muda fundamentalmente o comportamento do navegador. Ele não instrui o navegador
para carregar determinados recursos antes de outros e fornecer um contexto vital para as decisões tomadas em relação à solicitação de recursos.
Como medir o impacto das imagens
Ao otimizar os recursos de imagem, a performance percebida é geralmente mais importante e mais difícil de medir do que a transferência total apenas por tamanho.
As Métricas da Web fornecem métricas mensuráveis e acionáveis, além de orientações para melhorar experiência da Web, destacando problemas como como lentidão no tempo de resposta de um servidor da Web, problemas de renderização e atrasos na interatividade. As Core Web Vitals são um subconjunto desses objetivos, focados na experiência direta do usuário em uma página individual, um conjunto de medições técnicas que, juntas, determinam a velocidade de uma experiência para o usuário.
Cumulative Layout Shift
A Cumulative Layout Shift (CLS, na sigla em inglês) é uma medida de estabilidade visual. É uma métrica para capturar quanto o layout do conteúdo de uma página muda à medida que os recursos são carregados e a página é renderizada. Qualquer pessoa que tenha gasto uma quantidade significativa do tempo que usa a web perdeu seu lugar em uma longa sequência de texto devido a um "pulando" de uma página quando uma fonte da Web ou de imagem atrasada for repentinamente renderizado, ou teve um elemento interativo repentinamente movido para longe de seu ponteiro. Na melhor das hipóteses, um CLS alto é um incômodo e causa na pior das hipóteses, um "cancelamento" mudança para um espaço anteriormente ocupado por uma mensagem de confirmação assim como o usuário clica, por exemplo.
Com tempos de carregamento altos e a quantidade de espaço que elas podem ocupar em um layout, é razoável que as imagens sejam uma causa comum de altas pontuações de CLS.
Graças às alterações relativamente recentes nos navegadores modernos, é mais fácil do que você pensaria em evitar altas pontuações de CLS devido às imagens.
Se você trabalha com front-end há alguns anos, já deve estar familiarizado com os atributos width e height em <img>:
antes da ampla adoção do CSS, essas eram a única maneira de controlar o tamanho de uma imagem.
<img src="image.jpg" height="200" width="400" alt="…">
Esses atributos deixaram de ser usados na tentativa de manter nossas preocupações de estilo separadas das marcações, especialmente se elas forem responsivas
o web design tornou necessário especificar o tamanho com base em porcentagem via CSS. No início do Web design responsivo, "remover
os atributos width e height não utilizados era um conselho comum, já que os valores especificados em nosso CSS: max-width: 100% e
height: auto, eles serão substituídos.
<img src="image.jpg" alt="…">
img {
max-width: 100%;
height: auto;
}
Após a remoção dos atributos height e width, como no exemplo anterior, o único método que o navegador tem para determinar
a altura da imagem nesta situação é solicitar a origem, analisá-la e renderizá-la na proporção intrínseca, com base no
largura do espaço que ocupa no layout depois que as folhas de estilo são aplicadas. Grande parte desse processo ocorre depois que a página é
renderizado, com a altura recém-calculada causando mais trocas de layout.
A partir de 2019, o comportamento do navegador foi atualizado para lidar com os atributos width e height de forma diferente. Em vez de usar os valores dessas
atributos para determinar o tamanho fixo e baseado em pixels de um elemento img no layout, esses atributos podem representar
a proporção da imagem, embora a sintaxe seja a mesma. Os navegadores modernos dividem esses valores entre si para
determinar a proporção intrínseca de um elemento img antes da renderização da página, permitindo que ele reserve o espaço que a imagem ocupará enquanto o layout for renderizado.
Como regra, sempre use os atributos height e width em <img>, com valores correspondentes ao tamanho intrínseco da origem da imagem. Portanto,
desde que você tenha especificado height: auto junto com max-width: 100% para substituir a altura do atributo HTML.
<img src="image.jpg" height="200" width="400" alt="…">
img {
max-width: 100%;
height: auto;
}
Ao usar os atributos width e height nos elementos <img>, você evita uma pontuação de CLS alta devido a imagens.
É importante observar que não há desvantagem dessa abordagem, pois ela se baseia no comportamento tradicional de qualquer navegador.
compatível com CSS básico funcionará como sempre, com os atributos height e width na marcação substituídos pelos seus estilos.
Embora os atributos width e height evitem problemas de CLS, reservando o espaço de layout necessário para suas imagens, apresentar
usuários com uma lacuna vazia ou um marcador de posição de baixa qualidade enquanto
aguardar a transferência e a renderização de uma imagem também não é o ideal. Embora existam medidas que podem ser tomadas para reduzir os impactos
de imagens de carregamento lento, a única maneira de apresentar uma imagem totalmente renderizada a um usuário mais rapidamente é reduzindo o tamanho da transferência.
Maior exibição de conteúdo
A métrica Largest Contentful Paint (LCP) mede o tempo necessário para renderizar o maior elemento "com conteúdo" visível na janela de visualização do usuário, a elemento de conteúdo que ocupa a maior porcentagem da página visível. Pode parecer uma métrica excessivamente específica na superfície, mas essa serve como um proxy prático do ponto em que a maior parte da página foi renderizada, do ponto de vista do usuário. A LCP é essencial medida do desempenho (percebido).
Métricas como DOMContentLoaded ou o evento window.onload podem ser úteis para determinar quando o processo de carregamento da página atual
foi tecnicamente concluída, mas elas não correspondem necessariamente à experiência do usuário na página. Um pequeno atraso na renderização de um elemento
fora da janela de visualização do usuário seriam consideradas em qualquer uma dessas métricas, mas provavelmente não seriam detectadas por um usuário do mundo real.
Uma LCP longa significa que a primeira impressão do usuário de uma página (o conteúdo mais importante na janela de visualização atual) é que a página está lenta,
ou corrompidas por completo.
A percepção do usuário capturada pela LCP tem um impacto direto na experiência do usuário. Um experimento realizado pela Vodafone (em inglês) no ano passado descobriu que uma melhoria de 31% na LCP não só levou a 8% mais vendas (um resultado forte por si só), mas do número total de usuários, observou um aumento de 15% de aumento no número de visitantes que se tornaram clientes em potencial ("taxa de visitante para lead") e uma melhoria de 11% no número de usuários que visitaram o carrinho ("taxa de visitas do carrinho até o carrinho").
Em mais de 70% das páginas da Web, o maior elemento na fase inicial
a janela de visualização envolve uma imagem, como um elemento <img> independente ou um elemento com uma imagem de plano de fundo. Em outras palavras,
70% das páginas As pontuações de LCP são baseadas no desempenho da imagem. Não precisa de muita imaginação para entender o porquê: grande e que chame a atenção
é muito provável que imagens e logotipos sejam encontrados "acima da dobra".
Há algumas etapas que você pode seguir para evitar atrasos de LCP: primeiro, nunca especifique loading="lazy" em um local "acima da dobra" imagem
pois o atraso da solicitação até a página ser renderizada provavelmente terá um grande impacto negativo na sua pontuação de LCP.
Em segundo lugar, o uso de fetchpriority="high" pode informar ao navegador que a transferência dessa imagem deve ter prioridade acima das imagens em outros lugares da página.
Com essas regras em mente, o mais importante que você pode fazer para melhorar a pontuação de LCP de uma página é reduzir o tempo para transferir e renderizar essas imagens. Para fazer isso, é necessário manter as fontes de imagem tão pequenas e eficientes quanto possível (sem sacrificar a qualidade, é claro) e garantir que os usuários recebam apenas os recursos de imagem que aproveitam ao máximo para seus contextos de navegação.
Conclusão
Os recursos de imagem são que consomem mais recursos largura de banda: largura de banda tirada da transferência de todos os outros recursos necessários para renderizar uma página. As imagens introduzem problemas significativos em termos de desempenho percebido, durante e depois da página ao redor layout foi renderizado. Resumindo: os recursos de imagem causam danos.
Por mais assustadora que isso seja, "a Web seria melhor com menos imagens" isso certamente seria verdadeiro em termos de desempenho, também causaria um enorme desserviço aos usuários. As imagens são uma parte vital da web, e você não deve comprometer a qualidade conteúdo significativo somente para fins de desempenho.
No restante deste curso, você aprenderá sobre as tecnologias que impulsionam nossos ativos de imagem e técnicas para mitigar os no desempenho, sem comprometer a qualidade.