Skip to content
This repository has been archived by the owner on Nov 20, 2020. It is now read-only.

*Do* minify this response but *do not* cache it! (blacklist or res._option?) #5

Closed
joeytwiddle opened this issue Sep 11, 2013 · 3 comments

Comments

@joeytwiddle
Copy link

The section in the readme titled "Do not minify this response!" assumes that we don't want to minify dynamic responses.

However, if the minifier runs fast enough, it may still be desirable to minify dynamic documents before sending them to the client. In that case, we just don't want to cache dynamic data, because as you say, it will create a lot of cache entries which will likely not be hit again.

Something like res._no_cache_minified = true; would provide that feature, although perhaps a (list of) cache blacklist regexp(s) may be preferable because it is more declarative. (The regexps would be redundant, but would keep the behaviour all in one place. Perhaps both methods might be made available.)

(The same argument for a white/blacklist could be applied to the existing res._no_minify feature. Aren't routes usually dynamic? Therefore wouldn't res._do_minify make more sense, for those few routes which serve a static response, or a small range of responses?)

An alternative, is to cache all minified responses, but cleanup cache entries which have not been hit for a long time. (This should probably happen quite soon for the memory cache, less urgently for a file cache.) This might be the preferred solution for e.g. a news site which updates its front page just once a day, serving each day's document many times, but then never serving that document again.

@breezewish
Copy link
Owner

Hello. I found that the process of minifying mostly is the CPU bottlenick but I/O isn't because OS will do some optimization when heavily reading or writing. So do not minify may be worther than do not cache. Howover I will still separate these two functions in the options. Thank you for the advice :)

@joeytwiddle
Copy link
Author

This was for a website where our front-page (and help page) would always look the same, so minifying them and caching them would make sense. But many of our other pages were dynamic, so I was thinking of minifying them for transfer, but not caching them.

My concern was not with the overhead of saving the cache files, but simply that my cache would grow larger and larger with a lot of minified responses that will never be seen again!

In the end, we didn't minify any of our HTML pages, as our template renderer was already doing a good job. And as you say there is a CPU bottleneck to minification, and this will often be greater than the network bottleneck (although that rather depends on the user's network bandwidth).

Anyway all this seems a little redundant since express-minify does not perform minification of HTML pages! It is rare that a server would respond with dynamic JS/CSS files.

@joeytwiddle
Copy link
Author

Great work breeswish!

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants