Rapid LCP increase without any application end change

Web Performance Discuss Test Results
1

Starting from yesterday at around noon time, our web site home page’s LCP all the sudden increased from 3.## seconds to 10+ seconds when using WebPageTest tool. And I have checked from our end, no application end changes would cause this.

What might be the cause? Any change at WebPageTest end? Or anything wrong with my browser?

Thanks,

Tian

1 Like
2

Can you share a test run from both before and after the increase so we can dig in?

1 Like
3

before - WebPageTest - Running web page performance and optimization tests...
after - WebPageTest - Running web page performance and optimization tests...

Thanks,

Tian

1 Like
4

Thanks!

Looks like the big difference is due to the addition of a 4MB GIF as the new hero image.

On your before test, you can see in the filmstrip that the LCP is triggered by your hero image, in this case, a 186kb file.

eb-original-lcp
eb-original-lcp1145×956 253 KB

In the second test, when LCP fires much later, we see the hero image is now a 4MB GIF that takes much longer to arrive.

eb-lcp-new
eb-lcp-new1176×950 256 KB

We do track detailed LCP related information and store it in the JSON results for each test, so you can always find out more information there too. For example, here’s what I see for your later test.

"LargestContentfulPaintType": "background-image",
"LargestContentfulPaintNodeType": "DIV",
"LargestContentfulPaintImageURL": "https:\/\/eddiebauer.scene7.com\/is\/image\/EBContent\/210412_hp_legginggtm?$a8$",

This is a kind of interesting example, though. Enough of the GIF is displayed that visually, it looks like the hero image is in place about 8s earlier than LCP fires, but because LCP waits until the an image has fully arrived to to fire, that means the metric gets pushed out quite a bit.

2 Likes
5

So the metrics/measurement is no longer accurate and not accountable…

Will WebPageTest address this issue? Do we know which image is holding up LCP to be fired?

Thanks,

Tian

1 Like
6

So the metric itself is actually working as expected: by definition if an image is the LCP candidate, that metric doesn’t get reported until the image is fully loaded. Here’s what the specification says:

We define the image rendering timestamp as the next paint that occurs after the image has become fully loaded.

We can’t make any changes there ourselves without really confusing a lot of folks. We report the LCP information provided directly by Chrome. If we made a change to that, folks would now see one metric in the browser itself, and a different metric entirely in WebPageTest.

As for the image itself, it’s that GIF I highlighted in the previous comment. At 4MB, it’s super heavy and as a result, takes a long time to arrive. Your best bet is to use a different format (with or without animation) that compresses better.

2 Likes
7

It’s worth mentioning that the LCP that WebPageTest reports is the same that Chrome collects for CrUX that feeds into the core web vitals SEO stuff so the change to a 4MB gif hero image is going to seriously impact the Google-reported numbers as well (just takes a bit longer since it is a 28-day rolling window).

3 Likes
8

Thanks for the feedback!

1 Like
9

Thanks for the clarification!

1 Like
10

Do you have any recommendation of which format of animation could be compressed better?

Thanks,

Tian

1 Like
11

Generally, an autoplay video with no audio will always be the best (mp4). Otherwise, webp can be a good alternative.

1 Like
12

Thank you so much! :blush:

1 Like