Stop the server abuse!

By Oli on Thursday, 12th April 2007. More information. Comments.

I've made so many rants about using JavaScript correctly over the past couple of months that I'm starting to lose count! Now, I would seem quite pretentious if I expected every web designer on the Internet to have read them but I'm not the only person preaching that JS/CSS should be used

I've made so many rants about using JavaScript correctly over the past couple of months that I'm starting to lose count! Now, I would seem quite pretentious if I expected every web designer on the Internet to have read them but I'm not the only person preaching that JS/CSS should be used responsibly and under adult supervision...

Very large sites are pushing out horrendous JS/CSS combinations and for some of them they're causing an extremely large problem in terms of system responsiveness.

IconBuffet recently redesigned their site and added a bevy of javascript features to it. As soon as it was made public, it was immediately noticeable how slow it all was... A glance at the source for each page instantly tells us where the problem lies.

<link href="/stylesheets/global.css?1176394146" media="screen" rel="Stylesheet" type="text/css" />
<link href="/stylesheets/admin.css?1176394146" media="screen" rel="Stylesheet" type="text/css" />
<link href="/stylesheets/sco.css?1176394146" media="screen" rel="Stylesheet" type="text/css" />
<link href="/stylesheets/jmc.css?1176394146" media="screen" rel="Stylesheet" type="text/css" />

<script src="/javascripts/prototype.js?1176394146" type="text/javascript"></script>
<script src="/javascripts/effects.js?1176394146" type="text/javascript"></script>
<script src="/javascripts/dragdrop.js?1176394146" type="text/javascript"></script>
<script src="/javascripts/controls.js?1176394146" type="text/javascript"></script>
<script src="/javascripts/admin.js?1176394146" type="text/javascript"></script>
<script src="/javascripts/application.js?1176394146" type="text/javascript"></script>
<script src="/javascripts/auth.js?1176394146" type="text/javascript"></script>
<script src="/javascripts/builder.js?1176394146" type="text/javascript"></script>

<script src="/javascripts/global.js?1176394146" type="text/javascript"></script>
<script src="/javascripts/lightbox.js?1176394146" type="text/javascript"></script>
<script src="/javascripts/login.js?1176394146" type="text/javascript"></script>
<script src="/javascripts/overlay.js?1176394146" type="text/javascript"></script>
<script src="/javascripts/posts.js?1176394146" type="text/javascript"></script>
<script src="/javascripts/scriptaculous.js?1176394146" type="text/javascript"></script>
<script src="/javascripts/sifr.js?1176394146" type="text/javascript"></script>
<script src="/javascripts/slider.js?1176394146" type="text/javascript"></script>
<script src="/javascripts/tooltip.js?1176394146" type="text/javascript"></script>

<script src="/javascripts/unittest.js?1176394146" type="text/javascript"></script>

23 external files?!! No — we only have half the story. There are actually 23 JS files and 15 CSS files! Some of them are in body code. Everything is GZipped so the bandwidth impact is minimal. Just around 115k. So what's my problem?

38 external files! Each time a user loads the page, they make 39 connections JUST for the HTML, CSS and JS. Whack the images on top of that and you're talking 100s of connections per user.

To compound the issue, they appear to be masking a random variable onto the end of the filenames to ensure they are not cached. So rather than have the files cached, the users are actually (albeit unknowingly) fisting IconBuffet's server in its pooper, every page they hit... Well done IconBuffet!

Stop the abuse!

So how can they fix it? Roll all your damned files into two — 1 CSS file; 1 JS file. Done. The bandwidth you use by not having dynamically loaded stylesheets is made up instantly by saving your server the shed-load of connections. You're probably using that bandwidth just on the HTML to list all the files!

You should also recognise that compression rates work best with more data. By rolling all the files into one, you'll end up with so many more duplicate terms that it will compress much smaller than all of them separately!

With this done, you save your server god-knows how many millions of hits (the real meaning of "hits" — files downloaded) a day and your server will be so much faster!

It also frees up the HDs. The time they're currently spending in random access cycles finding all these files, can be spent just pushing out the 2 external files in a sequential matter. So. Much. Faster!

I hope somebody at IconBuffet sees this post, pulls their finger out and whacks the design around because it really will serve to make the whole site much better. Equally, I hope if there are any other people who have sites that use so many multiple files (ala Digg) like this come around to the right way of thinking.

If you are in that situation and you're considering bodging everything together as recommended here, please leave me a comment. I'm just curious to know how endemic the issue really is.

Grav

Written by Oli on Thursday, 12 April 2007. Tagged with webdev, javascript, <rant>. Read 2412 times. If you liked it, please give it a digg.

#1 /* 17 months, 23 days ago */
Right you are. When we first re-launched IconBuffet, all the assets were rolled together. In the process of debugging a CSS problem that popped up the next day, I unrolled the assets and never got around to fixing it. It's fixed now; thanks for the friendly prod!
#2 /* 17 months, 23 days ago */
(Well, don't look now, because I had to un-roll the JS again for the moment. But the CSS is in better shape, and I'll keep working on the JS.)
#3 /* 17 months, 23 days ago */
Nice Post!
#4 — Author comment /* 17 months, 23 days ago */
Firstly, thanks for getting back to me Scott.

What's the reasoning behind the querystrings on the resource urls? I agree that that's a pretty essential thing to have when you're still working on the code to prevent caching, but in the meanwhile it's making people download the files every time they come back to visit you.

Otherwise it looks like you're well on track to getting things sorted =) I really love the design, by the way... Great work.
#5 /* 17 months, 20 days ago */
The query strings are automatically appended by Rails, but they're based on the last-modified stamp on the asset, so they only change when the files are changed (or in practice, the last time we deployed.) Now that I think of it, it'd be cool if the query-string was a hash of the file contents, so that it was only re-fetched if the file was actually stale. Sounds like a Rails patch/plugin idea for somebody to implement.
#6 — Author comment /* 17 months, 20 days ago */
That's a clever idea they've got there. But why do all the files have the same QS? Surely you didn't add them all at precisely the same point? Or does it work out the QS when you "compile" (or whatever you crazy rails kids call it these days)?

The coupling between back-end and front-end sounds hideous though. I'm not a Rails developer. I've barely touched it but needing to bake that level of "knowledge" into the process seems quite an alien concept to me...

My ASPNET backend knows nothing about my CSS. It's just a line of HTML in the template as far as it's concerned. And I like it that way. Server side things interfering with the output (especially where standards are involved) inevitably ends up in something cocking up and one set of browsers getting different mark-up that's incompatible with your styling.

Perhaps that's just ASPNET. Perhaps Ruby does all this out of an innocent interest in your files, but yeah, automated tampering scares me.

Don't just sit there like a lemon! Reply!

Got something to say? Now's the time to share it with the author and everybody else that reads this posting! Lemons need not apply.

edtBOX - xHTML: yes - bbcode:no
Home | Advertise | About | Contact | Legal © Oli Warner 2001—2007 Proud 9rules member