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

misc: puppeteer script to test a page from devtools #12145

Merged
merged 27 commits into from
Apr 13, 2021

Conversation

adamraine
Copy link
Member

@adamraine adamraine commented Feb 26, 2021

Add a new puppeteer script to run LH from DT inspector. This script is better than the old web test one for a few reasons:

  • Significantly faster
  • Significantly less hacky (although still a little hacky)
  • Doesn't create any temporary files
  • Runs on linux, so we can run it in GCP

Still TODO:

  • Run on a list of URLs.
  • Output file(s).

Old script:
#11539
#11751

@google-cla google-cla bot added the cla: yes label Feb 26, 2021
@adamraine adamraine marked this pull request as ready for review February 26, 2021 22:42
@adamraine adamraine requested a review from a team as a code owner February 26, 2021 22:42
@adamraine adamraine requested review from patrickhulce and removed request for a team February 26, 2021 22:42
Copy link

@chrystianrgs chrystianrgs left a comment

Choose a reason for hiding this comment

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

test>next<import @devtools-bot

Copy link
Collaborator

@patrickhulce patrickhulce left a comment

Choose a reason for hiding this comment

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

very clever, I like it! :D

const page = await browser.newPage();

// Cut off JS for initial page navigation.
// This step is unnecessary for every page I tried except https://cnn.com.
Copy link
Collaborator

Choose a reason for hiding this comment

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

What happens when you allow JS? This is rather surprising to me.

Copy link
Member Author

Choose a reason for hiding this comment

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

LH never starts because cnn takes too long to load. I believe the page's scripts are hogging the main thread so much that startLighthouse never runs successfully.

Every other page I tested didn't need this step, but disabling JS still decreased the startup time for those pages.

Copy link
Collaborator

Choose a reason for hiding this comment

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

Yikes. I don't love doing this because if we can't run Lighthouse because a page is so busy, it might be indicative of our users not being able to run Lighthouse because a page is too busy.

Finding the "Lighthouse doesn't work in scenario X" is actually the point of creating a DevTools repro script, so perhaps we've already found our first bug :)

Copy link
Member Author

Choose a reason for hiding this comment

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

Good point, I took another look and it turns out I was overthinking the problem. The script just blocks on await page.goto(...) and never gets to the part where it tries to start LH.

Instead of disabling javascript to get the page to load faster, I just took out the await on page.goto(...).

Copy link
Member Author

Choose a reason for hiding this comment

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

Update: Trying to start LH immediately after navigation starts sometimes causes DT to hang on "Lighthouse is warming up..." forever.

Changed this to wait for DOMContentLoaded before trying to start LH.

lighthouse-core/scripts/pptr-run-devtools.js Outdated Show resolved Hide resolved
lighthouse-core/scripts/pptr-run-devtools.js Outdated Show resolved Hide resolved

fs.writeFileSync('latest-run/lhr.json', remoteLhrResponse.result.value);

await session.send('Runtime.disable');
Copy link
Collaborator

Choose a reason for hiding this comment

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

does this have a particular effect you noticed? fine to leave in, I just wouldn't expect it to do anything if we're shutting down the entire browser immediately after :)

Copy link
Member Author

Choose a reason for hiding this comment

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

No effect that I noticed.

FWIW I plan to update this script to test multiple urls. Script would open a new page for each test and close the page after, but browser remains open the entire time. Do you think this line would have an effect then?

Copy link
Collaborator

Choose a reason for hiding this comment

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

If you're still closing the page I wouldn't expect it to have an effect. I suppose it's slightly more plausible there's some memory leak in Chromium browser process no one has discovered before, but still seems unlikely to affect us.

package.json Show resolved Hide resolved
lighthouse-core/scripts/pptr-run-devtools.js Show resolved Hide resolved
const pageSession = await page.target().createCDPSession();
await pageSession.send('Page.enable');
pageSession.once('Page.domContentEventFired', resolve);
page.goto(process.argv[2]).catch(err => err);
Copy link
Collaborator

Choose a reason for hiding this comment

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

Can you process args at the top of the file, and leave a comment (like in the other file) on how to run this?

Copy link
Member Author

Choose a reason for hiding this comment

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

Added usage comment, wound up removing the usage of cli args in favor of stdin.

@brendankenny
Copy link
Member

It might be a bit annoying to hook this up to an existing Chrome session with remote debugging enabled. Could we add an extra parameter to this script to launch Chrome with a specific DT inspector build?

Yeah, that seems workable. We can think about it at some point.


const startLighthouse = `
(() => {
UI.ViewManager.instance().showView('lighthouse');
Copy link
Member

Choose a reason for hiding this comment

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

is this working for you locally still? When I run it it seems like this line isn't succeeding (it's stuck on the elements panel)

Copy link
Member Author

Choose a reason for hiding this comment

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

It's working fine for me on the latest Canary, but I was having issues earlier with a custom DT frontend.

Can you try opening DT on DT and running this line manually?

Copy link
Member Author

Choose a reason for hiding this comment

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

Copy link
Collaborator

Choose a reason for hiding this comment

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

Can you do const ViewManager = UI.ViewManager.ViewManager || UI.ViewManager; ... so it works in stable and canary?

Copy link
Member Author

Choose a reason for hiding this comment

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

Update: The issue here was that CHROME_PATH wasn't set, so puppeteer defaulted to M78 which uses the "Audits" panel instead of the "Lighthouse" panel.

Copy link
Collaborator

Choose a reason for hiding this comment

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

I've upgraded our puppeteer dep: #12284

Copy link
Collaborator

@patrickhulce patrickhulce left a comment

Choose a reason for hiding this comment

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

bulk of this seems as good as I remember! :)

.option('o', {
type: 'string',
default: 'latest-run/devtools-lhrs',
}).alias('o', 'output-dir')
Copy link
Collaborator

Choose a reason for hiding this comment

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

not a big deal, but I find it to be more readable for non-authors when the option is the typical JS camelCase version and the alias is the letter. You still get the same support for -o, --output-dir and --outputDir but it's much clearer in the JS when you use argv.outputDir and it matches the explicit option :)

Copy link
Member Author

Choose a reason for hiding this comment

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

I'm a little conflicted here.

I think you're right that the readability is better, but I would also prefer to keep --custom-devtools-frontend in kebab case because it matches the corresponding flag used on the chrome instance. It's probably better to keep the case for these two flags the same.

I think I will leave this as as for now.

Copy link
Collaborator

Choose a reason for hiding this comment

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

that's fine. fwiw I'd still take argv['custom-devtools-frontend'] over argv.d 😉

lighthouse-core/scripts/pptr-run-devtools.js Outdated Show resolved Hide resolved
lighthouse-core/scripts/pptr-run-devtools.js Outdated Show resolved Hide resolved
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants