Charlie's Diary

I see this problem too, especially on Mainstream Media sites that split the article into multiple pieces so that they can sell n pageviews per article instead of one. (Yes, I work for one.)

Since all the stats-gathering stuff is in JavaScript anyway, and everyone with JavaScript turned off might as well be invisible, why not send one clean HTML file per article, and use one big script per site (cached after the first pageview, like CSS and common images) to draw in all the crap and, if you must, split it into "pages"?

Don, thinking back to the early 1990s, the reason we split HTML pages was simply to allow them to load in less than 30 seconds over a 14.4K modem.

Now we see them split to quadruple the number of ads that can be embedded in one meg chunks.

And none of the people who design these sites seem to have tried to look at them using a mobile phone's GPRS-enabled browser, or on a tablet device ...

Back in 1996/1997 I wrote a few web site reviews for Internet World Magazine. Now this is when most people still had nothing better than a 28.8K modem, 33.6K at max. Not sure 56K technology was out.

So one of the things I use to highlight was the size of the page (also how well it looked in "lynx").

I wrote this about one site: However, the graphical nature of the site is part of the problem. The home page consists primarily of a picture of the Meadowhall complex (I assume) made to look like a christmas pudding. Pretty, but 45Kb download for no practical use. Clicking on the pudding takes you to a second page of around 60Kb which is just an intro page, and requires yet another click to get into the site proper. 16Kb of this just dedicated to the designers animated logo and a further 8Kb dedicated to the MSIE animated logo.

For some reason the owners of the site wrote to the editor to complain. In particular they said the site wasn't as bloated as I said. So I went back and looked at the sizes:
Home page: 3466
Background jpeg: 8404
Meadowhall on line icon: 7146
Star Logo: 4369
Dome logo: 24062

Total size: 47477 bytes - ie approx 45Kb as I said!

10 years later and the bloat factor has increased by a factor of 20.

Bloat is even worse than just download times; those animated GIFs, flash, audio and javascript intensive sites also chew up CPU time for no good reason. In a multi-tabbed browser you could be spending most of your processing power on this stuff.

Did you take mod_gzip into account in this analysis? A modem would be downloading somewhat less actual data, in that case. GIDZipTest says that particular page is being compressed before delivery, with the specific webpage containing 34.3 kb of HTML compressing down to 9.8 kb. I'd suppose style sheets and sub-documents would also be compressed before delivery.

But sure, even after that, you're mostly downloading Flash and graphics rather than content, and by a significant margin.

I surf away from my home connection using a Nokia N810 tethered to a 3g phone over bluetooth. We're talking about a maximum data rate of about 40k/sec and since I'm mostly in 2g areas often a lot less.

Without some form of adblocking a lot of the bigger sites are just unusable. With adblocking (And goat bless the man who ported adblock to OS2008) it's ok but even the sites with a lack of ads are just bloated messes. Don't get me started on all Flash sites either.

Considering just how popular mobile surfing is starting to become you'd think more sites would be taking advantage.

Not directly related to the contents of the post: I found that AdBlock Plus works way better and is kept up to date and fixed with more regularity than AdBlock. Apparently I'm not the only one to think so, because AdBlock Plus beats AdBlock 226,833 weekly downloads to 14,361.

I don't like AdBlock Plus -- I prefer to be in command of my own fine-tuned blocklist (and I'm au fait with regular expressions so I tune it myself). Obviously, though, I'm not a typical user ...

As someone once said: "Content is king. That's why you have to bow, scrape and grovel to get into Its Presence."

You're showing your age now Charlie!

The youngsters these days have no concept of "compact code", "minimum paths" and so on. The last graduate I was given to "educate" didn't know that a flow-diagram was, although he was red hot on OOD and RAD. It's bloatware all the way egged on by Uncle Bill and the boys at Intel.

I'm not complaining mind. Bloat-laden code allows me to go into virtually any client site and speed thier system by a factor of 10 or more simply by stripping all the crap out.

So don't stop the bloatware. Us aging programmers need something to keep us fed in our twilight years......

You can fine-tune the blocklist with AdBlock Plus... but that's off topic here.

That's said, in the course of the last 10 years or so my connection speed went from 48 kbit/s to 16000 kbit/s and here I am, still waiting a considerable time to read my usual website, who became larger and larger. Initially I didn't want to use AdBlock because most websites count on the ad incomes to survive, but when I realized that most of the time I spent second looking to the ad banners being loaded while the actual contents were nowhere to be seen I capitulated.

In my country there're still lots of people without access to cable/DSL,I can't understand how they can bear the current Internet with a 56 kbit/s modem. I'd throw everything out of the window if I was forced to revert to it.

I thought nearly the same things when I downloaded the main page of an Italian newspaper site using my cell phone (Nokia E50) that shows the amount of bytes you are downloading. 430k for reading the headlines while I was waiting for a friend is outrageous, given the fact that the web server KNOWS that I am using a cell phone and CAN switch to a lighter version.

The other problem is that all those scripts phone home, so you get the latency delays. On a cable modem those 860kb go by in about a second, and the browser rendering is probably not much longer, but the back-and-forth, that can take half a minute or so.

Quite true.
The funny thing is that I increasingly use rss aggregators which strip all the cruft and just provide the content.

And then there is the potential for malware.

Usually, "Sorry, you don't have the latest flash player installed" is stupid site coding. They've used "=8" when they should have used ">7". But video codec installers are a know malware vector. If the only way to get the right codec is to click on the link provided by the site, because they don't tell you anything about the codec they want you to use, you should be very suspicious.

And you should be careful about which video player you use as default.

Well, Charles, this is why the internet is so slow in a civilized part of the world, like Europe. But the reason the internet is so slow here in Tortureville, formerly known as Shithole America, is that most of us are still stuck on 56k dialup because the grotesquely abusive monopoly of inept corporate criminals misnamed "the American internet providers" has overpriced their underbandwidthed broadband connections far beyond what the average middle-class person can afford.

In fact, Charles, we here in Tortureville don't even get true broadband. We get midband, 1 megabit to 5 megabits, and we pay through the nose for it, $80 per month or more. For most people who live in Tortureville, genuine broadband (20 megabits copper to 1 gigabit fiber) is simply unavailable. At any price. Period. Even if you live in Manhattan, even if you live in Silicon Valley. It doesn't exist. You can't buy it no matter how much you offer to pay.

We do have the most state-of-the-art torture chambers in the world, though.

Really, it's not so different than a lot of print magazines or newspapers. I think my local paper was more ads than articles before I stopped reading it. And some of the women's magazines my wife get devote more to ads than content.

Of course, that's not always a bad thing -- my wife considers the ads to be an important part of the magazines. They tell people about new products to look up and what's in style...

A new word learnt today then.
I noticed it a couple of years ago. even although I had graduated to 256k broadband, pages still took ages to load, because they had pictures and adverts and rubbish stuck in them. It still feels no faster than when I was on dial up. I suppose its a bit like the way the traffic expands to fill up new road networks.*

Dave Bell- regarding the latest flash player, so thats how it works, or doesn't. I never knew that. I am a non-techy kind of geeky person. My computers will always have off switches and plugs in the wall for safety and security reasons.

*Subject ot the obvious space and number of people in the country kind of constraints.

At dilbert.com, the lighter page is the one behind the "Linux/Unix" link at the bottom. I don't think that it's a matter of compatibility, just that the Linux and Unix people were probably the ones complaining about page bloat.

Another useful extension: http://flashblock.mozdev.org/ Click or whitelist the Flash you really want to see, block the junk by default.

Charlie, can you estimate how much time was wasted by loading the actual data and how much was eaten by the extraneous http requests for each and every one of the tracking image files and other crap?

To be fair, you should .Z the Salon page before calculating the page-weight, since it's using HTTP 1.1 with compression turned on.

This is one of the reasons that people who complain about tables and redundant tags increasing page weight are misguided. It's a near certainty that redundancy in the html is compressed out of the file transfer.

That doesn't mean that it doesn't consume a lot of CPU at render-time and occupy a lot of RAM afterwards (I load a couple hundred tabs from bookmarks twice a day -- even with 4GB of RAM, Firefox often ends up paging out).

My brain has the admirable ability to adblock. I don't see the ones in the WashPost, online, on TV, or on billboards.

Keep in mind also that your browser will not be downloading every css and js file with each request, assuming the server is configured correctly and your browser is not set to always get new files.

I remember a time when we made a sales application, internal to the company, way faster by taking down the background jpg from 1M to a few kb. Cheap thrills.

Marillee @20: The industry term for this is "banner blindness". There is now a significant amount of time and effort spent on making sure that in-house promotions and special offers don't look like third-party ads that the viewer will just ignore.

This, I believe, is why Google will win the Advertising market, because it understands that while people don't want adverts when they're trying to read something unrelated, they don't mind adverts when they're looking for something.

As a side note, who was the bright spark at (I believe) Gawker, who decided that their web sites should serve their CSS from ads.blogads.com? My ad-blocker blocks that file, with the result that their sites look rubbish. Stupid, stupid, stupid.

As for CSS, it's a tricky one: assuming that the CSS files are served up gzipped (which they should be, as they're human-readable text files, which compress really well), then the trade-off is a) serving up just the CSS you need for this page, probably by dint of serving up a chosen small number of individual CSS files; or b) serving up a standard cornucopia CSS file (which will be large, but hopefully loaded only once as you click through the site), plus any per-page modifications. The issue here is that connecting to the site to prepare for the download actually takes significant time. See for instance what the WebKit people have to say about this.

The problems on Salon are actually worse than you're describing. I ran the URL through my Firefox debugging profile that runs Firebug and Yslow.

Yslow gave the page an F because not only is it loading a heap of URLs, they're all coming from different domains, so there's a lot of DNS lookup to do, there are no Expire or Etags, and no gzip compression on the text, and almost none of the javascript has been minified.

What surprised me was that most of the URLs are redirects — the browser is actually doing two more more requests for most of the content before it gets the data!

So not only are Salon spamming us, they really suck at it.

Further proof that Sturgeon was an optimist: more than 90% of everything is crap.

Of course, it also points out the Advertising Corollary: "A low response rate means we need to put our ads into more places, not that we need to make them better."

I'm with Dan@18 - it's probably the round-trips that kill it much more than the raw file size. No matter how fast your internet connection, 60 round trips is going to take time...

Andy @#9, flow diagrams?! I have *never* seen a flow diagram used for anything serious, because they're halfassed toys incapable of modelling anything without so much verbosity that it's harder to read them than it is to follow the flow in your head. (And what about all the *other* relationships that control flow doesn't capture?)

Scribbling the occasional flow graph (as a graph with labelled edges, not a stupid flow diagram) can sometimes be useful, but if it is it's only useful to refactor whatever-it-is so its flow graph is comprehensible without such aids.

The real problem with speed in this article is that people aren't using realistic test platforms.

The real problem with speed that *I* see, in the non-web-writing world, is that virtually nobody has a clue about algorithmic design or sensible optimization: even the distinction between O(2^n) and O(n) sometimes seems to be lost on them, let alone that between O(n log n) and O(n), and let's not even get into the importance of, say, avoiding server roundtrips: the web apps these people write are abominable. (The free software world is unusual here, as are large orgs like MS: they can afford to hire only the clued. But outside of that there is a scattering of clued people in a vast wash of the ignorant.)

No matter how fast your internet connection, 60 round trips is going to take time

Cory, apropos #19, the HTTP compression is irrelevant to the cruft tagged onto the article -- while HTML and CSS and Javascript should compress nicely (by about 40-60%), JPEG, GIF and Flash animations are already internally compressed; running an extra compression layer on top will vary their size by probably +/- 1% (in either direction) and just add to the processor workload then it's time to decompress them.

And let's not underestimate the added workload of dumping 60-odd additional HTTP transactions on top of the one (a pageful of text) that we requested. Of which most are triggered after we load and parse the first page and it's embedded iframe and javascript content. I haven't done a teardown of the cruft that's being pulled in -- life's too short for groveling through deliberately obfuscated javascript -- but I strongly suspect some of the cruft is third or fourth level cruft, that is stuff that's pulled in by scripts that were pulled in by the original page. So when you load a single page from Salon.com, the process you're kicking off is actually more like what you'd expect of a web spider, only with a Javascript interpreter built in: it's digging deep into a variety of websites to retrieve the content.

Now, it ought to be possible to serve cruft faster; to do so, you'd want to do something like re-invent tar(1), uudecode(1), and gzip(1) in Javascript, and have your web page consist of a javascript library and a long uuencoded tar.gz archive containing all the necessary content; the javascript would then unpack the tar.gz archive and render the files in it in situ. That'd get around the problem of the gigantic volume of HTTP requests, and it'd also force folks like me to switch on Javascript or not get to read the page they requested at all. Double-edged sword! But it also moves so much processing out towards the edge of the net that it's going to result in older, slower browsers running like snails.

Canis: I gave up counting after spotting 13 distinct hosts in the dump from lynx. Pipelining won't help you there ...

Me, though? I think I'm probably going back to Lynx.

Charlie - not to mention that web standards have been guided by professional web designers. So HTML has gone from a fairly accessable web scripting system to an arcane coding language which only those web designers properly grasp.

I finally gave up on trying to make my wordpress blog work - it took me forever to add a banner (and I ended up using , it was the *only* thing that worked...) and I never did manage to work out why the top image wasn't centered and didn't show up in firefox.

So I went back to something easier - writing a cutscene for Neverwinter Nights in its cut-down version of C. (Semi-joke: I am doing that, but it's not very easy to use. Still much easier than modern HTML but...)

bah, in the above comment I meant "ended up using "

Ah, the good old days, when men were men, and programmers were mean, lean coding machines.

I must admit to an occasional nostalgia pang for DOS, and an admiration for the people who could make it jump thru hoops with a minimum of bytes. (I am one of the people who considered WordPerfect 5.1 the Best Wordprocessor Evah; do the new versions of WP still include a toggle to emulate 5.1?)

One of the DOS programs I used, back in the day, was called ScriptThing, to mostly-automate the composing, formatting, and pagination of scripts. It was based on WP5.1, and used WP macros to do its magic. I remember going looking at the base macro code, and marvelling at how elegantly the author had set up the commands. (Especially the pagination macro, because, boy, doing that by hand was a BITCH!)

That was another thing about DOS: I actually had a semi-competent understanding of how it worked, and was getting close to doing some minor programming of my own in it, when WHAMMY! everything switched to Windows.

Alas, all this is just mutterings into my long gray beard, I fear. The petroglyphs of the past have been replaced by the Pollocks and Stellas of the present. Alas, alack, doom, woe, woe, woe. I'll take my nap now, nurse.

Bruce, I never did get my head around that whacky complicated GUI programming scene, myself. I'm okay at writing pre-forked multi-headed servers backing onto SQL database engines, but GUIs? That's not programming, that's graphic design with warmed-over voodoo on top.

Speaking as someone whose DSL modem died (after less than three months of service) and threw me back to dialup ... the DSL connection as done by The Phone Company (locally ATT) means that my local dialup connection now runs no faster than 31.2K, where it had been running sometimes at 40K-plus. (I didn't spring for the highest grade of DSL. I'm not downloading video, thanks.)

surely this is just about what the website considers an acceptable trade-off between render speed and perceived revenue gains from ads? Is it really that different from local application load and responsiveness?

What I think is interesting is that viewing is rapidly going to go mobile, with the attendant lower bandwidth. (disclaimer, I use am iPhone for viewing web pages a lot). The smaller screen and slow downloads, especially when not connected to WiFi, tends to drive me to familiar sites that are mostly text based - e.g. reading your blog is just great as it loads so fast and isn't putting crufty ads on my very valuable limited screen real estate.

At some point, commercial websites are going to realize that this is an important market and start offering special mobile versions of the site or start stripping the bloat from their pages.

Just to stake my claim: I've hand-assembled Z80 machine code and converted it into a string constant withim that BASIC code, which could be called and executed.

I gave up counting after spotting 13 distinct hosts in the dump from lynx. Pipelining won't help you there ...

By the way, if you're on your Mac, Safari will actually analyse all the cruft for you.
On the Advanced page of the Preferences, enable "Show Develop menu in menu bar" and you get a bunch of geek tools, one of which is Show Network Timeline.

This is, of course, because of the iPhone, and Apple's vested interest in people optimising their sites for fast access over slow connections.

It's interesting, because it shows how downloads are overlaid. For instance, loading this very page takes 186 ms and is entirely bound by the size of the content, which should make you happy :) There's 8.8kb of stylesheet and 3.07kb of scripts, but they're downloaded concurrently, as they're discovered. You can see all this in a cute shiny graph :)

Examining the original Salon link is interesting: First of all, it shows that (in my test) more time was spent downloading scripts than anything else. Secondly, it turns out Salon are not gzipping their css, js etc. Doh!

Bruce - When there's progress in function, fine. But websites of 3-4 years ago were just as functional, with a fraction of the HTML code complexity.

Salon has been a terrible offender for many years. During the dot-boom, I was drinking the Internet through the firehose of a T3 connection at my employer, and most pages I browsed loaded quickly. Not Salon's. I hated browsing there -- still do -- because their pages loaded so damn slowly.

There's an old truism that applications will always expand to take up the maximum amount of memory. It would seem that there's a correlary for bandwidth.

Because web developers have come to assume that their typical customer will have sufficient bandwidth to manage endless layers of cruft and bloat, that's the way that they code (spurred on, of course, by their clients wishes to put in as much advertising as they can get away with).

Thanks for doing the analysis. Whatever else you say about it, the web as presently instantiated is an incredibly inelegant medium for the transmission of text.

I suspect another factor would be that most web developers are young, and younger computer types don't really understand why anyone would want to use less than bleeding-edge gear. So that's what they design to, and the solution to performance problems is "update your hardware".

Bruce @31 Hey!

PJ @33, I got DSL last year at a special price and if they had increased that this year, I would have gone back to dialup. I spend most of my time reading and writing and while it's nice to see something on YouTube every now and then, it's not necessary.

Sometimes I'm happy that we don't have energy too cheap to meter.

I paid for the Accelerando, I can read the Salon article for no monetary cost, but they make up for it by charging my attention, and obviously yours.

I think it would be a good idea to get some buzz on the net that advertising is slowing down the net. It might be a good idea to 'hit where it hurts'. So as to make the establishment back off some.

I'll start submitting it to the sites where I am registered and let's hope it gets some attention.

Canis, 36
By the way, if you're on your Mac, Safari will actually analyse all the cruft for you.
On the Advanced page of the Preferences, enable "Show Develop menu in menu bar" and you get a bunch of geek tools, one of which is Show Network Timeline.

Works on the xp version of Safari too. Very handy. Thanks for pointing it out - I now have something to play with for the rest of the night.

good heavens! The ny times homepage clocks in at 1.313 megabytes! I had no idea!* Note that only 117kb is text, compared to, for instance 177kb of ... wait for it ... stylesheets. But that's only in 7.73sec, compared to Salon's 15.13sec, for 478kb total.

Which means the times has spent more time optimizing their cruft?

for reference:
MakingLight: 503kb, 140 in documents, 7.34sec
MakingLight open thread 107: 1011kb, 932 in documents, 12.28 sec
MakingLight view-all-by-Charlie Stross: 664kb, 638.85 in documents, 9.33sec
BoingBoing: 2.011Megabytes, 168.3kb in documents, 1.123 in images, 27.48sec
Slashdot: 536kb, 80 in documents, 354 in scripts [no surprise there, o l33t skr1pt k1dd13s], 6.08sec

*adblock, noscript, etc.

don delny, 47:
BoingBoing: 2.011Megabytes, 168.3kb in documents, 1.123 in images, 27.48sec

That half-a-minute is the reason I've (mostly) given up with BoingBoing.

"They don't have to use all those separate servers."

From their viewpoint, our time (and network & computer resources) are free. That's the trade for an advertising-supported service, isn't it? We pay for it with our attention.

Randolph: From their viewpoint, our time (and network & computer resources) are free.

That's why I call this stuff Spam.

The whole point about spam isn't merely that it's advertising (although intrusive advertising is pretty annoying anyway), it's the fact that it's attention theft. This stuff is also attention theft, insofar as those few seconds you wait while the web page you clicked on loads is time you could spend doing other stuff like, oh, blogging or having a life. And it may only be a few seconds at a time, but over a period of hundreds of web-clicks per day and hundreds of days per year it adds up.

One of the reasons I watch very little TV today? I've developed a general allergy to advertising because the advertising intervals have gotten longer, tending towards an American-style 12 minutes per hour. Watch TV for four hours and you've lost nearly a whole hour of time you could probably have been using for some other purpose.

From their viewpoint, our time (and network & computer resources) are free. That's the trade for an advertising-supported service, isn't it? We pay for it with our attention

BoingBoing: 2.011Megabytes, 168.3kb in documents, 1.123 in images, 27.48sec

That half-a-minute is the reason I've (mostly) given up with BoingBoing.

Anyway, RSS feeds for the win -- just click on the headlines you care about.

Moment of cognitive incogruity: One of the comments on this post is by the gentleman who *taught* me computers and programming in high school.

"it's the fact that it's attention theft."

Not theft. It's a deal, though perhaps too much like a drug deal. If we want different deal, well, we have to pay for it in some other way.

Sigh. I've been saying things like this for 20 years now. Being ahead of your time is a PITA.

You left off the latency due to _terrible_ ISP DNS servers. If you run a caching local server and don't even bother to forward to your ISP you can get much improved lookup times.

"..towards an American-style 12 minutes per hour."

ObFourYorkshiremen: We drrreeeeeam of twelve minutes per hour! Over on iTunes, you can see that typical episodes of new "one-hour" shows actually run about 43 minutes and change. It's the older ones that run 48 minutes.

Oh, and reruns are edited down even further. There are also pop-up ads along the bottom during the show. And finally the credits are typically squeezed to allow half-screen ads during them.

Let it all burn, I say.

Both of my current VCRs play a one-hour show at 40 minutes.

Charlie @ 51: 12 minutes per hour? I wish. I concur with Johan and Marilee. It is more like 44-ish minutes. Original Star trek episodes clocked in at about 50 minutes. Nex Gen was in the high forties whet it stared, lowish forties when it ended. Which IMO is why the original series episoed were often better, you can pack a lot of story in six minutes.

Tivo, or whatever DVR is available will be your Best Friend when it comes to time management. I routinely record commercial laden shows I could watch in real time, just to skip the adverts.

Charlie @51: DVR Is Your Friend. I routinely record stuff that I could watch in real time jsut to skip all the adverts.

Steven @59, I have cable. Because of zoning restrictions I can't have satellite. This means that the only PVR I can have is the cable company's one, for which they want more money than I'm prepared to pay. It's easier to Not Watch TV (and do other stuff with my time) instead.

Charlie, you could have MythTV -- you could probably even make the hardware bit from stuff around the house.

Sorry about the back to back posts on the same subject, I thought the first had vanished into the Aether.

Yeah, cost on those bad boys is certainly a factor. I waited until a new model was available and then ordered the older model to get a substantial price break from the original cost of said older model.

I lost both TV and internet for a couple of days after a hurricane remnant came roaring through central Virginia a few years ago. It was astonishing how much of a dent I made in my to-read pile.

That MythTV looks really good. Damn. I could build one of those.

Charlie@60: "Because of zoning restrictions I can't have satellite."

Surely an SF author knows some hardware gurus who could whip up an antenna that doesn't use a dish...

On MythTV: I have a MythTV and two TiVos. (My wife is a media junkie, I have to support her habit.)

The interface is fully usable by your average Mac user. Setting up a MythTV system (remember, it's currently version 0.21) is a week of research plus work, followed by endless nonessential tinkering. If you like that sort of thing, go right ahead. If not, TiVo is the way to go.

Johan: I live in a World Heritage Site. You can go to prison for replacing the slate roof tiles with plastic ones that let a signal through -- or for putting up an antenna without planning permission.

(Flip side of the coin: I live somewhere really pretty.)

-dsr- @64, TiVo costs money beyond the hardware. One of my VCRs died recently and I couldn't afford TiVo and looked into MythTV, but that would be more work at a table than I could probably handle, and then almost no plain VCRs are made anymore, so I bought a DVD/VCR and gave the old DVD to friends. Then again, Charlie makes a lot more money than I do. On the gripping hand, do they have TiVo in the UK?

One reason for using multiple servers is that browsers limit themselves to a certain number of open connections *per server*. Putting images or other static on a separate server means that the page is downloading using twice as many concurrent connections.

Bogons.net connectivity turned up, Virgin Media direct debit cancelled, bandwidth doubled!

I don't mind Salon so much, they have to earn a crust somehow. Delivering ads efficiently takes lots of time effort and money, just like any other non-trivial programming task. Presumably paying customers get a cleaner page ? dunno, I've never paid for it. ahem.

My particular bete noire is the American Express site for paying a CC bill. Being neurotic, I like to save the page that confirms the payment: it does not save, nor can it be cut-and-pasted. Once I dug into the code behind, but recoiled in horror from the vasty deeps thus revealed. Apparently they buy their Javascript by the yard - never mind the quality, feel the width !

http://www.google.com/search?q=Proxomitron+links
good filters are "elegant" (or just magic)
Also aumha mvps HOSTS updates
For Gawker or whoever, d/l copy of the css, then insert your local copy it as usercss. you may find improvements for many sites at userstyles.org
I suspect you can do similarly w/ userjs
_____
Ime, yahoo was one of the earlier swf and document.write() abusers
early samples of ajax showed the potential speed, but i assume the packers are larding down ajax w/cruft.
_____

/. scripts may be for the post rating system?
Tortureville find regions with >1 BB isp. then offer to invest if they start a branch in your region. :-)
_____
"banner blindness". There is now a significant amount of time and effort spent on making sure that in-house promotions and special offers don't look like third-party ads that the viewer will just ignore.
Incurring the wrath of those 3rd party advertisers, "hey! who do you think is the boss of you!?"
deliberately obfuscated javascript -- but I strongly suspect some of the cruft is third or fourth level cruft, that is stuff that's pulled in by scripts that were pulled in by the original page. So when you load a single page from Salon.com, the process you're kicking off is actually more like what you'd expect of a web spider, only with a Javascript interpreter built in: it's digging deep into a variety of websites to retrieve the content.
Open Ff's error console (tools menu) and click its "clear" button just before loading a cruftpage.

And then there's the fact that according to the W3C validator "http://validator.w3.org/":

This page is not Valid XHTML 1.0 Transitional!
Failed validation, 66 Errors

These errors also slow up browser-rendering.

I wish I had a browser add-in that would run the valdator on the current page,
and then if invalid, automatically send the validation result and bug-list to
the domain-webmaster.

FWIW.