TIC's en la Web

Cloudflare y los diccionarios compartidos: el CDN no sustituye a tu build

Cloudflare ha abierto en beta el modo passthrough de diccionarios compartidos, basados en el RFC 9842, y lo ha puesto disponible en todos los planes. Si solo lees el titular parece que alguien acaba de regalarte otro truco de rendimiento al borde de la red. Yo ya he vivido este guion con HTTP/3, con brotli y con las reglas de caché “inteligentes”: en el panel huele a victoria, en el día a día el cuello de botella sigue estando a veces en el sitio menos glamuroso, el origen y cómo empaquetas el frontend.

Según el changelog, en modo passthrough Cloudflare reenvía sin tocar ciertas cabeceras entre cliente y origen, acepta codificaciones como diccionario-compresión con Brotli y Zstandard de punta a punta sin re-comprimir y extiende la clave de caché para variar correctamente con lo que el navegador declara. Es decir: hace de auténtico transportista fino, no de alquimista que te arregla assets mal construidos. Eso cuadra con cómo Cloudflare suele crecer, añadiendo capacidades que premian a quien controla el stack completo y dejando a los demás con un interruptor bonito.

En pruebas internas que ellos mismos publicitan, un bundle de JavaScript de 272 KB pasó de ~92 KB con Gzip a ~2,6 KB con Zstandard en modo delta frente a la versión previa. Cifra espectacular, pero ojo con el asterisco invisible: necesitas un origen que entienda el ciclo de vida del diccionario, emita cabeceras como Use-As-Dictionary, negocie peticiones con Available-Dictionary y sea capaz de producir respuestas delta cuando toca. Si tu WordPress con diez plugins y un tema comprimido “como viene” representa el 70 % de tu negocio, esto no es un slider en el hosting compartido; es ingeniería de despliegue.

Además el soporte de navegador no es el universo completo: en el momento de redactar esto, los ejemplos que dan apuntan a Chrome 130+ y Edge 130+ anunciando dcb o dcz en Accept-Encoding. No es raro, es el patrón habitual: primero llega lo nuevo a un subconjunto de clientes, luego te preguntas por qué tu analítica muestra mezclas de comportamiento. Para una tienda online con tráfico mayoritariamente móvil y navegadores heterogéneos, el salto no lo vas a notar como en una demo de laboratorio.

¿Dónde dejo entonces el debate de comparativa? En que un CDN de pago o “gratis con extras” te puede ahorrar mucho dinero en ancho de banda y en latencia, pero cada capa nueva que depende de cabeceras raras y de builds reproducibles te acerca más al terreno del equipo de plataforma que al del autónomo que solo quería “ir rápido”. Cloudflare te facilita el transporte: activar passthrough puede ser una llamada a la API o un clic en el panel. Eso no reemplaza pipelines CI, versionado de assets, hashes en nombres de fichero ni una estrategia coherente de invalidación. Piensalo antes de prometerle a un cliente “compresión mágica” solo por estar delante del proxy.

También hay un matiz de producto que me gusta mencionar sin dramatizar: cuando una mejora está en beta abierta “para todos los planes”, el riesgo operativo lo absorbes tú. No es malo, es el contrato implícito. Si algo se comporta distinto en el borde respecto a tu origen, la primera ronda de debugging te toca a ti, no a un comercial que te vendió “optimización instantánea”. He visto proyectos donde el proveedor de CDN competidor cobraba menos al principio pero exigía menos contexto en origen; aquí la comparación real no es la cuota mensual sino el coste oculto de mantener cabeceras y artefactos sincronizados con cada release.

En resumen: los diccionarios compartidos son una pieza seria dentro de la torre de compresión moderna, y que Cloudflare los trate en passthrough es buena noticia si ya estabas dispuesto a asumir la parte fuerte del trabajo en el servidor de aplicaciones o en el build estático. Si no, corres el riesgo de convertirlo en otro interruptor encendido que en producción apenas se traduce en milisegundos.

Si mañana tu stack de despliegue te exigiera auditar cabeceras y generar deltas en cada release para exprimir RFC 9842, pero tu métrica única fuese el LCP en móvil real de usuarios con navegadores mezclados, ¿renunciarías a esta optimización y volverías a lo básico que ya controlas o te lanzarías igual por no quedarte fuera del changelog?

Fuentes

Salir de la versión móvil