You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Because next/image does not support <source> and <picture> tags, we cannot safely use next-gen image formats, as there is no way to provide a fallback. The best way to handle this is by automatically return an image format supported by the browser. This can be done by inspecting the Accept header sent in the request. ODB does not pass request headers, so the idea would be to use the same redirects that we use to redirect from the /_next URL to the ODB function, and embed the requested format in the URL.
This would be enabled by support for redirects by HTTP header
For example:
/_next/image* url=:url w=:width q=:quality /nextimg/:url/:width/:quality.avif 301! Header@Accept=image/avif
/_next/image* url=:url w=:width q=:quality /nextimg/:url/:width/:quality.webp 301! Header@Accept=image/webp
# Fallback for browsers that don't support next-gen images
/_next/image* url=:url w=:width q=:quality /nextimg/:url/:width/:quality 301!
The text was updated successfully, but these errors were encountered:
+1 to this. I want my app to utilize WEBPs where supported without having to "live on the edge" and break the site completely for users who don't use a browser that supports WEBP.
This is a feature already present in the base NextJS server, as seen in its image optimizer. It checks the header of the incoming request, determines if the client supports a next-gen image format, and supplies it if so.
Without this feature, the changes mentioned in #133 are not useful to me.
Because next/image does not support
<source>
and<picture>
tags, we cannot safely use next-gen image formats, as there is no way to provide a fallback. The best way to handle this is by automatically return an image format supported by the browser. This can be done by inspecting theAccept
header sent in the request. ODB does not pass request headers, so the idea would be to use the same redirects that we use to redirect from the/_next
URL to the ODB function, and embed the requested format in the URL.This would be enabled by support for redirects by HTTP header
For example:
The text was updated successfully, but these errors were encountered: