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

core(byte-efficiency): replace pessimistic graph with optimistic #15651

Merged
merged 8 commits into from
Dec 8, 2023
Merged
Show file tree
Hide file tree
Changes from 3 commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
23 changes: 17 additions & 6 deletions core/audits/byte-efficiency/byte-efficiency-audit.js
Original file line number Diff line number Diff line change
Expand Up @@ -308,29 +308,40 @@ class ByteEfficiencyAudit extends Audit {
if (metricComputationInput.gatherContext.gatherMode === 'navigation') {
const graph = await PageDependencyGraph.request(metricComputationInput, context);
const {
pessimisticGraph: pessimisticFCPGraph,
optimisticGraph: optimisticFCPGraph,
} = await LanternFirstContentfulPaint.request(metricComputationInput, context);
const {
pessimisticGraph: pessimisticLCPGraph,
optimisticGraph: optimisticLCPGraph,
} = await LanternLargestContentfulPaint.request(metricComputationInput, context);

wastedMs = this.computeWasteWithTTIGraph(results, graph, simulator, {
providedWastedBytesByUrl: result.wastedBytesByUrl,
});

const {savings: fcpSavings} = this.computeWasteWithGraph(
const {savings: fcpOptimisticSavings} = this.computeWasteWithGraph(
results,
pessimisticFCPGraph,
optimisticFCPGraph,
simulator,
{providedWastedBytesByUrl: result.wastedBytesByUrl, label: 'fcp'}
);
const {savings: lcpGraphSavings} = this.computeWasteWithGraph(
const {savings: lcpOptimisticGraphSavings} = this.computeWasteWithGraph(
results,
optimisticLCPGraph,
simulator,
{providedWastedBytesByUrl: result.wastedBytesByUrl, label: 'lcp'}
);

const {savings: lcpPessimisticGraphSavings} = this.computeWasteWithGraph(
results,
pessimisticLCPGraph,
simulator,
{providedWastedBytesByUrl: result.wastedBytesByUrl, label: 'lcp'}
);

// Use the min savings between the two graphs for LCP metricSavings.
const lcpMinGraphSavings = Math.min(lcpOptimisticGraphSavings, lcpPessimisticGraphSavings);
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thinking about this a little more. I think it was a mistake for our modus operandi to be "use the smallest estimate for savings possible". We should still use the optimistic graph because it is less noisy and focuses on the requests that definitely impacted LCP (at least in principle), but I don't think we need to add this arbitrary Math.min constraint just to get the lowest estimate. If a handful of edge cases have a higher savings estimate as a result that's fine with me but...

As I said in my previous comment, I think we should explore an LCP optimistic graph that is modeled on the LCP critical path which should further reduce the noise in our LCP savings estimate here. As an initial thought, the optimistic graph could include just the LCP resource and any render blocking requests.


// The LCP graph can underestimate the LCP savings if there is potential savings on the LCP record itself.
let lcpRecordSavings = 0;
const lcpRecord = await LCPImageRecord.request(metricComputationInput, context);
Expand All @@ -341,8 +352,8 @@ class ByteEfficiencyAudit extends Audit {
}
}

metricSavings.FCP = fcpSavings;
metricSavings.LCP = Math.max(lcpGraphSavings, lcpRecordSavings);
metricSavings.FCP = fcpOptimisticSavings;
adrianaixba marked this conversation as resolved.
Show resolved Hide resolved
metricSavings.LCP = Math.max(lcpMinGraphSavings, lcpRecordSavings);
} else {
wastedMs = simulator.computeWastedMsFromWastedBytes(wastedBytes);
}
Expand Down
10 changes: 5 additions & 5 deletions core/test/results/sample_v2.json
Original file line number Diff line number Diff line change
Expand Up @@ -4544,7 +4544,7 @@
"displayValue": "Potential savings of 64 KiB",
"metricSavings": {
"FCP": 0,
"LCP": 450
"LCP": 300
},
"details": {
"type": "opportunity",
Expand Down Expand Up @@ -4598,7 +4598,7 @@
"type": "debugdata",
"metricSavings": {
"FCP": 0,
"LCP": 450
"LCP": 300
}
}
},
Expand Down Expand Up @@ -4851,14 +4851,14 @@
"id": "efficient-animated-content",
"title": "Use video formats for animated content",
"description": "Large GIFs are inefficient for delivering animated content. Consider using MPEG4/WebM videos for animations and PNG/WebP for static images instead of GIF to save network bytes. [Learn more about efficient video formats](https://developer.chrome.com/docs/lighthouse/performance/efficient-animated-content/)",
"score": 0,
"score": 0.5,
"scoreDisplayMode": "metricSavings",
"numericValue": 3450,
"numericUnit": "millisecond",
"displayValue": "Potential savings of 666 KiB",
"metricSavings": {
"FCP": 0,
"LCP": 3300
"LCP": 0
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is a good change. Byte savings on the large gif are good, but it isn't the LCP resource so it's LCP impact is superficial.

},
"details": {
"type": "opportunity",
Expand Down Expand Up @@ -4895,7 +4895,7 @@
"type": "debugdata",
"metricSavings": {
"FCP": 0,
"LCP": 3300
"LCP": 0
}
}
},
Expand Down
Loading