Hi all,
I am wondering about the impact of gzipping CSS and JS files (after aggregation) in comparison to CPU cycles. In our Drupal site I have installed and enabled the JS and CSS aggregation modules, but they weren't utilized. So after some investigation I asked our hosts tech support and they confirmed that we're not serving resources compressed. From what I understood it was not enabled on the server side.
I was told that utilizing compression (gzip) would not provide me significant amount of savings, but impact the CPU cycles substantially.
Especially if you are running a CMS, such as Drupal, and you expect to find yourself running into a situation where you have any substantial amount of traffic, I would recommend against gzipping your data. Using compression across HTTP was far more common when users' bandwidth was the limiting factor rather than the computational ability of the server.
How accurate is this comparison? I have been trying to optimize our site to load faster, but am wondering through what great length I should go seeing that blogs like techcrunch, lifehacker, and style perform much worse than our site in Googles PageSpeed and YSlow. So far our biggest drawback is Facebook and twitter, that serve their content separate and without compression.
What do you do on your own sites and how much should one delve into trying to tweak a site?
Thank you very much - your feedback is greatly appreciated.
Comments
Boost Module
Sorry for the short post, but to get you started, look into the Boost module, which does gzip static html pages.
As the page says, its a more advanced module since there's a bit of setup, so look into that and any research you find out about it on the net.
The alternative is to set all that up on your server, which I don't think you'd want to do.
I'll post more details later.
Twitter
-Michael
Advagg
Another approach, specific to CSS+JS:
http://drupal.org/project/advagg
Works very well on its own.
Ideally you want to gzip/compress once, then serve up the compressed files. That's going to be easier than a gzip on every load, although you may need to do that for dynamic pages anyway.
IMO if you want to start tweaking performance start with http://www.newrelic.com and a demo account. It will tell you exactly where you are spending your page load time, db/memcache/web down to the function calls. I post about Newrelic a lot and could be their unofficial spokesperson but it's really, really excellent and tuned to work with Drupal.
@ Advagg: great tip on
@ Advagg: great tip on NewRelic. Looks like a wonderful benchmarking solution. Thanks.
@OP: Gzip is fairly computationally intensive, and when combined with Drupal it will help only with transmission time but with the server-side compression and client-side decompression it may not do much for your overall throughput. Worth trying, but if it doesn't produce the results you want you may find opportunities to trim your Drupal setup (looking forward to playing with NewRelic for that sort of thing).
Any CMS involves tradeoffs between speed of development and speed of delivery. Much of Drupal's power for development comes at the cost of extra clock cycles on the server, which is generally still very favorable in terms of ROI but like they say there is no free lunch. When performance really matters and you're getting good traffic it may be time to consider a dedicated host if you're currently on a shared host.
One issue with shared hosts is that you have no idea what other processes are running, and while you're trimming your system to be as efficient as possible other users of the same server may not be as diligent, effectively sucking the performance out of your apps like vampires.
With a dedicated server all that goes away, and pricing for dedicated servers at many hosting sites can be quite affordable these days, often well worth it for a commercial site.
If you're already on a dedicated server then NewRelic seems like an excellent way to identify the bottlenecks. Please let us know what you come up with - I'm very interested in server performance and would be grateful to hear what you learn.
Thanks -
gzip can be computationally
gzip can be computationally intensive, but when you have large css/js files getting sent off to the user at 1/5th of the original size, the advantages can outweigh that con. Your files being delivered from the server to the client at a faster rate does mean that your server will be able to handle more users at a given time. It is also important to note that there are other server settings you want for sending out files (future expiry date, etc) to ensure the files don't get transferred from your site again and again. As a note, apache can (and does) cache the result of gzipped files to shoot back to the user so it should only happen once on the very first page load for a given file with a future expiry date. I presented on some of the frontend optimizations at last year's drupalcamp in LA (the slides are at http://www.slideshare.net/BTMash/drupal-frontend-performance-and-scalabi.... The slides for the backend optimization are at http://www.slideshare.net/BTMash/drupal-backend-performance-and-scalability). Personally, I've found that as far as good resources go, 2bits talks a lot about backend performance tuning and Steve Souders talks a lot about front end performance tuning. They are not the only ones (naturally) but they're great places to start.
There are LOTS of tools you can use to figure out exactly where your site would require performance tuning (much like you wouldn't want a doctor not trying to diagnose an issue and start giving you some fairly strong prescriptions when you say you have a runny nose, you don't want to just start doing things to your website without first figuring out where the issues lie). I'm curious to try out newrelic at some point as well. I've gotten somewhat used to some of the methods that I have but if this will bring all of that under one large roof to go through more easily, then even better :)