perf(gatherers): skip optimization of cross origin images

[patrickhulce]

in the name of Operation Yaquina Bay #2146, fixes #1853

shaves about ~25 seconds off heavy sites like cnn.com

[ebidel]

It's too bad we're thinking about disabling this one. Images are the biggest source of bloat on the web and are often x-domain b/c of CDNs.

[patrickhulce]

@ebidel I definitely want to bring it back when we have a protocol method for doing the conversion instead of our current back and forth massive JSON serialization
LH -> getRequestBody -> DT
DT -> 📷 -> LH
LH -> evaluateScript(data: base64,📷 ) -> DT
DT -> bytes saved -> LH

[patrickhulce]

My gut also says that if you're doing the right thing and using a CDN, it's relatively unlikely you're sending a full bitmap down the wire, and we'll still be able to identify non-responsive cross-origin images, unused cross-origin images, etc.

My idea for a follow-up replacement would be to flag very large images beyond some KB / pixel threshold and only process those

[ebidel]

Ok. I think @brendankenny also mentioned it., but can you get a meta issue going that tracks all of these removals/disables so we can re-address after IO?

[brendankenny]

should this also have something in the description or in the results about unchecked images to make it clear this isn't the whole picture images-wise? Like a non-fatal version of how notifications/geolocation warn that they weren't able to check because a site is on http. It would be easy to conclude your images are all great because they weren't listed.

[patrickhulce]

should this also have something in the description or in the results about unchecked images to make it clear this isn't the whole picture images-wise? Like a non-fatal version of how notifications/geolocation warn that they weren't able to check because a site is on http. It would be easy to conclude your images are all great because they weren't listed.

That's a great point. Unfortunately, given that this about is about to be only displayed as the sparkline, it would be strange to show it empty just for the debug string, yet hiding it in the passed section feels like it'd never be seen either. Go with debug string and hope people expand that passed section?

[brendankenny]

Go with debug string and hope people expand that passed section?

will debugString be visible for sparklines by default? Having it that way would certainly be a good motivator to get the protocol support landed :)

[patrickhulce]

will debugString be visible for sparklines by default?

yes, but if the score is 100 it'll be shown in passed audits (not as a sparkline with the other byte efficiency audits)