One anecdote where their “Largest Contentful Paint” metric fails, and fixing degrades performance:
We have a large 300kb animated gif that takes up maybe 20% of the viewport above the fold. The gif demonstrates visually what our service does.
A couple months ago Webmaster Tools reported that page as being “slow” pointing to the large image download. So we decided to show the first frame of the gif as a (30kb) png file, and then swap in the gif 2 seconds after the page is fully loaded.
Except now the new “largest contentful paint” metric is failing on those pages because it includes the 2 second delay when the animated gif is swapped in. I guess technically they’re not wrong in how they’re calculating it.
In fewer words, Google doesn’t like anything being lazy loaded if it’s above the fold.
The metrics and how they’re calculated are questionable. We ended up optimizing for Google and removed the lazy load (ignoring that we think it’s a better UX to lazy load that specific gif).
Interesting case scenarios:
1) a Site has a stupid big gif that shows logo and staff parties, basically adding nothing but sucking up bandwidth(Not your case)
2) Your case, where you actually add value-content with the gif.
Now the speed metrics are just that, speed metrics they "report" in isolation from "content".
So now my question is: Is Google's OTHER-content-signals good enough to overcome any penalty that might have been applied because of the speed ?
That sounds like a nightmare. Is there any other way to delay the loading of the gif that doesn't negatively affect your score? Like a JS callback or similar.
As an aside, the other replies to your comment is very telling of the HN audience. Many of which aren't knowledgeable in the webdev field, but "they did it in the 90's", "use bleeding-edge tech" and "everything you're doing is wrong". Also IFRAMEs, hahaha.
Or you can scroll down. It's presumably a hero imagespace that serves to explain their product in the fastest way. 300kb for a gif isn't that big for such an inefficient type.
We have a large 300kb animated gif that takes up maybe 20% of the viewport above the fold. The gif demonstrates visually what our service does.
A couple months ago Webmaster Tools reported that page as being “slow” pointing to the large image download. So we decided to show the first frame of the gif as a (30kb) png file, and then swap in the gif 2 seconds after the page is fully loaded.
Except now the new “largest contentful paint” metric is failing on those pages because it includes the 2 second delay when the animated gif is swapped in. I guess technically they’re not wrong in how they’re calculating it.
In fewer words, Google doesn’t like anything being lazy loaded if it’s above the fold.
The metrics and how they’re calculated are questionable. We ended up optimizing for Google and removed the lazy load (ignoring that we think it’s a better UX to lazy load that specific gif).