Thank you Guillermo. One thing I am still curious about is, is there still a difference between serverside rendering and static site generation for things such as next/image, next/font, etc? Last time I tried SSG, next/image was not supported, but I could use a third party tool to optimize my images correctly, so I didn't understand why next/image couldn't do the same optimization at build time without relying on a CDN as in the case of SSR.
One fascinating thing (especially in view of this topic) about `next/image` is that the primary reason we decided not to optimize upon `next build` or `next export` is that we'd have all these customers migrating from Gatsby telling us their build performance was holding them back, and a big chunk of that was `sharp` optimization and overly eager static generation. Image optimization fits a "dynamic" model much better.
… it shows how Vercel lazily optimizes _specifically_ (1) for the images in viewport and (2) for the devices requesting those images. And new pages and images can be added without redeploying.
I think we could still put image optimization behind a flag with a durable cache at build time (think: `next export --optimize-images`), but it's always been hard to prioritize it as the world moves further away from pure-static solutions
As a userspace alternative, I don't think it'd be too hard to do a post-build script that runs `sharp` on a `source-images` folder, outputs it to `public/static-images` with content-addressable checksums, and sets `cache-control` in `next.config.js` `headers` to `public, max-age=31536000, immutable`. Oh, and you could first check if there work has already been done in `.next/images-cache` or something that the CI provider would cache across builds, to make it a bit faster.
