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
avif is much more efficient than jpg, png, and gif. It's better than webp. (SVG is already great.)
Note that currently Next.js has been automatically upscaling our images already to webp. This upscaling happens on the server, although is cached, so has some hit to our server resource usage & initial page load on a cold cache.
We should migrate all our source images to AVIF for a few reasons:
Avoid the server resource usage because the image will already be optimized.
Use AVIF rather than Next.js's default of upscaling to webp. AVIF is ~20% smaller and more useful when downloaded.
Reduce Git repo size bloat. AVIF is ~10% the size of our PNG/JPG images.
Next.js will fallback to JPEG if the browser doesn't support AVIF, so there is no risk to our end-users.
How to migrate
The best way I've found to convert images is using magick: magick my-img.png my-img.avif
API docs
Sphinx outputs PNG; having it output AVIF is not feasible. So, our conversion pipeline needs to convert the images.
Unfortunately, this will slow down our pipeline.
Guides
These images are controlled by us. We don't normally run a build process, so we would need to add a new workflow step.
Notably, we want to avoid introducing the PNG/JPG files in the first place because once they're in Git, the blob stays there forever. So, we should block PRs.
We probably want a script that will automatically scan every non-API image and convert them to AVIF. However, one tricky thing with this script is we would need to also update the markdown link to use .avif in the file. A simpler approach would be to only lint then tell the person how to run magick and update the markdown; I'm not sure how much automation to have.
Jupyter notebook output
See #1672. Jupyter notebooks are tricky because they store their images inline in the file. #1672 stores how we could instead store the images outside of the file so we can use Next.js's <Image> component; however, that optimization would only apply in closed source, which may require duplicating this AVIF logic in both repositories.
One other nuance is that our notebooks normally generate SVGs (which can be quite large! See #1678). Would it be better if we generated PNGs, then converted those PNGs into AVIF? Does that reduce file size? Does that negatively impact user experience too much?
The text was updated successfully, but these errors were encountered:
Why migrate
avif is much more efficient than jpg, png, and gif. It's better than webp. (SVG is already great.)
Note that currently Next.js has been automatically upscaling our images already to webp. This upscaling happens on the server, although is cached, so has some hit to our server resource usage & initial page load on a cold cache.
We should migrate all our source images to AVIF for a few reasons:
Next.js will fallback to JPEG if the browser doesn't support AVIF, so there is no risk to our end-users.
How to migrate
The best way I've found to convert images is using
magick
:magick my-img.png my-img.avif
API docs
Sphinx outputs PNG; having it output AVIF is not feasible. So, our conversion pipeline needs to convert the images.
Unfortunately, this will slow down our pipeline.
Guides
These images are controlled by us. We don't normally run a build process, so we would need to add a new workflow step.
Notably, we want to avoid introducing the PNG/JPG files in the first place because once they're in Git, the blob stays there forever. So, we should block PRs.
We probably want a script that will automatically scan every non-API image and convert them to AVIF. However, one tricky thing with this script is we would need to also update the markdown link to use
.avif
in the file. A simpler approach would be to only lint then tell the person how to runmagick
and update the markdown; I'm not sure how much automation to have.Jupyter notebook output
See #1672. Jupyter notebooks are tricky because they store their images inline in the file. #1672 stores how we could instead store the images outside of the file so we can use Next.js's
<Image>
component; however, that optimization would only apply in closed source, which may require duplicating this AVIF logic in both repositories.One other nuance is that our notebooks normally generate SVGs (which can be quite large! See #1678). Would it be better if we generated PNGs, then converted those PNGs into AVIF? Does that reduce file size? Does that negatively impact user experience too much?
The text was updated successfully, but these errors were encountered: