About minification

[fonsp]

I noticed some problems with the optimization built into Franklin, and I had to disable it. Looking around the issues, it seems like minification issues are happening to other people as well, which means that our minifcation solution is incorrect: it contains bugs that change the behaviour of the page, which a correct minifier should never do.

The minifier that we use (https://github.com/juancarlospaco/css-html-js-minify) does not look like a heavy-duty, well-tested library, and it is no longer being maintained. I have some ideas!

[fonsp]

Remove minification altogether

Minification of web assets is less relevant these days since most HTTP servers include gzip compression automatically (including GitHub Pages and netlify).

The advantage from gzip is often much greater than that of minification, and when already using gzip, the additional advantage from minification is relatively small. gzip is enabled automatically on most servers, and since it is lossless, it is guaranteed to have no effect on how the page is displayed. More information here: https://css-tricks.com/the-difference-between-minification-and-gzipping/

I think we could remove the minification from Franklin altogether, which would:

• Not cause any noticable performance impact
• Solve all minifcation-caused issues
• Remove the Python dependency from this project

Small assets

A second argument here is that (I would image that) the files that Franklin generates are often quite small to start with. People who use Franklin.jl don't write huge CSS and JS codebases, which is where minifcation/bunlding would make the greatest difference. This means that the performance bottleneck is not asset size (i.e. longer download time), but the overhead of DNS/HTTP (i.e. longer time-to-first-byte). This is unaffected by minification.

[clarkevans]

This creates one complication. The preparation phase should gzip files so that they are pre-compressed. Webservers then should serve up the .gz file directly if it exists.

[fonsp]

I assumed that hosts like github pages and netlify will compress once and then cache? You are definitely right that not all web servers have zero-config gzip compression.

[fonsp]

Use a modern bundler

Nowadays, 'minifying' has grown out to a broader domain: bundling. Besides minification, it can apply more advanced optimizations, like combining multiple assets into one, to reduce the number of requests.

For example, we could use parcel, a new, hip & trendy web bundler that is designed to work well for browser-targeting projects (like franklin) with minimal setup.

I think we could remove the minification from Franklin altogether, which would:

• Better performance on sites with lots of user-written JS and CSS that is split into multiple files, using ES imports or CSS imports.
• Solve all minifcation-caused issues (in theory)
• Remove the Python dependency from this project, and re-use the node dependency to also bundle
• Improve caching performance, since parcel content-addresses filenames: https://parceljs.org/features/production/#content-hashing

[clarkevans]

I agree with @fonsp -- but the new hotness is https://vitejs.dev/ ;)

[tlienart]

Thanks for the careful suggestions and write up!!

Parcel looks very impressive; thanks for the pointer, this is something to investigate for sure (even if just as a "here's a recommended step you can do for yourself").

Wrt Franklin I think we're broadly on the same page: the plan is to drop the dependency which also drops the Python dep and will reduce headache; then suggest people can use dedicated tools (such as Parcel or PurgeCSS or the GitHub image optimiser etc).