Hero image optimization by astro causes a pixelated image

[SoCuul]

I've noticed that when trying to provide a hero image for a page, the image loaded by Astro has url parameters specifying a fixed size (&w=400&h=400). This leads to the loaded image looking low quality, as it gets scaled down with a low pixel count.

Here is the difference between the default, and manually removing the URL parameters from the img src after the page has loaded.

---

Before

After

[delucis]

Thanks for the feedback @SoCuul!

I think when I built the component, I chose a size that was a reasonable trade-off between performance and quality across viewport widths. Since then, Astro has added tools to make it easier to include multiple resolutions, so we can probably revisit that to provide hero images that are optimized, but not so low resolution for larger devices.

[delucis]

Sharing some notes from a quick first investigation:

• Currently, we always ship a 400px image (displayed at a maximum width of ~380px), which can be not so crisp on high-DPI screens as noted above.

• I implemented it this way a) so I didn’t have to worry about generating multiple optimised images (the APIs weren’t as nice for this at the time) and b) because it guarantees a pretty small hero image which is a likely LCP candidate, improving load times and perceived performance.

• Now, we could switch to using the widths and sizes attributes on Astro’s <Image> component, so that a higher res image is available for devices that support it. For example, here’s what I came up with so far:

    widths: [400, 580, 760],
    // Matches the CSS layout styles below:
    // - One the smallest viewport widths, the hero image is roughly 70% of the width.
    // - Once the viewport is wider than 450px, the hero image is constrained to 320px wide.
    // - Once the layout switches to two columns, the hero image is roughly 35% of the width (4fr vs 7fr for the text).
    // - Once the viewport is wider than 1100px, the image is constrained to 380px wide.
    // User CSS may alter this, but hopefully the heuristics are close enough to roughly match what’s
    sizes: '(min-width: 1100px) 380px, (min-width: 800px) 35vw, (min-width: 450px) 320px, 70vw',

• This is slightly tricky though, because if someone changes the hero layout with CSS, then our sizes attribute may no longer align with reality.

• The size impact can be pretty significant with a change like this. For example, currently the Starlight docs hero image is 32 KB, but after this change on desktop it downloads the largest available size, which is now 86 KB, a 170% increase. That feels like a lot to pay for a slightly crisper image, although it does depend on the hero image in question — I don’t think the slight softness is that noticeable in the Starlight docs, but seems more so in the screenshot above.

  • Same applies with the perspective of the full page transfer size. For example Starlight docs homepage currently transfers 90 kB, but with this change that jumps to 140 kB, a 55% increase, with more than half of the bandwidth being used for the hero image.

• Side note: I also went to see if prefers-reduced-data exists, but although specced, no-one has implemented it yet due to privacy concerns. Otherwise it would have been nice to use here.

[delucis]

Ah, just realised something else: your site has some custom styles to display the hero image larger than the default, which obviously makes this issue really obvious — a 400px wide image is displayed at 550px, probably on a retina screen with a pixel density of 2. Not likely to look good 😅

I wonder if the only really solid way to support this would be to allow control over setting a width value in the frontmatter config. Then you would have had the freedom to set that to scale up the emitted images without switching to using the public/ directory. For example, could look like this:

hero:
  image:
    file: ./hero-image.webp
    width: 550

[SoCuul]

Something like that would be great to have!