Caso práctico de Adaptive Recognition
Un canal de publicación de WordPress a AWS basado en el renderizado
Cómo un gran sitio corporativo de WordPress creado con Elementor se convirtió en un proceso repetible de publicación estática sin sustituir la experiencia editorial.
Volumen de la exportación anterior
Más de 20.000 recursos
Artefacto basado en el renderizado
Aproximadamente 6.000 recursos
Entrega pública
S3 + CloudFront
De exportaciones frágiles a un flujo de publicación en producción
Reto
Los exportadores estáticos no podían modelar de forma fiable el sitio renderizado
Adaptive Recognition opera un gran sitio corporativo de WordPress creado con Elementor y con un comportamiento frontend que carga determinados recursos únicamente después de renderizar o desplazar la página. Los intentos anteriores con herramientas convencionales de exportación estática fallaban, requerían numerosas reglas de inclusión manuales o producían más de 20.000 archivos al recopilar muchos más recursos de los que realmente necesitaba la experiencia pública. Esta diferencia representa la decisión práctica analizada en Static Publisher frente a Simply Static: un canal de publicación renderizado en el navegador frente a una ruta de exportación estática más sencilla.
Intervención
Separar la configuración de WordPress de la ejecución en el navegador
WP Suite Static Publisher mantiene la configuración de publicación y los controles de tareas cerca de WordPress, mientras que un exportador Node.js independiente realiza el trabajo intensivo. Playwright abre el frontend real, observa la página renderizada, sigue el ámbito de rastreo, captura los recursos solicitados, reescribe las URL de origen para producción, construye el artefacto desplegable, lo sincroniza con Amazon S3 y actualiza Amazon CloudFront.
Resultado
Un artefacto de producción más pequeño y repetible
El flujo basado en el renderizado redujo la exportación de más de 20.000 a unos 6.000 recursos –aproximadamente un 70 %– y conservó el frontend renderizado por WordPress. Los editores siguen trabajando en WordPress, pero las solicitudes de páginas públicas se sirven desde S3 y CloudFront en lugar de depender del entorno activo de PHP y de la base de datos. En términos operativos, es el patrón descrito en Conservar WordPress para editar sin exponerlo públicamente.
El avance no fue otro analizador de archivos, sino permitir que un navegador real mostrase al sistema de publicación qué páginas y recursos utiliza realmente el sitio.
Arquitectura
WordPress sigue siendo la fuente; el worker de publicación construye el entorno de ejecución
El flujo mantiene el trabajo editorial, la orquestación de la publicación, el renderizado en el navegador y la entrega pública como responsabilidades operativas separadas. El patrón más amplio de separación se documenta en WordPress estático con entorno de ejecución dinámico en AWS; este caso práctico muestra en producción el lado de publicación de ese límite.
Editores y equipos de contenido
│
▼
WordPress + Elementor
contenido, medios, SEO y controles de publicación
│ poner en cola la tarea y el perfil de despliegue
▼
Plugin WP Suite Static Publisher
│ configuración y estado compartido de las tareas
▼
Ejecutor externo Node.js + Playwright
├─ rastrear páginas renderizadas
├─ observar recursos de red y del DOM
├─ capturar recursos adaptativos y de carga diferida
├─ reescribir URL de origen para producción
└─ ensamblar el artefacto estático
│
▼
Amazon S3
HTML estático, medios, CSS, JavaScript y fuentes
│
▼
Amazon CloudFront
entrega pública e invalidación posterior al despliegue
Límite operativo El ejecutor externo gestiona la automatización del navegador y el despliegue fuera del ciclo de vida de las solicitudes de WordPress. WordPress almacena la configuración y pone las tareas en cola; AWS sirve el sitio público resultante.
Flujo de publicación
Una cola controlada desde el editor hasta la red perimetral
La ruta de producción se diseña como una secuencia de tareas observables, no como una única solicitud larga de WordPress.
- Poner la publicación en cola desde WordPress — El plugin ofrece la superficie de control de WordPress para el ámbito de rastreo, las URL de destino, los ajustes de despliegue en AWS y la creación de tareas. Los editores no necesitan abandonar el flujo habitual del CMS para solicitar una nueva publicación.
- Ejecutar una sola tarea de exportación aislada cada vez — Un worker de cola iniciado por cron ejecuta el sistema de publicación externo y utiliza un bloqueo de proceso con un límite de concurrencia de una tarea. Así evita rastreos de Playwright solapados y despliegues en competencia, mientras mantiene la ejecución independiente de las sesiones del navegador y de los tiempos de espera de PHP.
- Renderizar, detectar y reescribir — Playwright visita el frontend real y registra lo que necesita el navegador, incluidos los recursos generados por el constructor, las variantes de imágenes adaptativas, las alternativas de picture y los elementos revelados por el comportamiento del frontend. Después, el sistema de publicación reescribe las URL de desarrollo o de origen para el dominio público y crea un artefacto específico.
- Desplegar en S3 y actualizar CloudFront — El artefacto terminado se sincroniza con el destino S3 de producción. La invalidación de CloudFront actualiza el contenido perimetral afectado, mientras que los registros de tareas ofrecen un rastro útil para investigar errores de rastreo, recursos y despliegue.
Detalles
Preguntas sobre el flujo de Adaptive Recognition
¿adaptiverecognition.com es un sitio WordPress headless?
No. WordPress y Elementor siguen renderizando el frontend que se convierte en el sitio público. Static Publisher captura esa experiencia renderizada y la despliega como archivos; no reconstruye la presentación en un framework JavaScript independiente.
¿Por qué se ejecuta el exportador fuera de WordPress?
El rastreo con navegador, la captura de recursos, la reescritura de URL y el despliegue son tareas operativas prolongadas. Trasladarlas a un worker Node.js específico evita vincular la compilación de producción a una solicitud PHP, a la sesión de navegador de un administrador o a los límites de ejecución de WordPress.
¿Por qué era importante la detección basada en el renderizado?
El sitio utiliza un comportamiento frontend que no aparece en un simple análisis del HTML y de las hojas de estilo descargadas. Un navegador real puede observar imágenes adaptativas, recursos de carga diferida, scripts del constructor y elementos solicitados únicamente después de inicializar la página.
¿Cómo evita el flujo los despliegues solapados?
El worker programado utiliza un bloqueo de proceso y está configurado para ejecutar una sola tarea cada vez. Por tanto, un nuevo rastreo o despliegue no puede comenzar sobre una tarea de publicación activa.
Publicación estática
Conserve WordPress para editar. Traslade la entrega pública a AWS.
Utilice Static Publisher cuando sea necesario capturar con fiabilidad un frontend real de WordPress, desplegarlo repetidamente y servirlo desde una infraestructura de Amazon S3 y CloudFront controlada por el cliente.