Prismic Image Optimization for Slice-Based Sites

Prismic is built around slices: reusable, structured blocks that content editors compose into pages without touching code. It is a clean model, and the image field that ships inside it is genuinely good. Every image gets served through an Imgix-backed URL API, so you can resize, crop, and reformat with query parameters.

That API is a strong tool. What it is not is a decision. It will execute any transform you ask for, on any asset, in any slice, but it will never tell you how much quality that particular image needs. Somebody, or something, still has to choose.

In practice that somebody is an engineer who picks one quality parameter, wires it into the slice component, and moves on. The number ships to every asset the slice ever renders. That is where the performance and the fidelity both quietly go wrong.

Key Takeaways

• Prismic serves images through an Imgix-backed URL API. It executes transforms, it does not judge quality.
• Images are the single heaviest resource on most pages, and the leading cause of a failed Largest Contentful Paint (HTTP Archive Web Almanac, 2022).
• Slice-based sites make the problem worse: one quality parameter, baked into a component, ships to every asset that slice ever renders.
• AVIF routinely lands 30 to 50% smaller than equivalent JPEG (web.dev, 2021), but format is table stakes. The quality decision per asset is the real work.

Does Prismic optimize images for you?

Partly, and it is the easy part. Prismic exposes images through an Imgix-backed URL API, so a single asset can be resized, cropped, and reformatted on the fly through URL parameters (Prismic docs, 2026). What it does not do is decide how much quality a given image actually needs before it ships.

That is the distinction that matters. A transform API is a mechanism for carrying out a decision. It is not a mechanism for making one. You still specify the quality parameter yourself, and the moment you hard-code that value into a slice component, you have applied one number to a photograph, a logo, a UI capture, and a flat background, as if they had the same requirement.

They do not. The broader pattern across the category, a content API plus an image layer you build on top, is covered in the guide to image optimization for modern CMS platforms.

What does the Imgix-backed layer actually do?

It handles delivery mechanics, and it handles them well. The Imgix layer resizes to the requested dimensions, converts formats, and serves from a CDN with caching. On photographic content, moving from JPEG to AVIF alone typically cuts 30 to 50% of the bytes at matched quality (web.dev, 2021), and AVIF now has support across every current major browser (caniuse, 2026).

So the plumbing is solid. The gap is upstream of the plumbing. Imgix will faithfully render q=75 or q=45 on whatever asset you point it at, but it has no view on whether 75 is wasteful here or 45 is destructive there. It executes. The judgment is yours, and if the judgment is a single baked-in constant, you have automated a guess.

Why does that matter more on Prismic than on a page-by-page site? Because slices multiply the guess.

Why do slices make the quality decision harder?

Because a slice is reused, so one hard-coded quality value fans out across the entire site. A single hero slice might render a moody editorial photograph on one page and a screenshot on another. Bake q=60 into that component and you have made the same quality bet for two assets whose detail requirements are nothing alike.

That is the structural trap of slice-based architecture for images. The abstraction that makes Prismic pleasant to build with, one component, many instances, is exactly what turns a single quality mistake into a site-wide one. Set it aggressively and you strip detail from the assets whose detail was the point. Set it conservatively and you carry dead bytes on everything else.

The reason this stays invisible is that both failure modes report as success. The only thing being measured is file size, so a too-aggressive setting looks like a win and a too-soft setting looks safe. Neither is checked against what the image actually needed. That argument in full: why file size is the wrong metric, and the specific slice-scale version in why blanket compression hurts your CMS.

What should you configure first?

Start with the mechanical checklist, because it is well understood and it genuinely helps. Roughly 40 to 60% of typical page weight is images, so the mechanics move real numbers (HTTP Archive Web Almanac, 2022). Get these right before anything clever.

The Imgix parameters worth setting

Serve AVIF for photographic slices with WebP as the fallback. Request responsive widths through the URL API and wire them to a srcset so a phone is not pulling a desktop hero. Set explicit width and height on the rendered element to protect Cumulative Layout Shift. Above all, never lazy-load the image that is your Largest Contentful Paint, which is the most common own-goal in the category (web.dev, 2023).

The part the checklist leaves open

Every item above still leaves you choosing the quality number. You can serve a perfectly-sized AVIF and still ship it at the wrong quality for that asset. Completing the checklist is necessary. It is not sufficient, and it never touches the per-asset decision. More on that boundary in core web vitals and image weight.

How does per-asset optimization fit the Prismic flow?

The principle is simple: the quality decision should be made per asset, at publish time, so no single baked-in constant fans out through your slices. Each image is evaluated on its own content, routed to the right path, verified, and delivered. Editors keep composing slices exactly as they do now. Nothing about the authoring experience changes.

In our own testing across mixed Prismic libraries, the assets that punish a single global quality setting hardest are exactly the ones editors care most about: the full-bleed editorial hero and the fine-detail product shot. A per-asset path treats those differently from a flat background by design.

Under the hood, our Neural Media Orchestrator evaluates each asset and selects the optimal path from 352 possibilities, delivering up to 95% neural compression savings on photographic sources while holding structural similarity at or above 0.975 against the original. It is Pareto-safe by routing, so it never returns a result larger than the strongest adaptive baseline. The comparison against conventional codecs is in neural vs adaptive compression.

How do you know it stays safe?

Because every optimized asset is verified against a perceptual quality floor before it is delivered, and anything that cannot clear the floor falls back instead of shipping degraded. The floor is structural similarity at or above 0.975 against the original. If an asset can hit its size target within that bar, it ships small. If it cannot, the system keeps the safer version.

That verify-and-fallback step is what separates automatic optimization from automatic damage. A slice component that bakes in one quality number has no such check: it ships whatever the constant produces, on every asset, forever. We publish the full methodology in how we benchmark. If you also run a heavy editorial pipeline, the Ghost publisher walkthrough covers the same decision from the newsroom side.

Frequently Asked Questions

Does Prismic optimize images automatically?

Prismic serves images through an Imgix-backed URL API that resizes, crops, and reformats on demand. It executes any transform you request, but it does not decide how much quality each asset needs. That decision stays with you.

Why is a single quality setting a problem on slice-based sites?

Because a slice is reused across many pages, so one hard-coded quality value fans out to every asset that slice renders. A photograph and a screenshot end up sharing the same quality bet, which is wrong for at least one of them.

What image format should I use with Prismic?

Request AVIF for photographic content through the Imgix parameters, with WebP as the fallback. AVIF typically runs 30 to 50% smaller than equivalent JPEG. Format is table stakes, though; per-asset quality is the harder decision.

Do I need engineers in the loop for every image?

Not if optimization runs at publish time on each asset. Baking a quality parameter into a slice component pushes the guess to engineering once and repeats it forever. A per-asset publish-time path removes that constant.

Will automatic optimization degrade my images?

Not with a verified perceptual floor. Every asset is checked against structural similarity at or above 0.975 before delivery, and anything that cannot clear the bar falls back to a safer version rather than shipping degraded.

The point

Prismic gave you a clean, reusable content model and a capable Imgix-backed transform API. Both do their jobs. The image field will render whatever quality you ask for, faithfully, on every slice instance.

That faithfulness is the trap. A transform API executes decisions; it does not make them, and a slice architecture takes one hard-coded quality guess and multiplies it across your whole site. Move the quality decision to where the asset actually is, per image, at publish time, verify it against a perceptual floor, and the guess stops fanning out. The category-level version of this is in the CMS image optimization hub.