Building WebAR Experiences on Top of WordPress
What it's like wiring augmented reality into an ordinary CMS: no native app, no App Store review, just a camera permission prompt and a lot of undocumented edge cases.
- WordPress
- AR
- JavaScript
An unusual brief
Most WordPress work is CRUD with better styling. Then a German agency asked for marketing pages where pointing a phone camera at a product package would pop up a 3D model in the browser — no app install, no QR-code-to-app-store detour, just tap a link and the camera opens. WebAR: augmented reality that runs entirely in the mobile browser using device motion sensors and camera access, no native SDK involved.
The technical shape of the problem was less “learn a new framework” and more “integrate a JavaScript library that assumes it owns the whole page into a CMS that assumes it owns the whole page.” WordPress wants to enqueue its own scripts in its own order; AR libraries want unrestricted access to the camera stream and the device orientation API the moment the page loads. Getting both to coexist meant being deliberate about script loading order, deferring anything non-essential, and building a small custom plugin whose only job was to inject the AR markup and library calls exactly where and when the page needed them — nothing baked into the theme, nothing that would break the next time a template changed.
What actually goes wrong with WebAR
- Camera permission handling is not optional UX — it’s the whole product. If a visitor denies camera access or their browser doesn’t support the needed APIs, “AR feature broken” reads as “the whole site is broken” to a non-technical visitor. Every implementation needs an honest fallback: a static product image, not a blank canvas.
- iOS Safari and Android Chrome disagree about almost everything — autoplay policies, camera stream permissions, motion sensor access requiring a user gesture on iOS specifically. You test on both, always, on real devices, because simulators lie about sensor behavior.
- Performance budgets get tight fast. A 3D model asset that feels reasonable on a laptop can stutter a mid-range Android phone into uselessness. Model compression and lazy-loading the AR library until the visitor actually taps “view in AR” — instead of loading it on every page view — made the difference between a delightful feature and a page speed complaint.
Why it was worth doing
It’s the kind of project that doesn’t come up often, but it reset my instinct for treating “the browser” as a much more capable runtime than typical WordPress work implies. Most of what I do is server-rendered pages and modest JavaScript; building something that leans this hard on client-side device APIs is a good reminder that the CMS is just the content layer — what runs in the visitor’s hand can be a lot more ambitious than another accordion widget.