Next.js 11 shipped a rewritten image component that promises automatic lazy loading, responsive sizing, and layout-shift prevention out of the box. We put it in front of a real client project, a mid-sized marketing site with a couple hundred images across product pages and blog posts, to see whether the migration effort was worth the payoff.
The built-in blur-up placeholder and explicit width and height requirements forced us to audit every image on the site, which was tedious but caught several unoptimized assets we'd been shipping for months without noticing, including a few hero banners that were still full-resolution PNGs exported straight out of a design tool. Lighthouse scores for largest contentful paint improved noticeably on image-heavy landing pages, dropping by roughly a second and a half on the slowest pages we tested, and cumulative layout shift dropped close to zero once every image had explicit dimensions the browser could reserve space for ahead of time.
The migration wasn't entirely painless. The image optimization pipeline in Next.js 11 runs through a server-side loader by default, which meant our plan to eventually move this site to a fully static export had to be shelved; static export and the built-in image optimizer don't play well together unless you configure a custom loader pointing at an external image service. We ended up wiring the component to our existing CDN's image transformation endpoint instead of the default Next.js loader, which took an extra afternoon but sidestepped the static export limitation entirely and gave us more control over caching headers.
A second gotcha showed up with SVGs used as decorative icons rather than photographic content. The image component's automatic sizing logic assumes raster images with meaningful intrinsic dimensions, and a handful of icon components needed to be pulled out of the migration and left as plain img tags or inlined SVG instead. Domains for externally hosted images, in our case a handful of author avatars pulled from a CMS, also needed to be explicitly allow-listed in the Next.js config, which is a small detail but one that will silently break a build in a way that isn't obvious from the error message alone.
For any Next.js project with more than a handful of images, the migration pays for itself within a sprint. The bigger win is cultural: it forces a level of image discipline most teams don't get around to on their own, since every image now has to declare its dimensions and go through a single optimization path rather than being dropped in ad hoc by whoever is editing a page that week. We're rolling the same pattern out to two more client sites before the end of the quarter.