You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Nov 20, 2020. It is now read-only.
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.
The text was updated successfully, but these errors were encountered:
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 :)
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.
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'tres._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.
The text was updated successfully, but these errors were encountered: