LCP Reults are Higher After Optimizing Images

[Tony_Perez]

Hi

Hoping some can help me understand what is happening under the hood with the WebPageTest calculations.

We’ve been playing with image optimization, and we’ve been able to successfully compress images. What’s really weird is that although the images are smaller, and taking less time to load, LCP has increased by 5x.

It’s completely illogical to us.

For context:

without optimization:

$ curl -s -o /dev/null -w “DNS Lookup: %{time_namelookup}sec\nTime to connect: %{time_connect} sec\nTime to first byte: %{time_starttransfer} sec\nTotal time: %{time_total} sec\n” https://theasty.com/wp-content/uploads/2018/02/thea-about-1.png
DNS Lookup: 0.001500sec
Time to connect: 0.028732 sec
Time to first byte: 0.132248 sec
Total time: 0.568572 sec

with optimization:

curl -s -o /dev/null -w “DNS Lookup: %{time_namelookup}sec\nTime to connect: %{time_connect} sec\nTime to first byte: %{time_starttransfer} sec\nTotal time: %{time_total} sec\n” https://theasty.com/wp-content/uploads/2018/02/thea-about-1.png
DNS Lookup: 0.001706sec
Time to connect: 0.013170 sec
Time to first byte: 0.075395 sec
Total time: 0.234043 sec

Another example:

without optimization:

$ curl -s -o /dev/null -w “DNS Lookup: %{time_namelookup}sec\nTime to connect: %{time_connect} sec\nTime to first byte: %{time_starttransfer} sec\nTotal time: %{time_total} sec\n” https://theasty.com/wp-content/uploads/2017/05/20170507_THEA_VANCOUVER-0096.jpg
DNS Lookup: 0.001674sec
Time to connect: 0.017756 sec
Time to first byte: 0.089407 sec
Total time: 0.396868 sec

with optimization:

$ curl -s -o /dev/null -w “DNS Lookup: %{time_namelookup}sec\nTime to connect: %{time_connect} sec\nTime to first byte: %{time_starttransfer} sec\nTotal time: %{time_total} sec\n” https://theasty.com/wp-content/uploads/2017/05/20170507_THEA_VANCOUVER-0096.jpg
DNS Lookup: 0.001677sec
Time to connect: 0.020291 sec
Time to first byte: 0.110304 sec
Total time: 0.249644 sec

Here is the performance without optimization:

WebPageTest

Here is the performance with optimization:

WebPageTest

We’ve been going nuts the past 48 hours trying to understand this, and we’ve succumbed to the need to ping you guys here.

Any insights, or thoughts, on what we’re not thinking of, or what we’re missing, would be soooooo much appreciated.

Thanks in advance for any help.

Tony

[tkadlec]

Well…that certainly doesn’t sound optimal.

The two test URL’s you provided are identical (and I’m not sure which result this is…before optimization or after). Can you re-paste the test URLs? Happy to have a look.

[Tony_Perez]

Hi Tim

That’d be really helpful.

Ok, had to rerun the tests. You can see it here:

1 - no optimization:

WebPageTest

2 - with optimization:

WebPageTest

You can even see the image optimization grade improves dramatically, and yet the peformance of LCP worsens dramatically.

[pmeenan]

Highlighting the layout shifts really helps show what is going on: WebPageTest - Visual Comparison

Before optimization, the interstitial pop-up shows up before the main hero image loads so the header is the largest contentful paint.

After optimization the hero image loads before the pop-up obscures the content and is recorded as the LCP.

As far as the calculations, WPT doesn’t actually calculate or measure it directly. WPT just reports the timings (and details) of the LCP candidate events that Chrome fires so the logic is actually Chrome’s (and the variable behavior will also exist in the field data depending on the order of the hero image and the overlay loading).

It’s clearly a much better user experience and a more accurate representation. You could probably make the pop-up deterministic relative to the image load but I assume the goal is to have it load as quickly as possible as well.