DevTools: Improve named hooks network caching

[bvaughn]

While testing the recently-launched named hooks feature, I noticed that one of the two big performance bottlenecks is fetching the source file. This was unexpected since the source file has already been loaded by the page. (After all, DevTools is inspecting a component defined in that same file.)

Based on a suggestion from @JoelEinbinder, I made this prototype to test and confirm that requests made by an extension don't share the page's network cache.

To address this, I made the following changes:

• Keep CPU bound work (parsing source map and AST) in a worker so it doesn't block the main thread but move I/O bound code (fetching files) to the main thread.
• Inject a function into the page (as part of the content script¹) to fetch cached files for the extension. Communicate with this function using eval() (to send it messages) and chrome.runtime.sendMessage() to return its responses to the extension).

With the above changes in place, the extension gets cached responses from a lot of sites- but not Facebook. This seems to be due to the following:

• Facebook's response headers include vary: 'Origin'.
• The fetch made from the content script does not include an Origin request header.

For example, the screenshot below shows the same source being loaded three times. The 1st time is the <script> tag in the page. The 2nd and 3rd times are via fetch() (running in the context of the page). Only the 3rd request (the second fetch) is a cache hit.

I'm not sure how to work around this issue. I'm aware that Origin is a restricted header that can't generally be modified by scripts running on the page. (Web extensions can, in some contexts, modify the header– but I don't think that's a route that would help us with this PR.)

To reduce the impact of cases where we can't re-use the Network cache, this PR also makes additional changes:

• Use devtools.network.onRequestFinished to (pre)cache resources as the page loads them. This allows us to avoid requesting a resource that's already been loaded in most cases.
• In case DevTools was opened after some requests were made, we also now pre-fetch (and cache in memory) source files when a component is selected (if it has hooks). If the component's hooks are later evaluated, the source map will be faster to access. (Note that in many cases, this prefetch is very fast since it is returned from the disk cache.)

With the above changes, we've reduced the time spent in loadSourceFiles to nearly nothing:

¹ I've also tried injecting this helper function into the page using devtools.inspectedWindow.eval so that the request comes from the page itself rather than from the content script, but this did not change the observable behavior.

[jstejada]

thanks!! lgtm! i mostly have a lot of questions, and just requesting changes so we update some of the original comments which do not reflect the current state.

[jstejada]

looks awesome, thanks! my only other question is about our test plan? did you test the newer logic to cache source files as they are loaded? not a blocker, but wondering if it's worth adding tests for the new layers of caching? (not sure that it is)

[bvaughn]

my only other question is about our test plan? did you test the newer logic to cache source files as they are loaded? not a blocker, but wondering if it's worth adding tests for the new layers of caching?

I tested this layer manually, but not programmatically.

We don't have any test coverage for the browser extension specific code, unfortunately. We'd have to either find a way to automate it using some e2e testing software (I don't know of anything that exists for testing extensions like this) or we'd have to mock out a lot of things to test it manually (which I'm not sure is worth the effort).

Happy to hear ideas and chat about this though!