Skip to main content
Performance regressions in your extension come from a short list of places. The most common are service worker cold-starts (initial startup delays), heavy content-script injection, oversized UI bundles, and media-heavy web-accessible resources. The checklists below map each type to a concrete fix.

Performance optimization capabilities

Fast optimization pass

  1. Measure first-run behavior on one target browser.
  2. Trim synchronous startup work in content scripts and background handlers.
  3. Defer optional UI features until after initial render.
  4. Re-check build output size and smoke-test critical flows.

Content scripts

  • Keep entry files small and defer non-critical work.
  • Avoid heavy synchronous DOM scans at document_start.
  • Scope observers and event listeners; clean up on remount/dispose.
  • Split reusable logic into shared modules, but avoid fragile dynamic import patterns.

Background/service worker

  • Minimize work at startup; initialize lazily when events arrive.
  • Cache stable computed state where safe.
  • Avoid long-running synchronous tasks in event handlers.
  • Watch service worker dependency churn during active development.

UI surfaces (popup/options/new tab/sidebar)

  • Keep initial render path lightweight.
  • Load large optional UI features on demand.
  • Use framework dev tools only when needed in local debugging sessions.
  • Keep styles modular and avoid large global CSS payloads.

Assets and resources

  • Optimize icon/image sizes by target use.
  • Limit web-accessible resources (WAR) exposure to required assets.
  • Keep public assets intentional; remove stale files.
  • Verify generated dist/<browser> output size regularly.

Performance budgets

Production builds (build) emit a warning when a bundle exceeds its per-category size budget. Budgets are warn-only (they never fail the build) and are enabled in production mode by default. Override any category in extension.config.js via perfBudgets (values in bytes):

Operational checks

  • Run multi-browser build checks in CI.
  • Track regression signals in end-to-end (E2E) runtime duration over time.
  • Add smoke tests for critical extension flows (install, open UI, content script activation).

Common performance pitfalls

  • Large content-script bundles loaded on every matched page
  • Heavy work at document_start without guard conditions
  • Service worker handlers doing synchronous, non-essential initialization
  • UI surfaces shipping large global CSS/JS when you only use partial features

Next steps