django-htmlmin
django-htmlmin copied to clipboard
Introducing the middleware makes everything slooooooooooow
One of our heavier pages was taking a very long time to load and often timing out. Took ages to understand why this is happening in production and not in development, and eventually we realised that setting DEBUG to False is what makes things slower (unintuitively). Turns out the culprit was the htmlmin middleware.
Other than general optimization, one solution could be to bail out and serve the unminified input if minification hasn't completed within a certain timeout period.
I had the same problem.
What is the response size? What is the middleware order?
I ran a test script on my machine.
ghost@amnesia ~/dev/django-htmlmin/htmlmin $ python speed.py
0.0757081508636
0.0739748477936
ghost@amnesia ~/dev/django-htmlmin/htmlmin $ python3 speed.py
0.08755087852478027
0.08422636985778809
ghost@amnesia ~/dev/django-htmlmin/htmlmin $
Since the can_minify_response is not using anything that the self provides, can we not move it outside the class? Or is that bad practice? Moving it outside will make it a tad bit faster. Should I create a Pull Request?
Same issue here. Has there been any fix lately?
I also meet this performance issue
especially for large contents. The html compression cost more than network transfer.
before htmlmin

after htmlmin
the transfer size is down, however the response time is nearly doubled.
Same issue here. The minification takes so long the response time is doubled or more.
A workaround that improved things a bit for me was setting HTML_MIN_PARSER = 'lxml', as lxml parser is way faster than the one from html5lib used by default.
I experienced the slow down as well, JMeter results showed nearly double response time which defeats the entire purpose of this package...
I'm experiencing the same behavior. My cpu load triples when I enable django-htmlmin.

Using the lxml parser as suggedted by @lockie seems to slightly improve the situation but not much.
