Información general

Las imágenes suelen ser los componentes más pesados de una página web, tanto en términos de bytes como de número de solicitudes HTTP. La optimización de las imágenes del sitio web es fundamental para mejorar la experiencia de los usuarios, reducir los costos de entrega y mejorar la posición en los motores de búsqueda. Por ejemplo, la métrica Largest Contentful Paint de Google en su algoritmo de clasificación de búsquedas se ve muy afectada por la optimización de las imágenes del sitio web.

Decisiones de arquitectura

Una solución de optimización de imágenes se puede diseñar de diversas formas, en función de sus requisitos en términos de costo, flexibilidad y rendimiento. Al diseñar una solución de optimización de imágenes, debe tomar las siguientes decisiones técnicas:

  • ¿Qué transformaciones de imagen se necesitan? Formatear, cambiar el tamaño, recortar, etc.
  • ¿Dónde decidimos qué transformación se aplicará a una solicitud de imagen específica? ¿En el frontend del cliente (diseño estático, de respuesta, etc.), del servidor (según el contenido de la solicitud, como el dispositivo) o una combinación de ambos?
  • ¿Dónde ejecutamos la transformación? ¿En una ubicación central o de forma distribuida?
  • ¿Cuándo ejecutamos la transformación? ¿Almacenamos imágenes transformadas siempre o durante un breve periodo de tiempo? ¿Se ejecuta de forma sincrónica o asincrónica?

Otra decisión importante que debe tomar es si desea crear la solución con los servicios de AWS o comprar una solución administrada por terceros.

Casos de uso comunes

Solución administrada por el cliente basada en CloudFront, S3 y Lambda

El caso de uso más común para la optimización de imágenes requiere el formato automático en función de las capacidades del navegador del usuario y ofrecer a la interfaz la posibilidad de cambiar el tamaño de la imagen. Los marcos de desarrollo web más populares, como Next.js, proporcionan componentes de imagen adaptables que pueden seleccionar automáticamente el tamaño de la imagen en función de la ventana gráfica del dispositivo. La arquitectura recomendada para este caso de uso común se explica en el siguiente diagrama:

  1. El usuario envía una solicitud HTTP para una imagen con transformaciones específicas, como la codificación y el tamaño. Las transformaciones se codifican en la URL, más precisamente, como parámetros de consulta. Una URL de ejemplo tendría este aspecto: https://exmaples.com/images/cats/mycat.jpg?format=webp&width=200.
  2. La solicitud se procesa en una ubicación periférica de CloudFront cercana, lo que proporciona el mejor rendimiento. Antes de pasar la solicitud en sentido ascendente, se ejecuta una CloudFront Function en el evento de solicitud del espectador para reescribir la URL de la solicitud. CloudFront Functions es una característica de CloudFront que permite escribir funciones ligeras en JavaScript para personalizaciones de CDN de gran escala y sensibles a la latencia. En nuestra arquitectura, reescribimos la URL para validar las transformaciones solicitadas y normalizamos la URL. Para ello, ordenamos las transformaciones y las convertimos en minúsculas para aumentar la proporción de aciertos de la caché. Cuando se solicita una transformación automática, la función también decide cuál es la mejor para aplicarla. Por ejemplo, si el usuario solicita el formato de imagen más optimizado (JPEG, WebP o AVIF) mediante la directiva format=auto, la CloudFront Function seleccionará el mejor formato en función del encabezado Accept presente en la solicitud.
  3. Si la imagen solicitada ya está almacenada en caché en CloudFront, se producirá una visita a la caché y la imagen se devolverá desde la caché de CloudFront. Para aumentar la proporción de aciertos de la caché, habilitamos Origin Shield, una característica de CloudFront que actúa como una capa adicional de almacenamiento en caché antes del origen, para descargarla aún más de las solicitudes. Si la imagen no está en la caché de CloudFront, la solicitud se reenviará a un bucket de S3, que se crea para almacenar las imágenes transformadas. Si la imagen solicitada ya está transformada y almacenada en S3, solo se ofrece y se almacena en caché en CloudFront.
  4. De lo contrario, S3 responderá con un código de error 403, que detectará la conmutación por error de origen de CloudFront. Gracias a esta característica nativa, CloudFront vuelve a intentar la misma URL, pero, esta vez, utiliza el origen secundario basado en la URL de función de Lambda. Cuando se invoca, la función de Lambda descarga la imagen original de otro bucket de S3, donde se almacenan las imágenes originales, la transforma mediante la biblioteca Sharp, almacena la imagen transformada en S3 y, a continuación, la ofrece a través de CloudFront, donde se almacenará en caché para futuras solicitudes.


Para implementar esta solución, siga los pasos de este blog. Además, en el blog, se muestra cómo usarla con el componente Image de Next.js. Tenga en cuenta que la solución le permite deshabilitar el almacenamiento de imágenes transformadas en S3 para confiar exclusivamente en la caché de CloudFront para entregar imágenes transformadas.

Soluciones administradas por terceros

Si prefiere utilizar una solución de optimización de imágenes administrada por terceros, considere las soluciones disponibles en AWS Marketplace, como CloudinaryImageKit.io o Cloudimage. Las tres soluciones utilizan CloudFront o tienen integraciones con CloudFront si desea administrar su propia distribución de CloudFront. Estos proveedores externos están especializados en la optimización de imágenes y pueden proporcionar capacidades de SaaS avanzadas, pero por un costo adicional.

Recursos

¿Le resultó útil esta página?