Next.js Adventures: Some Blasphemy Against The Holy Image Component

Dear Next.Js Aficionado,

I don’t want to spoil the party, you know…

So if you believe that the component is the finest solution for handling images ever invented, then I suggest you stop reading and go find other exciting stuff.

I’m about to tell a “horror story” involving the component, and I don’t want to destroy the happy bubble you’re living in.

You’re still here?

Good.

I’m glad you’ve chosen to be informed…

In the end, everything in this world has its pros and cons. The image component isn’t an exception to the rule. And there’s nothing wrong with pausing for a moment and talking about the possible pitfalls.

First, it’s important to mention that my website isn’t deployed with Vercel.

So all the cool stuff that comes automatically with their service isn’t available to me — the special image loader, the edge network optimization, etc.

Those are out of reach…

My website’s containerized and deployed with Google’s Cloud Run.

If you’re not familiar with the service, it’s “a managed compute platform that enables you to run containers that are invocable via requests or events.” Cloud Run is serverless, but it’s a kind of middle ground.

It’s not a cloud function nor – a virtual machine.

My favorite feature is the automatic scaling. That means my new site runs on a single instance most of the time. It’s super cost-effective.

But when a traffic spike happens, Cloud Run automatically creates new instances up to the maximum number I’ve set.

And here comes the kick…

If Next.Js uses the default image loader, which creates a local cache of the optimized copies, then the new instances don’t have access to that cache and need to optimize every image by themself.

So you have traffic ups and downs… Cloud Run constantly starts and kills new app instances… and each new app instance optimizes every image anew.

Yeah, pretty bad setup…

We need a custom loader in that scenario.

And when we use a custom loader, we need to apply the optimizations ourselves because 60% of the fantastic image handling features are unavailable.

However, don’t take this short article personally.

I’m not saying that the component isn’t handy. After all, many smarter than me people talk about it very favorably, like the authors of the article “Building an Effective Image Component.“

But we need to be careful…

Cheers,
Sashe Vuchkov