WYSIWYG Editor
Optimeleon's landing-page personalization editor started as a scraped screenshot with a canvas mask punched into it, went through a scrapped remote-browser-streaming prototype, and landed on a live iframe of the customer's real site, unlocked by a companion Chrome extension that strips the CSP headers blocking cross-origin framing.
Customers personalized a landing page by editing a reconstruction of it, not the page itself. A screenshot was fetched from a web scraper and rendered as a static image, with a canvas layered on top: cleared, filled with a dark overlay, then punched with transparent cutouts over every detected element using destination-out compositing, with invisible DOM buttons behind each cutout catching clicks and keyboard focus. Changing an element's style or text meant serializing the change into a DOM patch, sending it back to the scraper, and waiting for a full re-render and a new screenshot. That loop took roughly an hour to change one site and validate a single A/B test, and a parallel drag-to-select canvas surface used for bulk element picking started dropping frames once a page had more than a couple hundred detected elements.
- Treated the interaction layer's performance ceiling as a solvable problem first: added quadtree spatial indexing to cut the per-mouse-move hit-testing cost against hundreds of bounding boxes, then reverted it the same day once a plain linear scan turned out to be fast enough. Kept the code path simple instead of carrying indexing complexity it didn't need.
- Prototyped a genuinely live alternative next: streamed a remote-controlled Chromium session (Browserbase, driven over CDP via Playwright) into the dashboard through a Socket.IO relay. It was live in principle, but every interaction still round-tripped through a hosted browser session, too much latency for editing that has to feel instant. Shelved after about two and a half weeks.
- Landed on the approach that actually removes the round trip: load the customer's real page directly in an iframe, inspired by Coframe, and have the page's own already-embedded script detect an edit flag in the URL and inject a small editor bundle from CDN, rather than reconstructing or proxying the page at all.
- The one thing a plain iframe can't solve is a site's own CSP and X-Frame-Options headers blocking cross-origin framing. Shipped a companion, published Chrome extension that customers install once; it strips those headers for their own site and doubles as a second communication channel (chrome.runtime.sendMessage) running alongside native postMessage, so batch edits, element selection, and full-page resets sync to the live iframe with zero added latency.
The live-iframe editor is now the default path across every editing surface in the product, from initial setup through ongoing management. I designed and built this end to end, and it has shipped with zero reported errors from users since launch, who moved from running 1-2 A/B tests a month to 20-25+ per user per week once the edit loop stopped being the bottleneck.
