-
Notifications
You must be signed in to change notification settings - Fork 4
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
How should Chrome Headless arguments be passed? #1
Labels
question
Further information is requested
Comments
tollmanz
changed the title
How should Chrome Headless arguments
How should Chrome Headless arguments be passed?
Mar 25, 2018
The current interface's days are numbered. Really starting to hate typing this out:
|
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Context
The goal of this project is to provide a simple CLI for generating performance timelines. At a minimum, it should provide the same options that the Chrome DevTools interface provides; however, we should aim to make this project more powerful by exposing additional options. These options can be passed to Puppeteer or the Chrome Headless client for extending the capabilities of the tool.
For example, the Chrome DevTools UI allows you to select different CPU throttling rates:
In Perf Timeline, I want to do the same; however, I'm conflicted about how this should be done. As of the initial commit, I use the following args to configure a CPU slow down of
4x
:I use these exact terms to mirror the names used by Chrome Headless. My intent was to keep the same interface that you might use if you were coding this yourself. These values would then be used like this (not actual code, but shows how to access Chrome Headless directly):
The Problem
Currently, I allow direct access to Chrome Headless for CPU throttling and network emulation. These are only two categories of config. I am concerned that it may be an unnecessary burden on the CLI to provide args for the plethora of Chrome Headless args. I don't want to be in a place where this project dictates which args are acceptable and unacceptable.
Possible Solution
I'm thinking of changing the interface to allow for two things:
--chrome-commands
option that is parsed and passed to Chrome HeadlessRegarding 1, I'd expose named configs that map to sets of Chrome Headless args. Something like:
Note that to currently emulate a Lighthouse run, you need to do:
Of course, with this added convenience comes the loss of control. To ensure that those who wish to control everything, I'd expose a more advanced option to further config Chrome Headless.
For 2, I would give the ability to do something like this:
I'm not entirely sure that this would be the final form of the argument, but you should get the idea.
Questions
The text was updated successfully, but these errors were encountered: