Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Improve generalized/sourcemap fetcher #12070

Closed
paulirish opened this issue Feb 9, 2021 · 6 comments
Closed

Improve generalized/sourcemap fetcher #12070

paulirish opened this issue Feb 9, 2021 · 6 comments

Comments

@paulirish
Copy link
Member

#9459 landed our generalized fetcher (with an iframe).

We may have some areas where it can be improved.

CSP sensitivity.. I didn't test, but I believe a frame-src directive would introduce problems for this technique.

content-type sensitivity. In #12064 we see that if a map is served with application/octet-stream it'll trigger a user-visible download while Lighthouse is fetching it. DevTools, meanwhile, doesn't have that behavior when it fetches.

devtools generalized loading…

There's been some updates..

Sigurd added the Network.loadNetworkResource protocol method for sourcemaps. He recently added metrics to record how various load attempts succeed/fail.

AFAICT, there are currently four different types of fetch attempts... you can see them in PageResourceLoader.js's _dispatchLoad() in the devtools source.

Here's the umbrella crbug.

You can also see some of this in the new "Developer Resources" drawer panel in devtools:

image

@adamraine
Copy link
Member

CSP sensitivity.. I didn't test, but I believe a frame-src directive would introduce problems for this technique

It does #12044 (comment)

@connorjclark
Copy link
Collaborator

Network.loadNetworkResource was added in M87, stable is currently M88. We might consider checking the chrome version and using the current implementation as a fallback for awhile.

@brendankenny
Copy link
Member

Network.loadNetworkResource was added in M87, stable is currently M88. We might consider checking the chrome version and using the current implementation as a fallback for awhile.

What are y'all thinking for a timeline for this? Stable is now m89, earliest #12199 could land is m91, so the main reason to hold back is CLI users using an old stable Chrome/specific Chromium build?

@connorjclark
Copy link
Collaborator

connorjclark commented Mar 16, 2021

yea, exactly. It seems people using docker images are eternally a few more versions behind than you'd expect..

v8?

@paulirish
Copy link
Member Author

content-type sensitivity. In #12064 we see that if a map is served with application/octet-stream

https://proxx.app/ also reproduces this behavior.

@connorjclark
Copy link
Collaborator

We're using the new protocol method to fetch resources now, but we need to keep the old one around for LR: #13006

Let's track in #13394 – next month we should be able to drop the iframe fetcher completely.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

6 participants