Next.js3 min read
next/image in practice: sizes, priority and the LCP mistakes to avoid
next/image solves format, sizing and lazy loading for you — and then hands you two props, sizes and priority, that decide whether your LCP is 1.2s or 4s.
AVIF gives the smallest files at a given quality and is supported by all current major browsers, with WebP as a fast, universally-supported fallback and JPEG as the last resort. Serve them through content negotiation or a picture element, at multiple widths via srcset, with quality around 60–75 for photographs.
| Format | Best for | Relative size | Notes |
|---|---|---|---|
| AVIF | Photographs, complex images | Smallest | Slow to encode; excellent at low bitrates |
| WebP | General purpose | Small | Fast encode, universal support, supports transparency |
| JPEG | Fallback for photos | Baseline | No transparency |
| PNG | Screenshots with text, transparency | Large for photos | Lossless |
| SVG | Logos, icons, diagrams | Tiny | Scales infinitely; sanitise if user-supplied |
AVIF's advantage is largest on photographic content with gradients. On flat graphics with sharp edges, the difference narrows and PNG or SVG may be better than either.
<picture>
<source type="image/avif" srcset="/hero-800.avif 800w, /hero-1600.avif 1600w"
sizes="(max-width: 768px) 100vw, 800px">
<source type="image/webp" srcset="/hero-800.webp 800w, /hero-1600.webp 1600w"
sizes="(max-width: 768px) 100vw, 800px">
<img src="/hero-800.jpg" width="1600" height="900" alt="…"
loading="lazy" decoding="async">
</picture>Frameworks and image CDNs do this for you through content negotiation on the Accept header, which is simpler and keeps the markup clean. Hand-writing picture elements is only worth it when you have no image pipeline at all.
Yes, with a WebP or JPEG fallback via content negotiation or a picture element. Support is broad across current browsers and the fallback path costs nothing.
It uses far more sophisticated compression than JPEG. Encode at build time or through a CDN with caching, never synchronously in a request handler.
It is technically excellent but browser support has been inconsistent. Watch it, but do not build a pipeline around it as your primary format yet.
Three to five typically covers real device widths — for example 400, 800, 1200 and 1600. More adds storage and build time for little benefit.
ROVQIX Engineering
Engineering team, ROVQIX
The ROVQIX engineering team builds and maintains web platforms, APIs and infrastructure for clients across SaaS, ecommerce and enterprise. These notes come out of real production work — deploys, incidents, migrations and audits.
ROVQIXdesigns and builds production web platforms — Next.js front ends, Node.js APIs and the infrastructure behind them. Tell us what you're building and we'll scope it with you.
next/image solves format, sizing and lazy loading for you — and then hands you two props, sizes and priority, that decide whether your LCP is 1.2s or 4s.
Search engines still cannot see your images. Everything they know comes from the filename, the alt text and the words around it.
LCP is not one number, it is four phases. Optimising the wrong one is why so much performance work produces no measurable change.
No spam. Just the occasional case study and craft breakdown.