Optimización gratis de imágenes en Webflow con Cloudflare (2026): nuestro Worker O2O open source

ACTUALIZADO (2 de octubre de 2026): hemos reescrito este post por completo para la versión 6 de nuestro Worker, que ahora es gratis, open source y está en GitHub. Si seguiste la versión de enero de esta guía (la de los enlaces /cdn-cgi/image/, una variable DOMAIN y un CodePen que pegabas en el dashboard), salta directamente a la sección "Actualizar desde el Worker antiguo". Todo lo demás es nuevo.

Llevamos unos cuatro años intentando que Webflow y Cloudflare se lleven bien. Primero fue un apaño con los ajustes de SSL y la app Cassette para cachear y optimizar imágenes. Luego Cloudflare se cargó las apps y escribimos un Worker propio para hacer proxy y cachear las imágenes de Webflow. Después Webflow movió su hosting a Cloudflare, Orange-to-Orange (O2O) empezó a funcionar como es debido y en enero publicamos la primera versión de esta guía, con un Worker más grande y mejor que también se encargaba del CSS, el JS y las fuentes.

Y ahora, siendo sinceros, se nos ha ido un poco de las manos. Hemos reconstruido el Worker desde cero, lleva funcionando en nuestro propio sitio desde finales de septiembre y en un segundo sitio desde el 1 de octubre, lo hemos probado con cinco páginas reales de cuatro sitios de Webflow distintos y lo hemos subido entero a GitHub, gratis, con un botón de Deploy. Se acabó copiar un script de un CodePen. Haces clic en un botón, pegas un secreto, añades una línea y listo.

Lo hemos llamado Milk Moon Webflow Optimizer. Aquí tienes lo que hace, por qué cumple las reglas de Webflow, cómo funciona la caché, cuánto ahorra, cada ajuste, toda la configuración desde el DNS hasta el final y todo lo que puede salir mal. Es largo, así que ve a por un café.

La versión corta

El Milk Moon Webflow Optimizer es un Worker de Cloudflare que se coloca delante de tu sitio de Webflow (en la práctica, un proxy inverso de Webflow para tus archivos). A medida que cada página pasa por él, cambia la dirección de cada imagen, hoja de estilos, script y fuente de Webflow por una dirección en tu propio dominio. Cuando el navegador pide esos archivos, el Worker los trae de Webflow una vez, reduce las imágenes a AVIF o WebP (el que pueda abrir el navegador de ese visitante) y lo guarda todo en la caché de Cloudflare, cerca de tus visitantes, hasta un año. Todos los que vengan después reciben la copia cacheada.

Lo que consigues:

• Cada imagen PNG, JPG, GIF y WebP convertida al vuelo a AVIF o WebP. Nadie tiene que volver a exportar nada en Webflow.
• Imágenes, CSS, JS y fuentes servidos desde tu dominio y cacheados en el edge de Cloudflare.
• Muchos menos datos saliendo de Webflow, que es justo lo que Webflow te cobra.
• Páginas que se siguen actualizando en cuanto le das a publicar.
• Imágenes de vista previa para redes sociales que siempre funcionan (convertidas a JPEG para LinkedIn, Facebook, WhatsApp y X), además de la etiqueta og:url que Webflow nunca añade.
• Opcionalmente, imágenes que se descargan al tamaño al que de verdad se muestran, no al tamaño que Webflow supuso.
• Tu sitio se ve exactamente igual. Mismo diseño, mismas interacciones, mismo contenido.

Hoy, en nuestra home, los 38 archivos de imagen principales pesan 8.762 KB directos desde Webflow y 1.755 KB a través del Worker. Eso es un 80% menos, y ni una sola imagen salió más grande que la original. La peor de todas, una captura de proyecto en PNG de 2,7 MB, ahora llega como un WebP de 198 KB. La misma imagen.

¿Para qué molestarse? El problema con los servidores de archivos de Webflow

Webflow es genial para crear y alojar sitios, si no, no seríamos un estudio de Webflow. Pero la forma en que entrega tus archivos tiene tres pegas, y todas te cuestan dinero o velocidad.

1. Tus imágenes salen tal como las subiste. Webflow sí crea algunas copias más pequeñas de cada imagen para distintos tamaños de pantalla (los archivos -p-500, -p-800 que seguramente has visto), y tiene una herramienta Compress en el panel Assets que convierte imágenes a AVIF o WebP. Pero es un trabajo manual, sustituye tus originales y todo lo que no hayas convertido sigue saliendo exactamente como lo subiste. Una captura en PNG que subiste sigue siendo un PNG, y llega a cada móvil como PNG. Formatos modernos como AVIF y WebP pueden dejar esa misma imagen en una fracción del tamaño sin ninguna diferencia que llegues a notar.

2. Webflow cobra por ancho de banda. Cada plan de sitio tiene un límite mensual de ancho de banda, y la propia definición de Webflow es que el ancho de banda total es "cada byte que la CDN de Webflow entrega para tu sitio, incluidos HTML, CSS, JavaScript y assets". Los bots cuentan. Los 404 cuentan. Si te pasas dos meses seguidos, tu plan sube un nivel automáticamente. Las imágenes pesadas y las descargas repetidas son lo que dispara esa cifra.

3. Tus archivos no viven en tu dominio. Incluso con O2O activado, tus imágenes, CSS y fuentes están en cdn.prod.website-files.com (y en algunos hosts más antiguos de Webflow). Ese no es tu dominio, así que tu zona de Cloudflare no puede tocarlos. Ni reglas de caché de Cloudflare, ni optimización de imágenes, nada. La nube naranja solo cubre tus páginas.

El Worker arregla las tres cosas, y lo hace sin cambiar nada en tu proyecto de Webflow.

¿Está permitido? Webflow, O2O y las reglas

Respuesta corta: sí, y es la parte de la que estamos más contentos, porque los métodos antiguos de verdad no eran buenos. La app Cassette, los trucos de SSL con la nube gris, los subdominios para assets, todo eso éramos nosotros peleándonos con la plataforma. Esto no.

Así están las cosas, en palabras de la propia Webflow:

• El centro de ayuda de Webflow dice que "O2O es la forma admitida de usar funciones de Cloudflare delante de Webflow", y que O2O está disponible en cualquier plan de Cloudflare, incluido el Free.
• La propia tabla de compatibilidad de productos con O2O de Cloudflare indica que Workers es compatible, con una advertencia sensata: un Worker en tu host O2O puede afectar a tus visitantes si se porta mal. Que es exactamente por lo que el nuestro tiene los seguros que verás más abajo. La misma tabla también dice que, en general, no se recomienda cachear por tu lado, sobre todo el HTML, porque Webflow ya cachea tus páginas. Por eso el Worker deja las páginas a Webflow por defecto y solo cachea los archivos de Webflow, que nunca cambian sin cambiar también de dirección.
• Lo único que el centro de ayuda de Webflow menciona por su nombre es hacer proxy inverso de tu dominio de staging *.webflow.io, que según ellos incumple sus términos. Nosotros nunca lo tocamos. El Worker solo funciona en tu dominio personalizado, que es donde Webflow dice que debes hacer el proxy.
• La guía de proxy inverso de Webflow también pide que pases la ruta completa y la query string tal cual y que evites reescribir el HTML de forma que cambie los enlaces internos. El Worker deja pasar cada petición de página sin tocarla y solo reescribe las direcciones de los propios archivos de Webflow. Tus enlaces, tus formularios, tus páginas del CMS, tu búsqueda y tus filtros se quedan exactamente como los hizo Webflow.

Dos salvedades, siendo honestos. Primero, el equipo de soporte de Webflow no va a solucionar los problemas de un Worker por ti; lo dicen claramente ("Tú gestionas tu proxy"). Es justo, y también es la razón por la que desactivarlo es un cambio de una línea (más sobre eso en la sección Volver atrás). Segundo, no estamos diciendo que Webflow haya aprobado nuestro Worker. Lo que sí decimos es que está construido por completo sobre la configuración que Webflow admite oficialmente, usando una función de Cloudflare que Cloudflare dice que funciona con ella. Sin apaños.

Cómo funciona, en palabras sencillas

Imagina que Webflow es una fábrica que hace todo lo de tu tienda. Sin el Worker, cada pedido de cada cliente sale directamente de la fábrica, con el embalaje original y voluminoso, todas y cada una de las veces.

El Worker es el encargado de un almacén local. La primera vez que alguien pide algo, lo trae de la fábrica, lo vuelve a empaquetar en la caja más pequeña en la que cabe (una caja distinta según lo que pueda abrir el cliente) y deja una copia en la estantería. A partir de ahí, los clientes reciben lo de la estantería local. Es más rápido para ellos y la fábrica apenas envía nada. El encargado además sigue reglas estrictas: solo atiende pedidos cuyas etiquetas escribió él mismo, nunca toca ciertas entregas (los controles de seguridad, la analítica) y, si algo sale mal, se aparta y deja que el pedido llegue directamente de la fábrica, exactamente como siempre.

Aquí lo tienes en un dibujo de verdad.

Paso a paso

1. Un visitante pide una página. Alguien abre tu sitio. Gracias a O2O, la petición llega primero al centro de datos de Cloudflare más cercano.
2. El Worker trae la página de Webflow. Exactamente como la sirve Webflow.
3. Comprueba que de verdad es una página de Webflow. Cada página de Webflow lleva una pequeña marca en la etiqueta <html> (data-wf-site). Sin marca (una app, una API, una página de login), el Worker entrega la respuesta byte a byte y no hace nada más.
4. Reescribe las direcciones de los archivos mientras la página pasa. Cada dirección de imagen, hoja de estilos, script y fuente de Webflow se convierte en una dirección firmada en tu dominio. Esto ocurre mientras la página todavía está llegando, así que el navegador empieza a pintar enseguida. El Worker nunca se queda esperando a tener la página entera.
5. El navegador pide esos archivos a tu dominio.
6. El Worker comprueba la firma, convierte las imágenes y lo guarda todo. Las imágenes pasan por el conversor de imágenes de Cloudflare y, si la versión convertida fuera más grande que la original (pasa con fotos ya comprimidas), recibes la original.
7. Todos los que vengan después reciben la copia guardada. Desde la caché de Cloudflare, sin que el Worker llegue siquiera a ejecutarse y sin pedirle nada a Webflow.

Los enlaces firmados (y por qué nadie puede abusar de tu Worker)

Esta es la parte que hace que la versión 6 sea distinta de todo lo que habíamos hecho antes, así que ten un poco de paciencia conmigo.

Los servidores de archivos de Webflow son compartidos. Las imágenes de todos los clientes de Webflow viven en el mismo host cdn.prod.website-files.com, solo que en carpetas distintas. Así que un Worker que dice "yo traigo y optimizo cualquier cosa del servidor de archivos de Webflow" está ofreciendo, sin querer, traer y optimizar los archivos de Webflow de cualquiera, a través de tu dominio y con cargo a tu factura de Cloudflare. Nuestro Worker antiguo tenía exactamente ese agujero, y lo encontramos nosotros mismos en septiembre (ese mismo día lo limitamos a los IDs de nuestro propio sitio y luego nos pusimos a buscar una solución mejor).

La versión 6 lo hace como es debido. Cada dirección que el Worker escribe en tu página lleva una firma corta: 16 caracteres generados con HMAC-SHA256 y una clave secreta que solo conoce tu Worker (la SIGNING_KEY que configurarás durante la instalación). Cuando llega una petición de un archivo, el Worker vuelve a calcular la firma para esa dirección exacta. Si coincide, perfecto. Si no, porque alguien se inventó el enlace, cambió la ruta del archivo, lo apuntó a los archivos de otro sitio o simplemente tiene una errata, recibe un 403 y no se trae nada. Si no se trae nada, ni Webflow ni el conversor de imágenes tienen nada que cobrarte.

El efecto secundario bonito: no hay nada que configurar por sitio. Ni lista de IDs de sitios de Webflow, ni dominios permitidos. El Worker solo sirve lo que él mismo escribió, y punto.

Cómo funciona la caché

La caché es de donde salen la velocidad y el ahorro de ancho de banda, y también es donde la gente se pone nerviosa ("¿y si mis visitantes ven una versión antigua?"). Así que aquí va exactamente qué se guarda, dónde y durante cuánto tiempo.

Archivos: un año, y es seguro

Las imágenes, el CSS, el JS y las fuentes se guardan durante un año, en la caché de Cloudflare y en el navegador del visitante. La razón por la que es seguro es una costumbre de Webflow que juega muchísimo a nuestro favor: cada vez que un archivo cambia, Webflow le da una dirección nueva. Cambias una imagen y recibe un ID nuevo en el nombre del archivo. Publicas un cambio de estilos y tu archivo CSS recibe un hash nuevo. Tu página simplemente apunta al archivo nuevo, así que nadie puede recibir nunca una copia desfasada de un archivo que ha cambiado. Ni botón de purgar, ni webhook.

La caché que usamos es Workers Cache. Cloudflare responde a una petición repetida de un archivo sin que el código del Worker llegue a ejecutarse. Puedes verlo tú mismo: abre DevTools en nuestro sitio, haz clic en cualquier imagen u hoja de estilos y verás cf-cache-status: HIT y cache-control: public, max-age=31536000, immutable. El archivo CSS que acabo de revisar llevaba dos días en la caché.

Las imágenes tienen un truco más: una dirección, varias versiones. La misma URL de imagen se guarda una vez por cada tipo de navegador (AVIF para los que pueden abrirlo, WebP para el resto, la original para algún navegador viejo que quede por ahí), y cada navegador recibe la copia que pidió (eso es lo que hace la cabecera Vary: Accept). No tienes que gestionar nada de eso.

Páginas: frescas cada vez que publicas

Las páginas son otra historia, porque cambian sin cambiar de dirección. El propio Webflow les dice a los navegadores que guarden las páginas durante 16 días (max-age=1382400, échale un vistazo a las cabeceras de respuesta de tu propio sitio). Por eso un visitante que vuelve a veces ve tu home antigua después de publicar. El Worker lo sobrescribe con max-age=0, must-revalidate, así que los navegadores vuelven a comprobar en cada visita.

Y, por defecto, el Worker no guarda páginas en tu zona en absoluto. Webflow ya cachea tus páginas en su propia configuración de Cloudflare y vacía esa caché cuando publicas, así que dejar que haga lo suyo significa que lo publicado aparece al instante. Si quieres arañar un poco más, hay un ajuste (HTML_EDGE_TTL, más abajo) para guardar las páginas en tu zona unos minutos. Nosotros lo tenemos a 10 minutos, porque aprendimos por las malas que Webflow no vacía la caché de tu zona cuando publicas (vimos cómo una publicación se quedaba atascada detrás de una copia de hace 47 minutos). Diez minutos es un buen equilibrio para nosotros. Para la mayoría de los sitios, déjalo en 0.

Lo que nunca se cachea

• Errores de servidor de Webflow: nunca se guardan, así que una caída de Webflow nunca se "recuerda".
• Archivos que faltan (404): se guardan solo 60 segundos, para que un archivo que falta un momento no quede marcado como inexistente durante un año.
• Una conversión de imagen fallida: se sirve la imagen original y se guarda una hora, para que la versión optimizada vuelva a tomar el relevo cuando la conversión funcione.
• Cualquier cosa que no sea una página de Webflow o un archivo firmado: pasa tal cual con no-store.

¿De verdad ahorra ancho de banda de Webflow?

Sí. Webflow cuenta cada byte que su CDN entrega para tu sitio. Sin el Worker, cada visitante descarga cada archivo desde Webflow. Con el Worker, un archivo sale de Webflow más o menos una vez por ubicación de Cloudflare, la primera vez que alguien cerca de esa ubicación lo necesita, y a partir de ahí se sirve desde la caché de Cloudflare a todos los demás de la zona durante un año.

En nuestro primer día completo en producción, el 92% de las peticiones de CSS, JS y fuentes y el 79% de las peticiones de imágenes se respondieron directamente desde la caché, y eso mientras todas las ubicaciones de Cloudflare del mundo todavía se estaban llenando por primera vez. Debería subir en cuanto cada ubicación tenga su copia. Vamos a medir un día normal y actualizaremos esto cuando tengamos la cifra.

Eso sí, dos cosas que conviene saber. Tus páginas siguen viniendo de Webflow (eso es lo que mantiene la publicación instantánea), así que el ahorro está en los archivos, que de todos modos es donde está el peso. Y como el panel de uso de Webflow mide lo que envía su CDN, la cifra que verás bajar es la parte de archivos de tu ancho de banda, no la de páginas.

Imágenes a su tamaño justo (nuevo en 6.1)

Esta es sutil y es mi favorita, porque arregla algo que nadie nota pero que todo el mundo paga.

Webflow crea varios tamaños de cada imagen que subes y le dice al navegador a qué ancho se mostrará la imagen, usando el atributo sizes. Luego el navegador elige una copia. El problema es que Webflow calcula ese número a partir del canvas del Designer, no de cómo acaba realmente la imagen en la página, y muy a menudo dice 100vw ("esta imagen ocupa toda la pantalla"). Así que la imagen de tu blog, que en realidad está en una columna de 840 píxeles, se descarga en escritorio como la copia de 3.200 píxeles. El navegador se fio de Webflow. La mayoría de esos bytes nunca se ven.

Activa SIZES_AUTO y el Worker añade sizes="auto, …" a las imágenes con lazy loading. Las imágenes lazy solo se cargan cuando ya se conoce el layout, así que el navegador puede medir el espacio real y elegir la copia que de verdad encaja. Los navegadores que todavía no entienden auto simplemente lo ignoran y usan el valor de Webflow como antes, así que no se puede romper nada.

Medido en un navegador real en nuestro sitio: la home en escritorio pasó de 670 KB de imágenes lazy a 404 KB, en móvil de 376 KB a 255 KB, y un post del blog de 181 KB a 95 KB. Cero imágenes rotas o borrosas. Lo curioso es que funciona en los dos sentidos: en otro sitio que probamos, Webflow se había quedado corto con el tamaño de algunas imágenes, y ahora salen más nítidas (y un poco más pesadas). Eso es el navegador acertando, que es justo la idea. Viene desactivado por defecto, porque cambia qué archivo elige el navegador, pero nosotros lo tenemos activado.

Todo lo demás que hace

Lo más llamativo son las imágenes y la caché, pero hay un montón de cosas más pequeñas que hemos ido añadiendo después de tropezarnos con ellas en sitios reales.

• Los GIF animados siguen animados. Los GIF solo se convierten a WebP (que admite animación), nunca a AVIF (que, desde el conversor, no la admite).
• Nunca más grande que la original. Un JPEG de cámara grande y ya comprimido puede llegar a crecer al recodificarlo. En un sitio vimos una foto de 1,9 MB volver con 3,6 MB. Así que, cuando no está en caché, el Worker compara la imagen convertida con la original y envía la que sea más pequeña. Ese único cambio hizo que un sitio de prueba pasara de pesar un 17% más a pesar un 10% menos.
• Sin descargas dobles. Webflow les dice a los navegadores que empiecen a descargar tu CSS pronto, con una cabecera Link (que Cloudflare convierte en Early Hints). El Worker apunta esas descargas anticipadas a la misma dirección que usa la página, así que nada se descarga dos veces. Los preloads de fuentes se dejan como están a propósito, porque las fuentes se cargan desde dentro del CSS y reescribirlas provocaría justo la descarga doble que intentamos evitar.
• Vistas previas en redes que funcionan. og:image y twitter:image salen como JPEG comprimido (configurable), el único formato que todas las plataformas muestran sin fallar.
• El og:url que falta. Webflow nunca lo genera, aunque es una de las cuatro etiquetas básicas de Open Graph. El Worker lo añade usando la dirección canónica de la propia página, así que lo que se comparte de la misma página con códigos de seguimiento, o con y sin www, cuenta como una sola.
• Favicons, iconos de app, pósters de vídeo, imágenes de fondo inline y bloques <style> reciben el mismo trato.
• Nombres de archivo raros. A las exportaciones de Figma les encantan los espacios, los paréntesis y las comas, y Webflow a veces guarda un %20 literal como %2520. El Worker mantiene la ruta byte a byte, así que todos funcionan (en algún momento no funcionaban, por eso lo sabemos).
• La página 404 también se optimiza. La página de "página no encontrada" de Webflow es una página completa llena de archivos de Webflow, que se cobra como cualquier otra.
• Tu sitemap recibe la etiqueta correcta. Webflow sirve /sitemap.xml como tipo feed RSS; el Worker lo corrige a application/xml.
• Arreglos para lo estricto que es el navegador. Algunos hosts antiguos de Webflow envían scripts y hojas de estilos como un tipo de archivo genérico, que un navegador con nosniff se niega a ejecutar. El Worker envía el tipo correcto. Los SVG servidos desde tu dominio reciben una política de seguridad bien cerrada para que nada de lo que llevan dentro pueda ejecutarse.

Lo que deja en paz a propósito

• Cloudflare Turnstile (la comprobación de "¿eres humano?"), Google Tag Manager, Google Analytics, Google Fonts, Webflow Optimize y los scripts de apps del marketplace. Estos rotan o se personalizan por visitante, y cachearlos un año los rompería. Esta la conocemos de primera mano, y duele: una versión temprana hacía proxy de Turnstile y en julio rompió la comprobación de Turnstile de nuestro propio escáner.
• Los chunks de runtime de Webflow y los scripts de Finsweet Attributes, que tienen que cargarse desde su propio origen para encontrar sus archivos hermanos.
• El vídeo, que necesita peticiones por rangos.
• Tus enlaces, etiquetas canonical, preconnects y cualquier cosa que no sea un archivo de Webflow. CodePen, HubSpot y los embeds de YouTube cargan exactamente igual que siempre.

La red de seguridad

Este Worker está delante de un sitio en producción, el nuestro incluido, así que está hecho para fallar de forma aburrida. Aquí tienes cada seguro y lo que está ahí para evitar:

• Solo funciona en la ruta que le das. Apúntalo a www.yoursite.com/* y eso es todo lo que ve. (Nuestra caída de julio fue una ruta comodín que llegaba a los subdominios de nuestras apps. No uses *.yoursite.com/*.)
• Solo reescribe páginas reales de Webflow. Sin la marca data-wf-site, ni cambios ni caché. Así que, aunque la ruta llegara a una app por error, la app quedaría intacta.
• Solo sirve enlaces que él mismo firmó. Nada de relay abierto, nadie inflándote la factura.
• Solo trae archivos de los propios servidores de archivos de Webflow. Y solo /js/jquery… del host de jQuery de Webflow.
• Un ajuste mal puesto significa que se aparta. ¿Falta la SIGNING_KEY o es demasiado corta? Cada petición pasa sin tocar y el error queda registrado.
• Un error significa la página original. Si algo sale mal antes de que la página empiece a llegar, recibes la respuesta de Webflow, sin tocar. El peor caso es "tan rápido como Webflow a secas", nunca "el sitio está caído".
• No guarda archivos rotos. Una fuente que vuelve como una página de error HTML se rechaza en lugar de cachearse como fuente durante un año.

La configuración completa, de principio a fin

Bien, vamos con la configuración. Dos partes: poner tu dominio en Cloudflare con O2O (una vez por dominio) y luego instalar el Worker (una vez por sitio). Si ya estás en O2O, salta a la parte 2.

Lo que necesitas

• Un plan de sitio de pago de Webflow con dominio personalizado (O2O lo necesita).
• Un sitio en el hosting de Webflow sobre Cloudflare. Los sitios creados después del 21 de abril de 2025 ya lo están; los más antiguos tienen que haber hecho la migración de DNS de Webflow (revisa Workspace settings → Domain updates).
• Una cuenta de Cloudflare. Cualquier plan, el Free funciona. Nuestra segunda instalación funciona con el Free.
• Una cuenta de GitHub, para el botón de Deploy (o la línea de comandos, si lo prefieres).

Parte 1, paso 1: Añade tu dominio a Cloudflare

En el dashboard de Cloudflare, dale a Onboard a domain, introduce tu dominio raíz (yoursite.com) y sigue los pasos. Luego cambia los nameservers en tu registrador por los dos que te da Cloudflare. Esto puede tardar un rato en propagarse a todas partes (Webflow habla de hasta 48 horas, normalmente es mucho más rápido). whatsmydns.net con la opción NS te muestra cuándo está listo. Si el DNS se hace el remolón, tenemos un post sobre cómo acelerar la resolución DNS al publicar tu sitio de Webflow.

Parte 1, paso 2: Registros DNS con la nube naranja activada

Esta es la parte de O2O. En DNS → Records, crea registros CNAME con proxy:

• Tipo CNAME, nombre @, destino cdn.webflow.com, estado del proxy Proxied (nube naranja ACTIVADA)
• Tipo CNAME, nombre www, destino cdn.webflow.com, estado del proxy Proxied (nube naranja ACTIVADA)

Borra cualquier registro A antiguo que apunte a 198.202.211.1 (o a las IPs muy antiguas de Webflow, o a proxy-ssl.webflow.com). No puedes tener las dos cosas. Si usas otros subdominios en Webflow, añade un CNAME con proxy para cada uno. Y si tu dominio tiene registros CAA, asegúrate de que permiten Let's Encrypt y Google Trust Services, o tus certificados no se renovarán.

Parte 1, paso 3: SSL/TLS en Full (strict)

Ve a SSL/TLS en Cloudflare y pon el modo de cifrado en Full (strict). Con cualquier otro estarás persiguiendo errores 525.

Parte 1, paso 4: Conecta y publica en Webflow

Ya en Webflow, ve a Site settings → Publishing → Production, conecta tu dominio (raíz y www), elige tu dominio por defecto y publica.

Seguramente verás "Update needed" junto a tu dominio. Ignóralo. Con la nube naranja activada, la comprobación de Webflow no puede ver tus registros DNS a través del proxy, y el propio artículo de ayuda de Webflow dice que es lo esperado. Si el sitio carga, todo bien. A mí el aviso se me ha quedado ahí una eternidad en algunos sitios y ha desaparecido en otros.

Para comprobar que O2O funciona: el sitio carga, tus registros en Cloudflare muestran la nube naranja y, al cabo de unos minutos, Analytics de tu dominio en el dashboard de Cloudflare empieza a mostrar tráfico. (No te fíes de la cabecera cf-ray, ahora la tienen todos los sitios de Webflow, con O2O o sin él.) Bien, la plataforma ya está lista. Ahora viene lo divertido.

Parte 2, paso 5: Haz clic en Deploy to Cloudflare

Ve a nuestro repo, github.com/J8kesVanEeden/milkmoon-webflow-optimizer, y pulsa el botón naranja Deploy to Cloudflare del README. Esto es lo que pasa, porque la primera vez no es obvio:

• Cloudflare te pide que inicies sesión y conectes GitHub.
• Crea una copia de nuestro repositorio en tu propia cuenta de GitHub. Esa copia es tuya: ahí viven tus ajustes y es desde donde Cloudflare hace el build.
• Crea el Worker en tu cuenta de Cloudflare y lo conecta a tu copia, así que cada vez que hagas commit de un cambio, Cloudflare lo vuelve a desplegar automáticamente (eso es Workers Builds).

Parte 2, paso 6: Pega una SIGNING_KEY

Durante el deploy te pedirá la SIGNING_KEY. Es el secreto que usa tu Worker para firmar sus enlaces. Pega un valor aleatorio de al menos 32 caracteres. En Mac o Linux, openssl rand -base64 36 en la Terminal te da uno, o usa el generador de tu gestor de contraseñas. Guárdalo en un sitio seguro, aunque nunca tendrás que volver a escribirlo. Se guarda como secreto de Cloudflare, no en tu código, y el Worker no se despliega sin él.

Parte 2, paso 7: Ponlo en tu sitio

En este punto el Worker existe pero todavía no está en tu sitio (a propósito, para que nada pase por sorpresa). En tu copia del repo en GitHub, abre wrangler.jsonc, busca el bloque routes comentado (tres líneas que empiezan por //), quita el // de las tres y pon tu host de Webflow:

"routes": [{ "pattern": "www.yoursite.com/*", "zone_name": "yoursite.com" }],

Haz commit. Cloudflare lo detecta y vuelve a desplegar en más o menos un minuto. Usa solo el host que sirve tu sitio de Webflow. No *.yoursite.com/*, sobre todo si tienes apps en otros subdominios (créenos). Y pon la ruta aquí, en el archivo, y no en el dashboard, porque el archivo es lo que se despliega y sobrescribirá los cambios que hagas en el dashboard.

Parte 2, paso 8: La excepción de OWASP (plan Pro o superior)

Si tu zona está en Pro o superior y usas el OWASP Core Ruleset de Cloudflare en Managed Rules, añade una excepción; si no, algunos visitantes (y los renderizadores de Google) recibirán una página de desafío en lugar de tus imágenes. La regla 949110 de OWASP ve un nombre de host de Webflow dentro de la ruta del archivo y se pone suspicaz. Es seguro saltarse OWASP en estas rutas porque cada petición que llega a ellas ya la comprueba la firma del Worker. Esta nos mordió en nuestro propio sitio: alrededor del 11% de las peticiones de archivos recibían un desafío hasta que la añadimos.

1. Dashboard de Cloudflare → tu dominio → Security rules → Create → Managed rules.
2. Ponle un nombre del estilo Skip OWASP on Webflow Optimizer paths.
3. Edita la expresión y pega: starts_with(http.request.uri.path, "/_wf/") or starts_with(http.request.uri.path, "/_img/")
4. Después: Skip specific rules from a Managed Ruleset → selecciona el Cloudflare OWASP Core Ruleset → Select rules → selecciónalas todas → Next → Deploy.
5. Asegúrate de que la excepción queda por encima de la regla que despliega el ruleset de OWASP. Las excepciones solo se saltan las reglas que aparecen después de ellas.

En el plan Free no tienes el ruleset de OWASP, así que puedes saltarte este paso.

Parte 2, paso 9: Comprueba que funciona

Ejecuta esto en la Terminal (o mira las cabeceras de respuesta en DevTools):

curl -s -o /dev/null -D - https://www.yoursite.com/ | grep -i x-edge-worker

(Usa exactamente este comando. El curl -I, más corto, envía una petición HEAD, que el Worker deja en paz a propósito, así que nunca te enseña la cabecera.)

Deberías recibir x-edge-worker: webflow-o2o/6.1.0 (o la versión más reciente que haya). Después:

• Mira el código fuente de la página. Las direcciones de las imágenes deberían empezar por https://www.yoursite.com/_img/ y las de las hojas de estilos por https://www.yoursite.com/_wf/.
• Abre la pestaña Network en DevTools, filtra por Img y recarga. Las imágenes deberían venir de tu dominio, con content-type: image/avif o image/webp.
• Recarga otra vez y busca cf-cache-status: HIT en las cabeceras de una imagen.
• Comprueba que una página con un formulario o con Turnstile sigue funcionando, y revisa tus vistas previas en redes en opengraph.xyz o en el Sharing Debugger de Facebook.

La forma más fácil de comprobarlo a simple vista sigue siendo la extensión DrFlare para Chrome. Se quedó obsoleta, pero ha vuelto como DrFlare Reloaded, consíguela aquí. Ábrela desde DevTools, recarga la página y pasa el ratón por encima de las imágenes para ver el antes y el después. Acuérdate de recargar una vez que DrFlare esté abierta.

Y con eso queda instalado. Sin el interruptor "Enable Image Transformations", sin lista de orígenes permitidos, sin variable DOMAIN, sin webhook para purgar la caché. La guía antigua tenía todo eso, y ya no hace falta nada: el Worker convierte las imágenes él mismo, algo que Cloudflare permite en cualquier zona que ejecute un Worker.

¿Prefieres la línea de comandos?

Lo mismo, a mano: clona el repo, ejecuta npm ci, npx wrangler login, npx wrangler secret put SIGNING_KEY (pega tu clave), edita routes en wrangler.jsonc y luego npm run deploy. Necesitas tener Node instalado. El README tiene los comandos exactos.

Cada ajuste, explicado

Todo es opcional excepto la clave de firma. Los ajustes van en la sección vars de wrangler.jsonc en tu copia del repo (haz commit y se vuelve a desplegar). Un número o un formato no válido vuelve sin hacer ruido al valor por defecto, así que no puedes romper nada por teclear mal un ajuste de calidad. Las dos excepciones son la clave de firma y los ajustes legacy de más abajo: si los pones mal, el Worker se aparta (tu sitio sigue funcionando, solo que sin el Worker) hasta que los arregles.

• SIGNING_KEY (obligatoria, es un secreto, no una var). Al menos 32 caracteres aleatorios. Cambiarla más adelante le da a cada archivo una dirección nueva, lo que implica volver a llenar la caché una vez. No es un desastre, pero no lo hagas por diversión.
• IMAGE_QUALITY (por defecto 85, de 1 a 100). Calidad de las imágenes de las páginas. Con 85 se ven genial. Bájalo a 75 si de verdad quieres exprimir bytes; nosotros no bajaríamos mucho más para fotografía.
• OG_FORMAT (por defecto jpeg; también se admiten png y webp). Formato de las imágenes de vista previa en redes. Déjalo en JPEG, algunas plataformas todavía no muestran otra cosa.
• OG_QUALITY (por defecto 80). Calidad de las imágenes de vista previa en redes.
• EDGE_TTL y BROWSER_TTL (por defecto 31536000, un año, en segundos). Cuánto tiempo se quedan los archivos en la caché de Cloudflare y en los navegadores. Un año es seguro porque Webflow cambia el nombre de los archivos modificados. Nunca hemos tenido motivo para tocarlos.
• SIZES_AUTO (por defecto false). Ponlo en "true" para la función de imágenes a su tamaño justo de más arriba. Nosotros lo tenemos activado en nuestras dos instalaciones.
• HTML_EDGE_TTL (por defecto 0, hasta 86400). Segundos que se guardan las páginas en tu zona. Déjalo en 0 a menos que tu ruta no cubra nada más que tu sitio de Webflow, porque un valor positivo cachea cada respuesta de la ruta antes de que el Worker pueda comprobar que es una página de Webflow. Si lo configuras, una publicación puede tardar hasta ese tiempo en aparecer (nosotros usamos 600, diez minutos).
• LEGACY_ROUTES, WEBFLOW_SITE_IDS, LEGACY_DOMAIN. Solo para quienes usaban nuestro Worker antiguo. Mira la sección de actualización, más abajo. Las instalaciones nuevas no los necesitan.

Algunas cosas de wrangler.jsonc que no son ajustes pero que conviene conocer:

• "cache": { "enabled": true, … } activa Workers Cache, que es lo que permite que las peticiones repetidas se salten el Worker por completo. Déjalo activado.
• "secrets": { "required": ["SIGNING_KEY"] } es la razón por la que un deploy sin clave falla, en lugar de salir a producción a medio configurar.
• "observability" guarda logs del 10% de las peticiones, que es más que suficiente para detectar un problema y sale barato.
• "workers_dev": false, porque este Worker solo tiene sentido en tu propio dominio.

Lo que cuesta

El Worker es gratis y tiene licencia MIT. Lo que pagas, si es que pagas algo, es Cloudflare:

• Peticiones de Workers. Cuenta cada petición en tu ruta: las páginas y cada archivo de imagen, CSS, JS y fuente, incluidos los cacheados (un acierto de caché se salta el tiempo de procesamiento del Worker, no el recuento de peticiones). Workers Free cubre 100.000 peticiones al día. Workers Paid cuesta 5 USD al mes con 10 millones incluidas, y luego 0,30 USD por millón (precios de Cloudflare). Cuentas rápidas: una página con 40 archivos son unas 41 peticiones, así que el plan gratuito cubre más o menos 2.400 páginas vistas al día. Muchos sitios pequeños caben ahí; un sitio con mucho tráfico querrá el plan de 5 USD. Si te pasas de 100.000 en Workers Free, Cloudflare no te cobra: deja de ejecutar el Worker durante el resto del día. Configura tu ruta en modo fail open (tu Worker → Settings → Domains & Routes) para que los visitantes reciban Webflow a secas en lugar de una página de error.
• Conversiones de imágenes. Cloudflare incluye 5.000 transformaciones únicas gratis al mes. Una transformación única es una imagen con un ajuste en un formato, por mes, y las visualizaciones repetidas son gratis. Cloudflare dice que una misma imagen servida en distintos formatos cuenta una sola vez, pero nosotros pedimos cada formato por separado, así que, por si acaso, haz tus cuentas como si una imagen pudiera contar hasta tres veces (AVIF, WebP y la original). Pasadas las 5.000, las conversiones nuevas fallan y el Worker sirve sin hacer ruido la imagen original hasta que empiece el mes siguiente, a menos que estés en Images Paid, a 0,50 USD por cada 1.000 extra (precios). Para que te hagas una idea: nuestro sitio, con sus 600 y pico páginas, usó 732 en todo septiembre.

Compáralo con subir un nivel de ancho de banda en Webflow y no cuesta mucho convencerse.

¿Hace el sitio más rápido? Números reales

Somos prudentes con lo que decimos sobre velocidad, porque las puntuaciones de PageSpeed bailan entre 10 y 20 puntos entre ejecuciones idénticas, y mucho de lo que hace lento un sitio (scripts, animaciones, etiquetas de terceros) no tiene nada que ver con las imágenes. Así que lo probamos de forma justa: las mismas 8 páginas en nuestro sitio en producción (con el Worker) y en la copia de staging del propio Webflow (sin Worker), misma herramienta, mismos dispositivos, lado a lado.

• El Worker nunca empeoró una puntuación.
• Los avisos de "entrega de imágenes" y "peso de la página" de PageSpeed eran menores con el Worker en todas las páginas. Una página de proyecto pesaba 3.196 KB con él y 4.195 KB sin él.
• Las páginas llegan igual de rápido que antes: la mediana del tiempo hasta el primer byte fue de 95 ms con la versión 6 frente a 94 ms con la versión anterior (20 páginas, 5 ejecuciones cada una). La reescritura en streaming de verdad no añade espera.
• Imágenes de la home, medidas hoy con la 6.1.0: 38 archivos, 8.762 KB directos desde Webflow, 1.755 KB a través del Worker (un 80% menos), ninguno más grande que el original. AVIF para 20 de ellos, WebP para 17 y un PNG que ya era todo lo pequeño que podía ser.
• Primeras 24 horas de la versión 6 en producción: cero errores del Worker y, una vez puesta la excepción de OWASP del paso 8, el 0,3% de las peticiones de archivos rechazadas (casi todas de bots pidiendo direcciones que el Worker nunca escribió, rechazadas a propósito). Una revisión completa de cada página y cada archivo del sitio salió bien (628 páginas, 1.255 archivos).

Y para ser honestos con nosotros mismos: las grandes mejoras vienen de subidas grandes y sin optimizar, como capturas en PNG. Si tus imágenes ya son WebP pequeños, algunas no cambiarán nada, porque Cloudflare se queda con la original cuando ya es la más pequeña. Eso es el sistema funcionando, no fallando.

Bajo el capó (para curiosos)

Esta parte es para los desarrolladores, y para cuando algo sale mal y quieres saber dónde mirar. Aquí tienes cada decisión que toma el Worker con una petición.

Algunos detalles que vale la pena saber:

• La página se reescribe con HTMLRewriter de Cloudflare, que analiza atributos HTML reales mientras la página va llegando (la versión de enero hacía ocho pasadas de regex sobre una página cargada entera en memoria, y por eso durante meses se le escaparon las imágenes sociales y los favicons: Webflow escribe content= antes de property=, y la regex solo miraba en un sentido).
• Las direcciones firmadas tienen la forma /_img/img/<signature>/<webflow host>/<path> para las imágenes y /_wf/<signature>/<webflow host>/<path> para todo lo demás. Solo hay dos presets de imagen, img y og. Un visitante nunca puede pedir otro tamaño u otra calidad, que es lo que impide que alguien se ponga a generar conversiones a costa de tu cuenta.
• La conversión de imágenes ocurre dentro del Worker con un fetch cf.image, que elige AVIF o WebP según la cabecera Accept del navegador.
• El código es JavaScript plano en diez archivos pequeños (el README tiene un mapa), con 146 tests automáticos que se ejecutan en el mismo runtime que usa Cloudflare, incluidas cinco páginas reales de cuatro sitios de Webflow distintos (y, encima, una segunda instalación completa). Está todo en GitHub, cotillea todo lo que quieras.

Opcional: puede vigilarse a sí mismo

Webflow puede cambiar su markup o sus hosts de archivos en cualquier publicación, por su lado y sin avisar. Las redes de seguridad del Worker evitan que rompa tu sitio, pero no te avisan si un cambio deja tus imágenes sin optimizar sin que nadie se entere. Por eso tu copia del repo incluye un monitor opcional que funciona con GitHub Actions: cada hora comprueba que tus páginas cargan y que tus archivos pasan por el Worker, cada día revisa todas las páginas de tu sitemap y todos los archivos que contienen, y si algo no cuadra abre un issue en GitHub (GitHub te manda un email), y lo vuelve a cerrar cuando todo está bien. (GitHub ejecuta las tareas programadas cuando buenamente puede, así que lo de "cada hora" puede ser algo flexible en un día con mucho lío.) No hace nada hasta que lo configuras; el README explica la configuración, que lleva dos minutos. Nunca cambia tu sitio.

Actualizar desde el Worker antiguo

Si seguiste la versión de enero de este post, el cambio es así:

1. Instala la versión 6 como se explica arriba (es un Worker nuevo, desde el botón de Deploy).
2. Mantén funcionando tus enlaces antiguos. Google Imágenes, publicaciones antiguas en redes y páginas cacheadas seguirán pidiendo durante un tiempo las direcciones antiguas /img-original/, /img-cache/, /asset-cache/ y /cdn-cgi/image/. Pon LEGACY_ROUTES en "true", WEBFLOW_SITE_IDS con los IDs de tu sitio y de tu CMS de Webflow (separados por comas, los IDs de 24 caracteres que aparecen en las direcciones de tus archivos de Webflow) y LEGACY_DOMAIN con el host exacto en el que funciona tu sitio, como www.yoursite.com (no el dominio a secas si estás en www). Configura los tres a la vez: si LEGACY_ROUTES está activado y faltan los IDs o el dominio, el Worker se aparta por completo hasta que lo arregles, y la cabecera x-edge-worker desaparece. Con los tres configurados, el Worker nuevo también responde a las direcciones con el formato antiguo, limitado a tus propios archivos.
3. Mueve la ruta. Quita la ruta del Worker antiguo y añádela al nuevo. Después ya puedes borrar el Worker antiguo.
4. De momento, deja Image Transformations activado. Los enlaces antiguos /cdn-cgi/image/ los sirve Cloudflare directamente, no el Worker, así que mantén las transformaciones (y tus orígenes permitidos) activadas mientras siga llegando algo de tráfico antiguo, y blinda ese endpoint con una regla WAF para que nadie más pueda usarlo. Cuando tus logs muestren que los enlaces antiguos ya no reciben visitas, puedes desactivarlo todo.

Actualizar la versión 6 más adelante es sencillo: trae nuestra última versión a tu copia del repo (añade nuestro repo como remote y haz merge) y haz commit, y Cloudflare vuelve a desplegar. Tus ajustes y tu secreto se quedan como están. No uses el botón de Deploy para actualizar, porque crea una copia nueva y un Worker nuevo en lugar de actualizar el tuyo. La cabecera x-edge-worker te dice qué versión estás usando.

Solución de problemas

No ha cambiado nada, las direcciones de las imágenes siguen apuntando a Webflow

• Comprueba que la ruta está descomentada en wrangler.jsonc y que coincide exactamente con tu host (www.yoursite.com/*, no el dominio raíz si tu sitio vive en www).
• Comprueba que el deploy se ejecutó de verdad: dashboard de Cloudflare → tu Worker → Deployments (o la pestaña Builds).
• Comprueba la cabecera x-edge-worker. Si no aparece, el Worker no está en esa ruta o falta la SIGNING_KEY (en ese caso deja pasar todo sin tocar y registra el motivo).
• Haz una recarga forzada (Cmd/Ctrl + Shift + R). Puede que tu navegador todavía tenga una copia de la página de antes.

Algunas imágenes muestran un desafío o un 403

• Una página de desafío, o imágenes que solo fallan para algunos visitantes: es el ruleset de OWASP. Añade la excepción del paso 8 y asegúrate de que queda por encima de la regla de OWASP.
• Un 403 a secas con "Bad or missing signature": el enlace no lo escribió tu Worker. Normalmente es una copia antigua de una página de antes de que cambiaras tu SIGNING_KEY, o alguien (o un bot) editando un enlace. Recarga la página para obtener enlaces nuevos.

Las imágenes no son AVIF ni WebP

• Comprueba que la dirección contiene /_img/. Los SVG y las imágenes que subiste como AVIF se sirven tal cual, a propósito (Cloudflare no puede convertir AVIF y los SVG no lo necesitan). Sube JPG o PNG a Webflow y deja que el Worker haga la conversión; Webflow ni siquiera crea tamaños responsive para las imágenes subidas en AVIF.
• Si has gastado tus 5.000 conversiones gratuitas del mes, las imágenes nuevas llegan como originales hasta que empiece el mes siguiente. El dashboard de Cloudflare (Images → Transformations) muestra tu recuento.

Lo que publico no aparece

• Con el HTML_EDGE_TTL por defecto de 0 debería ser instantáneo. Si lo has subido, espera ese tiempo o purga la página en Cloudflare (Caching → Configuration → Custom Purge).
• Prueba en una ventana privada para descartar tu propio navegador.

Las vistas previas en redes se ven mal

• Pasa la página por el Sharing Debugger de Facebook o por opengraph.xyz. El og:image debería ser una dirección /_img/og/ en tu dominio y volver como JPEG. Las plataformas cachean las vistas previas durante un tiempo, así que usa el "scrape again" del debugger.
• Las imágenes sociales que subiste como AVIF se quedan a propósito en la dirección de Webflow, porque los scrapers de las redes sociales llevan fatal el AVIF. Sube un JPG para tu imagen de Open Graph.

Webflow dice "Update needed" en mi dominio

Es lo esperado con O2O. Webflow no puede ver tu DNS a través de la nube naranja. Si el sitio carga, ignóralo.

Error 525 Handshake

Eso es el SSL, no el Worker. Pon SSL/TLS en Full (strict). Si tu zona usa Zone Hold, la documentación de Webflow dice que lo liberes mientras se emite el certificado.

Límites (nada es perfecto)

• Solo ve lo que está en el HTML de la página. Las imágenes que se añaden después con JavaScript, y las imágenes de fondo referenciadas desde dentro de la hoja de estilos de Webflow, siguen cargándose desde Webflow. Lo mismo pasa con los archivos de animación Lottie y las fuentes referenciadas dentro del CSS.
• Las páginas siguen viniendo de Webflow en cada visita (por defecto), que es lo que mantiene la publicación instantánea. El ahorro está en los archivos.
• Cache Reserve no aplica. La documentación de Cloudflare dice que Cache Reserve se omite con O2O, así que los archivos viven en la caché normal del edge, que puede descartar antes de tiempo los archivos que se usan poco. Simplemente se vuelven a traer.
• No hace más rápido tu JavaScript. Si tu sitio va lento por interacciones pesadas o scripts de terceros, eso es cosa del sitio, no de las imágenes.
• No puede reducir una imagen que ya es todo lo pequeña que puede ser.

Volver atrás

Si algo sale terriblemente mal (no debería, pero ya sabes): en el dashboard de Cloudflare abre tu Worker, ve a Settings → Domains & Routes y borra la ruta. Eso funciona al momento. Después vuelve a comentar la línea routes en wrangler.jsonc y haz commit, para que el siguiente build no la vuelva a poner. Tu sitio vuelve al instante a cargarlo todo desde Webflow, y O2O y todas tus demás funciones de Cloudflare se quedan exactamente como estaban. Los archivos cacheados simplemente dejan de usarse. Para quitarlo del todo, borra también el Worker.

Una breve historia de peleas con la plataforma

Para los nostálgicos, y para que veas por qué la versión 6 es como es:

• 2022: la app Cassette y el truco del SSL. Funcionó hasta que dejó de funcionar.
• 2023: nuestro primer Worker de imágenes, solo para imágenes.
• Enero de 2026: O2O llega como es debido, y con él la primera versión de esta guía, con CSS, JS y fuentes. Abajo tienes el vídeo de aquella época, con el trabajo todavía en curso.
• Julio de 2026: lo reconstruimos para que hiciera streaming de las páginas en lugar de cargarlas enteras en memoria, lo que además arregló las imágenes sociales y los favicons, que en silencio nunca habían funcionado. También fue el mes en que nuestra propia ruta comodín rompió la comprobación de Turnstile de nuestro escáner. Lección aprendida, ruta blindada.
• Septiembre de 2026: encontramos y cerramos el agujero del servidor de archivos compartido. Luego lo reconstruimos todo como versión 6, genérica para cualquier sitio de Webflow, con enlaces firmados, y la subimos a GitHub.
• Octubre de 2026: versión 6.1 con imágenes a su tamaño justo, un segundo sitio instalado directamente desde la plantilla pública y monitorización automática.

¿No te apetece hacerlo tú?

Normal. Los cambios de DNS en un sitio en producción ponen nervioso a cualquiera, y no todo el mundo quiere una cuenta de GitHub. El rendimiento de Webflow es un poco lo nuestro (somos un pequeño estudio de Webflow que pasa una cantidad francamente poco sana de tiempo en dashboards de Cloudflare), así que mándanos un mensaje y te lo configuramos todo: O2O, el Worker, la excepción de OWASP, las comprobaciones. Y si necesitas convencer a un cliente (o a tu jefe) de por qué todo esto importa, nuestro post sobre cómo la velocidad de carga impulsa el éxito de un negocio lo explica muy bien.

Preguntas frecuentes

¿El Milk Moon Webflow Optimizer es gratis?

Sí. Es open source, con licencia MIT, y está en GitHub. Solo pagas a Cloudflare si decides pasarte a un plan de pago. Si superas los límites gratuitos (100.000 peticiones de Worker al día, 5.000 conversiones de imagen únicas al mes), no se cobra nada: las imágenes salen sin convertir hasta que empiece el mes siguiente y el Worker deja de ejecutarse hasta el día siguiente (configura tu ruta en modo fail open para que los visitantes reciban Webflow a secas).

¿Está permitido usar un Worker de Cloudflare con Webflow?

Sí, en tu dominio personalizado. Webflow dice que O2O es "la forma admitida de usar funciones de Cloudflare delante de Webflow", y Cloudflare indica que Workers es compatible con O2O. Lo que los términos de Webflow prohíben es hacer proxy de tu dominio de staging *.webflow.io, algo que esto nunca hace. El soporte de Webflow no va a solucionar los problemas del Worker por ti, por eso desactivarlo es una sola línea.

¿Webflow usa Cloudflare?

Sí. Webflow movió su hosting a Cloudflare en 2025. Los sitios creados después del 21 de abril de 2025 ya están ahí, y los más antiguos se pasaron a los nuevos registros DNS (cdn.webflow.com). Ese cambio es justo lo que hace posible O2O, y este Worker.

¿Reduce mi ancho de banda de Webflow?

Sí, en los archivos. Webflow cuenta cada byte que entrega su CDN. Con el Worker, cada imagen, hoja de estilos, script y fuente sale de Webflow más o menos una vez por ubicación de Cloudflare y luego se sirve desde la caché de Cloudflare durante hasta un año. Las páginas siguen viniendo de Webflow.

¿Qué es cdn.prod.website-files.com?

Es el servidor de archivos de Webflow, donde de verdad viven 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 hay ahí, ni siquiera con O2O. El Worker reescribe esas direcciones para que los archivos se optimicen y se cacheen a través de tu propio dominio.

¿Todavía tengo que activar Image Transformations en Cloudflare?

Con la versión 6, no. El Worker convierte las imágenes él mismo, algo que Cloudflare permite en cualquier zona que ejecute un Worker. Solo necesitas las transformaciones activadas si todavía sirves enlaces antiguos /cdn-cgi/image/ de la versión anterior.

¿Cómo vacío la caché después de publicar en Webflow?

No hace falta. El Worker no cachea las páginas por defecto, así que lo que publicas aparece al momento, y los archivos que cambian reciben direcciones nuevas de Webflow automáticamente. Si has puesto HTML_EDGE_TTL por encima de 0, espera ese tiempo o purga la página en Caching → Configuration, en Cloudflare.

¿Romperá mis formularios, Turnstile o la analítica?

No debería. Turnstile, Tag Manager, Google Analytics, Google Fonts, Webflow Optimize y los scripts de apps del marketplace nunca se tocan, y las páginas sin la marca de Webflow pasan sin tocar. Aun así, prueba un formulario después de instalarlo, se tarda un minuto.

Y ya está

Eso es todo, en resumidas cuentas. Un botón, un secreto, una línea, y tu sitio de Webflow sirve imágenes más pequeñas desde tu propio dominio, desde la caché de Cloudflare, con Webflow enviando una fracción de lo que enviaba antes. Si lo instalas, me encantaría de verdad saber cómo te va (y cuánto te ha ahorrado). Escríbenos, y echa un vistazo a la sección How-To de nuestro blog para más tutoriales.