Bases técnicas

Publicar una web en Cloudflare

Los archivos estáticos y las peticiones dinámicas tienen límites diferentes. Mantenga separadas páginas y operaciones del formulario. Publicar en Cloudflare no describe una única arquitectura. Un artículo se entrega como HTML mientras un Worker valida y guarda consultas. El plan gratuito no garantiza procesamiento dinámico ilimitado.

Publicar una web en Cloudflare

Separe el contenido público de las operaciones del servidor

Publicar en Cloudflare no describe una única arquitectura. Una web de presentación puede servir HTML, estilos, imágenes y JavaScript como archivos estáticos. Las solicitudes de un formulario o un área privada pueden necesitar un Worker. Esa separación ayuda a entender que no todas las visitas provocan el mismo trabajo dinámico.

En Orvunweb, el contenido público se genera previamente. El formulario, la administración y la selección del idioma en la dirección raíz son operaciones específicas. D1 se utiliza para solicitudes, no para recuperar cada artículo del blog durante cada lectura. Es una decisión que mantiene el contenido y la operación de datos en funciones distintas.

Servir archivos directamente evita ejecutar código innecesario para cada imagen. Sin embargo, los caminos privados no deben saltarse la autenticación. La prioridad estática es compatible con controles estrictos sobre API y administración. Configuración de Static Assets.

Lea el plan gratuito junto a sus límites

Un plan gratuito puede ser adecuado para determinadas webs, pero no equivale a capacidad infinita ni disponibilidad incondicional. Existen límites relacionados con peticiones dinámicas, CPU, archivos y tamaño. Las condiciones deben verificarse en la documentación oficial cuando se publica.

Una petición tampoco representa necesariamente una persona. Un visitante puede originar varias y los robots también generan tráfico. El tiempo de CPU se diferencia de la espera de red. Evaluar el servicio exige conocer qué componentes utiliza el proyecto, no contar únicamente páginas. Límites de Workers.

D1 mide lecturas y escrituras de filas y aplica límites de almacenamiento. Una consulta sin índices puede leer más datos de los que finalmente muestra. Para una gestión pequeña de solicitudes, filtros limitados, paginación e índices evitan trabajo innecesario. Otros proyectos de la cuenta pueden compartir cuotas relevantes. Precios de D1.

Complete cuentas, protección y comprobación

Código preparado y sitio publicado son estados distintos. Hacen falta permisos, dominio, DNS y secretos correctos. Si esos datos no están disponibles, no debe afirmarse que existe una publicación verificada. El entorno de prueba debe separarse de los datos reales.

Compruebe el formulario aparte de la portada: validación, verificación de seguridad, registro persistente y acceso autorizado del responsable. Una página que responde correctamente no demuestra que las solicitudes se guarden. Ante un fallo del servicio de seguridad o de la base de datos, no se debe mostrar un éxito ficticio.

La entrega necesita titular de cuenta, comandos de publicación, nombres de secretos y procedimiento de diagnóstico. Los valores secretos no pertenecen a archivos públicos. Una incidencia de cuota debe hacerse visible sin activar automáticamente productos de pago. Una instalación bien preparada se reconoce por esas responsabilidades resueltas, no solo por el proveedor elegido. Revise el consumo real antes de decidir cualquier ampliación del servicio.

Lista práctica

  • Revisar plan vigente
  • Separar entornos
  • Vigilar errores

Un ejemplo concreto: Un artículo se entrega como HTML mientras un Worker valida y guarda consultas.

Un límite importante: El plan gratuito no garantiza procesamiento dinámico ilimitado.

Siguiente paso

Cuéntele su proyecto a Orvunweb

Lecturas relacionadas

Fuente