Different behavior while fetching and displaying images with react-datocms <Image /> component

🆘 Support
1

We have some issues with DatoCMS React <Image /> component on the dewesoft.com page that we are currently upgrading to NextJS 15 and RSC.

On the old site we are using "react-datocms": "^4.0.8" but on the new project we are using "react-datocms": "^7.2.2".

The problem

We are using the same GraphQL queery to query DatoCMS data whic is:

cover {
  responsiveImage(imgixParams: {auto: format, w: 1000}) {
    srcSet
    webpSrcSet
    sizes
    src
    width
    height
    aspectRatio
    alt
    title
    base64
  }
}

Now what we see it the actual image rendered on new page is lower resolution then on the old page. Here is the image we get from DatoCMS:

New project
https://www.datocms-assets.com/53444/1658154658-dewesoft-portable-data-acquisition-systems.jpg?auto=format&dpr=1.5&w=1000

Old project

https://www.datocms-assets.com/53444/1658154658-dewesoft-portable-data-acquisition-systems.jpg?auto=format&w=1000&dpr=4

We see that dpr=4 parameter is added to the old project and on the new it is 1.5 and image is of lower resolution.

I am trying to figure out what causes this difference? Does this have anything to do with my <heading> viewport setting:

Old site:
<meta name="viewport" content="width=device-width">

New site:
<meta name="viewport" content="width=device-width, initial-scale=1">

Kind regards,
Primoz

2

@primoz.rome

Thanks for sending over the examples. Nothing in your <meta viewport> settings is affecting the outcome here—the change comes from the newer version of react-datocms itself.

From v6 onward we lowered the DPR of the fallback src that the <Image /> component prints, moving from 4 × down to 1.5 ×. That single URL is the one you copied in DevTools. All the higher-density candidates (2 ×, 3 ×, 4 ×) are still part of the srcset, so on a Retina-class screen the browser will continue to fetch exactly the same sharp 4 × file you were seeing in the old site—only now the first request every visitor makes is lighter, which saves bandwidth and improves LCP.

If you really want to restore the previous behaviour you have two options:
• pass your own list of DPR multipliers, for example
<Image data={…} srcSetCandidates={[0.25,0.5,0.75,1,2,3,4]} />
• or ask for the high-density file directly in GraphQL, eg.
responsiveImage(imgixParams: { auto: format, w: 1000, dpr: 4 }) { src … }

Otherwise you can safely keep the default; on high-density devices the visual result is identical while the initial payload is smaller for everyone.

Hope that clarifies what you’re seeing.
Let me know if anything’s still unclear or if there’s anything else I can help with!

1 Like
3

Thank you Marcelo, all clear, great explanation.

I think it’s the right optimization, I just wasn’t sure where this comes from.

Cheers,
Primoz

<SRCImage /> vs <Image /> render problems