Lighthouse kept warning me about inefficient cache lifetimes, even though I had already added caching for my static files.
The missing piece was Nuxt Image and its generated URLs.
In this post, I’ll share the simple caching setup I use for Nuxt build files, public assets, and optimized images without risking stale content after deployment.
The basic rule is simple: Cache files aggressively when changing the file also changes its URL.
Be more careful when the same URL can serve different content later.
You have probably seen the same Lighthouse warning I have: Use efficient cache lifetimes.
Browser caching for static files is usually straightforward.
You add a header, choose a reasonable lifetime, and the browser avoids downloading the same files again on every visit.
However, in a Nuxt application, not every static-looking file should use the same caching policy.
Nuxt build files are automatically versioned.
Files inside usually are not.
Nuxt Image also creates transformed image URLs under , which need their own cache rule.
In this post, I’ll go through the setup I use, including the Nuxt Image rule that was missing during my latest Lighthouse audit.
The simple caching rule The most important question is not whether a file is an image, font, or JavaScript file.
The important question is: Will the URL change when the file changes?
When the answer is yes, you can safely cache the file for a very long time.
When the answer is no, you should use a shorter cache lifetime.
Otherwise, visitors may continue seeing an old version after you deploy an update.
What the cache directives mean Here are the main directives used in this setup: allows browsers and shared caches such as CDNs to store the response. controls how long the browser considers the file fresh. controls how long shared caches such as Cloudflare consider it fresh. tells the browser that the file is not expected to change while that URL exists.
The important one here is .
You should only use it when changing the file also results in a new URL.
The three main asset types in Nuxt
1.
Nuxt build files: Nuxt and Vite generate filenames that contain a content hash.
For example: When the file changes, its hash changes too.
That means the URL changes: might become something like: after another deployment.
This makes Nuxt build files perfect candidates for aggressive caching.
You can cache them for a year and use because the next deployment will reference a completely different file when its contents change.
2.
Files inside Files in Nuxt's directory work differently.
For example: is served as: The problem is that its URL does not automatically change when the file changes.
You could replace during your next deployment while keeping exactly the same URL: If that file was cached for a year with , some users could continue seeing the old logo.
For these files, I normally do one of two things: Give them a reasonable cache lifetime, such as several days or weeks.
Version the filename when I need aggressive caching.
For example: or: Once the filename itself changes whenever the content changes, long-term caching becomes much safer.
3.
Nuxt Image files: This is the part that caused my Lighthouse warning.
When you use Nuxt Image with the local IPX provider, the browser often doesn't request your original image directly.
Instead, Nuxt generates a transformed image URL that can look something like this: That URL contains information about the requested transformation, such as image quality and dimensions.
So you may have an original image: while the browser actually loads: Those are two completely different HTTP requests.
And therefore, they can have completely different caching headers.
This was exactly what I had missed.
I already had caching configured for my normal image directory, but Lighthouse was complaining about the generated request.
Adding a rule for does not automatically cache .
There is another important detail here.
I don't treat IPX URLs as completely immutable by default.