Background compile JS extension scripts injected at document start [chromium/src : main]
Luis Pardo (Gerrit)
Luis Pardo voted and added 2 comments![]( "Open in Gerrit")
Votes added by Luis Pardo
| Commit-Queue | +1 |
2 comments
@rdevlin...@chromium.org Can you take a look at this feature? Here is the related [design doc](https://docs.google.com/document/d/1gryv6WZItlP5VbuOwL9VtNnjbM8yvvFpEPnELXWGM9E/edit?usp=sharing). Also linked in the bug.
// TODO(https://crbug.com/436274244): filter out frames that will not have any
// script injections.@rdevlin...@chromium.org Any suggestions on how to address this? It would be nice to only do this work once, so maybe refactoring to fill the pending injections here?
Related details
- Devlin Cronin
Code-Coverage
Code-Owners
Code-Review
No-Unresolved-Comments
Review-Enforcement
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
Devlin Cronin (Gerrit)
Devlin Cronin added 1 comment![]( "Open in Gerrit")
Thanks for the CL! Sorry, I haven't had a chance to get to this yet, but I hope to tomorrow.
One of the concerns I have here is that it seems like this would be difficult to determine if it's a net performance improvement. Moving the compilation to a background thread seems like it has the potential to slow down the compilation of document_start scripts, but since we block the page on the injection of document_start scripts, that would mean we block page load on that.
Is there a rollout plan to ensure we'll measure the impact of this and that we're not regressing any other important metrics?
Related details
- Devlin Cronin
- Luis Pardo
Code-Coverage
Code-Owners
Code-Review
No-Unresolved-Comments
Review-Enforcement
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
Luis Pardo (Gerrit)
Luis Pardo added 1 comment![]( "Open in Gerrit")
Thanks for the CL! Sorry, I haven't had a chance to get to this yet, but I hope to tomorrow.
One of the concerns I have here is that it seems like this would be difficult to determine if it's a net performance improvement. Moving the compilation to a background thread seems like it has the potential to slow down the compilation of document_start scripts, but since we block the page on the injection of document_start scripts, that would mean we block page load on that.
Is there a rollout plan to ensure we'll measure the impact of this and that we're not regressing any other important metrics?
I added an [experimentation plan section](https://docs.google.com/document/d/1gryv6WZItlP5VbuOwL9VtNnjbM8yvvFpEPnELXWGM9E/edit?tab=t.0) to the design doc. We'll run an experiment with First Contentful Paint as the success metric, this should catch any regressions on page load, we are also adding other metrics for parameter tunning. I don't think I can run finch trials in Chrome, so I'm setting up the infrastructure in this CL and I'll run the experiment on Edge, it would be great if someone could run the in the Chrome side too.
Related details
- Devlin Cronin
Code-Coverage
Code-Owners
Code-Review
No-Unresolved-Comments
Review-Enforcement
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |