search

w3c / largest-contentful-paint

Specification for the LargestContentfulPaint API
https://w3c.github.io/largest-contentful-paint/
Other
88 stars 16 forks source link

"Contentful style-background-images" definition is too vague to be relied upon? #55

Closed seanw closed 3 years ago

seanw commented 4 years ago

Contentful style-background-images...LCP uses simple heuristics to exclude background images with a background role...The heuristics to identify a background-purposed image may include: ... Document position - background images of the document's or its are more likely to serve as a background for the page.

  1. Will this definition be made more exact to make it clear that background images on the <body> or <html> will always be ignored as the LCP?

  2. Will a viewport sized background image on a <header> at the top of the page be flagged as the LCP?

It would be frustrating to change the web design and code of a site to improve the LCP time based on the above and then for the definition of LCP to change.

Additionally, this seems to have a big impact on web design in general if you cannot rely on the above, especially if LCP timings start to influence your search rank. Many sites use large background header images that are only decorative that don't stop the (contentful) header text from being quickly readable - if large background images always tank your LCP score, wouldn't your only options be to use e.g. images that are smaller than the header text or only SVG backgrounds/images?

npm1 commented 4 years ago

Contentful style-background-images...LCP uses simple heuristics to exclude background images with a background role...The heuristics to identify a background-purposed image may include: ... Document position - background images of the document's or its are more likely to serve as a background for the page.

  1. Will this definition be made more exact to make it clear that background images on the <body> or <html> will always be ignored as the LCP?

It does say that right below that paragraph, and yes we do ignore those at the moment.

  1. Will a viewport sized background image on a <header> at the top of the page be flagged as the LCP?

I believe so but you could check with a sample website where you do that. Presumably most sites don't use a giant header? Not sure why you're asking this.

It would be frustrating to change the web design and code of a site to improve the LCP time based on the above and then for the definition of LCP to change.

One thing we've though about is whether we should just exclude any large (or viewport sized) background images from being LCP, though as of now we don't have plans to change this.

Additionally, this seems to have a big impact on web design in general if you cannot rely on the above, especially if LCP timings start to influence your search rank. Many sites use large background header images that are only decorative that don't stop the (contentful) header text from being quickly readable - if large background images always tank your LCP score, wouldn't your only options be to use e.g. images that are smaller than the header text or only SVG backgrounds/images?

While some background images are decorative, others are actually important content of the website, and it can be hard for an algorithm to distinguish this. We intend to document any changes in the LCP documentation here https://chromium.googlesource.com/chromium/src/+/master/docs/speed/metrics_changelog/lcp.md.

seanw commented 4 years ago

Thanks for your reply.

While some background images are decorative, others are actually important content of the website, and it can be hard for an algorithm to distinguish this.

To explain myself better, what I'm really asking is: What are the guidelines on how to design web pages that feature large decorative only (i.e. non-contentful) images in the header that will get a performant LCP score?

npm1 commented 4 years ago

To explain myself better, what I'm really asking is: What are the guidelines on how to design web pages that feature large decorative only (i.e. non-contentful) images in the header that will get a performant LCP score?

@philipwalton could probably respond this better, but note that if the intrinsic size of the image is small then it will likely not be considered LCP. And if its intrinsic size is large then it hopefully isn't a heavyweight resource anyways, since it's just decorative? I.e. having a heavyweight decorative image is probably not the best for performance as it may slow down the other content.

  • The recommended approach is to use background: url on the <html> element and there isn't an alternative? I've personally not seen this approach before, but if it's the only way to get a good LCP score with a large background image, I can see the current heuristic pushing developers in that direction.

We did see cases like this, which is what triggered the exclusion. It's certainly not a perfect heuristic.

  • Usually you'd style the <header> element but from some testing myself this will get flagged as the LCP. Is this just a case of a false positive or there's a reason the <header> approach should be scored lower than the <html> approach?

Setting a background for a <header> (or do you mean <head>? Same reasoning applies though) )would result in something totally different from setting it in the <html> or <body>, so I'm not sure why you mention these as interchangeable... Note the heuristic we have is to cover cases where the image is really just decorative, but covering the majority of the site (which is not really the case for a background of the header).

seanw commented 4 years ago

@npm1

having a heavyweight decorative image is probably not the best for performance as it may slow down the other content.

Here's a minimal example of using background: url to implement the same page design getting very different LCP scores:

  1. This sets a background image on the body element and gets a 0.8s LCP score:

https://clever-hawking-7f390b.netlify.app/lcp-body-background/

https://developers.google.com/speed/pagespeed/insights/?url=https%3A%2F%2Fclever-hawking-7f390b.netlify.app%2Flcp-body-background%2F

  1. This sets a background image on the header element and gets a (red) 3.4s LCP score:

https://clever-hawking-7f390b.netlify.app/lcp-header-background/

https://developers.google.com/speed/pagespeed/insights/?url=https%3A%2F%2Fclever-hawking-7f390b.netlify.app%2Flcp-header-background%2F

What I'm getting at is:

  1. Page designs with big decorative images like this are common and popular.

  2. When Google start incorporating LCP into search rankings, developers are going to look for ways to get the best LCP score.

  3. The body background url approach I used above seems like a hack to me (with likely cleaner variations) but that's what the current heuristics are going to encourage.

My suggestions are:

  1. If the body background url example above should really be getting a bad LCP score, I would improve the heuristic to correct for this as it's likely to get abused eventually.

  2. If it's possible to implement a page design like the above while getting a good LCP score, I would add some guidelines on the recommended way to go about this seeing as it's such a common page design. I'd be happy to contribute some text for this if that would help.

Hope that makes sense. The context here is that when I'm consulting for a client to improve their website performance, I want to know if it's best to entirely avoid page designs like in the example I gave (unless the background has a low file size).

npm1 commented 4 years ago

Thanks, the examples are super helpful :) I think I would be in favor of excluding any background image which occupies all of the viewport, and not just those which are set in the body or html.

seanw commented 4 years ago

I think I would be in favor of excluding any background image which occupies all of the viewport, and not just those which are set in the body or html.

npm1 commented 4 years ago

Sean, we’re not in a position to make any statements about how the Google Search team will deal with malicious actors — that’s for them to figure out. All metrics are gameable and it’s not a new problem for them.

What we do need to think about is what behaviors we want to encourage to be the norm and how to make them easy. Which is to say, we should have a well documented best practice for how to deliver LCP-well-performing designs with large decorative images. That said, I'm not convinced that this needs to live in the spec, or that it’s the right place for it: this is not where an average developer will look for guidance. CC @philipwalton for input.

npm1 commented 3 years ago

I'll close this issue. Any additional guidance should probably live in sites like MDN or web.dev.

itcomindo commented 3 years ago

I use SVG image as div background and it's done

LukeLeber commented 2 years ago

While some background images are decorative, others are actually important content of the website, and it can be hard for an algorithm to distinguish this. We intend to document any changes in the LCP documentation here https://chromium.googlesource.com/chromium/src/+/master/docs/speed/metrics_changelog/lcp.md.

Detecting decorative images shouldn't be difficult. There are well defined patterns that already exist.

  1. An empty alt tag: <img alt="">
  2. Having a presentation role: <img role="presentation">
  3. Being aria-hidden: <img aria-hidden="true">

It seems to me at least that decorative images should be excluded from being LCP element candidates if for no other reason that they are only actual relevant to a subset of visitors that do not suffer from disabilities.

My 2¢ :smiley: