• engineering
  • performance
  • webdev

iframes vs Web Components — which one actually performs better in 2025?

iframes were introduced in 1997 — the same year Princess Diana died, the first Harry Potter book was published, and Google.com was…

Published

iframes were introduced in 1997 — the same year Princess Diana died, the first Harry Potter book was published, and Google.com was registered as a domain.

Twenty-eight years later, they’re still the most reliable way to embed isolated HTML on a page. That blows my mind.

Surely we’ve invented something better by now. Enter Web Components — the browser-native, standards-based alternative that promises encapsulated, reusable components without the baggage of iframes.

But here’s the twist: Even after all these years, I wasn’t sure which one actually performs better.

So I decided to try and find out.

With a little help from Copilot, I built two identical widgets — one with an iframe, one as a Web Component — and ran over 100 automated performance tests using Playwright. I wanted data, not opinions.

The results surprised me: Web Components load around 4.5× faster than iframes, while using the same memory and achieving the same frame rate.

Let’s dive in.

The Third-Party Widget Problem

Before we get into comparisons, let’s remember why this matters.

You know that tiny weather widget on your site? The one that shows “23°C, Partly Cloudy”? It probably shipped 3.2 MB of JavaScript. That’s React, ReactDOM, Lodash, Moment.js, a CSS-in-JS library, and probably an analytics SDK for good measure.

I’ve seen entire React apps used to render a simple sports result. Literally something like:

Foodball ResultsEngland: 4Germany: 2

That’s it. Two characters of data rendered by half a megabyte of framework code.

The Modern Web Performance Paradox

Third-party widgets are everywhere:

  • Sports scores
  • Weather forecasts
  • Social media feeds
  • Advertisement slots
  • Chat widgets
  • Analytics dashboards

Each one brings:

✅ 10–50 lines of actual UI code
 ❌ 500 KB — 3 MB of dependencies
 ❌ Potential security vulnerabilities
 ❌ CSS conflicts with your page
 ❌ JavaScript that can crash your site

We solve this with iframes — creating isolated browsing contexts. But that isolation comes with overhead: extra document contexts, separate HTTP requests, and layout complexity.

So the question becomes: Can Web Components give us encapsulation without the iframe tax?

TL;DR

I (with help from Copilot) built identical sports scoreboards using both iframes and Web Components, then ran automated performance tests across 1, 5, and 10 concurrent instances.

Using percentile-based metrics (p50, p95) instead of simple averages, I discovered:

  • Web Components load 4.5× faster (21 ms vs 116 ms median for a single instance)
  • iframes have inconsistent load times (p95 = 134 ms vs p50 = 50 ms)
  • Memory usage is identical (9.54 MB median for both)

👉 View the complete test suite on GitHub

The Experiment Setup

I wanted a realistic test — not “Hello World.” So I built a sports scoreboard widget that:

  • Updates every 5 seconds
  • Shows “live” scores and game status
  • Fetches JSON data (mock API)
  • Has meaningful styling and layout

Why a scoreboard? Because it’s the kind of thing developers reach for iframes to do:

✅ Frequent updates
✅ Self-contained functionality
✅ Needs isolation
✅ Scales naturally

I implemented it twice — once as an iframe, once as a Web Component — with identical functionality.

What I Built

A live sports scoreboard widget with:

  • Score updates every 5 s
  • Period/quarter tracking
  • Game status (Live, Final, Scheduled)
  • Realistic progression from JSON
  • Identical styling

Both versions were deliberately lightweight:

  • Zero frameworks or dependencies
  • Pure vanilla JavaScript (~100 lines each)
  • Shared CSS (~50 lines)

No build tools. No transpilers. No polyfills. Just raw browser primitives — <iframe> vs Custom Elements + Shadow DOM.

This isolates the cost of the isolation mechanism itself, not framework overhead.

Two Implementations, Identical Functionality

iframe version:

<iframe src="scoreboard.html?1" width="350" height="180"></iframe>

Self-contained HTML document. Complete isolation. Old school.

Web Component version:

<sports-scoreboard></sports-scoreboard>

Custom element with Shadow DOM. Modern standards. New school.

Both fetch the same JSON and update on the same interval — only the isolation mechanism differs.

The Testing Methodology: Beyond Averages

Test Scenarios

To understand performance degradation:

  1. 1 instance — baseline
  2. 5 instances — moderate load
  3. 10 instances — heavy load

Each scenario ran automated tests via Playwright, collecting metrics from Chromium.

Metrics That Matter

Load Time, First Paint (FP), First Contentful Paint (FCP), DOM Interactive, DOM Complete, Memory Usage, FPS.

Why Percentiles > Average

Averages hide outliers. Percentiles reveal what most users see (p50) and the worst-case (p95).

The Results

Summary Statistics (after 102 runs)

Metric           p50 (median)   p95 (worst-case)   σ (std dev)--------------------------------------------------------------Load (ms)              50              134              53FCP (ms)               46              112              39Memory (MB)           9.54             9.54            0.00FPS                   60.0             60.2             0.1

Comparison by Implementation

| Instances | Metric     | iframe p50 | web-component p50 | Delta          |-----------|------------|------------|-------------------|----------------| 1         | Load (ms)  | 116        | 21                | +95 (+452.4%)       | 1         | FCP (ms)   | 100        | 40                | +60 (+150.0%)       | 5         | Load (ms)  | 45         | 27                | +18 (+66.7%)     | 5         | FCP (ms)   | 52         | 44                | +8 (+18.2%)         | 10        | Load (ms)  | 113        | 21                | +92 (+438.1%)   | 10        | FCP (ms)   | 44         | 36                | +8 (+22.2%)

Key Findings

1 Instance → Winner: Web Components

  • Load Time 4.5× faster (21 ms vs 116 ms)
  • FCP 150% faster (40 ms vs 100 ms)
  • Memory was identical (9.54 MB)

Insight: iframes pay a full document-creation tax. Web Components share the parent context and skip that.

5 Instances → Still Web Components (but gap narrows)

  • iframes improve (116 → 45 ms) — likely caching or parallelisation
  • Web Components scale linearly (21 → 27 ms)

10 Instances → Web Components Again

  • iframes show higher variance (47–173 ms)
  • Web Components remain stable (~21 ms)

Insight: Web Components are consistently predictable. iframes vary.

Why These Differences Exist

iframe Architecture

Pros: True isolation, CSS safety, robust security
Cons: Full document contexts, extra HTTP requests, limited communication

Web Component Architecture

Pros: Lightweight, shared context, scoped styles
Cons: Still main-thread, no true sandbox, you control the code

Practical Recommendations

Use iframes when:

  • You need true isolation (third-party content)
  • Security is critical
  • You’re embedding full mini-apps

Use Web Components when:

  • You control all code
  • You need parent–child communication
  • SEO and performance matter
  • You’re loading multiple widgets

Hybrid approach:
Use Web Components for internal widgets, iframes for external ones.

How to Run This Test Yourself

git clone https://github.com/dp-lewis/iframes-v-webcomponentscd iframes-v-webcomponentsnpm installnpx playwright install chromiumnpm run serve   # in one terminalnpm test        # in another

Then open http://localhost:8080/dashboard/index.html. The suite is fully automated, percentile-based, and visualised.

What I Learned About Performance Testing

  1. Averages lie — use percentiles.
  2. Test at scale — issues emerge under load.
  3. Measure what matters — FCP, memory, FPS, consistency.
  4. Automate — Playwright + Performance API = reproducible.
  5. Visualise — dashboards reveal anomalies fast.

Conclusion

After 102 automated test runs, across six scenarios and two isolation methods, the data is clear: Web Components consistently outperform iframes for load time — about 4–5× faster — without compromising memory or frame rate.

Let’s be honest though: a 100 ms difference isn’t something users consciously feel. Your product will survive either way. But when two technologies solve the same problem, and one is objectively faster and more modern, why stick with the slower one?

  • iframes aren’t “bad” — they’re just doing more. They create full document contexts, enforce strong security boundaries, and guarantee bulletproof isolation.
  • Web Components, by contrast, share the main thread — lighter, leaner, and perfect for trusted internal widgets.

So here’s the rule of thumb:

  • Use Web Components for your own trusted, internal code — faster, cleaner, and easier to integrate.
  • Use iframes when you’re embedding untrusted or third-party content — security first, even if it costs you 100 ms.

In short:

  • Web Components win on speed and simplicity.
  • iframes win on security and sandboxing.
  • The right choice depends on your context.

And one final plea: whatever you choose, keep your widgets lightweight. The isolation mechanism matters less than what you pack inside it. A game score in React shouldn’t weigh more than the page it’s displayed in.

Ship less. Ship faster. Respect your users’ bandwidth, battery, and time.

Build for 2025.

⭐ GitHub Repository — Star if you found this helpful!