Minification of static files about express-minify HOT 2 CLOSED

Hello, you understant it correctly :), express-minify sets 'a hook' of req.write so that it could get the entire body before data is sent. It calcs the SHA1 checksum and then try to get it from the cache.

When I first implemented this flow, I had some worries about performance like you :). But later I think I should still implement it like above and here are the reasons:

• A minifier use express.static() is already existed ( express-uglify ). I should not do repeat works.

• Minifying static files only is a little circumscribed. I want to implement a universal, easy-to-use, really simple minification middleware. As you see, user only needs to add a line app.use(require('express-minify')()) to add minify functions to there apps and remove this line to disable the feature. No need to change any other codes.

• I got this idea from express.gzip(). Previously I use gzippo middleware to provide Gzip functions in my app. Gzippo uses an own static file handler. Change code from express.static to gzippo.staticGzip is simple but I really meet a lot of problems because gzippo.staticGzip is NOT as powerful and equivalent as express.static and when I'm using extended functions in express.static, I found it really hard to change these code to gzippo.staticGzip. What's more, if express.static add something new and the developer of gzippo do not implement it, I will unable to use the new functions. The real reason of causing the above problem is, gzippo did something more then it should did. It should only gzip and it shouldn't serve static. The function of serving static file should be leaved to other middlewares. Later, I found that expressJs natively provides a gzip middleware: express.gzip(). It is really simple! Add the line to provide Gzip and remove the line to disable Gzip. This is a real middleware. So I re-implemented express-minify and the flow is similar to express.gzip.

• Why should I consider performance issues? Minifying contents has already became a CPU-cost process. Seting a hook, calcing the checksums, reading from the local FS, these won't cause too much CPU consumption. (May be 'a lot of' memory instead when setting hooks?) If the user uses a memory cache, the only CPU cost is calculating SHA1 and the process is still really fast. If the user uses a FS cache, the bottlenick is I/O and the improvement of I/O performance should be done by the OS. In fact, OS will optimize I/O reading or writing if a block is continually operated (use FS cache).

  And, the same as JSON.stringify and JSON.parse in reading cache. These extra conversations of couse will slow down the process. but how much? May be less then 1%. Using 1% of the time to strongly improve reliability, I think this is a good idea.

• What's more, if a user is strongly sensitive to the performance, the best way is to pre-minify contents as I mentioned in README. (Use something like grunt is really a good choice and you can have a try). express-minify should not care of this.

from express-minify.

Thanks for your detailed explanation. You are of course correct, my concerns are pretty minor, and my proposed changes would add significant complexity for small gains in efficiency.

I can see the benefit in keeping this project small and simple.If anyone really needs 20,000 requests per second rather than 10,000, then they can make a super-optimized but complex fork of express-minifier, OR as you say not use it at all, in favour of pre-minification!

I was aware of the issues surrounding "replacing" express middleware, but have no experience of trying it. It sounds like it is not so easy to hook into its internals, although I imagine it should be possible to pass a request directly to it when needed.

from express-minify.