Cache web extension byte code

[chrmod]

This topic was briefly discussed at WECG Meetup Berlin 2025.

Contexts to cover:

• service workers and background scripts
• action pages
• sidebar pages
• offscreen documents

[xeenon]

This seems more browser-specific optimization than something we need to specify as a group.

[carlosjeurissen]

@xeenon while not exactly discussed in the issue starting post, from an extension and user perspective, there are a few aspects we can discuss. Some quick throw-at-the-wall items being:

1. keep an extension popup html loaded for instant reopening (for example, when the user temporarily has to "close" the popup due to the opening of a new tab).
2. the ability to transition an action document to a sidebar document and reverse
3. keeping a sidebar page loaded even when the sidebar is currently closed.

[Rob--W]

In the last meeting we noted that this is a browser-specific optimization that makes sense but does not require API changes.

@carlosjeurissen Your additional suggestions for discussion points are unrelated to byte code caching, but have been discussed before as part of:

• Proposal: Complete privileged page process even after closing #315

[Rob--W]

For better visibility, the relevant discussion was at:

webextensions/_minutes/2025-03-28-berlin-f2f.md

Lines 335 to 352 in 4d08213

	* [krzysztof] Observed that our complicated UIs take a while to load. We don't bundle JS, we have well structured individual files. Would browser vendors be open to some kind of cache warmup? We use JavaScript modules.
	* [rob] Sounds like something browsers could/should do without API changes. Makes sense to do this for background scripts, especially.
	* [krzysztof] Hack solution for an extension is to load these files in the background (e.g. a background tab) to warm the files before injection.
	* [timothy] This is what we do in Safari already; frequently used code is compiled and cached.
	* [krzysztof] This happens when code runs once. Could we warm up the cache?
	* [timothy] Probably something we could do. Default behavior has been to let it happen when the user interacts with the resource.
	* [oliver] Is there a reason why this is more of an issue here than on the web?
	* [krzysztof] Large production websites don't use ESM directly. They bundle scripts.
	* [simeon] Chrome uses a completely different loading path for extensions resources.
	* [rob] If perceived cold startup is a concern, could you add a small script or style that shows progress.
	* [devlin] In Chrome we don't cache extension resources. Artifact of current implementation. Something we'd be open to. I think the extension service worker is cached, but nothing else.
	* [krzysztof] Wasn't sure if it was worth having an issue.
	* [devlin] We've had a few threads about this in the extension mailing list.
	* [oliver] Yeah, but most have been higher level requests. For example, we've had requests to freeze the background service worker instead of terminating.
	* [krzysztof] Would recommend against that. Violates expectations of web script behaviors. Devs don't expect that their context will live forever.
	* [rob] Going back, Firefox has been working on sharing compiled code across pages.
	* [krzysztof] I haven't noticed performance issues in Firefox. Specifically observed in Safari in Chrome.
	* [tomislav] We also preload the action panel content in Firefox when it seems likely for the user to open the panel, when the user hovers over the extension action button.