Version 3

Background

This project started out as a small package. Over time, more and more features were added and it now provides many different things and is used by many developers. But I’m not 100% happy with the current version for the following reasons:

• it depends on many different webpack loaders which has led to some workarounds and many features cannot be combined because the loaders don’t work well with each other. See #84, #91 for examples.
• those loaders also depend on other packages which have also introduced errors/bugs where we don’t have the possibility to fix them directly (as in #75).
• while this package grew, the installation and configuration became more and more complex and I think there is some space for improvement here.

Idea

To make this package robust for the future and easy to maintain, I think the only way is to fix those issues. And this probably requires a rewrite of the whole package.

It can be broken down into multiple parts:

Webpack loaders

This is the most important part of this package and is currently out of our control. To support use-cases such as mentioned in #84 or #91 and so we are able to provide a stable plugin, I think the only way is to write an own webpack loader which does the image optimizations. That would have the following advantages:

• all features work together (e.g. you can resize a jpg, convert it to webp and generate a lqip all at the same time, which is not possible right now)
• we have more control over the libraries used for image optimization (that part would of course still be a 3rd party library)
• it would be published as a separate loader and could also be used outside of a next.js project

Next.js plugin

This plugin would configure the independent webpack loader for easy use with next.js. It should also support the upcoming next.js plugin system for an easy installation.

Support run-time optimization

One of the most requested features was to be able to optimize images during run-time (e.g. from an API) and not only local images during build-time (see #104, #77, #74). With the API routes introduced in next.js 9, I think it should be possible to provide an easy-to-use service for that. It obviously can’t relay on webpack, but the code used in the webpack loader should be reusable. That would have the following advantages:

• it is possible to optimize images returned from an API/3rd party service
• they would have exactly the same optimization options and query strings so you can use them exactly the same as a local image

But this feature would need to be defined more detailed (e.g. it would need a store, like S3, so images are not optimized on every request, and this API would be best located behind a CDN, etc.).

Provide image components

Creating an image component is not easy, especially if you want to support all features of this plugin (webp fallback, lqip, srcset, …). And you still have to think about what happens when JS is disabled (while lazy loading), how it has to be optimized for screen readers and search engines and so on. So if you want your images to be working well for everyone, it is not just <img src={require('./image.jpg')} />, there is a lot more work to do and you don’t want to do this again in every project.

So I’m thinking about providing an image component that will work well with this plugin and already does most of the things for you (non-JS fallback, a11y, lazy loading with fallbacks, …).

It should support the following things:

• webp with fallbacks for old browsers (see #111)
• lazyloading using either a low quality image placeholder (Blur Up), Image Outlines or Dominant Colors

Additionally, it would be nice to provide a babel plugin which makes it even easier to use this component. So instead of this:

<Img
  src={require('./image.jpg')}
  sizes={{
    100: require('./image.jpg?resize&size=100'),
    300: require('./image.jpg?resize&size=300'),
    600: require('./image.jpg?resize&size=600')
  }}
  lqip={require('./image.jpg?lqip')}
/>

You would only use it like this and the babel plugin will transform it to the way more complex way above:

<Img src={require('./image.jpg')} sizes={[100, 300, 600]} lqip />

Feedback wanted

I am of course open to any feedback on any part of this idea. Also, if you have ideas of new features, now would be the time as they could be included from the beginning of the new version.

I am not quite sure on which image optimization library this should be based on. Right now, it is mainly imagemin but I am not really happy with it since it is not easy to install, especially in some CI/CD environments since it requires specific binaries to be installed on the system. So I was thinking about using sharp as the main optimization library as it is a lot easier to install, has a great node API and is still quite fast compared to other node libraries.

Feedback on this would be very appreciated, especially:

• has someone made experiences with both libraries? (regarding speed, simplicity, …)
• would you switch to another library?
• if the decision falls for sharp, should imagemin (or others) also be additionally supported?

Is there an ETA?

No, development has started but is in the early stages. The features mentioned above are quite complex and require a lot of work, so it will probably take some weeks. But I will update this issue when progress is made and when a canary version is available.

[cyrilwanner]

I’m sorry for the long silence on this issue. I just didn’t have much time to work on this over the last few months, unfortunately. But yes, all this is still planned and will come. Last week, I started to work on this issue again so I’ll hopefully be able to share some progress soon.

Currently, I’m working on compiling the different image optimization tools into WebAssembly so we are able to make the whole installation (especially in a CI/CD environment) a lot easier and more consistent. Squoosh, unfortunately, doesn’t provide their compiled WASM binaries as packages, but I’m slowly getting there. That’s probably the biggest and most time-consuming part. So once that is done, the other features are way easier to implement.

[cyrilwanner]

It was a lot of work and there is still a lot to do, but the first canary version is now available 🎉

Not all planned features are already available. The remote image optimization & lazy loading components (like blur-up) are missing. But they are still planned and will get added soon to the canary version. Other than that, I think most of the planned features are now done and stable.

Some of the new features are:

• Image optimization is performed either in node or WebAssembly - there is no need for imagemin plugins anymore and so no native binaries are required (= works in every environment out of the box)
• Build cache for images - results in way faster builds and images are also optimized in the dev environment by default
• Image components are provided for even easier use - there shouldn’t be a need to use query params anymore normally (a babel plugin does that now for you)
• images.config.js for global configuration and definition and re-use of image types and their options
• Full typescript support thanks to the provided image components
• Query params can be chained now - for example ?webp&width=400
• …and more. Read the readme file for an overview of all features.

I suggest you check out the readme on the canary branch for more details.

---

Any feedback, further ideas, or bug reports are of course very much appreciated and will help to bring the canary version to the @latest tag faster. The babel plugin for the image components probably doesn’t recognize 100% of all use-cases, so if you find any, please share them if possible.

I would be very happy if some of you could test the canary version and report back if something is not working. Or if some of you have open-source projects using this package, it would already help if you can share them with me so I can see if there are some use-cases I did not think about and try it myself to update next-optimized-images to the canary version.

Also, if you find anything unclear in the readme or upgrade guide, don’t hesitate to ask. It was already late when I wrote there so it is possible that not everything is 100% is explained well enough.

---

If you want to update this plugin in an existing project, please read the upgrading guide guide as some breaking changes were introduced.

Also, not yet all features previously available are already in the canary version. If your project depends on one of the following features, you may have to wait a few more days until they were ported into the new version:

• Gif optimization (gif images can be used normally, they just don’t get optimized)
• ?trace query param
• ?sprite query param

---

And thank you all for your continued support and feedback. I understand that it took a long time to get to this point, but I’m very happy with the result and think that it was worth it. And the remaining todos won’t take that long anymore.