If you only have time to make one technical change to your interactive content stack this year, make it this one: stop embedding quizzes, polls, and personality tests in iframes.

This is not a stylistic preference. The iframe is the single largest performance and engagement leak in the interactive-content category, and the gap between iframe-based widgets and native-web-component widgets has widened every year since custom elements landed in the platform. In 2026 the gap is not arguable.

The numbers above are not the whole story. They're the symptom of a deeper architectural mismatch — between what an iframe is for and what an interactive widget needs to be.

What the iframe was for

The iframe is a wonderful tool. It was designed to render a foreign document inside a host document while preserving security boundaries — the cross-origin, sandboxed document. Ads, payment forms, third-party identity dialogs. For those, it remains the right tool.

It was never designed for content that needs to:

• read its parent's typography to match the article around it,
• adapt its width to a responsive column,
• emit events into the host's analytics stack,
• not block the host's main thread during page load,
• defer its own network requests until the reader scrolls to it,
• be navigated by keyboard and screen readers as if it were part of the article.

Interactive widgets need every single one of those. The iframe gives you zero.

“

The iframe is a security boundary first and a rendering construct second. Interactive content is a rendering construct first and a security boundary almost never. We have been embedding rectangles where we should have been embedding elements.

The cost, measured

The eager iframe — the default install path of every legacy quiz tool — is the worst variant of the worst pattern. It boots an entire foreign document during page load and blocks the host's LCP while doing it. The numbers compound across every article that embeds one.

Four embed strategies, four real costs

Median across 50 publisher sites · throttled to slow 4G, same widget content

Best

Native web component

+0.04sLCP impact

• CLS0.00
• INPunder 50ms

The only strategy that doesn't degrade CWV.

Hydrated React island

+0.18sLCP impact

• CLS0.01
• INP70–110ms

Acceptable on modern sites; ships a runtime.

Lazy iframe

+0.05sLCP impact

• CLS0.04
• INP90–150ms

LCP fine; INP drags after scroll-in.

Worst

Eager iframe

+1.6sLCP impact

• CLS0.11
• INP200ms+

Universally tanks article-level CWV.

LCP, INP and CLS are the three Core Web Vitals Google uses as ranking signals. The iframe is the only embed strategy in the category that fails all three.

The engagement consequences are a separate story.

Engagement delta by embed strategy

Start rate = % of readers who began the interactive · n = 14,200 sessions

★ sweet spot86%

71%

38%

34%

24%

Native web component (inline)Element renders as part of the article.

Hydrated React island (inline)Hydration cost, but element-shaped.

Lazy iframe (inline)Visible after scroll, but interaction lags.

Eager iframe (inline)Boots before interaction; reader bounces.

Iframe in a modalModal trigger = a second decision.

The reader doesn't know what's underneath. Their browser does. So do their input latencies. So does the layout-shift their thumb encounters when they go to tap.

Why a custom element wins

A modern web component is just a class extending HTMLElement, registered with customElements.define(). Browsers have shipped this in every release since 2018; in 2026 the support story is identical to <div>. What you get for free, the moment you author the widget as a custom element:

• Native parsing. The browser knows how to parse <my-question uuid="..."> at HTML-parse time — no JavaScript needs to run before the layout is correct.
• Real DOM. The widget is in the same document as the article. Selectors work. CSS variables cascade. Typography inherits.
• Real focus order. Tab navigation and screen-reader landmarks flow naturally — the widget is part of the article, not a sandboxed sibling.
• Real event bubbling. The widget can emit CustomEvents the host can listen for — no postMessage choreography, no schema versioning between embedder and embedded.
• Real lazy-load. loading="lazy"-equivalent patterns work — the widget can defer its own network until IntersectionObserver fires.
• Shadow DOM, when you want it. Style encapsulation without the iframe tax. Brand styles can either pierce in (CSS custom properties) or be sealed out (mode: "closed").

The shadow-DOM detail matters more than it looks. Iframes give you full style isolation at the cost of breaking everything an embed should inherit. Shadow DOM gives you the same isolation by default, and lets you selectively opt in to inheritance via CSS custom properties. That's the entire architectural argument in one line.

The hidden taxes you stop paying

Switching from iframe to web component removes a long tail of secondary costs that don't show up in any one metric, but compound.

The 2026 migration path

The good news is that the migration is mechanical. A web-component-based interactive widget exposes itself in HTML exactly as the iframe-shaped one did — one custom tag with one or two attributes. The MDX, the CMS, the editorial team don't care which is underneath.

The publisher-side change is one line per embed. The vendor-side change — whether your current widget tool offers a web-component variant at all — is the real question.

The publisher migration order that has worked in practice:

1. Audit the article CWV impact of your current iframe embeds — use the field data, not lab data.
2. Pilot on one high-traffic vertical for two weeks. The numbers will be unambiguous.
3. Roll across the rest of the site in one cycle. Don't half-migrate — the inconsistent embed strategy is its own engagement tax.
4. Strip the postMessage handlers and analytics bridges. They were workarounds for the iframe; they don't apply to the element-based version.

A pre-rollout checklist

• Embed renders as a custom element, not an iframe or a script-injected iframe.
• Layout is reserved (no CLS on widget boot).
• Widget defers its own network until visible via IntersectionObserver.
• CustomEvents are emitted for start / complete / share / vote; analytics listens host-side.
• Shadow DOM mode is open or closed by intent — not by accident.
• Brand CSS custom properties pierce cleanly (typography, accent color, radii).
• AMP / dynamic-CMS variants render the same custom element without a wrapper.
• One vendor, one rendering path. No iframe fallback "for legacy."

“

The iframe was the right answer for a different question. Interactive content is not third-party content from the reader's perspective. It should not be third-party content from the browser's perspective either.

iThinkToday ships every widget — quizzes, polls, personality tests, photo battles — as a single native custom element: <my-question uuid="…" type="…">. No iframe, no script-injected wrapper, no separate AMP variant. The free plan is enough to run the audit above on one of your own articles and see the field-data numbers for yourself. The longer-form companions: the pillar quiz playbook for the craft side, the polls playbook for the simplest format to migrate first.