[WIP] Next.js Image Component

[timneutkens]

Keeping track of the feedback so far:

• Fix flashing of no-src image when using next/image #18195 Lazy loading flickers a <img> with empty or not found src icon
• Make lazy-loading the default for next/image #18123 Images that are rendered in a flexbox are not lazy loaded (@timneutkens)
• Make lazy-loading the default for next/image #18123 Lazy loading has to be the default (@timneutkens)
• Make lazy-loading the default for next/image #18123 Throw error when width and height are missing and unsized is not set (@styfle)
• Change Image component lazy=true to loading=lazy #18138 Rename lazy=true to loading=lazy to match web standard (@styfle)
• Update Image Optimization API to prevent upscaling image  #18147 Prevent upscaling images, API should never return an image width larger than the source image width (@styfle)
• Add docs for Image Optimization #18107 Add documentation for next/image and automatic image optimization (@styfle)
• Update redirect query encoding #18149 Correctly encode the url parameter (@ijjk)
• Add missing w param fallback #18151 Add missing w param for old browsers like IE that dont support srcset (@styfle)
• Add support for string width/height on Image component #18178 Add support for string width and height attributes (use parseInt and error) (@styfle)
• Add next/image default loader errors #18152 Errors from image optimization need to be surfaced, ie better message when absolute url is not in domains (@ijjk)
• Lazy loading can probably be converted to effect + state (@atcastle @devknoll)
• Add config limit checks for image optimizer #18217 Limit maximum number of images.domains and images.sizes to 50, maximum value of size to 10000
• Bypass image optimization for vector images #18179 Ignore svg for optimization (vector images can be considered already optimized) (@styfle)
• #5321 Only enable Vercel API in @vercel/next when loader=default (@styfle)
• Image Optimization API should 404 when loader is not default #18211 Only enable Next API when loader=default (@styfle)
• Fix Image srcset to ensure the component's width is the largest possible image #18236 Fix srcset to ensure the components width is the largest possible image (@styfle)
• Separate config into deviceSizes and iconSizes #18267 Separate deviceSizes and iconsSizes (@styfle)
• Add support number quality on Image Component #18224 The quality attribute should allow number or string like width (@ykzts)
• Fix trailing slash for default image loader #18298 Fix redirect in next dev for /_next/image/ to /_next/image (@styfle)
• E2E tests to compare next dev and Vercel deployments
• Add err.sh for image config errors #18424 Add err.sh for missing images domain #18325 Add err.sh links for all errors
• Deploy to nextjs.org (start with /next/conf) (@leerob)
• Deploy to vercel.com (start with @geist/image/new)

[todortotev]

I could lend a hand with these if needed.
Throw error when width and height are missing and unsized is not set
Add err.sh links for all errors

[kevva]

• Support AMP

[timneutkens]

• Support AMP

Given the current <img> usage requires replacement with amp-img it's not a goal of the RFC to support AMP initially. Should be relatively straight-forward to add support for it later though given we'll enforce width and height which AMP does as well.

[ItsWendell]

Great work on this, I've been following the RFC, canary developments and the above pull requests. In the RFC it was mentioned that there should be support for multiple CDNs at the same time.

We're modelling the way we save user-generated images now and notice that just saving the absolute url might not be enough, since then we can't make proper use of the next/image component. Now we're thinking of saving the root url, relative path, dimensions and source / provider (e.g. imgix / cloudinary).

According to the docs, loaders should be defined like this:

module.exports = {
  images: {
    loader: 'imgix',
    path: 'https://example.com/myaccount/',
  },
}

Now what if we are initially using cloudinary, later want to move to imgix or our own solution?

The RFC mentioned the following:

Support for files from multiple sources
It’s not uncommon for an application to feature images served from multiple image hosts. The Image component will support this through an optional host attribute that lets the user specify from one of multiple hosts declared in the next.config.js file. The component will use both the host substring and the loader registered to go along with that host in constructing the URL.

If no host attribute is supplied, the default host and loader will be used

I don't see any (work in process) PR's open for this functionality and it's not clear on how to implement this yet, is someone working on this and is this planned for the coming release?

[timneutkens]

I don't see any (work in process) PR's open for this functionality and it's not clear on how to implement this yet, is someone working on this and is this planned for the coming release?

Support for it was removed for the initial release given that it adds significant complexity in both implementation and configuration. It also caused more code than necessary to be shipped to the browser. We'll address it later if there's enough need for it. In general it's uncommon to be hosting on both imgix and cloudinary at the same time.

[dohomi]

I am excited to see the new Image component. I would like to know if there will be an example how to deal with an Image which is part of a 2 column flexrow element (lets say on a grid with 50% or 30% width) on tablet/desktop. But on a mobile its 100% width. Is there any example in place how that should be done?

[ryanwalters]

Support for it was removed for the initial release given that it adds significant complexity in both implementation and configuration. It also caused more code than necessary to be shipped to the browser. We'll address it later if there's enough need for it. In general it's uncommon to be hosting on both imgix and cloudinary at the same time.

Does this comment include removing support for a single, custom service loader? In our case, we have an in-house image service that doesn't conform to the path patterns for any of the options I saw in the documentation (default, imgix, cloudinary, akamai).

Is there a way to disable the loader and simply pass the path through to the Image component (maybe something like loader: 'none')? Being able to get the performance benefits of the Image component while building our own path would be great.

[codetheweb]

Apologies if this is the wrong place to ask, but it doesn't seem like the Image component currently supports optimizing images during the build phase for completely static sites. Is this something that has been considered?

[colepeters]

So excited about this component and all the work around it. Thanks to all involved!

🐛 Hope this isn't the wrong place to mention this, but I just noticed when testing the Image component that src attributes starting with a double slash, e.g. //images.ctfassets.net for Contentful images, seem to be treated as local assets instead of hosted assets. I'm getting around this for now by rewriting // to https://, but I suspect this might not be too deep of an edge case for hosted images 😄

[matamatanot]

Is there a way to disable the loader and simply pass the path through to the Image component (maybe something like loader: 'none')? Being able to get the performance benefits of the Image component while building our own path would be great.

Here BUILT IN LOADERS are.

next.js/packages/next/client/image.tsx

Lines 383 to 459 in 5d7f7a4

	//BUILT IN LOADERS
	type LoaderProps = CallLoaderProps & { root: string }
	function normalizeSrc(src: string) {
	return src[0] === '/' ? src.slice(1) : src
	}
	function imgixLoader({ root, src, width, quality }: LoaderProps): string {
	const params = ['auto=format', 'w=' + width]
	let paramsString = ''
	if (quality) {
	params.push('q=' + quality)
	}
	if (params.length) {
	paramsString = '?' + params.join('&')
	}
	return `${root}${normalizeSrc(src)}${paramsString}`
	}
	function akamaiLoader({ root, src, width }: LoaderProps): string {
	return `${root}${normalizeSrc(src)}?imwidth=${width}`
	}
	function cloudinaryLoader({ root, src, width, quality }: LoaderProps): string {
	const params = ['f_auto', 'w_' + width]
	let paramsString = ''
	if (quality) {
	params.push('q_' + quality)
	}
	if (params.length) {
	paramsString = params.join(',') + '/'
	}
	return `${root}${paramsString}${normalizeSrc(src)}`
	}
	function defaultLoader({ root, src, width, quality }: LoaderProps): string {
	if (process.env.NODE_ENV !== 'production') {
	const missingValues = []
	// these should always be provided but make sure they are
	if (!src) missingValues.push('src')
	if (!width) missingValues.push('width')
	if (missingValues.length > 0) {
	throw new Error(
	`Next Image Optimization requires ${missingValues.join(
	', '
	)} to be provided. Make sure you pass them as props to the \`next/image\` component. Received: ${JSON.stringify(
	{ src, width, quality }
	)}`
	)
	}
	if (src && !src.startsWith('/') && configDomains) {
	let parsedSrc: URL
	try {
	parsedSrc = new URL(src)
	} catch (err) {
	console.error(err)
	throw new Error(
	`Failed to parse "${src}" in "next/image", if using relative image it must start with a leading slash "/" or be an absolute URL (http:// or https://)`
	)
	}
	if (!configDomains.includes(parsedSrc.hostname)) {
	throw new Error(
	`Invalid src prop (${src}) on \`next/image\`, hostname "${parsedSrc.hostname}" is not configured under images in your \`next.config.js\`\n` +
	`See more info: https://err.sh/nextjs/next-image-unconfigured-host`
	)
	}
	}
	}
	return `${root}?url=${encodeURIComponent(src)}&w=${width}&q=${quality || 75}`
	}

I feel like these functions are simple.

I want to create a custom Loader func which receives LoaderProps, and set it in next.config.js as loader. When will that be implemented or not?

P.S.
The following is my custom loader. Default loader is a little different than mine.

function myLoader({ root, src, width, quality }: LoaderProps): string {
  const paramsString = `width=?${width}&quality=${quality || 75}`
  return `${root}${normalizeSrc(src)}${paramsString}`
}

Edit
@atcastle already had referred to custom loader. 🙏

#16832 (comment)

Support for self-hosted images
Though the Image component is designed with CDNs in mind, it will also work with locally hosted images. The application developer simply needs to add an image compression/resizing step into their build process, and write a custom loader that generates URLs pointing to the output paths used by that build process.

This shouldn’t be too difficult, as there are a variety of popular build tools for resizing images, and a custom loader can be as simple as a template string.

[styfle]

The // prefix won't work because the Image Optimization API needs to make the upstream request before optimizing and serving the image. We can't rely on the scheme/protocol because many Node.js servers run as HTTP with a HTTPS proxy in front. If we rely on headers, they can be faked.

It's best to use https:// when referencing external images.

[AlexandraKlein]

So excited about this component and all the work around it. Thanks to all involved!

🐛 Hope this isn't the wrong place to mention this, but I just noticed when testing the Image component that src attributes starting with a double slash, e.g. //images.ctfassets.net for Contentful images, seem to be treated as local assets instead of hosted assets. I'm getting around this for now by rewriting // to https://, but I suspect this might not be too deep of an edge case for hosted images 😄

@colepeters Having trouble with this. What does your next.config.js look like?

Edit: forgot to add domains: ['images.ctfassets.net'],. Works now with prepending https: to src.

[colepeters]

@styfle Just to be clear, the // prefix is being used by Contentful (and possibly other CMSes) as the prefix for URLs for image assets. I agree it'd be best to use https when referencing external images, but at the moment there is some user-level intervention required to do this, at least when referencing images served by Contentful. :)

@AlexandraKlein Here's what I've got:

module.exports = {
  images: {
    domains: [
      'images.ctfassets.net'
    ]
  }
}

What I'm doing is prepending https: to my src when using the Image component.

[AlexandraKlein]

With Contentful, when the image src prop changes within the same react component on route change, Image component isn't swapping out old image for new. @colepeters have you seen this?

Takes a browser reload to see new image.

Though adding a key prop triggers rerender populating correct image.

[colepeters]

@AlexandraKlein Sounds like another case of #18369

[mirshko]

I'm wondering if there's plans for a Contentful loader?

Contentful has an Image API similar to Imgix or Cloudinary, wondering it makes sense to use that directly?

[laSinteZ]

I'm wondering if there are plans to add support for custom loaders? Maybe, for example, user could pass a loader callback to <Image>, which receives LoaderProps and returns image url? I think it will be much easier for users to write their own loaders, than to wait for them to be added to Next.js

Anyway, are there plans for Cloudflire Resize loader? I think I could contribute...

[matamatanot]

@laSinteZ
Check #18450 out.

[AlexandraKlein]

@styfle Just to be clear, the // prefix is being used by Contentful (and possibly other CMSes) as the prefix for URLs for image assets. I agree it'd be best to use https when referencing external images, but at the moment there is some user-level intervention required to do this, at least when referencing images served by Contentful. :)

@AlexandraKlein Here's what I've got:

module.exports = {
  images: {
    domains: [
      'images.ctfassets.net'
    ]
  }
}

What I'm doing is prepending https: to my src when using the Image component.

This works fine locally for me but urls give me 400 errors in production with "url" parameter is required response.

Source url with 400 error: https://mywebsite.com/_next/image?url=https%3A%2F%2Fimages.ctfassets.net%2F1xkvhwkgcr51%2F6HODBVSFqUTbEKI7ilXx%2Ff9f16ab3552e973b764c922f06db181a%2Fmy-image.png&w=1200&q=75

Source url locally with no error: http://localhost:3000/_next/image?url=https%3A%2F%2Fimages.ctfassets.net%2F1xkvhwkgcr51%2F6HODBVSFqUTbEKI7ilXx%2Ff9f16ab3552e973b764c922f06db181a%2Fmy-image.png&w=1200&q=75

[AlexandraKlein]

I'm wondering if there's plans for a Contentful loader?

Contentful has an Image API similar to Imgix or Cloudinary, wondering it makes sense to use that directly?

PR in progress: #19117

[Jeffrey-FLS]

I made a component layer above next-image with Image as the naming component, and have set a function with autocompleting asset location if only filename is provided and am currently getting an error of "using relative image it must start with a leading slash "/"" Is there a way to turn this off? The app won't compile without it. Also, reason for the function is to shorten the length of the Image component by removing paths

[balazsorban44]

This issue has been automatically locked due to no recent activity. If you are running into a similar issue, please create a new issue with the steps to reproduce. Thank you.