Trasladar la generación de miniaturas de un backend en PHP a Cloudflare Workers eliminó toda la carga de CPU en el servidor de origen de un sitio de alojamiento de videos que sirve millones de imágenes al día. El cambio también desplazó la latencia del procesamiento de imágenes desde el centro de datos hacia el edge, reduciendo drásticamente los tiempos de respuesta y haciendo que los costos de ancho de banda fueran predecibles.

Por qué falló el modelo anterior

El sitio, una plataforma que muestra decenas de miles de videos, incrusta hasta 40 miniaturas en una sola página. Cada miniatura se redimensiona bajo demanda mediante un script de PHP que lee el archivo original y lo escala. Cuando los rastreadores (crawlers) visitaban el sitio, el servidor del backend se bloqueaba.

El procesamiento en el edge resuelve los cinco requisitos principales

Una API de miniaturas de nivel de producción debe gestionar:

  • Fan-in – extraer imágenes de origen de múltiples hosts de terceros.
  • Fan-out – producir varios tamaños (por ejemplo, tarjetas de 320 px, imágenes hero de 640 px).
  • Negociación de formato – servir WebP o AVIF cuando el navegador los soporte para reducir el ancho de banda.
  • Caché – asegurar que la primera solicitud pueda ser costosa, pero que cada solicitud posterior sea gratuita.
  • Seguridad – evitar que cualquier persona abuse del servicio para procesar imágenes arbitrarias.

Cloudflare Workers aborda cada punto sin tocar la CPU del origen:

  1. Proximidad – Los Workers se ejecutan en centros de datos cercanos al usuario, por lo que la imagen procesada recorre un camino más corto.
  2. Redimensionamiento de imágenes integrado – La función Image Resizing de la plataforma realiza el trabajo de píxeles, eliminando la necesidad de una biblioteca personalizada.
  3. Cache API – Los Workers almacenan la imagen redimensionada en el edge; tras la primera solicitud, el edge la sirve directamente.
  4. Seguridad programable – Un pequeño script valida las firmas HMAC, aplica una lista de permitidos (allow-list) de nombres de host y anchos, y normaliza las claves de caché para evitar el envenenamiento de caché (cache poisoning).

Cómo funciona el sistema

  1. El origen crea URLs firmadas – El backend mantiene una clave secreta y añade una firma HMAC a cada solicitud de miniatura. La URL también incluye el ancho y el formato deseados.
  2. El Worker verifica la firma – Al recibirla, el Worker vuelve a calcular el HMAC con el secreto compartido. Si la firma falta o es incorrecta, la solicitud se rechaza, deteniendo el abuso.
  3. Aplicación de la lista de permitidos – El script comprueba que el nombre de host de origen esté en una lista predefinida y que el ancho solicitado sea uno de los tamaños admitidos. Esto evita que se guarden en caché hosts maliciosos.
  4. Normalización de la clave de caché – La firma en sí se elimina de la clave de caché; la clave solo contiene la URL de origen, el ancho y el formato. Esto aumenta la probabilidad de que diferentes usuarios que soliciten la misma imagen accedan a la misma entrada en caché.
  5. Búsqueda y redimensionamiento en el edge – Si la imagen no está ya en caché, el Worker obtiene la original del host de terceros, ejecuta la Image Resizing API y almacena el resultado en la caché del edge.
  6. Calentamiento de caché (Cache warming) – Después de cada rastreo, un script ligero de Python realiza solicitudes previas de las miniaturas más recientes. Por lo tanto, el primer usuario real recibe una respuesta en caché en lugar de esperar a la operación de redimensionamiento.

Impacto medible después de un mes

  • CPU del origen para imágenes – Cayó a cero; el backend nunca vuelve a procesar bytes de imágenes.
  • Velocidad de servicio de HTML – Mejoró notablemente porque el servidor ya no se bloquea con el trabajo de las imágenes.
  • Tasa de aciertos de la caché del edge (cache hit rate) – Alcanzó el 96 %, lo que significa que casi todas las solicitudes se satisficieron desde el edge sin una búsqueda en el backend.
  • Latencia – Disminuyó, ya que las imágenes ahora se sirven desde un centro de datos cercano al usuario en lugar de un origen central.
  • Previsibilidad del ancho de banda – Con el almacenamiento en caché en el edge, el tráfico saliente del origen es estable y fácil de pronosticar.

Conclusión

Delegar la generación de miniaturas a Cloudflare Workers convirtió un cuello de botella limitado por la CPU en una caché de edge de coste casi nulo. El origen ahora solo emite URLs firmadas, mientras que el edge se encarga de la obtención, el redimensionamiento, la negociación de formatos y el servicio de resultados en caché. Para cualquier sitio que dependa en gran medida de las imágenes —especialmente las plataformas de video que muestran docenas de miniaturas por página—, el enfoque "edge-first" ofrece páginas más rápidas, costes previsibles y una separación más clara entre "qué mostrar" (origen) y "cómo entregarlo" (edge).