Allow specifying the viewport dimensions when running benchmark-web-vitals

[westonruter]

The benchmark-web-vitals command has only been testing a desktop-ish sized viewport at 960x700. In order to test a mobile viewport or a more common desktop viewport, this PR introduces a --window-viewport (-w) parameter which allows the desired window dimensions to be supplied like 360x800. The default remains 960x700.

[felixarntz]

@westonruter Awesome, I can't believe we didn't have something like this before - so were always only testing with this "small desktop"-ish viewport?! Wow.

One recommendation for enabling simpler usage rather than having to specify specific widths, but otherwise this is good.

[felixarntz]

It makes sense to have this parameter, but I wonder whether we should additionally have more than just this one default, to simplify usage.

I'm thinking about our typical mobile vs desktop differentiation. Maybe we could allow passing special string values mobile and desktop for the --window-viewport argument, and in that case rely on a specific default for that viewport type that we set?

I wonder what PageSpeed Insights uses, maybe we could align with that?

[westonruter]

Good idea. That did cross my mind, but I didn't implement it. I picked the 360x800 and 1920x1080 since they are the most common mobile and desktop dimensions currently. In 1f3b1c5 I've implemented the mobile and desktop aliases, and I've set their default values to correspond to what Lighthouse uses.

[westonruter]

Something else to consider, beyond adding support for deviceScaleFactor would be whether a mobile user agent should be sent when requesting with mobile viewport dimensions, and whether the same should be done for desktop. WP Rocket, for example, has different caches for mobile and desktop user agents, with device-specific optimizations applied. For non-responsive sites, it's common to send back entirely different HTML for desktop and mobile. So if we don't (eventually) also support full emulation then we won't get the expected results back.

[westonruter]

Thinking about this some more, I think we should also have a --emulate-device (-e) option which allows you to pass a predefined device name which would then populate the viewportWindow. This would supply the deviceScaleFactor and set the user agent and all that. We can still also provide a --window-viewport argument to override the specific dimensions, or if we don't want to emulate anything.

[felixarntz]

Thanks @westonruter, LGTM!

[felixarntz]

@westonruter Those ideas sound good to me, we could explore them in separate PRs. Though this could also wait until we find an actual use-case that would require us to support those.

[westonruter]

As it stands right now, specifying -w mobile won't necessarily result in what is expected since the pixel density won't be right and the user agent won't be sent as a mobile device, so I think it's important to support to get accurate results.

[westonruter]

Follow up: #166