core(lhr): expose environment info#5871
Conversation
brendankenny
left a comment
There was a problem hiding this comment.
nice! this seems like it'll be great to have to start being able to have a normalized view of lighthouse results
I like environment for the name. Maybe we should rename Util.getEnvironmentDisplayValues to get rid of the last references to the old environment stuff? Unless we want to include all the other values in there?
| } | ||
|
|
||
| export interface Environment { | ||
| hostUserAgent: string; |
There was a problem hiding this comment.
can you copy the above doc strings down for these too?
| if (userAgentEntry && !baseArtifacts.NetworkUserAgent) { | ||
| // @ts-ignore - guaranteed to exist by the find above | ||
| baseArtifacts.NetworkUserAgent = userAgentEntry.params.request.headers['User-Agent']; | ||
| } |
There was a problem hiding this comment.
could also do baseArtifacts.NetworkUserAgent = await driver.getUserAgent() after GatherRunner.setupDriver() is called. It's shorter, but is it better to just look at the actual network traffic?
There was a problem hiding this comment.
Given the number of ways that have popped up in issues as the way folks are trying to set the user agent string, I thought it was best to grab it directly from network records instead of assume it's done being manipulated after setupDriver
There was a problem hiding this comment.
SG. I guess HostUserAgent might end up weird too if people are overriding things
| * @see https://docs.google.com/spreadsheets/d/1E0gZwKsxegudkjJl8Fki_sOwHKpqgXwt8aBAfuUaB8A/edit?usp=sharing | ||
| * | ||
| * The benchmark creates a string of length 100,000 in a loop. | ||
| * The returned index is the number of numbers per second the string can be created. |
There was a problem hiding this comment.
number of times per second?
There was a problem hiding this comment.
heh, yep fixed :)
| * - <75 is a budget Android phone, Alcatel Ideal, Galaxy J2, etc | ||
| */ | ||
| /* istanbul ignore next */ | ||
| function ultradumbBenchmark() { |
There was a problem hiding this comment.
I know we just had a whole thing with page-functions, but I kind of wish this was in its own file for easier running :) I guess we can always add yarn ultradumbBenchmark later
| LighthouseRunWarnings: [], | ||
| UserAgent: await options.driver.getUserAgent(), | ||
| HostUserAgent: await options.driver.getUserAgent(), | ||
| NetworkUserAgent: '', // updated later |
There was a problem hiding this comment.
NetworkUserAgent doesn't seem self-obvious to me but I don't have a great suggestion for an alternative. Will brainstorm :)
There was a problem hiding this comment.
sg, I also tried RuntimeUserAgent but thought NetworkUserAgent was a bit more descriptive
There was a problem hiding this comment.
yeah. I still have nothings, so that's fine with me. If @paulirish has ideas we can do a follow up PR quickly before we ship it :)
| } | ||
|
|
||
| /** | ||
| * @return {Promise<number>} |
There was a problem hiding this comment.
will you add a simple docstring here?
| UserAgent: await options.driver.getUserAgent(), | ||
| HostUserAgent: await options.driver.getUserAgent(), | ||
| NetworkUserAgent: '', // updated later | ||
| BenchmarkIndex: await options.driver.getBenchmarkIndex(), |
There was a problem hiding this comment.
do we want to run the benchmark in the target page (vs about:blank or whatever we end up on)? Seems like what's going on in the page could affect the results
There was a problem hiding this comment.
yeah I think we'll want to experiment with when this gets evaluated, for example at the moment in CLI case I think it's being affected by being run while Chrome is still being setup. The values I'm seeing are noticably lower than when I run it after page load.
There was a problem hiding this comment.
good call moving it just after load blank which does the 300 ms waiting already much improves the estimate 👍
There was a problem hiding this comment.
good call moving it just after load blank which does the 300 ms waiting already much improves the estimate 👍
ha, I was going to come back later and say maybe it doesn't make a difference and isn't worth it, so good to hear :)
I guess it's possible it'll cause more issues with moving off using about:blank in the future, but that's a problem for another day :)
| assert.equal(results.UserAgent, 'Fake user agent', 'did not find expected user agent string'); | ||
| }); | ||
| const results = await GatherRunner.run([], options); | ||
| expect(Number.isFinite(results.BenchmarkIndex)).toBeTruthy(); |
There was a problem hiding this comment.
I feel like you must be trolling here...
|
|
||
| const ultradumbBenchmark = require('../lib/page-functions').ultradumbBenchmark; | ||
|
|
||
| console.log('Running ULTRADUMB™ benchmark 10 times...') |
There was a problem hiding this comment.
lint says you need a ; :)
|
@paulirish will probably want your eyes on these names to do another pass before we actually ship, ship this :) |

Summary
Before we can start automatically adjusting throttling settings, we need to be collecting and detecting more environment information. This PR adds a
environmentproperty (proposed name) to the LHR that will contain the host machine information, detected device class, perhaps more network diagnostic information, etc.Right now it has 3 properties
hostUserAgent- This is just a copy of the lhr.userAgent property for now (assumed we can deprecate and remove in v4), the User Agent of the version of Chrome that Lighthouse is using.networkUserAgent- This is the user agent that was sent over the network to the site. It's been frequently requested and confused with thehostUserAgentso makes sense to provide both.benchmarkIndex- This is the ULTRADUMB™ benchmark value that will eventually be used to autoset throttling if it proves to be stable and reliable enough in our field testing (anecdotally it's already been much more volatile in the runs I've tried than it was on a refreshed Chrome page :/ we might need to have longer timespans and persist the value to user storage somewhere).I've also added this information to the Runtime Settings section of the report.

Related Issues/PRs
closes #5665