Implementação Cloudflare edge

Três razões. Desempenho, porque o front renderiza a partir do mais próximo de mais de 300 localizações edge. Custo, porque o runtime é faturado por pedido em vez de por servidor. Resiliência, porque o edge absorve picos de tráfego que derrubariam um único VPS. O backend do WordPress pode continuar num host PHP gerido; o edge é a superfície pública.

Sim, com a arquitetura certa. Catálogo e detalhe de produto renderizam a partir do edge com cache; carrinho e checkout correm como SSR ou como rotas Worker separadas que leem em direto do WooCommerce. Separamos as rotas deliberadamente para que as páginas comerciais se mantenham rápidas e as páginas transacionais se mantenham corretas.

Por pedido, não por servidor. O plano Workers Paid cobre a maioria dos sites em produção até dezenas de milhões de pedidos mensais com um custo mensal previsível. A largura de banda é ilimitada para respostas em cache. A superfície de custo relevante são pedidos, milissegundos de CPU por Worker e armazenamento em R2 ou KV. Dimensionamos isso na fase de arquitetura, não depois.

A Cloudflare oferece encaminhamento de dados apenas na UE em planos Enterprise, e o origin do WordPress mantém-se onde o colocar (normalmente um host PHP na UE). Para efeitos de RGPD tratamos a Cloudflare como subcontratante, o origin na UE como localização dos dados do responsável pelo tratamento, e documentamos o fluxo de pedidos no registo das atividades de tratamento. Os controlos de NIS2 e DORA acumulam-se sobre essa decisão.

Sim. O output de build de Astro e Next.js é compatível com Cloudflare Pages com pequenas alterações de adapter. As edge functions e middleware portam, na maioria dos casos, do Vercel Edge Runtime para Workers. Definimos o âmbito da migração após uma auditoria de uma hora; tarifação individual.