Images generated by next/image not in optimized formats and have 301 redirect issue

[vxncetxn]

Describe the bug
Images generated by next/image 1) are not in optimized webp format despite using webp-compatible browsers (the resultant format is jpeg which is the original image format) and 2) have a strange 301 redirect issue. I tested this in the latest versions of Firefox, Chrome and Safari and error number 2 manifests slightly differently in each browser - in the worst case (Firefox), the transferred 301 file have the same size as the original image, leading to x2 KBs being transferred (and visually-apparent slowness in loading images) whereas in the best case (Safari), the 301 files seem to have 0Bs.

I also tested this both in localhost and in Vercel and none of the above two errors appear in those scenarios.

The image below shows both of these errors in Firefox browser:

To Reproduce
Steps to reproduce the behavior:

1. Go to https://marketing-proxy-two.netlify.app/
2. Open Devtools
3. Click on Network tab and click on Images to only see image resources
4. Refresh and see errors as described above

Expected behavior
Images should be in optimized webp formats and should not have a 301 redirection as in the below image (which is from localhost).

Versions

• Next.js: v11.1.2
• @netlify/plugin-nextjs: v3.9.0
• @netlify/build: v18.13.12
• node: v16.11.0
• yarn: v1.22.10

If you're using the CLI to build

• OS: [e.g. macOS, Windows] macOS Catalina Version 10.15.7

[lourd]

Confirming that this is still an issue with v4 of the plugin, as mentioned by OP here.

As an example, we'll have an image in our app like this:

import Image from "next/image"
import Error404Image from "./404.png"

const MyComponent = () => {
  return <Image src={Error404Image} />
}

At runtime we see a request to https://deploy-preview-8180--{redacted}.netlify.app/_next/image?url=%2F_next%2Fstatic%2Fmedia%2F404.13dea090.png&w=750&q=75

And the server responds with a 301 redirect to https://deploy-preview-8180--{redacted}.netlify.app/_ipx/w_750,q_75/%2F_next%2Fstatic%2Fmedia%2F404.13dea090.png?url=%2F_next%2Fstatic%2Fmedia%2F404.13dea090.png&w=750&q=75.

Looking at the docs for ipx, I can force the conversion to webp by add f_webp to the modifier list, i.e.: https://deploy-preview-8180--{redacted}.netlify.app/_ipx/f_webp,w_750,q_75/%2F_next%2Fstatic%2Fmedia%2F404.13dea090.png?url=%2F_next%2Fstatic%2Fmedia%2F404.13dea090.png&w=750&q=75.

So it should be (🤞) relatively minimal new logic needed in the handler to check the user-agent/client hints and use the most optimized format it supports (i.e. webp or avif).

[maxtechera]

Hello I'm seeing this issue as well, where can I check the status of the fix implementation if any?
I would be interested in taking a look if no one is working on it.
This is pretty crucial to consider this plugins up to par with a Vercel deployment!

[ascorbic]

Hi. There is experimental support now, using Edge Functions. If you set the env var NEXT_USE_NETLIFY_EDGE to true it will enable Edge Functions, including for image proxying. This will remove the need for redirects, and will enable support for image format content-negotiation, with support for WebP and AVIF.

[maxtechera]

Hi. There is experimental support now, using Edge Functions. If you set the env var NEXT_USE_NETLIFY_EDGE to true it will enable Edge Functions, including for image proxying. This will remove the need for redirects, and will enable support for image format content-negotiation, with support for WebP and AVIF.

Thanks for the quick response. I can verify that by enabling the env var the redirects are gone and file format optimization works.
Not all images are loading due to timeouts. I'll do some exploration and see if there are any other issues around about it.
Thanks again.

[austinlangdon]

Hi @maxtechera, did you ever figure out a solution when setting NEXT_USE_NETLIFY_EDGE to true?

Experiencing the same - redirects are gone, but not all images are loading due to timeouts.

[hughrawlinson]

Hey @austinlangdon - I've seen on answers.netlify.com that when a source image is large enough for it to take the edge function more than 10s (their max length) to transcode the image, they time out and cut off. The advice was to reduce the size of the original image, though I wasn't able to reduce the size enough to get under the timeout threshold.

[austinlangdon]

@hughrawlinson scaling down the image size fixed the issue. Thank you!

[ascorbic]

I think disabling AVIF could fix it, because that takes a lot longer than other formats. I'll open an issue to add support for that.

[ascorbic]

Closing this because the original issue is fixed with edge functions

[asktree]

I'm experiencing this exact problem a year later, tried enabling NEXT_USE_NETLIFY_EDGE but it had no effect. The image in question is 280kb, so maybe it's too big and we're timing out.

Note 301 in screenshot