Could you implement image-minimizer-webpack-plugin or other?

[fitodac]

Great template, I used for a couple projects and works perfect.
Maybe you could implement this (or another) library for image optimization.

Thank you for your great work.

[pavelloz]

Thank you for your kind words.

TLDR: Ill take a look how to do so it wont collide with performance oriented nature of this template.

Long story:

I've been thinking about this for a long time and i got to the conclusion that image optimization is pretty hard to do well (especially in bulk, where user cannot inspect before/after) during asset building.

There are some problems that stopped me in the past:

• variability from project to project, and even from image to image. Ie. you want your photo to be high quality, and background low quality because it doesnt matter that much. So you either undercompress all your images and leave KBs on the table, or overcompress images that are supposed to be high quality. Its not an easy task to so even by hand, and sometimes teams argue a lot about that (dont ask me how i know this :) ).
• cached somewhere (with all the consequences of caching [invalidating] things)
• not cached, but optimized every time build is made, which is a big no-go from my performance mind

What i recommend is doing one of three (the fact that there are 3 things is kind of a proof that i dont know how to do it universally very good):

1. Compress images by hand using best tool for the job (i use imageoptim + svgo) and commit them to repo
2. Use CDN that does it for you (Cloudflare, Cloudinary, etc)
3. Use sharp-cli that at the end of the whole build will go over the images and compress them (and commit to repo). With a little bit of luck, next time sharp will detect that there is not much to compress and do it much faster.

Personally I do the first variant, if there is no modern cdn in the stack, and do 3 as the last resort.
Having said that, number 3 is the closest to what i consider automated, hence adding it to the template. It should have the least performance impact and has the best chance of covering most use cases with that little footprint.

I will take a look at this very soon :)

[fitodac]

I use the template in small projects so I will follow your recommendations. Thank you.

…

On Thu, Apr 28, 2022 at 8:45 AM Paweł Kowalski ***@***.***> wrote: Thank you for your kind words. TLDR: Ill take a look how to do so it wont collide with performance oriented nature of this template. Long story: I've been thinking about this for a long time and i got to the conclusion that image optimization is pretty hard to do well (especially in bulk, where user cannot inspect before/after) during asset building. There are some problems that stopped me in the past: - variability from project to project, and even from image to image. Ie. you want your photo to be high quality, and background low quality because it doesnt matter that much. So you either undercompress all your images and leave KBs on the table, or overcompress images that are supposed to be high quality. Its not an easy task to so even by hand, and sometimes teams argue a lot about that (dont ask me how i know this :) ). - cached somewhere (with all the consequences of caching [invalidating] things) - not cached, but optimized every time build is made, which is a big no-go from my performance mind What i recommend is doing one of three (the fact that there are 3 things is kind of a proof that i dont know how to do it *universally* very good): 1. Compress images by hand using best tool for the job (i use imageoptim + svgo) and commit them to repo 2. Use CDN that does it for you (Cloudflare, Cloudinary, etc) 3. Use sharp-cli that at the end of the whole build will go over the images and compress them (and commit to repo). With a little bit of luck, next time sharp will detect that there is not much to compress and do it much faster. Personally I do the first variant, if there is no modern cdn in the stack, and do 3 as the last resort. Having said that, number 3 is the closest to what i consider *automated*, hence adding it to the template. It should have the least performance impact and has the best chance of covering most use cases with that little footprint. I will take a look at this very soon :) — Reply to this email directly, view it on GitHub <#12 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AA2LE42L3A52Q4DTSWOFUTLVHJ26XANCNFSM5UR2GC5Q> . You are receiving this because you authored the thread.Message ID: ***@***.***>