Performance

Why Performance Matters for Web Components

Web Components are often reused across pages, frameworks, and products. Poor performance in a shared component multiplies across every place it is used. Fast components improve page load, runtime responsiveness, and user experience.

Performance tuning focuses on how components load, render, update, clean up resources, and avoid unnecessary work in the browser.

Avoid Unnecessary Re-rendering

class StatusBadge extends HTMLElement {
  static get observedAttributes() {
    return ["variant"];
  }

  attributeChangedCallback(name, oldValue, newValue) {
    if (oldValue === newValue) return;
    this.render();
  }

  render() {
    const variant =
      this.getAttribute("variant") || "info";
  }
}

A simple performance win is skipping work when values have not changed. Avoid full re-renders on every lifecycle or attribute callback if the UI does not need to update.

Lazy Loading Components

const loadChartWidget = async () => {
  await import("./chart-widget.js");
};

button.addEventListener("click", async () => {
  await loadChartWidget();
  const chart = document.createElement("chart-widget");
  panel.appendChild(chart);
});

Do not load every custom element on every page. Split component code with dynamic imports and register heavy widgets only when they are needed.

Efficient DOM Updates

class UserList extends HTMLElement {
  set items(value) {
    const next = Array.isArray(value) ? value : [];
    if (this._sameItems(next)) return;

    this._items = next;
    this.updateList();
  }

  updateList() {
    const fragment = document.createDocumentFragment();

    this._items.forEach((item) => {
      const li = document.createElement("li");
      li.textContent = item.label;
      fragment.appendChild(li);
    });

    this.list.replaceChildren(fragment);
  }
}

Prefer targeted DOM updates over rewriting large HTML strings on every change. Use fragments, replaceChildren(), and change detection to reduce layout work.

Shadow DOM Performance Tips

• Create the shadow root once in the constructor.
• Reuse templates instead of rebuilding markup strings repeatedly.
• Share styles with adoptedStyleSheets across components.
• Avoid deep shadow trees when a simpler structure works.
• Minimize style recalculation with stable class names and CSS.
• Update only the nodes that actually changed.

const sharedSheet = new CSSStyleSheet();
sharedSheet.replaceSync(`
  button { font: inherit; cursor: pointer; }
`);

class SharedButton extends HTMLElement {
  constructor() {
    super();
    this.attachShadow({ mode: "open" });
    this.shadowRoot.adoptedStyleSheets = [sharedSheet];
  }
}

Lifecycle Cleanup

class LiveFeed extends HTMLElement {
  connectedCallback() {
    this.timer = setInterval(() => this.poll(), 5000);
    this.observer = new ResizeObserver(() => this.resize());
    this.observer.observe(this);
  }

  disconnectedCallback() {
    clearInterval(this.timer);
    this.observer?.disconnect();
  }
}

Memory leaks and background work hurt performance over time. Always clean up timers, observers, listeners, and subscriptions in disconnectedCallback().

Debounce and Throttle Expensive Work

class SearchInput extends HTMLElement {
  connectedCallback() {
    this.input = this.querySelector("input");
    this.input.addEventListener("input", () => {
      clearTimeout(this._timer);
      this._timer = setTimeout(() => {
        this.dispatchQuery();
      }, 250);
    });
  }

  disconnectedCallback() {
    clearTimeout(this._timer);
  }
}

Input handlers, resize logic, and scroll reactions should debounce or throttle expensive updates so components do not overwhelm the main thread.

Large Lists and Virtualization

// Instead of rendering 10,000 rows at once
renderVisibleRows(startIndex, endIndex) {
  const visible = this.items.slice(startIndex, endIndex);
  this.viewport.replaceChildren(
    ...visible.map((item) => this.createRow(item))
  );
}

Components that render large collections should virtualize or paginate results. Rendering thousands of DOM nodes inside custom elements can quickly degrade performance.

Reduce Bundle Size

Measuring Component Performance

performance.mark("badge-render-start");
component.render();
performance.mark("badge-render-end");

performance.measure(
  "badge-render",
  "badge-render-start",
  "badge-render-end"
);

const [measure] =
  performance.getEntriesByName("badge-render");
console.log(measure.duration);

Use browser performance APIs, Lighthouse, and DevTools profiling to measure render time, script cost, and layout impact before optimizing blindly.

Web Components and Core Web Vitals

Reserve space for components when possible, lazy load non-critical widgets, and keep interaction handlers fast to protect Core Web Vitals.

When Performance Optimization Matters Most

• You ship a design system used on many high-traffic pages.
• Components render large lists, charts, or media-heavy UI.
• Widgets load on initial page render above the fold.
• Multiple custom elements mount and unmount frequently.
• Mobile users need fast interaction on slower devices.
• Third-party embeddable components run on external sites.

Common Performance Use Cases

• Lazy loading infrequently used dialogs and charts.
• Optimizing data table and list rendering.
• Sharing stylesheets across many button and input primitives.
• Cleaning up observers in single-page app route changes.
• Splitting a component library into per-component bundles.
• Measuring render cost before publishing shared UI packages.

Performance Best Practices

• Skip renders when input values have not changed.
• Lazy load heavy components and dependencies.
• Clean up timers, observers, and listeners on disconnect.
• Prefer targeted DOM updates over full HTML rewrites.
• Share styles with constructable stylesheets when possible.
• Debounce or throttle expensive input and resize handlers.
• Measure before optimizing and track regressions in CI.

Common Performance Mistakes

• Re-rendering the entire shadow tree on every small change.
• Loading the full component library on every page.
• Leaving timers and observers active after removal.
• Rendering very large lists without virtualization.
• Using expensive observers when simpler checks are enough.
• Inlining huge style blocks in every component instance.
• Optimizing without measuring real user impact.

Key Takeaways

• Web Component performance affects every page that uses them.
• Reduce load cost with lazy imports and smaller bundles.
• Reduce runtime cost with efficient updates and cleanup.
• Shadow DOM performance improves with shared styles and stable DOM.
• Measure, optimize, and prevent regressions in shared libraries.