"Properly size images" providing incorrect current sizes

[philkrie]

Provide the steps to reproduce

1. Run LH on https://www.musiciansfriend.com/?mobile=yes. Simulated Slow 4G and Applied Slow 4G get the same result.

What is the current behavior?

LH shows images as having higher weight than reported in the Network tab.

As seen below, https://static.musiciansfriend.com/thehub/binaries/content/gallery/mf/behind-the-gear/kauer-guitars-shop.jpg?imwidth=300 is reported to have a size of 198 KB.

The network tab shows that it has a size of 26.6 KB

What is the expected behavior?

These numbers should line up, since clients are more likely to view the Network tab as the source of truth. This degrades trust in the test.

Environment Information

• DevTools
• Lighthouse version: 5.2.0
• Operating System: MacOS 10.14.6
• Chrome Version 77.0.3865.90 (Official Build) (64-bit)

[patrickhulce]

Thanks for filing @philkrie! That server responds differently to this image request depending on the User-Agent. When requested by Lighthouse's UA (A Nexus 5X Android phone with a Chrome-Lighthouse suffix), the file returned is a WebP image that's ~198KB and larger resolution than necessary.

curl -vvvv https://static.musiciansfriend.com/thehub/binaries/content/gallery/mf/behind-the-gear/kauer-guitars-shop.jpg\?imwidth\=300 -H "User-Agent: Mozilla/5.0 (Linux; Android 6.0.1; Nexus 5 Build/MRA58N) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/74.0.3694.0 Mobile Safari/537.36 Chrome-Lighthouse" > /dev/null

* SSL connection using TLSv1.2 / ECDHE-RSA-AES256-GCM-SHA384
* ALPN, server accepted to use h2
* Server certificate:
*  subject: C=US; ST=California; L=Westlake Village; O=Guitar Center, Inc.; OU=IT; CN=*.musiciansfriend.com
*  start date: Aug 19 00:00:00 2019 GMT
*  expire date: Sep 17 12:00:00 2020 GMT
*  subjectAltName: host "static.musiciansfriend.com" matched cert's "*.musiciansfriend.com"
*  issuer: C=US; O=DigiCert Inc; CN=DigiCert SHA2 Secure Server CA
*  SSL certificate verify ok.
* Using HTTP2, server supports multi-use
* Connection state changed (HTTP/2 confirmed)
* Copying HTTP/2 data in stream buffer to connection buffer after upgrade: len=0
* Using Stream ID: 1 (easy handle 0x7fcea9806600)
> GET /thehub/binaries/content/gallery/mf/behind-the-gear/kauer-guitars-shop.jpg?imwidth=300 HTTP/2
> Host: static.musiciansfriend.com
> Accept: */*
> User-Agent: Mozilla/5.0 (Linux; Android 6.0.1; Nexus 5 Build/MRA58N) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/74.0.3694.0 Mobile Safari/537.36 Chrome-Lighthouse
>
* Connection state changed (MAX_CONCURRENT_STREAMS updated)!
< HTTP/2 200
< access-control-allow-origin: http://static.musiciansfriend.com
< last-modified: Thu, 19 Sep 2019 14:58:03 GMT
< access-control-allow-headers: Cookie
< access-control-expose-headers: Location
< etag: "1533068665666"
< access-control-allow-credentials: true
< x-im-result-width: 1024
< server: Akamai Image Manager
< content-length: 202724
< content-type: image/webp
< cache-control: private, no-transform, max-age=708134
< expires: Wed, 02 Oct 2019 02:49:56 GMT
< date: Mon, 23 Sep 2019 22:07:42 GMT
<
{ [716 bytes data]
100  197k  100  197k    0     0  2242k      0 --:--:-- --:--:-- --:--:-- 2249k

[philkrie]

@patrickhulce thanks for the quick response!

When you run a LH test, is this the reason for why the page appears to load multiple times? Basically once with the LH UA and once the Chrome UA.

When preserving the network log, I'm not able to get this WebP image to appear in the Network tab, so it looks like the Network tab doesn't measure requests made by LH. Is there way to capture this, or for LH to use the same user agent as the browser?

Otherwise I'm assuming the only resolution here is to ensure that the server serves the same resources to the LH UA as it does to a Chrome mobile UA.

[connorjclark]

I'm not able to get this WebP image to appear in the Network tab, so it looks like the Network tab doesn't measure requests made by LH

Canary Chrome will now.

[philkrie]

Got it, is LH going to run in the same context as the rest of DevTools from now on, or just certain parts? I noticed in canary LH will also reflect blocked requests.

[connorjclark]

We only override the network throttling / device screen emulation (the options in the Audits panel). Everything else sticks.

[patrickhulce]

@connorjclark pretty much covered it 👍

To circle back to

When you run a LH test, is this the reason for why the page appears to load multiple times? Basically once with the LH UA and once the Chrome UA.

No, we only load with the LH UA when loading as mobile but there are multiple passes for

• Normal
• Offline
• Hitting http instead of https and javascript disabled

[philkrie]

Great, thanks for the explanations!

One final question related to this: Is there a specific technical reason why LH needs its own UA? Would it not be possible to render the page using the regular Chrome UA?

[patrickhulce]

Is there a specific technical reason why LH needs its own UA? Would it not be possible to render the page using the regular Chrome UA?

Technical reason, no. Policy reason, yes. Folks want to know where automated traffic is coming from. FWIW, the UA is identical to a Nexus 5X with the only modification being Chrome-Lighthouse appended to the end. All but the most fragile of regexes should still treat it as a real Chrome UA.

[brendankenny]

Looks like this issue was addressed. If not, please comment and we can reopen.