Cannot run lighthouse-ci on https site without http

[peller]

I came home from #ChromeDevSummit looking forward to trying lighthouse-ci and hit a blocker.
Lighthouse apparently has an audit which fails with ERR_EMPTY_RESPONSE and exits, making it very difficult for us to run lighthouse-ci in our environment (which seems like a fairly typical react development environment). This is a known issue going back to 2016: GoogleChrome/lighthouse#1217

webpack-dev-server stubbornly refuses to serve http content, only https. This doesn't seem like a very unusual situation. Any advice on workarounds, without setting up additional proxy servers?

[connorjclark]

Can you try running LHCI against a more production-like environment? I don't think webpack-dev-server is a good substitute - it has lots of bells and whistles that you don't want when Lighthouse looks at the page (like hot code reloading). If you just need a static server, you can use the server built-in to Lighthouse CI with the --staticDistDir flag.

[peller]

@connorjclark for better or worse, it's the development environment used by all of our teams. If lighthouse-ci can't accommodate this we're probably not going to use it any time soon, sadly. I'm sure we'd get more accurate measurements in prod, but I would hope the relative measurements would still be a useful metric.

[patrickhulce]

@peller you don't need to be running against a production environment, but @connorjclark is right that webpack-dev-server isn't ideal for running performance tests. Is there a reason you can't build your assets with webpack and use the server built-in to Lighthouse CI by passing the --staticDistDir=./your-output-folder flag?

If there's something extra you need like proxying API requests from the built-in server to a different backend, we'd be interested to hear what the requirements would be to see if we can add first-class support for them.

[patrickhulce]

Does this alternative approach work for your use case @peller? A fix for the root cause is in the works in lighthouse-core, but you'll likely get much more comparable results with staticDistDir over webpack-dev-server if it's an option for you.

[peller]

@patrickhulce @connorjclark thank you for your advice, a simple server does sound like the right way to go. Just some feedback that it was frustrating figuring this out, and it's probably a common situation to be in (https w/o http). Did you really just make a PR for that old bug? Thank you again!

[patrickhulce]

Yep thanks for filing that feedback! Since the only outstanding issue is already tracked upstream and a PR in progress, I'm going to go ahead and close this one, but feel free to reopen if there's new information you'd like to add to be fixed here.

[peller]

hrm. http-server doesn't support http/https either. bummer. http-party/http-server#548 . Looking forward to that PR!

[patrickhulce]

I'm curious @peller is there a particular reason you need https supported in this environment? localhost is treated as a secure origin for web APIs requiring security and the audits that would fail without https in Lighthouse all have their assertions disabled in the recommended assertion presets.

[peller]

@patrickhulce I'm curious, too. Haven't had a chance to dig into this, but our app does not run out of the box on http. Given that https is the default nowadays, I wonder if this isn't uncommon.

[patrickhulce]

Running https on localhost is still fairly uncommon in my experience even if https is the default for any internet-based serving. https on localhost usually runs into certificate issues that can be annoying to solve yourself.

preact-cli is the only major framework CLI I'm aware of that actively encourages https development.

[peller]

Among other things, I think we would have mixed protocol warnings/errors if running as http, but there's obviously more to it I haven't investigated yet.

Well, just giving you our pain points. Resolving the above PR would go a long way, but lacking that, some entries about this in a FAQ might have saved us some pain. The error message wasn't that obvious.