Next.js next/image WebP vs Pre-Converted WebP: Which Is Faster?

If you use Next.js, you have two paths to serving WebP images: let next/image convert them automatically at runtime, or convert them to WebP before deployment and serve the pre-converted files directly. Both produce WebP in the browser. But the performance characteristics are very different. This post breaks down exactly what happens in each approach and when to pick which.

How next/image's on-demand conversion works

When a browser requests an image through Next.js's image optimization pipeline, the server does the following on the first request:

1. Reads the source image from disk or fetches it from a remote URL
2. Decodes the image into a raw pixel buffer
3. Re-encodes it to WebP at the requested quality and dimensions
4. Writes the result to a disk cache (typically .next/cache/images/)
5. Streams the WebP response to the browser

On every subsequent request (same URL, same width, same quality), Next.js reads the cached WebP from disk and skips re-encoding. The cache is keyed by URL + width + quality + format, so a 400px and an 800px render of the same image are cached separately.

The cold-start penalty

The first request for each image variant is slow. Here are typical encoding times on a mid-range cloud VM (2 vCPU):

On a serverless deployment (Vercel, AWS Lambda) the cold-start happens on every instance spin-up. High-traffic pages get warm caches quickly; low-traffic or long-tail pages serve slow first renders to every new user who visits while the server is cold.

Pre-converted WebP: the static approach

The alternative is to run a build-time conversion step — using sharp, cwebp, or an online tool like Picovert's PNG to WebP converter — and commit the resulting .webp files to your repository (or upload them to a CDN). You then reference the .webp directly in your markup:

<img src="/images/hero.webp" width={1200} height={630} alt="Hero" />

Or, if you still want Next.js's responsive resizing but not its format conversion, pass a .webp file to next/image — the optimizer detects WebP input and skips re-encoding, serving it directly (with only resizing if needed).

Head-to-head comparison

When to use next/image on-demand conversion

• User-generated content — images are uploaded at runtime and unknown at build time. Pre-conversion isn't possible.
• Large image libraries — hundreds or thousands of product images where pre-converting everything adds minutes to CI.
• Traffic is concentrated on popular pages — the warm cache makes cold starts rare in practice.
• You need AVIF support — next/image negotiates the best format per browser. Pre-converting to AVIF is slow at build time; serving AVIF to supporting browsers and WebP as fallback is nontrivial without the optimizer.

When to pre-convert to WebP

• Marketing/landing pages — small image count, high traffic, where every millisecond of TTFB matters.
• Static site generation (SSG) with a CDN — once built, the WebP files are served directly from edge nodes with zero server processing.
• Serverless deployments with unpredictable cold starts — eliminating encoding latency guarantees consistent first-byte times.
• Images that don't change often — logo, hero image, OG thumbnails — where the build-step cost is negligible.

The hybrid approach

Most production Next.js apps benefit from combining both strategies: pre-convert the small set of critical above-the-fold images (hero, LCP candidate) to WebP, and let next/image handle the long tail of dynamic or less-critical images. This gets you near-zero LCP latency on the images that matter, without a massive build-step overhead for your full image catalog.

Bottom line

next/image's on-demand conversion is the right default for most apps. But for images that are on the critical render path — hero images, above-the-fold thumbnails, OG images — pre-converting to WebP removes the cold-start penalty entirely and delivers consistently fast first renders regardless of server state. The two strategies complement each other.