Étude de cas Adaptive Recognition
Un pipeline de publication WordPress vers AWS tenant compte du rendu
Comment un grand site WordPress d’entreprise sous Elementor est devenu un processus de publication statique reproductible sans remplacer l’environnement éditorial.
Empreinte de l’ancien export
Plus de 20 000 ressources
Artefact tenant compte du rendu
Environ 6 000 ressources
Diffusion publique
S3 + CloudFront
Des exports fragiles à un processus de publication en production
Défi
Les exportateurs statiques ne pouvaient pas modéliser fiablement le site rendu
Adaptive Recognition exploite un grand site WordPress d’entreprise construit avec Elementor, dont le comportement frontend ne charge certaines ressources qu’après le rendu ou le défilement de la page. Les tentatives antérieures avec des outils d’export statique classiques échouaient, exigeaient de nombreuses règles d’inclusion manuelles ou produisaient plus de 20 000 fichiers en collectant bien plus de ressources que l’expérience publique n’en utilisait réellement. Cet écart correspond au choix pratique étudié dans Static Publisher face à Simply Static : un pipeline de publication rendu dans un navigateur plutôt qu’un chemin d’export statique plus simple.
Intervention
Séparer la configuration WordPress de l’exécution dans le navigateur
WP Suite Static Publisher conserve la configuration de publication et le pilotage des tâches près de WordPress, tandis qu’un exportateur Node.js distinct exécute les opérations gourmandes en ressources. Playwright ouvre le véritable frontend, observe la page rendue, suit le périmètre d’exploration, capture les ressources demandées, réécrit les URL sources pour la production, construit l’artefact déployable, le synchronise vers Amazon S3 et actualise Amazon CloudFront.
Résultat
Un artefact de production plus petit et reproductible
Le flux tenant compte du rendu a ramené l’export de plus de 20 000 à environ 6 000 ressources – soit une réduction proche de 70 % – tout en préservant le frontend rendu par WordPress. Les équipes éditoriales continuent de travailler dans WordPress, mais les requêtes publiques sont servies depuis S3 et CloudFront au lieu de dépendre de l’environnement PHP et de la base de données actifs. Sur le plan opérationnel, il s’agit du modèle décrit dans Conserver WordPress pour l’édition sans l’exposer publiquement.
La percée n’est pas venue d’un autre analyseur de fichiers, mais d’un véritable navigateur indiquant au système de publication les pages et ressources réellement utilisées par le site.
Architecture
WordPress reste la source ; le worker de publication construit l’environnement d’exécution
Le flux sépare le travail éditorial, l’orchestration de la publication, le rendu dans le navigateur et la diffusion publique en responsabilités opérationnelles distinctes. Le modèle de séparation plus large est décrit dans WordPress statique avec environnement d’exécution dynamique sur AWS ; cette étude de cas montre le versant publication de cette frontière en production.
Équipes éditoriales et de contenu
│
▼
WordPress + Elementor
contenu, médias, SEO, pilotage de la publication
│ mise en file de la tâche et du profil de déploiement
▼
Extension WP Suite Static Publisher
│ état partagé des tâches et configuration
▼
Runner externe Node.js + Playwright
├─ explorer les pages rendues
├─ observer les ressources réseau et DOM
├─ capturer les ressources adaptatives et différées
├─ réécrire les URL sources pour la production
└─ assembler l’artefact statique
│
▼
Amazon S3
HTML statique, médias, CSS, JavaScript et polices
│
▼
Amazon CloudFront
diffusion publique et invalidation après déploiement
Frontière opérationnelle Le runner externe prend en charge l’automatisation du navigateur et le déploiement en dehors du cycle de vie d’une requête WordPress. WordPress stocke la configuration et met les tâches en file ; AWS sert le site public obtenu.
Processus de publication
Une file contrôlée de l’éditeur jusqu’au réseau de périphérie
Le chemin de production est conçu comme une suite de tâches observables plutôt que comme une longue requête WordPress.
- Mettre la publication en file depuis WordPress — L’extension fournit l’interface de pilotage WordPress du périmètre d’exploration, des URL cibles, des réglages de déploiement AWS et de la création des tâches. Les équipes éditoriales n’ont pas à quitter leur processus CMS habituel pour demander une nouvelle publication.
- Exécuter une seule tâche d’export isolée à la fois — Un worker de file piloté par cron démarre le système de publication externe et utilise un verrou de processus avec une limite de concurrence d’une tâche. Il empêche ainsi le chevauchement des explorations Playwright et des déploiements concurrents, tout en maintenant l’exécution indépendante des sessions du navigateur et des délais PHP.
- Rendre, détecter et réécrire — Playwright parcourt le véritable frontend et enregistre ce dont le navigateur a besoin, notamment les ressources générées par le constructeur, les variantes d’images adaptatives, les solutions de repli picture et les éléments révélés par le comportement du frontend. Le système de publication réécrit ensuite les URL de développement ou sources pour le domaine public et crée un artefact ciblé.
- Déployer vers S3 et actualiser CloudFront — L’artefact terminé est synchronisé vers la cible S3 de production. L’invalidation CloudFront actualise le contenu concerné en périphérie, tandis que les journaux de tâches fournissent une piste exploitable pour diagnostiquer les erreurs d’exploration, de ressources et de déploiement.
Détails
Questions sur le flux Adaptive Recognition
adaptiverecognition.com est-il un site WordPress headless ?
Non. WordPress et Elementor rendent toujours le frontend qui devient le site public. Static Publisher capture cette expérience rendue et la déploie sous forme de fichiers ; il ne reconstruit pas la présentation dans un framework JavaScript distinct.
Pourquoi l’exportateur s’exécute-t-il en dehors de WordPress ?
L’exploration dans un navigateur, la capture des ressources, la réécriture des URL et le déploiement sont des tâches opérationnelles longues. Leur transfert vers un worker Node.js dédié évite de lier la construction de production à une requête PHP, à la session de navigateur d’un administrateur ou aux limites d’exécution de WordPress.
Pourquoi la détection tenant compte du rendu était-elle importante ?
Le site utilise un comportement frontend qu’une simple analyse des fichiers HTML et des feuilles de style téléchargés ne révèle pas. Un véritable navigateur peut observer les images adaptatives, les ressources chargées en différé, les scripts du constructeur et les éléments demandés uniquement après l’initialisation de la page.
Comment le flux évite-t-il les déploiements qui se chevauchent ?
Le worker planifié utilise un verrou de processus et est configuré pour exécuter une seule tâche à la fois. Une nouvelle exploration ou un nouveau déploiement ne peut donc pas démarrer par-dessus une tâche de publication active.
Publication statique
Conservez WordPress pour l’édition. Transférez la diffusion publique vers AWS.
Utilisez Static Publisher lorsqu’un véritable frontend WordPress doit être capturé fiablement, déployé de manière répétée et servi depuis une infrastructure Amazon S3 et CloudFront contrôlée par le client.