Add support for Chromium Edge

[pedro93]

Hey guys,

Just found this really interesting project that gives the Chrome Debugging Protocol access to information on the Edge browser https://github.com/Microsoft/edge-diagnostics-adapter. I was wondering, could this be used to make lighthouse run audits on Edge?

How much of the Chrome debugging protocol does Lighthouse use for the (for example) performance audits?

It would be great to know what other browsers would have to implement at the debugging protocol level to permit true cross-browser auditing tools.

Is cross-browser support in the roadmap? What would it take to make it happen?

---

see also "Support for iOS" #1447

[paulirish]

Yeah it's something we've discussed a bit.

There are a few projects around that bridge compatibility for other browsers to the devtools protocol: https://github.com/ChromeDevTools/awesome-chrome-devtools#browser-adapters
And https://compatibility.remotedebug.org/ lists out what's supported in various implementations.

Here's a look at what protocol methods we're currently using, sorted by popularity:

FWIW, here's how to get that list:

gulp --cwd lighthouse-extension clean
ag "sendCommand\('(.*?)'" -o | grep -E  -o  "'.*?'" | sort | uniq -c |  sort -nr

There's a LOT of stuff we do that isn't available in Edge's adapter, but..

I've looked through our driver and gatherers to audit what's currently implemented in the Edge adapter. The most obvious is "Runtime.evaluate", however we rely on asynchronous evaluation pretty often, which isn't supported by the adapter. With some work, it's possible for the accessibility and the image optimization audits to work in Edge. None of our other gatherers seem to have enough protocol support to work.

On the perf side: The Edge diagnostics adapter doesn't offer any mobile emulation or network throttling. The lighthouse perf metrics won't be calculable without access to their trace format (AFAIK this isn't exposed to any API right now.)

---

In general, we think Lighthouse provides maximum benefit when it gives specific and actionable advice regarding non-obvious issues. We do prioritize advice that is applicable to all browsers. While I hope to see these protocol adapters improve their scope, the feature-set they currently could enable for a cross-browser Lighthouse would be fairly basic. So for the moment, I think the engineering investment on our side wouldn't pay off big for our users. But as the protocol-adapter projects mature, this will be an increasingly attractive target.

[pedro93]

Thank you for the thorough and extensive reply, it's great to hear that this idea is present and has been thought about.

From my own understanding of the audits and how they are done in LH, most should report the same regardless of the browser used to run the audits on.

Accessibility, use of PWA technologies and general best practices should apply equally to all browsers (there is are web standards for a reason).

The most to be gained from cross-browser audits are in audits with non-discrete outputs, e.g: performance, rendering timings, perceived speed, etc.
In these audits simulation is not even strictly necessary (though nice if a dev lacks a user's representative device) right?

What needs to be available is the debugging protocols methods that supply the needed network & rendering timings from a browser, whether that's desktop or mobile. I mean that's how we can use lighthouse to test on real devices no? If a dev has an iPhone, connect via usb and lighthouse retrieves timings from safari, if it's a windows phone from I.E./Edge or Android from Chrome, as we can currently do.

If what I'm saying is correct (please correct me if not), wouldn't other browsers have to support a subset of the protocol methods currently used by lighthouse for the most benefit?

[auchenberg]

The RemoteDebug initiative lists the currently known adapters for the Chrome DevTools protocol, http://remotedebug.org/adaptors/

[paulirish]

Edge is now supported. :) See webhintio/hint#2264

Non chromium browsers are unlikely soon, but Firefox is doing some exciting things with their protocol. 😎

[connorjclark]

waiting on upstream to chrome-launcher webhintio/hint#2260 (comment) then we can call this closed.

[brendankenny]

@paulirish and @connorjclark aren't these chrome-launcher comments? Not sure they're closely related to the original request of using Lighthouse to control other debugger (or similar) protocol clients

[paulirish]

Edge Chromium is supported via the CHROME_PATH. chrome-launcher could also get more firstclass support for Edge but hasn't yet.

[paulirish]

While other browsers support a subset of the protocol, we don't see much user value in enabling Lighthouse to run against them. (The performance category would definitely not work, etc)

[kawadhiya21]

How to run on Edge 81 using lighthouse-cli ? I could only run it on Chrome.

[patrickhulce]

@kawadhiya21 set CHROME_PATH to your path to Edge instead of Chrome

e.g.

CHROME_PATH="/Applications/Microsoft Edge.app/Contents/MacOS/Microsoft Edge" lighthouse https://example.com

[kawadhiya21]

Thanks. It worked !

[ankityadav4]

I tried the below

1. lighthouse https://example.com/ --output json --output-path C:\0506.json --disable-device-emulation --chrome-flags
   "CHROME_PATH='C:\Program Files (x86)\Microsoft\Edge\Application\msedge.exe'"
2. lighthouse https://example.com/ --output json --output-path C:\0506.json --disable-device-emulation --chrome-flags="CHROME_PATH='C:\Program Files (x86)\Microsoft\Edge\Application\msedge.exe'"
3. First setting CHROME_PATH="C:\Program Files (x86)\Microsoft\Edge\Application\msedge.exe"
   then -> lighthouse https://example.com/ --output json --output-path C:\0506.json --disable-device-emulation

What is it that I am doing wrong ?

[adamraine]

@ankityadav4 try this for windows

set CHROME_PATH="C:\Program Files (x86)\Microsoft\Edge\Application\msedge.exe"
lighthouse https://example.com/ --output json --output-path C:\0506.json --disable-device-emulation