Hacker News Reader

Comment by r6203 | Hacker News Reader

I don't get it. It's still not possible to use next/image (without some fancy loader or 3rd party service) when exporting a SSG build.

Are people really not using responsive images when exporting a static site? Seems quite ridiculous to rely on some 3rd party service for image optimization when the images could be generated locally when exporting the site...

View on HN

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.

This argument doesn't really make sense.

> 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.

When I said hard, I didn't mean technically. I meant it's hard for Next.js to decide how to solve the problem so it works for everyone. I'm doubtful if it even makes sense for them to try to support every possible use case.

There are solutions available to all of these problems today. You can pick the ones which you prefer or fit your workflow.

Agreed on this, I'd much rather do the image optimization at build time and just push it in an /asset folder or similar.

However I assume this isn't done because it doesn't scale well. On my website with 10 images it might work, but what happens when I have 1,000, that doesn't bundle well.

Just use Gatsby v4 if you want good image support! v4 brings Gatsby in-line with Next.js because it introduced runtime SSR support like Next.

I assume that Gatsby generates the different widths/formats at build time. How well does that scale? Like if you have a thousand images, what's the build time like?

We have a job framework that can distribute image processing jobs on supported platforms* as well as automatically caching subsequent jobs. So it scales easily and as most builds don't have that many image changes (if any), the impact on warm builds is negligible.

* like Gatsby Cloud https://www.gatsbyjs.com/products/cloud/

It's similar to generating compressed files with the build. I think it belongs on the web server layer.

Here's an open source, self-hosted one, that should be easy to integrate with Next.js:

https://github.com/willnorris/imageproxy

To define a custom one, you need only provide a function:

https://nextjs.org/docs/api-reference/next/image#loader

It is definitely an awkward design choice, but image services often generate the images on demand, by having one and creating the otherones at request + caching. A static build does not have the capacity to cache images, unless it generates a really large number of them during build!

Right, this could work for small sites, but not sites with a ton of images.

Maybe I'm missing something, but aren't we able to use `next/image` to transform local assets since v10?

The imperative phrase is

> when exporting a static site

i.e. running `next export` to generate a bunch of HTML, JS and CSS files that you just serve from a static file server. It would be nice if that could generate responsive versions of your images too.

See for the feature request: https://github.com/vercel/next.js/discussions/19065

Reply on news.ycombinator.com