Dear Lazyweb,
Is it wise to gzip static resources (javascript and CSS) before sending them to client?
The opinion of Internet seems to be divided
- GZip decompression takes too much time at the client end and thus it is not wise (latency at the clients end)
- Bandwidth save is enough to counter the decompression latency
So if we put this to context of
- Compressed and merged CSS and Javascript files of Plone
- Assuming the users are using the state of the art browsers: Safari 4, Chrome, Firefox 3.6 and IE8
- Connections are faster than 384 Kbit/s
…and forget…
- Recompressing images (GIF, PNG and JPEG) using GZip as there is no notable save
should I enable GZip compression on the front-end server (Apache) with disk cache enabled?
Of course, I could do testing and timing myself, but I’ll simply ask for your experiences first before investing few hours for this. Also, hints how to measure how fast GZip decompression is, are welcome.
Thank you.
![\"\"](\"https://www.feedburner.com/fb/images/pub/feed-icon16x16.png\")
Subscribe to RSS feed ![](\"https://opensourcehacker.com/wp-content/uploads/twitter-24.png\")
Follow me on Twitter
![](\"http://opensourcehacker.com/wp-content/uploads/facebook-24.png\")
Follow me on Facebook ![](\"https://opensourcehacker.com/wp-content/uploads/googleplus.png\")
Follow me Google+
Experience has shown that it generally seems to be a good idea to merge, minimize and even gzip resource files. Note that the gzipping can be done automatically by your web server software (Apache, a WSGI middleware, etc.). It’s completely reasonable to question this empirical evidence, of course. But as of recently there was little possibility to actually profile the innards of the browser. This has changed with the Speed Tracer extension for Google Chrome http://code.google.com/webtoolkit/speedtracer/. It allows you to monitor how much the browser spends on certain things, including page rendering and dynamic AJAXy stuff. I suggest you just give it a go and let us know what you found out 🙂