Visão geral

As imagens geralmente são os componentes mais pesados de uma página da Web, tanto em termos de bytes quanto de número de solicitações HTTP. Otimizar imagens em seu site é fundamental para melhorar a experiência dos usuários, reduzir os custos de entrega e melhorar sua posição no ranking dos mecanismos de pesquisa. Por exemplo, a métrica de maior conteúdo de pintura do Google em seu algoritmo de classificação de pesquisa é altamente afetada pelo quanto você otimiza as imagens em seu site.

Decisões arquitetônicas

Uma solução de otimização de imagem pode ser arquitetada de várias maneiras, com base em seus requisitos em termos de custo, flexibilidade e performance. Ao arquitetar uma solução de otimização de imagem, você precisa tomar as seguintes decisões técnicas:

  • Quais transformações de imagem são necessárias? É formatação, redimensionamento, recorte, etc?
  • Onde decidimos qual transformação será aplicada a uma solicitação de imagem específica? No front-end no lado do cliente (design estático, responsivo etc.), no lado do servidor (com base no conteúdo da solicitação, como dispositivo) ou em uma combinação de ambos?
  • Onde executamos a transformação? Em um local central ou de forma distribuída?
  • Quando executamos a transformação? Sempre ou armazenamos imagens transformadas por um curto período? É executado de forma síncrona ou assíncrona?

Outra decisão importante a ser tomada é se você deseja criar a solução usando os serviços da AWS ou comprar uma solução gerenciada de terceiros.

Casos de uso comuns

Solução gerenciada pelo cliente baseada em CloudFront, S3 e Lambda

O caso de uso mais comum para otimização de imagens requer formatação automática com base nos recursos do navegador do usuário e oferece ao front-end a possibilidade de redimensionar a imagem. Frameworks populares de desenvolvimento Web, como o Next.JS, fornecem componentes de imagem responsivos que podem selecionar automaticamente o tamanho da imagem com base na janela de visualização do dispositivo. A arquitetura recomendada para esse caso de uso comum é explicada no diagrama a seguir:

  1. O usuário envia uma solicitação HTTP para uma imagem com transformações específicas, como codificação e tamanho. As transformações são codificadas na URL, mais precisamente como parâmetros de consulta. Um exemplo de URL ficaria assim: https://exmaples.com/images/cats/mycat.jpg?format=webp&width=200.
  2. A solicitação é processada por um local de borda próximo do CloudFront, fornecendo a melhor performance. Antes de passar a solicitação para o upstream, uma função do CloudFront é executada no evento de solicitação do visualizador para reescrever o URL da solicitação. O CloudFront Functions é um atributo do CloudFront que permite escrever funções leves em JavaScript para personalizações de CDN de alta escala e sensíveis à latência. Em nossa arquitetura, reescrevemos a URL para validar as transformações solicitadas e normalizá-la ordenando as transformações e as convertendo em letras minúsculas para aumentar a taxa de acerto do cache. Quando uma transformação automática é solicitada, a função também decide qual delas deve ser aplicada. Por exemplo, se o usuário solicitar o formato de imagem mais otimizado (JPEG, WebP ou AVIF) usando a diretiva format=auto, a Função CloudFront selecionará o melhor formato com base no cabeçalho Accept presente na solicitação.
  3. Se a imagem solicitada já estiver armazenada em cache no CloudFront, haverá uma falha no cache, e a imagem será retornada do cache do CloudFront. Para aumentar a taxa de acertos do cache, habilitamos o Origin Shield, um atributo do CloudFront que atua como uma camada adicional de cache antes da origem, para descarregá-lo ainda mais das solicitações. Se a imagem não estiver no cache do CloudFront, a solicitação será encaminhada a um bucket do S3, criado para armazenar as imagens transformadas. Se a imagem solicitada já estiver transformada e armazenada no S3, ela será simplesmente veiculada e armazenada em cache no CloudFront.
  4. Caso contrário, o S3 responderá com um código de erro 403, que é detectado pelo Origin Failover do CloudFront. Graças a esse atributo nativo, o CloudFront tenta novamente a mesma URL, mas desta vez usando a origem secundária com base na URL da função do Lambda. Quando chamada, a função do Lambda baixa a imagem original de outro bucket do S3, onde as imagens originais são armazenadas, a transforma usando a biblioteca Sharp, armazena a imagem transformada no S3 e a veicula por meio do CloudFront, onde ela será armazenada em cache para solicitações futuras.


Para implantar essa solução, siga as etapas neste blog. Além disso, o blog mostra como o usar com o componente de imagem do Next.JS. Observe que a solução permite que você desative o armazenamento de imagens transformadas no S3, confiando exclusivamente no cache do CloudFront para veicular imagens transformadas.

Soluções gerenciadas por terceiros

Se você prefere usar uma solução de otimização de imagem gerenciada por terceiros, considere as soluções disponíveis no AWS Marketplace, como o Cloudinary, o ImageKit.io ou o Cloudimage. As três usam o CloudFront ou têm integrações com o CloudFront se você quiser gerenciar sua própria distribuição do CloudFront. Esses fornecedores terceirizados são especializados em otimização de imagens e podem fornecer recursos avançados de SaaS, mas por um custo adicional.

Recursos

Esta página foi útil para você?