> God forbid that the solution is committing binary images to the Git repository.

Where does the misconception that that's somehow a problem stem from? In 30 years of having web sites, that approach has invariably served me well.

From what I read and experienced, it makes the size of the Git repository much bigger than it should be with how Git tries to keep copies of old binary files (specifically the data and hash) since it cannot diff those unlike plaintext. You eventually have cache of the old files in the repo if you're not deliberate with setting --depth when cloning.

> From what I read and experienced, it makes the size of the Git repository much bigger than it should be...

Of course, it's a trade-off, but how is that particular one more painful than being at the whims of (and paying for) a third-party provider for something as mundane as static image files?

Together with the static site, in /img/ directory next to the html files.

i've always used /art/

as data uris. the whole static site is on one of a couple different CDNs depending on region.

Like encoded base64 and using a post-processor to convert the images?

yup. also, i've started denoising and converting images to avifs. amazeballs compression. sometimes denoising introduces artifacts in the "whatever" to AVIF conversion, so ymmv.

im using Cloudflare for my static content (includes images)

I see. I considered doing a static site dedicated to images on Cloudflare Pages and hotlinking from there. According to the docs[1], Cloudflare Pages projects support up to 20000 files.

[1]: https://developers.cloudflare.com/pages/platform/limits/