misc: puppeteer script to test a page from devtools - #12145
Conversation
patrickhulce
left a comment
There was a problem hiding this comment.
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. |
There was a problem hiding this comment.
What happens when you allow JS? This is rather surprising to me.
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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 :)
There was a problem hiding this comment.
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(...).
There was a problem hiding this comment.
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.
|
|
||
| fs.writeFileSync('latest-run/lhr.json', remoteLhrResponse.result.value); | ||
|
|
||
| await session.send('Runtime.disable'); |
There was a problem hiding this comment.
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 :)
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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.
| const pageSession = await page.target().createCDPSession(); | ||
| await pageSession.send('Page.enable'); | ||
| pageSession.once('Page.domContentEventFired', resolve); | ||
| page.goto(process.argv[2]).catch(err => err); |
There was a problem hiding this comment.
Can you process args at the top of the file, and leave a comment (like in the other file) on how to run this?
There was a problem hiding this comment.
Added usage comment, wound up removing the usage of cli args in favor of stdin.
Yeah, that seems workable. We can think about it at some point. |
|
|
||
| const startLighthouse = ` | ||
| (() => { | ||
| UI.ViewManager.instance().showView('lighthouse'); |
There was a problem hiding this comment.
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)
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
There was a problem hiding this comment.
Can you do const ViewManager = UI.ViewManager.ViewManager || UI.ViewManager; ... so it works in stable and canary?
There was a problem hiding this comment.
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.
patrickhulce
left a comment
There was a problem hiding this comment.
bulk of this seems as good as I remember! :)
| .option('o', { | ||
| type: 'string', | ||
| default: 'latest-run/devtools-lhrs', | ||
| }).alias('o', 'output-dir') |
There was a problem hiding this comment.
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 :)
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
that's fine. fwiw I'd still take argv['custom-devtools-frontend'] over argv.d 😉
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:
Still TODO:
Old script:
#11539
#11751