Adaptive Recognition case study
A render-aware WordPress-to-AWS publishing pipeline
How a large, Elementor-based corporate WordPress site became a repeatable static publishing workflow without replacing the editorial experience.
Previous export footprint
20,000+ assets
Render-aware artifact
~6,000 assets
Public delivery
S3 + CloudFront
From fragile exports to a production publishing flow
Challenge
Static exporters could not reliably model the rendered site
Adaptive Recognition operates a large corporate WordPress site built with Elementor and frontend behavior that loads some assets only after the page is rendered or scrolled. Earlier attempts with conventional static export tools either failed, required extensive manual include rules, or produced more than 20,000 files by collecting far more assets than the public experience actually needed.
Intervention
Separate WordPress configuration from browser-based execution
WP Suite Static Publisher keeps the publishing configuration and job controls close to WordPress, while a separate Node.js exporter performs the resource-intensive work. Playwright opens the real frontend, observes the rendered page, follows the crawl scope, captures requested assets, rewrites source URLs for production, builds the deployable artifact, synchronizes it to Amazon S3, and refreshes Amazon CloudFront.
Outcome
A smaller and repeatable production artifact
The render-aware flow reduced the export from more than 20,000 assets to roughly 6,000—about a 70% reduction—while preserving the WordPress-rendered frontend. Editors continue to work in WordPress, but public page requests are served from S3 and CloudFront instead of relying on the live PHP and database runtime.
The breakthrough was not another file scanner. It was letting a real browser show the publisher which pages and assets the site actually uses.
Architecture
WordPress remains the source; the publishing worker builds the runtime
The flow keeps editorial work, publishing orchestration, browser rendering, and public delivery as separate operational responsibilities.
Editors and content teams
│
▼
WordPress + Elementor
content, media, SEO, publishing controls
│ queue job and deployment profile
▼
WP Suite Static Publisher plugin
│ shared job state and configuration
▼
External Node.js + Playwright runner
├─ crawl rendered pages
├─ observe network and DOM assets
├─ capture responsive and lazy-loaded resources
├─ rewrite source URLs for production
└─ assemble the static artifact
│
▼
Amazon S3
static HTML, media, CSS, JavaScript and fonts
│
▼
Amazon CloudFront
public delivery and post-deployment invalidation
Operational boundary The external runner handles browser automation and deployment work outside the WordPress request lifecycle. WordPress stores the configuration and queues jobs; AWS serves the resulting public site.
Publishing workflow
A controlled queue from editor to edge
The production path is designed as a sequence of observable jobs rather than one long WordPress request.
- Queue the publication from WordPress — The plugin provides the WordPress-side control surface for crawl scope, target URLs, AWS deployment settings and job creation. Editors do not need to leave the familiar CMS workflow to request a new publication.
- Run one isolated export job at a time — A cron-driven queue worker starts the external publisher and uses a process lock with a single-job concurrency limit. This prevents overlapping Playwright crawls and competing deployments while keeping execution independent from browser sessions and PHP timeouts.
- Render, discover and rewrite — Playwright visits the real frontend and records what the browser needs, including builder-generated resources, responsive image variants, picture fallbacks and assets revealed by frontend behavior. The publisher then rewrites development or source URLs for the public domain and creates a focused artifact.
- Deploy to S3 and refresh CloudFront — The completed artifact is synchronized to the production S3 target. CloudFront invalidation refreshes the affected edge content, while job logs provide a practical trail for troubleshooting crawl, asset and deployment failures.
Details
Questions about the Adaptive Recognition flow
Is adaptiverecognition.com a headless WordPress site?
No. WordPress and Elementor still render the frontend that becomes the public site. Static Publisher captures that rendered experience and deploys it as files; it does not rebuild the presentation in a separate JavaScript framework.
Why does the exporter run outside WordPress?
Browser crawling, asset capture, URL rewriting and deployment are long-running operational tasks. Moving them to a dedicated Node.js worker avoids tying the production build to a PHP request, an administrator’s browser session or WordPress execution limits.
What made render-aware discovery important?
The site uses frontend behavior that is not represented by a simple scan of downloaded HTML and stylesheets. A real browser can observe responsive images, lazy-loaded resources, builder scripts and assets requested only after the page has initialized.
How does the flow avoid overlapping deployments?
The scheduled worker uses a process lock and is configured to run one job at a time. A new crawl or deployment therefore cannot start on top of an active publication job.
Static publishing
Keep WordPress for editing. Move public delivery to AWS.
Use Static Publisher when a real WordPress frontend must be captured reliably, deployed repeatedly, and served from customer-controlled Amazon S3 and CloudFront infrastructure.