Investigate Cloudflare Images as an alternative to our `bakeDriveImages` baking step

[ikesau]

We currently bake gdocs images by pulling down the original versions from S3, resizing them multiple times, and uploading all the images to Netlify.

This is an inefficient process because we do the resizing every single time, instead of caching the efforts anywhere which is protracting our deploy times.

But before we improve that, we'd like to check and see if Cloudflare Images would be a better way to solve the entire problem.

This issue is an invitation for a team member to mess around with Cloudflare Images and try to answer the following questions:

• Approximately how much would it likely cost us to use in production?
• What would the Gdocs implementation look like?
• What would the WordPress implementation look like?
• How would it work with local development and staging environments?

If I'm not the one to do it, feel free to reach out to me to ask questions about the current baking process 👍

Update 2024-03-12: At this point this is mostly a nice to have for us devs because the image workflow is pretty complicated and occasionally breaks in annoying ways. #3199 was a motivation to reopen this issue and we still think that this and the simplification of the codebase would be worth a few days of dev time.

[ikesau]

Update: Marcel has done some tentative exploration into the service.

Results are promising, though one caveat is that SVG tags get all metadata stripped, which, given that we want all our new static charts to be SVG with embedded webfonts (#2518), precludes CFI from being our be-all and end-all solution for all image hosting.

We would still want to use it for legacy images, the team page, etc.

If we discover that we can't use SVGs at all, then we could use it for everything.

[larsyencken]

Closing this for now, we can still investigate further later.

[ikesau]

We could do some nice things like content graph integration and GPT alt text if we started uploading images via the admin instead.

Technically these features could be implemented with Google Drive, but it would be more complex and annoying. Google Drive doesn't allow us to configure an event handler for file uploads (only per-minute polling), so the flows would become more complex for little gain.

We should evaluate all the important user stories for the image workflow to make sure the admin implementation handles them nicely.

Here are some that I can think of:

• As an author, I want to be able to upload an image and see it in my preview article
• As an author, I want to be able to upload a new version of an image and trigger rebakes of the articles that use it
• As an author, I want to be able to search for images by filename and type
• As an author, I would like to be able to see where an image is used
• As an author, I would like to know that my featured images are the correct aspect ratio
• As an author, I would like to know when my images are too low resolution
• As an author, I would like to know that my source images aren't too large or too small
• As an author, I want uploaded images to have alt text automatically suggested when I upload a new image
• As an author, I want to be able to regenerate alt text when I upload a new version of an image
• As a reader, I want to be able to download the source image in a widely-supported file format (i.e. PNG or JPEG)
• As a reader, I want to load the smallest image for my display
• As a developer, I would like to be able to use my own images to test things with
• As a developer, I would like to easily debug authors' articles

[ikesau]

Here's a datasette query showing all our posts with featured images with aspect ratios that are more than 0.1 off our target of 1.9

Not required for this feature, but it would be nice if we could design it in such a way that bulk updating all these images to ones with correct aspect ratios would be possible.