Despliegue Cloudflare edge

Tres motivos. Rendimiento, porque el front se renderiza desde el más cercano de más de 300 ubicaciones edge. Coste, porque el runtime se factura por petición en lugar de por servidor. Resiliencia, porque el edge absorbe picos de tráfico que tumbarían un VPS individual. El backend de WordPress puede seguir corriendo en un host PHP gestionado; el edge es la superficie pública.

Sí, con la arquitectura adecuada. Catálogo y detalle de producto se renderizan desde el edge con caché; carrito y checkout se ejecutan como SSR o como rutas Worker separadas que leen en directo de WooCommerce. Separamos las rutas de forma deliberada para que las páginas comerciales sigan siendo rápidas y las páginas transaccionales sigan siendo correctas.

Por petición, no por servidor. El plan Workers Paid cubre la mayoría de los sitios en producción por debajo de decenas de millones de peticiones mensuales con un coste mensual predecible. El ancho de banda no se mide para respuestas en caché. La superficie de coste relevante son peticiones, milisegundos de CPU por Worker y almacenamiento en R2 o KV. Lo dimensionamos en la fase de arquitectura, no después.

Cloudflare ofrece enrutamiento de datos solo en la UE en planes Enterprise, y el origin de WordPress permanece donde lo coloques (normalmente un host PHP en la UE). A efectos de RGPD tratamos a Cloudflare como encargado del tratamiento, el origin en la UE como ubicación de los datos del responsable y documentamos el flujo de peticiones en el registro de actividades de tratamiento. Los controles de NIS2 y DORA se superponen a esa decisión.

Sí. La salida de build de Astro y Next.js es compatible con Cloudflare Pages con cambios menores de adapter. Las edge functions y middleware se portan en la mayoría de los casos desde Vercel Edge Runtime a Workers. Definimos el alcance de la migración tras una auditoría de una hora; tarificación individual.