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(lhr): expose environment info #5871

Merged
merged 4 commits into from
Aug 23, 2018
Merged

core(lhr): expose environment info #5871

merged 4 commits into from
Aug 23, 2018

Conversation

patrickhulce
Copy link
Collaborator

@patrickhulce patrickhulce commented Aug 20, 2018

Summary
Before we can start automatically adjusting throttling settings, we need to be collecting and detecting more environment information. This PR adds a environment property (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 the hostUserAgent so 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.
image

Related Issues/PRs
closes #5665

Copy link
Member

@brendankenny brendankenny left a comment

Choose a reason for hiding this comment

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

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?

typings/lhr.d.ts Outdated
@@ -16,6 +16,12 @@ declare global {
[varName: string]: string;
}

export interface Environment {
hostUserAgent: string;
Copy link
Member

Choose a reason for hiding this comment

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

can you copy the above doc strings down for these too?

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

done

if (userAgentEntry && !baseArtifacts.NetworkUserAgent) {
// @ts-ignore - guaranteed to exist by the find above
baseArtifacts.NetworkUserAgent = userAgentEntry.params.request.headers['User-Agent'];
}
Copy link
Member

Choose a reason for hiding this comment

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

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?

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

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

Copy link
Member

Choose a reason for hiding this comment

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

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.
Copy link
Member

Choose a reason for hiding this comment

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

number of times per second?

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

heh, yep fixed :)

* - <75 is a budget Android phone, Alcatel Ideal, Galaxy J2, etc
*/
/* istanbul ignore next */
function ultradumbBenchmark() {
Copy link
Member

Choose a reason for hiding this comment

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

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

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

done :)
image

@@ -374,7 +374,9 @@ class GatherRunner {
return {
fetchTime: (new Date()).toJSON(),
LighthouseRunWarnings: [],
UserAgent: await options.driver.getUserAgent(),
HostUserAgent: await options.driver.getUserAgent(),
NetworkUserAgent: '', // updated later
Copy link
Member

Choose a reason for hiding this comment

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

NetworkUserAgent doesn't seem self-obvious to me but I don't have a great suggestion for an alternative. Will brainstorm :)

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

sg, I also tried RuntimeUserAgent but thought NetworkUserAgent was a bit more descriptive

Copy link
Member

Choose a reason for hiding this comment

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

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 :)

@@ -107,6 +107,13 @@ class Driver {
return this.evaluateAsync('navigator.userAgent');
}

/**
* @return {Promise<number>}
Copy link
Member

Choose a reason for hiding this comment

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

will you add a simple docstring here?

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

yep, done

UserAgent: await options.driver.getUserAgent(),
HostUserAgent: await options.driver.getUserAgent(),
NetworkUserAgent: '', // updated later
BenchmarkIndex: await options.driver.getBenchmarkIndex(),
Copy link
Member

Choose a reason for hiding this comment

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

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

Copy link
Collaborator Author

@patrickhulce patrickhulce Aug 22, 2018

Choose a reason for hiding this comment

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

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.

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

good call moving it just after load blank which does the 300 ms waiting already much improves the estimate 👍

Copy link
Member

Choose a reason for hiding this comment

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

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();
Copy link
Member

Choose a reason for hiding this comment

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

I feel like you must be trolling here...

Copy link
Member

@brendankenny brendankenny left a comment

Choose a reason for hiding this comment

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

LGTM!


const ultradumbBenchmark = require('../lib/page-functions').ultradumbBenchmark;

console.log('Running ULTRADUMB™ benchmark 10 times...')
Copy link
Member

Choose a reason for hiding this comment

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

lint says you need a ; :)

@patrickhulce
Copy link
Collaborator Author

@paulirish will probably want your eyes on these names to do another pass before we actually ship, ship this :)

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

Successfully merging this pull request may close these issues.

Expose both user agents in "Runtime settings"
2 participants