` in your template | High — build rendering logic | | Content appearance speed | Fast; brief flash possible on inline content | Fastest; no flash | Depends on your implementation | | DOM impact | Replaces/populates selectors | Populates a pre-placed container | None from Maestra | | SPA compatible | Yes | Yes | Yes | | A/B testing | Managed by Maestra | Managed by Maestra | Your dev team manages | | SEO impact on original content | None | None | None; personalized content in initial HTML | ## Injector mode (default) Maestra's SDK targets a CSS selector on your page and renders campaign content (pop-up, embedded block, recommendation widget) directly into it. **How it works:** * Pop-ups and overlays render in an isolated container at the end of the ``, completely outside your application's component tree. * Inline content (embedded blocks, recommendations) replaces or populates the specified selector. * No dev work required beyond installing the SDK. For inline content, the original element is briefly visible before Maestra's content swaps in. See [Troubleshoot flickering](#troubleshoot-flickering) below. ## Manual div placement Your developers place a dedicated `

` in the site template. Maestra populates it; the surrounding DOM stays under your team's control. **How it works:** * The container is already in the page, so there's no element to find and swap — content appears faster than with injection. * Works best when the widget shows to all (or nearly all) visitors — if it only shows to a subset of your audience, an empty container may hurt your CLS more than help it. * No flash or flicker, because there's no original element to display before Maestra's content loads. * Your framework (Vue.js, React, etc.) can be told to ignore the container entirely. ## API-only (headless) Maestra returns product recommendations, ranking data, or customer's segments data. Your front-end team handles all rendering. **How it works:** * Zero DOM impact from Maestra — you control every pixel. * Personalization data can be fetched server-side and included in the initial HTML response, making it visible to search crawlers without JavaScript. * A/B testing requires your dev team to implement test branching logic. * This approach requires significant development effort on your end — plan for ongoing dev involvement to build, maintain, and extend the integration. ## SPA and framework compatibility If your site runs on React, Vue.js, Next.js, Nuxt, or another SPA framework, Maestra is designed to avoid DOM conflicts. **Pop-ups and overlays** render in a separate container at the end of the ``, outside your framework's component tree. No risk of race conditions. **Inline widgets** use a dedicated `

` that your framework ignores: * In Vue.js, the container is excluded from reactive updates. * In React, the container sits outside the React root. This prevents both Maestra and your framework from attempting to modify the same elements simultaneously. Maestra has been integrated with React and Vue.js SPA architectures across multiple production sites without race conditions or rendering conflicts. ## Troubleshoot flickering When Maestra's injector mode replaces an existing element after the page renders, the original element may be briefly visible before the swap. This is most noticeable with A/B tests on visible elements or injection into navigation bars and banners. **To eliminate flickering entirely:** use manual div placement — but **only if the widget shows to all (or nearly all) visitors**. Since the placeholder is already in your template, there's nothing to flash. **To minimize flickering in injector mode:** * **Reserve layout space.** Add a placeholder `

` with a fixed height where Maestra content will appear. The layout stays stable; Maestra fills the space when ready. * **Keep injected tests below the fold.** Content loads before the visitor scrolls to it. * **Use the API approach for above-the-fold personalization.** Fetch data server-side or during your framework's initial render cycle to avoid any client-side swap. In some cases, a brief flash is an acceptable trade-off — for example, temporarily changing a nav bar label for a sale may be preferable to a dev change that could outlast the campaign. The visibility of the flash depends on your site architecture and connection speed. Pop-ups and overlays are not affected — they appear as an intentional overlay and don't replace existing content.