Next Image Components Compared

Ethan Glover

Last Updated: 1 year ago

There seems to be come confusion about what exactly the new next/image does. People are recommending using next/future/image as a way to embed images without width and height. This is not the purpose of the change. Rather, the component is integrating native browser APIs instead of the custom solutions built into the original component with the help of Google's Project Aurora.

If you actually read the documentation instead of just linking to it, you'll see no mention of not needing image dimensions. Instead, you will see a list of examples to deal with the removal of the layout, objectFit, and objectPosition props.

Previously, in order to use next/image without image dimensions, you would simply use a parent container to set those dimensions:

1<div style={{ height: '300px', position: 'relative', width: 'auto' }}>

The current perception seems to be that with the next Image component, you can just do a simple <Image src="" /> and everything is magically taken care of for you. This is not the case. The effect is the same. By default, width and height are still required. And by using the fill property to skip using width/height you still need to define object fit inside of a relative container. Here is the equivalent code using next/future/image:

1<div

Are you can see, there is no difference except moving objectFit into the style object The original objectFit argument was simply a redundancy.

Focus on Necessary Information for Content, Not Shortcuts

The Next image component is amazing. It does a ton of performance work we don't typically think of. A huge amount of work went into a lot of small details to produce it. By wanting to embed images without dimensions, people are focusing on the wrong problems.

If you're not storing width/height with your images, where are you getting alt texts from?

Standard practice for me for a very long time has been to store image URLs with, at a minimum, width, height and altText. Some image hosts like Cloudinary can store dimensions for you. But none of them can take care of readable, accessible alt text. That is something you need to be storing alongside your content anyway.

Dimensions are the same story. Instead of depending on Next.js to magically take care of performance without necessary information, I argue that you should never be using the fill layout except as a very rare escape hatch. And that looking for a solution that involves not using dimensions should only be a last resort.