Add opt-in Cloudflare binding image optimization during build#16194
Add opt-in Cloudflare binding image optimization during build#16194Desel72 wants to merge 4 commits into
Conversation
🦋 Changeset detectedLatest commit: 9aae56e The changes in this PR will be included in the next version bump. Not sure what this means? Click here to learn what changesets are. Click here if you're a maintainer who wants to add another changeset to this PR |
There was a problem hiding this comment.
I'm not sure if this is correct. In theory the image binding should have sharp for prerender optimization. And the binding should be available when workerd is used for prerendering.
cc @OliverSpeir @Princesseuh who might have more context to share
|
Cloudflare-binding intentionally does not transform images on pre-rendered routes locally during build. The intention is they go to the image endpoint at request time as well, one benefit of this is faster build times |
|
It should use the cloudflare binding itself to optimize them during build time though, not sharp. So like during |
|
Thank you for the context, @alexanderniebuhr! I think I misunderstood the design intent behind |
@Desel72 yeah after discussion we think this the the better way. I'll update the original issue so it makes more sense. Would you like to still work on that? If so, do you want to use this PR or should we close it and you can create a new one? |
|
I'd love to use this PR @alexanderniebuhr I will solve perfectly. |
|
Hi @matthewp @alexanderniebuhr I've done. Welcome to your feedback. Thanks |
|
@Desel72 we are going to review the PR as soon as we have bandwidth, but please fix the failing lint check :) |
|
@alexanderniebuhr Thanks for your reviewing. I've solved. |
|
Hi @alexanderniebuhr is there any update on this PR? |
|
We are still reviewing this. Current state is that this should be put behind a option, so users can opt-in and opt-out and the changeset can't be a patch, since it's a breaking change. |
alexanderniebuhr
left a comment
There was a problem hiding this comment.
Please make sure that this is a major change, which means we need to update the changeset as well as have an docs PR. The behavior should also put behind a flag so users can opt-in or opt-out. I suggest using the triplet configuration suggested here: #15662
Hi @alexanderniebuhr, how are you? Sorry for the late. I've solved this. Please review this. |
|
@alexanderniebuhr |
|
Hi @alexanderniebuhr, I addressed the requested changes from the Apr 16 review:
Local verification:
Could you please re-review when you have bandwidth? |
|
@alexanderniebuhr |
… in cloudflare-binding mode (withastro#16035) When using the default `cloudflare-binding` image service, prerendered pages had un-optimized images because the IMAGES binding was only used at runtime. Now during the build, `handleStaticImagesRequest` uses the IMAGES binding in workerd to transform images, and the optimized bytes are written directly to the output directory. Falls back to Sharp if the binding is unavailable.
…pt-in config
Per maintainer feedback, the new behavior is now opt-in via the compound
`{ build: 'cloudflare-binding', runtime: 'cloudflare-binding' }` config.
The string shorthand `'cloudflare-binding'` preserves the historical
runtime-only behavior and is unaffected.
- Extend ImageServiceConfig type with a second compound form for `cloudflare-binding`
- Add `transformAtBuild` flag returned from normalizeImageServiceConfig
- Bump changeset from patch to minor since this adds a new config option
Changes
imageServiceconfiguration for using the Cloudflare Images binding during build-time prerendering. The defaultimageService: 'cloudflare-binding'shorthand keeps the existing runtime-only behavior.workerdprerender worker to transform static images, writes successful transforms to the client output, and falls back to Sharp only when a transform is not returned by the binding.Testing
cloudflare-bindingconfig opts into build-time transforms.Docs