TLDR: The emulation flags are awkward and there's implicit assumptions made. We should fix that and support our varied usecases with first-class settings. Key idea: get rid of emulatedFormFactor=none.
DevTools, Calibre, and WPT are three lighthouse clients that handle emulation previous to lighthouse running. In DevTools' case, only screen emulation is applied, and lighthouse is expected to apply its own network emulation. And calibre's case, both emulations are applied and the intent is for a lighthouse to not apply double emulation anywhere. LH on WPT supports a few approaches and everyone's been confused at some point.
We introduced the illustrious internalDisableDeviceScreenEmulation flag (#9377) to solve this. (However even with this, LH will still overwrite any previously set userAgentOverride). But if emulatedFormFactor (#6098) is none and external UA emulation is applied, you don't get correct scoring.
This is messy and I think that there's an opportunity to completely redefine this configuration to be more clear.
Goals
- no surprises wrt mobile or desktop scoring being used
- a more first-class config for this external-emulation setup
- continue to support the no-emulation-lh-is-running-against-a-real-phone scenario
Starting Proposal
- Rename
emulatedFormFactor to formFactor. This is the key flag and the value must be either mobile or desktop, none (née provided) is no longer a valid option. Our perf metrics and 3 SEO metrics change their behavior based on mobile v desktop, so it seems important to make this an explicit user contract.
- Add two more flags:
disableScreenEmulation and disableNetworkEmulation.
- Remove
internalDisableDeviceScreenEmulation. Throw if this or emulatedFormFactor are used.
- Internally, we drop the guessed
TestedAsMobileDevice bool and just use the formFactor enum of 'desktop'|'mobile'.
The combination of these allows us to support the below user stories with clear expectations. It also prevents the case of a using incorrect scoring accidentally.
User stories
I believe we have 4 user stories to support (right?)
- Typical LH (we apply emulation):
formFactor is set.
- DevTools:
formFactor is set via the mobile/desktop radio, and screenEmulation is false.
- Calibre and WPT:
formFactor is set, and both screenEmulation: false, throttlingMethod: 'provided'. emulatedUserAgent is set as desired.
- LH on mobile device:
--no-screenEmulation and --throttling.cpuSlowdownMultiplier=1. (--formFactor=mobile is the default already)
Extra thoughts and questions
References
TLDR: The emulation flags are awkward and there's implicit assumptions made. We should fix that and support our varied usecases with first-class settings. Key idea: get rid of
emulatedFormFactor=none.DevTools, Calibre, and WPT are three lighthouse clients that handle emulation previous to lighthouse running. In DevTools' case, only screen emulation is applied, and lighthouse is expected to apply its own network emulation. And calibre's case, both emulations are applied and the intent is for a lighthouse to not apply double emulation anywhere. LH on WPT supports a few approaches and everyone's been confused at some point.
We introduced the illustrious
internalDisableDeviceScreenEmulationflag (#9377) to solve this. (However even with this, LH will still overwrite any previously set userAgentOverride). But ifemulatedFormFactor(#6098) isnoneand external UA emulation is applied, you don't get correct scoring.This is messy and I think that there's an opportunity to completely redefine this configuration to be more clear.
Goals
Starting Proposal
emulatedFormFactortoformFactor. This is the key flag and the value must be eithermobileordesktop,none(néeprovided) is no longer a valid option. Our perf metrics and 3 SEO metrics change their behavior based on mobile v desktop, so it seems important to make this an explicit user contract.disableScreenEmulationanddisableNetworkEmulation.internalDisableDeviceScreenEmulation. Throw if this oremulatedFormFactorare used.TestedAsMobileDevicebool and just use theformFactorenum of'desktop'|'mobile'.The combination of these allows us to support the below user stories with clear expectations. It also prevents the case of a using incorrect scoring accidentally.
User stories
I believe we have 4 user stories to support (right?)
formFactoris set.formFactoris set via the mobile/desktop radio, andscreenEmulationis false.formFactoris set, and bothscreenEmulation: false, throttlingMethod: 'provided'.emulatedUserAgentis set as desired.--no-screenEmulationand--throttling.cpuSlowdownMultiplier=1. (--formFactor=mobileis the default already)Extra thoughts and questions
--formFactor=mobileor do we make it (annoyingly) required?emulated-form-factor=none. We could also detect a potential double-emulation scenario here and warn to make sure flags are correctly setup.References
disableDeviceEmulationflag before v5 #7044