Nuestra guía 2026 para usar Webflow con Cloudflare mediante O2O y un Worker que hace proxy, optimiza y cachea tus imágenes, CSS, JS y fuentes en tu propio dominio.
Webflow funcionaba antes sobre AWS y durante un tiempo usó Fastly. Aunque es una opción aceptable, hemos comprobado que en proyectos grandes, sobre todo los que tienen muchas imágenes, Cloudflare nos ha dado mejoras de velocidad importantes, mejor disponibilidad y toda una serie de opciones de optimización, además de Workers. Pero, a diferencia de otras plataformas, cambiar tu DNS a Cloudflare no era sencillo. Webflow y Cloudflare no se llevaban bien cuando se trataba de hacer proxy de tu sitio y optimizarlo a través de Cloudflare.
En los viejos tiempos, ideamos un truco que usaba el ajuste de SSL y los datos de conexión sin SSL junto con la app Cassette para cachear y optimizar imágenes. Con el tiempo, Cloudflare eliminó las apps y, a base de mucha prueba y error, creamos un Worker propio para hacer proxy y cachear en Cloudflare las imágenes de Webflow.
Bueno, tenemos buenas noticias. Eso ha cambiado.
Webflow ha migrado a Cloudflare y durante un tiempo estuvimos en el limbo.
Lo mejor es que, gracias a su migración a Cloudflare, ahora tenemos Orange-to-Orange (O2O) funcionando de forma nativa. Se acabaron los apaños, las apps Cassette y los subdominios complicados para tus assets. Si leíste nuestro post anterior sobre cómo cachear Webflow con Cloudflare, básicamente puedes tirar a la basura la mayor parte (bueno, quédate con las partes que explican por qué querrías hacerlo en primer lugar).
Entonces, ¿cuál es la situación actual en cuanto a caché y proxy con Cloudflare? Pues, ahora que Webflow admite O2O, la nube naranja está activada en tu configuración de DNS, totalmente compatible con Webflow, y sin preocupaciones con el SSL ni similares. También significa que ahora puedes usar con facilidad la amplia gama de herramientas de seguridad y Workers que ofrece Cloudflare.
SIN EMBARGO, y esta es la gran salvedad, todos tus assets, desde las imágenes hasta el CSS, siguen alojados en un dominio de CDN de Webflow y, como no está en TU DOMINIO, sigues sin tener ningún control sobre ellos, a menos que...
En este post te guiaremos para configurar un Worker de Cloudflare (en la práctica, un proxy inverso de Webflow para tus assets) que transformará tu sitio de Webflow para que prácticamente todos los assets pasen por el proxy y se cacheen. Hablamos de optimización automática de imágenes, proxy de assets y caché en el edge, todo servido desde tu propio dominio. Suena divertido, ¿verdad? En el pasado nos centrábamos solo en las imágenes. Ahora vamos un paso más allá: abarcamos más y lo hacemos más fácil de usar que nunca.
Un recordatorio: esto es un tema avanzado. Hemos hecho el script más intuitivo, pero presta atención a la configuración. Léelo con cuidado; más adelante publicaremos un vídeo. ¡Vamos allá!
A continuación tienes la guía de inicio rápido. Para conocer más detalles del script, visita el MD en GitHub aquí, que entra en mucho más detalle.
Qué queremos conseguir
La situación es esta. Webflow aloja todos tus assets en sus dominios de CDN (cdn.prod.website-files.com, assets.website-files.com, etc.). Como esos dominios no son el tuyo, tu zona de Cloudflare no puede tocarlos, y eso crea varias limitaciones:
- Sin optimización de imágenes: las imágenes se sirven tal cual, sin conversión automática a AVIF o WebP. Eso lo haces en Webflow y no ocurre nada al vuelo.
- Restricciones de CORS: las peticiones entre orígenes a veces pueden fallar
- Sin caché unificada: tus assets están repartidos en distintos dominios
- Quebraderos de cabeza en redes sociales: las imágenes OG no están optimizadas para compartir
Nuestro Worker de Cloudflare intenta resolver gran parte de esto interceptando el HTML de tu sitio y reescribiendo todas esas URL de la CDN de Webflow para que pasen por tu dominio.
Una vez configurado, obtienes:
- Conversión automática de formato: AVIF para navegadores modernos, WebP para el resto, o lo que prefieras
- Optimización de calidad: compresión configurable (usamos 85 % por defecto, se ve genial)
- Caché en el edge: todos los assets se cachean en los más de 300 centros de datos globales de Cloudflare (recuerda que no hay precarga de caché)
- Entrega sin problemas de CORS: todo se sirve desde tu dominio
- Optimización para redes sociales: las imágenes OG y de Twitter se convierten a JPEG por compatibilidad (recuerda que Cloudflare puede convertir a AVIF, pero no puede volver atrás)
Y ahora lo mejor. Una vez que todo esto funciona, puedes añadir también otras funciones de Cloudflare. Page Rules, Cache Rules, WAF, Bot Protection, todo. Ahora la zona es tuya, ¡a divertirte!
Pero no son solo imágenes.
El Worker también hace proxy y cachea todos tus archivos CSS, JavaScript y de fuentes a través de tu dominio (o lo intenta). Tus WOFF2, tus TTF, tus bundles de JS minificados: todo se descarga de la CDN de Webflow, se cachea en el edge de Cloudflare y se sirve desde tu dominio con las cabeceras de caché adecuadas. ¿Imágenes AVIF? Ya están optimizadas, así que el Worker se salta la transformación y simplemente les hace proxy directamente. Los favicons reciben el tratamiento completo de imágenes. En resumen, si Webflow lo sirve desde su CDN, nosotros lo tomamos y lo hacemos tuyo.
Así que hemos subido el nivel. Más abajo encontrarás instrucciones de alto nivel. El vídeo solo muestra el sistema funcionando, pero cuando tenga tiempo grabaré una guía completa. Por ahora puedes seguir la guía escrita.
Parte 1: Configurar tu dominio con Cloudflare y Webflow
Hay dos formas de conectar tu dominio gestionado en Cloudflare con Webflow:
- Configuración estándar: Cloudflare solo gestiona el DNS y Webflow sirve todo (proxy DESACTIVADO)
- Configuración O2O: el tráfico pasa primero por tu zona de Cloudflare y después por Webflow (proxy ACTIVADO)
Queremos O2O porque es lo que nos permite usar Workers, reglas de caché, WAF y todas las demás ventajas de Cloudflare. Pero veamos las dos para que conozcas la diferencia.
Requisitos previos
Tu sitio de Webflow tiene que estar en la infraestructura de Cloudflare. Los sitios creados después del 21 de abril de 2025 ya están ahí. En los sitios más antiguos, revisa los ajustes de tu Workspace → Domain Updates para ver si primero tienes que migrar.
Configuración DNS estándar (sin O2O)
Si solo quieres que Cloudflare gestione tu DNS sin proxy (es lo que indican las instrucciones por defecto de Webflow):
Para tu dominio raíz (@):
- Tipo:
A - Nombre:
@ - Valor:
198.202.211.1 - Estado del proxy: Solo DNS (nube gris)
Para www:
- Tipo:
CNAME - Nombre:
www - Destino:
cdn.webflow.com - Estado del proxy: Solo DNS (nube gris)
Esto funciona bien, pero no obtienes ninguna función de Cloudflare más allá del DNS. El tráfico va directo a Webflow.
Configuración O2O (la que queremos)
Para activar Orange-to-Orange y usar de verdad las funciones de Cloudflare, necesitas registros CNAME con proxy:
Para tu dominio raíz (@):
- Tipo:
CNAME - Nombre:
@ - Destino:
cdn.webflow.com - Estado del proxy: Con proxy (nube naranja ACTIVADA)
Para www:
- Tipo:
CNAME - Nombre:
www - Destino:
cdn.webflow.com - Estado del proxy: Con proxy (nube naranja ACTIVADA)
Importante: elimina cualquier registro A existente que apunte a 198.202.211.1. No puedes tener ambos. Para O2O, se usan registros CNAME con el proxy activado.
Si tienes otros subdominios (como blog.yourdomain.com), añade también un CNAME con proxy para cada uno.

Ajustes de SSL/TLS
Ve a SSL/TLS en tu panel de Cloudflare y establece el modo de cifrado en Full (strict).

Añadir el dominio en Webflow
Ahora, en Webflow:
- Ve a Site settings → Publishing → Production
- Añade tu dominio (tanto la raíz como www)
- Publica tu sitio
Sobre esa advertencia de "Update needed"
Esto es lo que ocurre. Una vez que la nube naranja está activada, Webflow ya no puede ver tus registros DNS. Así que se va a quejar, o al menos puede hacerlo. Verás "Update needed" o "Update pending" en los ajustes de Publishing.
Ignórala.
Es un comportamiento esperado. La verificación de Webflow no puede ver a través del proxy. Si tu sitio carga correctamente, todo está bien. Puedes seguir publicando con normalidad. A mí la advertencia se me ha quedado pegada, y en algunos casos desaparece.
Comprobar que funciona
Visita tu sitio. Si carga, todo va bien. También puedes:
- Usar SSL Labs para probar tu certificado SSL
- Usar whatsmydns.net para confirmar que tu dominio resuelve a IP de Cloudflare
- Revisar las cabeceras de respuesta en busca de
cf-ray(indica que Cloudflare está en la cadena)
Muy bien, O2O está listo. Ahora vamos a la parte divertida.
Parte 2: Activar las funciones de Cloudflare necesarias
Antes de desplegar el Worker, tenemos que activar un par de cosas en Cloudflare y asegurarnos de que las suscripciones adecuadas están activas.
Activar Image Transformations
Este es el ingrediente mágico que permite a Cloudflare convertir y optimizar tus imágenes al vuelo.
- Ve al Cloudflare Dashboard → Tu zona
- Navega a Images → Transformations
- Haz clic en Enable Image Transformations
Sin esto, las URL /cdn-cgi/image/ no funcionarán y tus imágenes darán simplemente un 404. No es lo ideal.
Costes: el plan gratuito incluye 5.000 transformaciones únicas al mes. En un plan de pago, las primeras 5.000 transformaciones únicas también están incluidas y después cuesta 0,50 $ por cada 1.000 transformaciones únicas al mes. Para la mayoría de los sitios de Webflow, el plan gratuito es más que suficiente para empezar.
Añadir orígenes permitidos
Sin salir de Images → Transformations, haz clic en Sources y añade estos orígenes:
Origen:
-
cdn.prod.website-files.com assets.website-files.comassets-global.website-files.com-
uploads-ssl.webflow.com cdn.webflow.com-
www.yourdomain.com¡Crítico!
Este último es fundamental y fácil de pasar por alto. Las URL de transformación usan tu propio dominio como origen (porque hacemos el proxy a través de /img-original/), así que Cloudflare necesita permiso para obtener contenido de sí mismo. Meta, ya lo sabemos.

Activar Workers
Necesitarás tener Workers activado en tu zona.
- Ve a Workers & Pages en el Cloudflare Dashboard
- Si nunca has usado Workers, se te pedirá que configures un subdominio
Costes: el plan gratuito incluye 100.000 peticiones al día. Es mucho. El plan de pago cuesta 5 $ al mes por 10 millones de peticiones, si necesitas más.
Parte 3: Crear el Worker
Ahora sí, el Worker en sí. Aquí es donde ocurre la magia.
Paso 1: Crear un Worker nuevo
- Ve a Workers & Pages
- Haz clic en Create Application → Create Worker
- Ponle un nombre (algo como
webflow-optimizerosite-cache) - Verás una plantilla Hello World: bórrala entera
Paso 2: Pegar el código del Worker
Tenemos un script de Worker completo que se encarga de todo. Es un archivo JavaScript bastante largo que:
- Intercepta las respuestas HTML de Webflow
- Reescribe todas las URL de imágenes para usar Cloudflare Image Resizing
- Hace proxy directo de las imágenes AVIF (ya son óptimas)
- Hace proxy y cachea CSS, JS y fuentes
- Gestiona las imágenes OG/Twitter para compartir en redes sociales
- Añade las cabeceras CORS adecuadas
- Lo cachea todo en el edge
Pega el script completo del Worker (puedes tomarlo de nuestro GitHub o de la página de aquí).
Mira el Pen Webflow CDN - Cloudflare Asset Proxy Worker de Jakes van Eeden (@milkmoonstudio) en CodePen.
Paso 3: Guardar y desplegar
Pulsa Save and Deploy. El Worker ya está activo, pero todavía no hace nada porque no le hemos dicho dónde ejecutarse.

Parte 4: Variables de entorno
El Worker usa variables de entorno para que puedas configurarlo sin editar el código. Ve a tu Worker → Settings → Variables and Secrets.

Variable obligatoria
Variable: DOMAIN
Value: Tu dominio (sin https://), así que en nuestro caso www.milkmoonstudio.com
Esto le indica al Worker qué dominio usar en las URL reescritas. Si no está presente, el código comprobará el dominio actual y lo usará como alternativa.
Variables opcionales (con valores por defecto razonables; todas las variables tienen un valor de reserva)
Variable: IMAGE_FORMAT
Value: auto", webp", o avif
Variable: IMAGE_QUALITY
Value: 85 (Calidad de 1 a 100; 85 es un buen equilibrio)
Variable: OG_IMAGE_FORMAT
Value: jpeg (Formato de las imágenes para compartir en redes sociales)
Variable: OG_IMAGE_QUALITY
Value: 80 (Calidad de las imágenes OG)
Variable: EDGE_CACHE_TTL
Value: 31536000 (Duración de la caché en el edge, en segundos) (por defecto: 1 año)
Variable: BROWSER_CACHE_TTL
Value: 604800 (Duración de la caché del navegador, en segundos; por defecto: 1 semana)
Variable: CATCH_ALL_EXTERNAL
Value: false (Procesa también imágenes que no son de la CDN de Webflow; es una función muy experimental y requiere image transformations para usar cualquier dominio)
Recomendaciones:
- Deja
IMAGE_FORMATenauto: sirve AVIF a los navegadores que lo admiten y WebP al resto IMAGE_QUALITYen 85 se ve genial en la mayoría de las imágenes. Bájalo a 70-75 si de verdad quieres ahorrar bytes- Deja
OG_IMAGE_FORMATenjpeg: algunas plataformas sociales todavía no gestionan AVIF/WebP en las vistas previas
Parte 5: Configurar la ruta del Worker
Aquí hay un punto crítico en el que mucha gente se atasca. El Worker tiene que ejecutarse en tu dominio personalizado, no en el subdominio *.workers.dev. La Cache API no funciona en workers.dev, lo que significa que no hay caché, lo que echa por tierra todo el objetivo.
Añadir la ruta
- En tu Worker, ve a Settings → Domains & Routes
- Haz clic en Add → Route
- Configura:
- Route:
*yourdomain.com/* - Zone: Selecciona tu zona
- Route:
- Haz clic en Add Route
El * del principio captura tanto www.yourdomain.com como yourdomain.com. El /* del final captura todas las rutas.
Si solo usas www, puedes ser más específico: www.yourdomain.com/*

Parte 6: Cómo funciona todo
Vamos a ver qué ocurre realmente por debajo. Esta parte es para los curiosos (y para cuando algo salga mal, que inevitablemente pasará, y necesites depurarlo).
El flujo de las peticiones
Cuando alguien visita tu sitio:
- La petición llega a Cloudflare: primero a tu zona (O2O)
- El Worker intercepta: comprueba si es una petición HTML
- Obtiene el contenido de Webflow: consigue el HTML (cacheado en el edge)
- Transforma las URL: reescribe todas las URL de la CDN de Webflow
- Devuelve el HTML transformado: el navegador recibe la página modificada
Cuando después el navegador pide una imagen:
- La petición llega a
/cdn-cgi/image/format=auto,quality=85/https://yourdomain.com/img-original/... - Cloudflare Image Resizing: interpreta la URL de transformación
- Obtiene el origen: consigue el original desde tu endpoint
/img-original/ - El Worker hace proxy:
/img-original/obtiene el contenido de la CDN de Webflow - Transforma: convierte a AVIF/WebP y aplica la calidad
- Cachea: tanto el original como el transformado se cachean en el edge
- Devuelve: la imagen optimizada se sirve al navegador
Estructura de la URL
Veamos cómo es una URL transformada:
Original (en Webflow):
https://cdn.prod.website-files.com/63565c108c96756a59b92502/image.jpg
Transformada (en tu HTML):
https://yourdomain.com/cdn-cgi/image/format=auto,quality=85/https://yourdomain.com/img-original/https%3A%2F%2Fcdn.prod.website-files.com%2F63565c108c96756a59b92502%2Fimage.jpg
Desglosándola:
https://yourdomain.com/cdn-cgi/image/: el endpoint de redimensionado de imágenes de Cloudflareformat=auto,quality=85/: los parámetros de transformaciónhttps://yourdomain.com/img-original/: nuestro endpoint de proxyhttps%3A%2F%2Fcdn.prod...: la URL de la imagen original, codificada
Qué se transforma y qué solo pasa por el proxy
- PNG, JPG, WebP, GIF: Optimizados mediante Cloudflare Image Resizing
/cdn-cgi/image/→/img-original/ SVG: Saneado (se eliminan los scripts), formato conservado/cdn-cgi/image/→/img-original/AVIF: Solo proxy (ya es óptimo)/img-cache/- CSS, JS: Con proxy y caché
/asset-cache/ Fuentes: (woff, woff2, ttf, otf, eot) con proxy y caché/asset-cache/ (very experimental)Favicons: Optimizados como imágenes/cdn-cgi/image/→/img-original/Imágenes OG/Twitter: Convertidas a JPEG/cdn-cgi/image/→/img-original/
Parte 7: Probar tu configuración
Es hora de asegurarnos de que todo funciona bien.
Comprobaciones básicas
1. Ver el código fuente de la página
- Visita tu sitio
- Clic derecho → Ver código fuente de la página
- Busca
/cdn-cgi/image/: debería aparecer en las URL de las imágenes - Busca
/asset-cache/: debería aparecer en las URL de CSS y JS
Si las ves, el Worker está funcionando y transformando tu HTML.
2. Revisar la pestaña Network
- Abre DevTools (F12 o Cmd+Option+I)
- Ve a la pestaña Network
- Recarga la página
- Filtra por "Img"
- Comprueba que las URL de las imágenes vienen de tu dominio, no de la CDN de Webflow
3. Verificar las cabeceras de caché: haz clic en una imagen de la pestaña Network y revisa las cabeceras de respuesta (la cabecera propia de Cloudflare cf-cache-status indica HIT o MISS de la misma manera):
X-Cache: HIT= Servido desde la caché de Cloudflare (¡bien!)X-Cache: MISS= Primera petición, ahora ya está en caché (también correcto)Content-Type: image/avifoimage/webp= La conversión de formato funciona
4. Probar cómo se comparte en redes sociales
- Usa el Sharing Debugger de Facebook
- Usa una herramienta de vista previa de tarjetas como opengraph.xyz o el editor de publicaciones de X (el antiguo Card Validator de Twitter ya no muestra vistas previas)
- Comprueba que las imágenes OG cargan sin errores
Usar la extensión DrFlare
La forma más fácil de probar tu configuración es con la extensión DrFlare para Chrome. Ábrela desde DevTools y actualiza la página. Verás estadísticas detalladas y podrás pasar el cursor sobre las imágenes para analizarlas en el propio sitio. Se había dejado de mantener, pero ha vuelto a la vida como DrFlare Reloaded, consíguela aquí.
Recuerda actualizar el navegador una vez que tengas DrFlare abierto.
Parte 8: Solución de problemas
Las cosas fallan. Así se arreglan los problemas más comunes.
Las imágenes devuelven 404
Síntomas: las imágenes no cargan, errores 404 en la consola.
Lista de comprobación:
- ✅ ¿Image Transformations activado en Cloudflare?
- ✅ ¿Tu dominio añadido a Allowed Origins?
- ✅ ¿Ruta del Worker activa y correcta?
- ✅ ¿Variable de entorno
DOMAINconfigurada correctamente?
Revisa los registros del Worker: Cloudflare Dashboard → Workers → Tu Worker → Logs
Los assets siguen cargándose desde la CDN de Webflow
Síntomas: las URL de CSS/JS no se han transformado.
Lista de comprobación:
- ✅ ¿Worker desplegado en una ruta de dominio personalizado (no en
*.workers.dev)? - ✅ ¿Patrón de ruta correcto? (p. ej.,
*yourdomain.com/*) - Borra la caché del navegador y recarga (Ctrl/Cmd + Shift + R)
Mira el código fuente de la página. Si las URL no están transformadas, el Worker no se está ejecutando en esa ruta.
Las imágenes OG no funcionan en redes sociales
Síntomas: las vistas previas en redes sociales muestran imágenes rotas.
Comprueba:
- Usa el Sharing Debugger de Facebook o una herramienta de vista previa de tarjetas para ver el error real
- Verifica que
OG_IMAGE_FORMATestá configurado comojpeg - Comprueba que la etiqueta meta del código fuente de la página se ha transformado
Webflow muestra "Update needed" para el dominio
¡Es lo esperado! Cuando el proxy de Cloudflare está activado, Webflow no puede ver tus registros DNS. Si tu sitio carga correctamente, ignora esta advertencia.
Error 525 Handshake
Normalmente significa que hay algún problema con tu configuración de SSL:
- Comprueba que el modo SSL/TLS está en Full (strict) en Cloudflare
- Asegúrate de que no tienes ajustes de SSL en conflicto
Parte 9: Costes
Hablemos de dinero. ¿Cuánto te va a costar esto?
Cloudflare Workers
- Plan gratuito: 100.000 peticiones/día
- De pago: 5 $/mes por 10 millones de peticiones
Image Transformations
- Plan gratuito: 5.000 transformaciones únicas/mes
- De pago: las primeras 5.000 transformaciones únicas incluidas, después 0,50 $ por cada 1.000 transformaciones únicas/mes
Para un sitio de Webflow típico
La estrategia de caché reduce los costes de forma notable:
- HTML cacheado en el edge → menos peticiones al origen
- Imágenes originales cacheadas → la transformación solo ocurre una vez por imagen
- Imágenes transformadas cacheadas → se sirven desde el edge en las visitas repetidas
- TTL de 1 año → las imágenes permanecen en caché hasta que las purgues
- Recuerda que las reglas de caché y de página permiten una estrategia de caché más compleja. Por ejemplo, las páginas del blog pueden cachearse de forma menos agresiva que una página de inicio, porque los posts se actualizan con más frecuencia, mientras que las páginas estáticas suelen poder cachearse casi indefinidamente.
Vaciar la caché
Una vez que hayas configurado tu estrategia de caché, recuerda que los cambios pueden no reflejarse de inmediato. Si estableces la caché en el edge durante una semana para una página o un asset, solo descartará la versión cacheada en el edge cuando pase esa semana.
Para vaciar la caché en el Cloudflare Dashboard, ve a Caching → Configuration y usa Custom Purge (para ser más específico sobre lo que vacías) o Purge Everything (que elimina toda la caché).
Después, recuerda borrar la caché del navegador o probar con una ventana de navegación privada o de incógnito. Si lo que tarda en actualizarse es el DNS y no la caché, tenemos un post sobre cómo acelerar la resolución de DNS al publicar tu sitio de Webflow, échale un vistazo.

Custom Purge ofrece las siguientes opciones, que permiten purgas dirigidas.

Purgar la caché con un webhook en el panel de ajustes de Webflow
También es posible purgar al pulsar Publicar en Webflow añadiendo un webhook a los ajustes de Webflow.
Webflow → Webhook de purga de caché de Cloudflare
Este es el resumen rápido:
El flujo
- Webflow dispara un webhook cuando publicas tu sitio
- Algo recibe ese webhook y llama a la API de Cloudflare para purgar la caché
El problema: Cloudflare no tiene un endpoint directo para "recibir webhooks", así que necesitas un intermediario (un Worker de Cloudflare, Zapier, Make o una sencilla función serverless).
Pasos de configuración
1. En Webflow
- Ve a Site settings → Apps & integrations → Webhooks
- Añade un webhook con el tipo de disparador: Site publish
- Apúntalo a la URL de tu intermediario (Worker, Zapier, etc.)
2. En Cloudflare
- Consigue tu Zone ID (en la página de resumen de tu dominio)
- Crea un API Token con el permiso
Zone.Cache Purge
3. El intermediario (ejemplo con un Worker de Cloudflare)
Tu Worker recibe el webhook de Webflow y llama al endpoint de purga de Cloudflare:
POST https://api.cloudflare.com/client/v4/zones/{zone_id}/purge_cache
Con el cuerpo: {"purge_everything": true}
Documentación
- Webflow Webhooks: https://developers.webflow.com/data/docs/working-with-webhooks
- Cloudflare Purge Cache API: https://developers.cloudflare.com/api/resources/cache/methods/purge/
Parte 10: Limitaciones
Nada es perfecto. Esto es lo que conviene saber:
Limitaciones conocidas
- Cache Reserve no disponible: Webflow usa proxy O2O, que se salta Cache Reserve. Los assets se cachean solo en el edge.
- JSON-LD no se transforma: Las URL de los datos estructurados no se modifican. Los buscadores gestionan bien las URL originales.
- Transformación basada en regex: Varias pasadas sobre el HTML. Es aceptable para páginas típicas (<200KB).
Lo que no funciona
- URL de datos (
data:image/...): están incrustadas, no hay nada que pasar por el proxy - URL blob (
blob:...): las genera el navegador, no se les puede hacer proxy - URL relativas: ya están en tu dominio
- Assets que no son de la CDN de Webflow: a menos que
CATCH_ALL_EXTERNAL=true
Contenido dinámico
El Worker solo transforma el HTML de la respuesta inicial. Es posible que las imágenes añadidas mediante JavaScript tras cargar la página no se transformen, a menos que también estén en el HTML inicial. Si haces mucho renderizado en el cliente, tenlo en cuenta.
Instrucciones de reversión
Si algo sale terriblemente mal (probablemente no pasará, pero por si acaso):
Desactivación rápida (conservando el Worker)
- Ve a Worker → Settings → Domains & Routes
- Elimina la ruta
- El sitio vuelve de inmediato a servirse directamente desde Webflow
- Activa Developer Mode para saltarte la caché
Eliminación completa
- Elimina la ruta del Worker
- Elimina el propio Worker
- (Opcional) Desactiva Image Transformations
- (Opcional) Quita los Allowed Origins
Tu sitio volverá al alojamiento estándar de Webflow con el proxy O2O todavía activo. Seguirás teniendo las demás funciones de Cloudflare, como WAF y protección contra bots.
Preguntas frecuentes
¿Webflow usa Cloudflare?
Sí. Webflow trasladó su alojamiento a Cloudflare en 2025. Los sitios creados después del 21 de abril de 2025 ya están en Cloudflare, y los más antiguos tuvieron que cambiar sus dominios personalizados a los nuevos registros DNS de Webflow (el CNAME cdn.webflow.com y el registro A 198.202.211.1). Ese cambio es justo lo que hace posible O2O, y por eso ya no hacen falta los trucos de nuestros posts anteriores.
¿Cómo configuro la CDN y el SSL de Cloudflare para un sitio de Webflow?
Apunta los nameservers de tu dominio a Cloudflare, añade registros CNAME con proxy para @ y www que apunten a cdn.webflow.com, establece SSL/TLS en Full (strict), añade después el dominio en Webflow en Site settings → Publishing → Production y publica. Eso es O2O, y la Parte 1 de arriba lo explica paso a paso. Si solo quieres Cloudflare para el DNS, usa en su lugar los registros con nube gris (solo DNS), pero entonces no obtienes ninguna de las ventajas de caché u optimización.
¿Qué es cdn.prod.website-files.com?
Es la CDN de assets de Webflow, el dominio donde viven realmente tus imágenes, CSS, JavaScript y fuentes. Como no es tu dominio, tu zona de Cloudflare no puede cachear ni optimizar nada de lo que se sirve desde ahí, ni siquiera con O2O activado. El Worker de este post lo soluciona reescribiendo esas URL para que los archivos pasen por el proxy, se optimicen y se cacheen a través de tu propio dominio.
¿Cómo vacío la caché después de publicar en Webflow?
Webflow gestiona su propia caché cuando publicas, pero todo lo que esté cacheado en tu zona de Cloudflare se queda ahí hasta que caduca el TTL. Púrgalo en el panel de Cloudflare, en Caching → Configuration (Custom Purge o Purge Everything), o automatízalo con un webhook de Site publish que llame a la API de purga de Cloudflare, tal como se describe en la sección sobre la caché de más arriba. Después borra la caché de tu navegador o prueba en una ventana privada.
Para terminar
Y eso es todo. Ya tienes un sitio de Webflow con turbo, funcionando a través de Cloudflare con optimización de imágenes, caché de assets y todas las ventajas del edge que puedas querer.
¿Lo mejor? Una vez que esto está en marcha, puedes añadir más funciones de Cloudflare. Configura Page Rules (o Cache Rules, que las están sustituyendo) para un comportamiento de caché específico. Añade reglas de WAF para la seguridad. Configura Bot Protection. Usa Waiting Room si esperas picos de tráfico. Ahora la zona es tuya. Tendrás que experimentar para sacarle el máximo partido.
Gran parte de la optimización viene de jugar con la caché, las reglas de página, etc.
Llevamos un tiempo con esta configuración en producción y las mejoras de rendimiento parecen sólidas. Tiempos de carga más rápidos, mejores Core Web Vitals, archivos de imagen más pequeños y clientes más contentos. Si necesitas convencer a un cliente (o a tu jefe) de por qué importa, nuestro post sobre cómo la velocidad de página impulsa el éxito del negocio lo argumenta muy bien.
Si tienes problemas o alguna pregunta, escríbenos. Siempre nos encanta charlar sobre optimización del rendimiento en Webflow (es un poco lo nuestro). Intentaremos responderte lo antes posible.
No olvides echar un vistazo a la sección How-To de nuestro blog para ver más tutoriales. Tenemos posts sobre de todo, desde la configuración de Tag Manager hasta el tamaño dinámico de fuentes.
Hasta la próxima, sigue creando. ✌️

Estas pruebas se hicieron en el momento de la publicación, así que todas las cosas raras que probamos en nuestro sitio en cada momento deberían estar funcionando.





