-
Notifications
You must be signed in to change notification settings - Fork 9.4k
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
core(lantern): add edges from initiatorRequest when there are duplicate records #10097
Conversation
Thinking this a bit more, I think this can be generalized a bit further (for example, when iframes are prefetched) by making sure that lighthouse doesn't choose prefetch request as initiators (in network-recorder.js or adding links to frames in page-dependency-graph.js) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
thanks a ton @warrengm, great find!! 👏 👏 💯
@@ -0,0 +1,851 @@ | |||
[ | |||
{ | |||
"method": "Page.lifecycleEvent", |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
would you mind running this through our ./lighthouse-core/scripts/lantern/minify-devtoolslog.js
script to prune some of the unnecessary stuff?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
did you get a chance to give that script a whirl?
if (!possiblePrefetchRecords.has(record.url)) { | ||
possiblePrefetchRecords.set(record.url, record); | ||
} | ||
} else if (!typedRecords.has(record.url)) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I wonder if we should start taking the same approach here as in page-dependency-graph and not set the initiator if it was ambiguous on the typedRecords
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Possibly. I can take a look in a follow-up PR.
I did look a bit into resolving ambiguities in page-dependency-graph, and they all seemed to increase the errors in simulation. Even when I did:
const parentCandidates = (networkNodeOutput.urlToNodeMap.get(initiator) || [])
.filter(candidate => candidate.startTime < node.startTime);
Though there are cases that I would expect to be resolvable. For example, sometimes gpt.js is loaded inside of the top window and inside of iframes. But, again, some of the naive filters I wrote increased the amount of error in simulation so more work would be needed to investigate. (Which is out of scope of this PR but I could look into at some point)
// Only add the initiator relationship if the initiator is unambiguous | ||
const parent = parentCandidates.length === 1 ? parentCandidates[0] : rootNode; | ||
const parent = parentCandidates.length === 1 ? parentCandidates[0] : directInitiatorNode; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
we probably should have been doing this all along but now that we're selecting initiators that will be later in load can we add a quick check that the request started after the parent?
@@ -353,7 +359,10 @@ class NetworkRecorder extends EventEmitter { | |||
const initiatorURL = record.initiator.url || (stackFrames[0] && stackFrames[0].url); | |||
// If we were redirected to this request, our initiator is that redirect, otherwise, it's the | |||
// initiator provided by the protocol. See https://github.com/GoogleChrome/lighthouse/pull/7352/ | |||
const initiator = record.redirectSource || recordsByURL.get(initiatorURL); | |||
const initiator = record.redirectSource || |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
should probably do that same time check about starting after the initiator here too
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM thanks very much warren! looks awesome 😍 just a few minor nits
@@ -340,20 +371,26 @@ class NetworkRecorder extends EventEmitter { | |||
// get out the list of records & filter out invalid records | |||
const records = networkRecorder.getRecords().filter(record => record.isValid); | |||
|
|||
// create a map of all the records by URL to link up initiator | |||
const recordsByURL = new Map(); | |||
// The initiator is unlikely to be a prefetch record which have type 'Other' |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
❤️
@@ -0,0 +1,851 @@ | |||
[ | |||
{ | |||
"method": "Page.lifecycleEvent", |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
did you get a chance to give that script a whirl?
Hi @patrickhulce, I think this is ready to merge now! I didn't notice that my branch was behind master and then went on some travels--but I made time to finish it up today. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM! 🎉
} | ||
} | ||
|
||
return candidates.length ? candidates[0] : null; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
friendly bump on this, if you're already thought this through a simple explanation is all I'm lookin for here :)
oh btw @warrengm you've got to update https://github.com/GoogleChrome/lighthouse/blob/master/lighthouse-core/test/fixtures/lantern-master-accuracy.json now too to get the lantern data tests to pass to match the expectations, nice accuracy improvements! :) |
friendly ping on the two last little comments on this, would love to land before 6.0 final :) |
All (the pull request submitter and all commit authors) CLAs are signed, but one or more commits were authored or co-authored by someone other than the pull request submitter. We need to confirm that all authors are ok with their commits being contributed to this project. Please have them confirm that by leaving a comment that contains only Note to project maintainer: There may be cases where the author cannot leave a comment, or the comment is not properly detected as consent. In those cases, you can manually confirm consent of the commit author(s), and set the ℹ️ Googlers: Go here for more info. |
@googlebot I consent. |
CLAs look good, thanks! ℹ️ Googlers: Go here for more info. |
This PR fixes some missing edges in the lantern simulation graph where a network record won't depend on its
initiatorRequest
if there are multiple records for the initiator. In practice I think this mainly affects cases where a script is prefetched which in turn causes multiple records and prevents connections to its initiated requests.I fixed this by:
network-recorder.js
: make sure thatinitiatorRequest
points to the proper script request, not the prefetch record.page-dependency-graph.js
: fall back to the initiator request (when present) rather than the root node if the parent candidate is ambiguous.The main changes to lantern are:
In pubads audits we duct taped this issue with googleads/publisher-ads-lighthouse-plugin#174.