Next 13 adding <link rel="preload"> to images not using the images component - bad for LCP

[valley-boy]

Summary

For various reasons (see below example) we don't want to use the next/image component for our images (we just want to use a regular img tag), however on our SSR pages Next is still setting a link rel="preload" tag in the head for each img without a loading=lazy. We don't want to set a loading = lazy, on these specific images, is there any other way we can prevent next from adding the link rel="preload" for images

Additional information

The reason this killing our LCP that its selecting the siteimages/image-full.jpg (our high res fallback) as the <link rel="preload"> but its not used as most browsers support the webp. So we are loading x2 images when only 1 required!

<picture>
    // load webp in different sizes if browser supports it
    <source type="image/webp"
        sizes=" (max-width: 500px) 500px,
                (max-width: 768px) 768px,
                (max-width: 1024px) 1024px,
                100vw"
        srcset="
          webp/image-500.webp 500w,
          webp/image-768.webp 768w,
          webp/image-1024.webp 1024w,
          webp/image-full.webp 1920w
        "
        >
    // fallback on original src.
    <img 
        srcset="siteimages/image-1024.jpg 1024w, 
            siteimages/image-768.jpg 768w,
            siteimages/image-500.jpg 500w"
        sizes=" (max-width: 500px) 500px,
                (max-width: 768px) 768px,
                (max-width: 1024px) 1024px,
                100vw"
        src="siteimages/image-full.jpg" 

        alt="image description"
        class="myimageclass">
</picture>

Example

No response

[gnoff]

@valley-boy agreed, this should be handled upstream in React correctly. We will update it so that images inside pictures are not automatically preloaded

[valley-boy]

Hi Josh, many thanks for the reply If you need a working example on the following the first Nursing Home listing preloads both the jpg fallback in the img src and and webp photo in the source srcset, we ideally don't want the jpg preloading as it undoes all our good performance work of trying to go webp vs jpg! https://www.nursinghomes.com/il/chicago/ (our first next.js site and very much enjoying it!) look forward to the resolution, and very much appreciated cheers Oli

…

On Tue, 5 Sept 2023 at 18:59, Josh Story ***@***.***> wrote: @valley-bot agreed, this should be handled upstream in React correctly. We will update it so that images inside pictures are not automatically preloaded — Reply to this email directly, view it on GitHub <#54799 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/BCH6VUXTSH44B5BQ7G4PUBDXY5SB5ANCNFSM6AAAAAA4FBM5NA> . You are receiving this because you authored the thread.Message ID: ***@***.***>

[gnoff]

preloading pictures is hard given there are multiple layers of selection and the browser is going to only pick one source to load. We could try to preload the first source inside a picture and for browsers that would fallback they'd just not benefit from the preload while browsers that do match the first source would get the preload. I'll work on this in the next week or two

[valley-boy]

Hi Josh understood, issue with loading the first source is that it may be the right format for the browser but the wrong image size for current device Maybe a safer option would be not to set any preload and leave it up to us to add a preload link. We would then add a preload link with a srcset with only the webp files, not the fallback jpg. Preload supports the srcset so works nicely. cheers Oli

…

On Tue, 5 Sept 2023 at 20:40, Josh Story ***@***.***> wrote: preloading pictures is hard given there are multiple layers of selection and the browser is going to only pick one source to load. We could try to preload the first source inside a picture and for browsers that would fallback they'd just not benefit from the preload while browsers that do match the first source would get the preload. I'll work on this in the next week or two — Reply to this email directly, view it on GitHub <#54799 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/BCH6VUU55YHU5QVKTO6JKN3XY55ZTANCNFSM6AAAAAA4FBM5NA> . You are receiving this because you were mentioned.Message ID: <vercel/next .***@***.***>

[gnoff]

Hi Oli,

using <link rel="preload" as="image" imagesrcset="...the source srcset" imagesizes="...the source sizes" type="...the source type" /> the browser should preload the correct size and only if it can support the image type. Are you saying that there are still cases where a preload constructed this way would potentially load the wrong size?

[valley-boy]

Hi Josh, sorry I see now, think this will work well, so in the above it would preload this part as the preload srcset type="image/webp" sizes=" (max-width: 500px) 500px, (max-width: 768px) 768px, (max-width: 1024px) 1024px, 100vw" srcset=" webp/image-500.webp 500w, webp/image-768.webp 768w, webp/image-1024.webp 1024w, webp/image-full.webp 1920w "

…

On Wed, 6 Sept 2023 at 16:16, Josh Story ***@***.***> wrote: Hi Oli, using <link rel="preload" imagesrcset="...the source srcset" imagesizes="...the source sizes" type="...the source type" /> the browser should preload the correct size and only if it can support the image type. Are you saying that there are still cases where a preload constructed this way would potentially load the wrong size? — Reply to this email directly, view it on GitHub <#54799 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/BCH6VUVC4DOT2WK3FCOZZG3XZCHVLANCNFSM6AAAAAA4FBM5NA> . You are receiving this because you were mentioned.Message ID: <vercel/next .***@***.***>

[gnoff]

Yeah so if the browser did not support webp it would not preload anything but for browsers that do support webp it would preload the right src from srcset based on the sizes defined so there should be no duplicate fetch for the image

[valley-boy]

sounds great, cheers Josh

…

On Wed, 6 Sept 2023 at 19:04, Josh Story ***@***.***> wrote: Yeah so if the browser did not support webp it would not preload anything but for browsers that do support webp it would preload the right src from srcset based on the sizes defined so there should be no duplicate fetch for the image — Reply to this email directly, view it on GitHub <#54799 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/BCH6VUSFFYDEGOKZA36WSNDXZC3LRANCNFSM6AAAAAA4FBM5NA> . You are receiving this because you were mentioned.Message ID: <vercel/next .***@***.***>

[gnoff]

@valley-boy so upon further considering this is going to be more of challenge to implement ideally because you can suspend inside the <picture> and that can lead to incorrect behavior when determining which source would be approrpiate. I'm going to land a quick fix which just omits the preloads for img-inside-picture and consider a more comprehensive solution later

[gnoff]

fixed in facebook/react#27346

[valley-boy]

cheers Josh, appreciated Any idea of a timeline for the next stable release that will have this amendment included?

…

On Thu, 7 Sept 2023 at 20:49, Josh Story ***@***.***> wrote: fixed in facebook/react#27346 <facebook/react#27346> — Reply to this email directly, view it on GitHub <#54799 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/BCH6VUTXCM7ZBIHETZOCXGDXZIQK3ANCNFSM6AAAAAA4FBM5NA> . You are receiving this because you were mentioned.Message ID: <vercel/next .***@***.***>

[gnoff]

I expect sometime next week

[vankatadam]

@gnoff We have part in our codebase, which before next13 app directory was working correctly. Now we are switching to server component and our noscript images are being preloaded even if js is on. Is this already a known Bug? And do you know if its Next or React related, so we could open the Issue in the correct forum.

Example:

  <noscript>
    <img style={props?.style} alt={props.alt} src={props.src} />
  </noscript> 

[ascorbic]

I think a workaround for now is to add loading="lazy"

[vankatadam]

@ascorbic That is only a bad workaround for us, because we don't want to have all our images to be lazily loaded. @gnoff Is this already a known issue and is there a fix coming for this?

[ascorbic]

facebook/react#27346

[yiminghe]

same issue in next 15.3.1

[mpkelly]

Sibling selectors are another reason there should be an opt-out. I have some rules that target sections that immediately follow sections with certain features, and those are broken in some cases due to preloads being plonked into the DOM.