Pin `formats` before you take the next/image v4 bump

A post on dev.to argues that most Next.js image performance trouble in 2026 comes from one routine act: upgrading to `next/image` v4 without noticing that AVIF is now the first entry in the default `formats` array, and that the `domains` option has been retired in favor of `remotePatterns` ^[1][3][7]. Neither change announces itself during the upgrade, which is exactly why they land in production as latency and broken image loads rather than as a decision someone made ^[1].

The trade is legible once you write it down. AVIF is claimed to produce files 20 to 30 percent smaller than WebP at equivalent visual quality, and to cost 3 to 5 times more encode time ^[4][5]. The post's worked example, an 80KB WebP product image landing at 55 to 60KB as AVIF, actually implies a 25 to 31 percent saving, slightly better than its own headline range ^[10][11]. Set against the claim that images are 40 to 60 percent of total page weight, the best case whole-page byte saving is roughly 8 to 18 percent ^[9][18]. Real, worth having, not worth an outage.

The outage path runs through fallback. Users on Safari 15 or older Android browsers do not get AVIF; the component reads the `Accept` header and regenerates a WebP variant on demand, which produces a first-request latency spike and doubles server-side optimization work for that cohort ^[12]. The post puts AVIF support past 90 percent global coverage in late 2025 and separately advises reconsidering the default if analytics show 5 percent or more of traffic on pre-AVIF browsers ^[6][13]. Those two numbers sit awkwardly together: 90 percent coverage means up to 10 percent of global traffic on the slow path, twice the threshold the post itself sets ^[19]. Your own analytics decide this, not a global average.

`remotePatterns` is the second tripwire and the more abrupt one, because it enforces protocol, hostname and pathname matching where `domains` matched hostnames alone, so existing third-party image sources stop resolving ^[7]. Alongside it, `maximumDiskCacheSize` and `contentDispositionType` are the settings the post says teams skip, with disk exhaustion and CDN cache bypass as the consequences ^[8]. Cache bypass is the expensive one: it turns a 3 to 5 times encode penalty into a per-request cost instead of a once-per-variant cost ^[5][8]. The post also flags `priority` and `sizes` as routinely misconfigured, with priority images needing manual preload links in layouts and wrong `sizes` values generating oversized variants ^[15].

The mitigation is unglamorous: state `formats` explicitly rather than inheriting it, for example `['image/webp', 'image/avif']` with pinned `deviceSizes` and `imageSizes`, so the format order is a choice in your repo instead of a framework default that can move under you ^[14].

One caveat on provenance. This is a single source, and it discloses that it was written with AI assistance under human supervision and review ^[16]. Treat the version numbering, the coverage figure and the config names as prompts to check the release notes and your own `next.config` diff, not as settled fact.

What to watch after the bump: CDN cache hit ratio on the optimizer route, p95 image response time segmented by browser rather than in aggregate, disk cache growth on the node doing the encoding, and error rates for remote hosts that previously passed under `domains` ^[7][8][12].