Using a Chrome Extension to Validate MAB Hero Images Before Full CMS and Target Setup
Context
The bottleneck of the homepage MAB (Multi-Arm Bandit) workflow was not simply publishing images to the CMS and CDN. The real bottleneck came after that: each processed image had to be attached to a CMS backing doc, associated to the correct hero component target characteristics through name/value pairs, matched to one of 12 to 14 CMS variants, and then Adobe Target needed to be set up similarly to handle that same number of variants and JSON offers. Only after all of that wiring was complete could the team create Target preview links and confirm whether a processed image actually looked correct across devices and breakpoints.
Decision
Build a Chrome extension that lets editors, designers, and stakeholders preview CMS-processed hero images directly on the live homepage by swapping CDN image paths and layout settings in the browser, before a developer spends time wiring backing docs, component variants, and Adobe Target offers.
Alternatives Considered
Continue validating images only after the full CMS and Adobe Target configuration was complete
- Uses the exact production setup with no additional tooling.
- Keeps all validation inside the existing CMS and Target workflow.
- Requires developer time for every validation cycle.
- Makes simple crop and quality checks dependent on 12 to 14 variant mappings.
- Slows down design sign-off because issues are found too late.
Add preview hooks directly into the production homepage application
- Could create a more formal preview system inside the app.
- Might be reusable for future experiments.
- Introduces unnecessary code and risk into a high-traffic production surface.
- Still requires coordination and deployment for an internal-only workflow tool.
- Expands scope well beyond the immediate validation problem.
Build a standalone internal preview app
- Could support richer controls and more structure over time.
- Would avoid extension installation for users.
- Would be harder to keep aligned with the real homepage DOM and CSS behavior.
- Adds infrastructure and maintenance for a narrow workflow.
- Still would not naturally inherit the exact processed asset behavior seen on the live page.
Reasoning
The extension solved the narrowest high-value problem: letting non-developers validate the final CMS-processed image asset before the expensive variant setup work began. Editors could publish an image, let the CMS generate the production-ready crops and compression, copy the CDN folder path into the extension, and immediately test the asset on the live homepage across breakpoints. That made it possible to judge crop quality, responsiveness, CTA side, and background positioning before a developer had to build backing docs, component characteristics, or Target offers. The approach preserved production fidelity, reduced rework, and moved visual sign-off closer to the people making content decisions.
What Problem the Extension Actually Solved
The extension was not designed to bypass the CMS or replace Adobe Target. The CMS still needed to process the source image into the final production-ready image set, and Target still remained the delivery mechanism for the real experiment.
What the extension removed was the need to fully wire every processed image into the MAB setup just to answer an earlier question: is this image actually usable? That meant designers and stakeholders could validate crop quality, breakpoint behavior, CTA placement, and background positioning before a developer spent time connecting backing docs, component characteristics, and Target offers.
This was especially valuable because a single test often included 12 to 14 variants. Without the extension, every image review cycle meant repeating a large amount of setup just to discover that one image needed a better crop or a different CTA alignment.
Why a Chrome Extension Was the Right Shape
A Chrome extension fit because it could operate directly against the live homepage DOM without requiring any change to the production application. That kept the implementation low-risk and made the preview more trustworthy, since the tool was manipulating the same page structure, styles, and breakpoints used in production.
It also turned the workflow into something non-developers could run on their own. Once the image had been published and processed through the CMS, the user only needed the CDN folder path and a few visual settings. That shifted sign-off work away from engineering and shortened the turnaround time for MAB asset review.
Core Extension Pieces
At a high level, the tool had two separate JavaScript responsibilities.
The first was the extension UI itself. That layer handled the popup experience, captured values like the image path, background position, and CTA position, and packaged them into a message when the user clicked Apply.
The second was the page-side script that actually changed the homepage. In Chrome extension terms, this is the script that can read and manipulate the DOM on the current tab. Its job was to wait for settings from the extension UI, locate the relevant hero styles and elements, and then update the page in place.
The extension also needed a manifest.json file to declare the extension metadata and wire those pieces together. That manifest is effectively the entry point for the whole extension. It defines what scripts exist, which pages they can interact with, and what permissions are required for the popup to communicate with the active tab.
How the Message Flow Worked
The popup did not manipulate the page directly. Instead, it collected user input and sent a payload to the script running against the page.
When the user clicked Apply, the extension sent a message like this:
const response = await chrome.tabs.sendMessage(tab.id, {
type: 'APPLY_BACKGROUND_SETTINGS',
payload,
});That payload carried the values needed to update the homepage preview, including the CDN image path, background positioning, and CTA placement.
On the page side, the DOM script waited for those messages through Chrome’s runtime listener:
chrome.runtime.onMessage.addListener((message, sender, sendResponse) => {
// interpret payload and update the page
});Once the message arrived, the page-side script could parse the payload, identify the correct hero-related DOM or style targets, and apply the requested changes. That separation was important because it kept the popup focused on input and state, while the DOM script handled the logic for modifying the page.
What the DOM Script Changed
The page-side script was responsible for making the preview trustworthy. It needed to locate the homepage hero implementation and update it in a way that matched production behavior across breakpoints.
In practice, that meant replacing the processed image references with the new CDN path and updating other visual settings that affected final approval, such as background positioning and which side the CTA content should sit on. Because the page already contained the production structure and responsive rules, this gave the team a realistic preview without having to create the full CMS and Target setup first.
It also meant the extension could be used repeatedly while an editor refined crops and reran CMS processing. Publish the image, let the CMS generate the final assets, test the processed result, adjust the source image if needed, and test again. That feedback loop was much faster than rebuilding the entire experiment configuration on every pass.
Resulting Workflow Change
Before the extension, developers were pulled into image validation because checking one candidate image usually meant walking through the larger variant setup process. After the extension, a non-developer could verify whether a processed image worked before asking engineering to wire it into a backing doc and Target configuration.
That is what made the tool high leverage. It did not replace the experiment stack. It reduced unnecessary setup work, shortened design sign-off, and let engineering spend time on the actual implementation instead of acting as the middle layer for visual QA.