|
I have a system that supports optimized images in SSG that doesn't rely on any third-party services. But it requires custom config (babel macro plugin), though it only works for the most trivial websites. Let's break it down why its hard. If you want responsive, optimized images in a SSG context, without any dependency on 3rd party services, your only option is to pre-generate images at build time. Fair enough, you can go through all your images and pre-generate them at different size and different format. You can do that manually, or automate that for example by using a babel macro. Let's say you want provide resized images at 4 different widths, and support jpeg, avif, webp. That means a whole lot of CPU that you need to burn during build (even with sharp, resizing images takes time), and uses up loads of storage (that you need to ship to your static web server). If your site has anything but a trivial amount of images, the CPU usage will turn your 60 seconds deployment into a 30 minutes deployment (or longer), that doesn't scale. You can store the generated images in the git repository, but that quickly blows up the repository size, so it's not ideal either. You can use a cloud storage service to cache the generated images (self-hosting that on AWS, GCP or your own blob storage service is not difficult) but introduces a dependency on an external service. How do you imagine optimized and responsible images in a SSG context to work? I (and pretty sure the Next.js developers as well) am curious about any suggestions… PS. I'm happy to share my babel macro, but as I said, it's only usable for the simplest of simple websites. |
> That means a whole lot of CPU that you need to burn during build
This doesn't makes it hard, and I'd rather spend the CPU once than at every edge server on first request.
> uses up loads of storage (that you need to ship to your static web server)
Uploading to S3 (for example) is free, and the edge servers need to store the images anyways (because they are slow to generate as you just mentioned).
> your 60 seconds deployment into a 30 minutes deployment (or longer), that doesn't scale.
Says who? It's a static site so it's not being updated every 30 minutes, and with some intelligent incremental compilation I bet it would remain fast even for the largest sites.