-
-
Notifications
You must be signed in to change notification settings - Fork 50
Open
Description
In order to solve #288, we've decided to stop compressing (optimizing) images on our own, especially images used in HTML books.
Recent runs and analysis done in #374 proved that optimization we were doing on images was not that useless.
Two examples below:
| 2023-08 | 2025-10 | |
|---|---|---|
| Size | 63k | 101k |
| Preview | ![]() |
![]() |
| Online at | https://dev.library.kiwix.org/content/gutenberg_de_all_2023-08/53217_fig1.jpg | https://browse.library.kiwix.org/content/gutenberg_de_all_2025-10/53217_fig1.jpg |
| 2023-08 | 2025-10 | |
|---|---|---|
| Size | 30k | 63k |
| Preview | ![]() |
![]() |
| Online at | https://dev.library.kiwix.org/content/gutenberg_de_all_2023-08/52492_abb12.jpg | https://browse.library.kiwix.org/content/gutenberg_de_all_2025-10/52492_abb12.jpg |
While we could see some visual artifacts induced by higher compression, the difference in file size is clearly at the advantage of higher compression.
We should probably:
- put compression of images back in place
- confirm expected size difference (should save about 2.11G on Gutenberg DE)
- decide how to handle optimization cache invalidation (see Scraper takes ages to complete EN version and books are regularly updated #288)
- put optimization cache back in place
Or is this kind of image increased optimization something to do on Gutenberg side directly? @eshellman can you advise? I imagine compression is less important on Gutenberg side than on Kiwix one, but still this is not negligible.
Reactions are currently unavailable



