# Image caching is not working anymore in 0.154.2

**URL:** <https://discourse.gohugo.io/t/image-caching-is-not-working-anymore-in-0-154-2/56499>\
**Category:** support\
**Tags:** images\
**Created:** [January 4, 2026, 12:50am UTC](https://discourse.gohugo.io/t/image-caching-is-not-working-anymore-in-0-154-2/56499 "2026-01-04T00:50:10Z")\
**Posts on this page:** 5\
**Page:** 1

<div class="post-metadata">

**Author:** ![jzeneto](https://yyz2.discourse-cdn.com/flex036/user_avatar/discourse.gohugo.io/jzeneto/32/9539_2.png) [@jzeneto](https://discourse.gohugo.io/u/jzeneto)\
**Post date:** [January 4, 2026, 12:50am UTC](https://discourse.gohugo.io/t/image-caching-is-not-working-anymore-in-0-154-2/56499/1 "2026-01-04T00:50:11Z")

</div>

TL;DR: It seems Hugo’s image processing is currently ignoring cache, always reprocessing all image files.

In my site, I use image processing to turn each JPG file to a fixed set of WebP files, each in a different resolution (to get responsive images). Because of this, I was using Hugo’s extended version, to be able to encode WebP files. And, to avoid making this processing in the server (which is Netlify), I usually run the JPG \> WebP processing locally, so all the generated WebP files can be version-controlled. This worked fine, until now.

Today I’m updating my personal site from 0.152.2 to 0.154.2 (current). First, I tested the extended version, which took very MUCH longer than usual to build my site: Hugo reprocessed **all** the images, generating different filenames. But, as no error was thrown, I then tested the standard version (which since 0.153 got WebP processing). It **again** took way much longer than usual, and, to my surprise, all the filenames were different from the extended-generated ones. (In those tests, I’ve always ran `hugo server –gc` .)

Then, I stopped Hugo server and re-ran it (same Hugo version, same Hugo executable), hoping to get normal build times (as the cached files would not need to be regenerated), which in my machine are around 6 seconds. But Hugo reprocessed _ **again** _ all the images, ignoring the cache and, obviously, tooking much longer than expected (around 15 _ **minutes** _).

I then turned back to extended version, and the results were the same: an always very long build time, despite the cache.

So, it seems to me image file caching is somewhat nor deterministic nor working anymore, and this happened between 0.152.2 and 0.154.2.

---

<div class="post-metadata">

**Author:** ![jmooring](https://yyz2.discourse-cdn.com/flex036/user_avatar/discourse.gohugo.io/jmooring/32/4214_2.png) [@jmooring](https://discourse.gohugo.io/u/jmooring)\
**Post date:** [January 4, 2026, 3:02pm UTC](https://discourse.gohugo.io/t/image-caching-is-not-working-anymore-in-0-154-2/56499/2 "2026-01-04T15:02:09Z")

</div>

> [@jzeneto](#):
>
> to avoid making this processing in the server (which is Netlify)

Add this to your site config to make the image cache persistent when building your site with Netlify:

```plaintext
[caches.images]
  dir = ":cacheDir/images"
  maxAge = "1440h"

```

See [details](https://gohugo.io/configuration/all/#cache-directory).

In this case there’s no benefit to keeping your `resources` directory under version control.

> [@jzeneto](#):
>
> Hugo reprocessed **all** the images

This is expected and desirable. There are subtle decoding and encoding changes with the v0.153.0 WebP implementation (do a file size comparison), so the cache key (and file name) must be changed.

> [@jzeneto](#):
>
> It seems Hugo’s image processing is currently ignoring cache, always reprocessing all image files.

I am unable to reproduce this as written:

```plaintext
git clone --single-branch -b hugo-forum-topic-56499 https://github.com/jmooring/hugo-testing hugo-forum-topic-56499
cd hugo-forum-topic-56499
hugo 
hugo

```

On my exceptionally average laptop, the first build takes 4 seconds, and the second build takes 0.1 seconds. I tested with both the extended and standard editions of v0.154.2. And the edition that you use from one run to the next is irrelevant.

---

<div class="post-metadata">

**Author:** ![bep](https://yyz2.discourse-cdn.com/flex036/user_avatar/discourse.gohugo.io/bep/32/3332_2.png) [@bep](https://discourse.gohugo.io/u/bep)\
**Post date:** [January 4, 2026, 4:42pm UTC](https://discourse.gohugo.io/t/image-caching-is-not-working-anymore-in-0-154-2/56499/3 "2026-01-04T16:42:15Z")

</div>

I have not read the entire thread, but with the new `webp` decoder/encoder, I decided to increment the version number used in the image file hashes – which is probably what you see.

---

<div class="post-metadata">

**Author:** ![idarek](https://yyz2.discourse-cdn.com/flex036/user_avatar/discourse.gohugo.io/idarek/32/26229_2.png) [@idarek](https://discourse.gohugo.io/u/idarek)\
**Post date:** [January 4, 2026, 7:21pm UTC](https://discourse.gohugo.io/t/image-caching-is-not-working-anymore-in-0-154-2/56499/4 "2026-01-04T19:21:48Z")

</div>

From my experience

I moved all my sites to latest version, removed resources folder and reprocessed them, knowing that new decoder change things. After that one off reprocessing all going back to as it was previously.

---

<div class="post-metadata">

**Author:** ![jzeneto](https://yyz2.discourse-cdn.com/flex036/user_avatar/discourse.gohugo.io/jzeneto/32/9539_2.png) [@jzeneto](https://discourse.gohugo.io/u/jzeneto)\
**Post date:** [January 7, 2026, 2:06am UTC](https://discourse.gohugo.io/t/image-caching-is-not-working-anymore-in-0-154-2/56499/5 "2026-01-07T02:06:33Z")

</div>

Sorry for the silence, I’m not able to test your suggestions until Thursday or Friday. I’ll update this thread as soon as I test the solutions. Thank you in advance!