CDN Optimizing HTML On the Fly

Caerdwyn writes "Cotendo, which is a content distribution network, has taken to altering HTML as it passes through their CDN to optimize web pages for faster rendering. This is essentially a repackaging of the Apache mod mod_pagespeed (from Google), with the critical difference being that the rewriting of HTML occurs inline rather than at the web server. We all know that well-written HTML can result in much better rendering of whatever your content is; the questions are 'Will this automatic rewriting cause other problems, i.e. browser quirks?' and 'Assuming that only the web pages of Cotendo's customers are altered, are there nonetheless potential legal troubles with someone rewriting HTML before delivery to a browser?'"

Too much work

[FranTaylor]

Instead of doing it over and over again on the fly, why not just do it once and shoot the "fixed" html back to the authors, and firmly insist that they update their pages? This seems like a much better way to accomplish the same thing.

Re:Too much work

[Anonymous Coward]

The authors could be using any one of a number of frameworks which make it at best very hard to meet some best practices.

Re:Legal precedent

[Anonymous Coward]

I think you missed the point in your rush to get first post. This isn't about ISPs filtering and altering HTML as it passes through to the customer. This is about optimizing HTML as it enters a content delivery network, so that information can then be more efficiently delivered to the customer.

There are no legal issues

[chrb]

If you voluntarily upload your web site to a CDN that tells you it is going to optimise your code, what legal issues could there be? The arrangement is entirely mutually consensual. If you don't want your site optimised, then don't use that CDN.

Oh please

[gaspyy]

This seems like an ad for Contendo disguised as an inflammatory post.

Any webmaster worth their salt is using a variety of tools to improve loading speed - minification of html/css/js, combining scripts, CSS optimization, js packing, compressing PNGs with better tools and using CSS sprites.

I use W3 Total Cache for two of my blogs and the speed increase is substantial.

While we are at it, I wish developers would think it through before using JQuery for trivial stuff. Loading JQuery + bunch of plugins to do simple (and I mean simple) fades or form validations is pointless. Here's an example [richnetapps.com] of what I mean.

So if they're doing this transparently, it's all th better.

Re:Too much work

[KiloByte]

Also, most HTML these days is generated rather than static, even if just to have common parts as includes rather than multiple copies.

But what of the crypto possibilities?

[Zawash]

Just think of all the possibilities with steganography in poorly written html? <br/> vs <br> and <br /> tags, empty span and font tags, the number of &nbsp;'s - casing in css styling and everything!

Just look to North Korea [thedailywtf.com]!

Re:Legal precedent

[totally bogus dude]

What's the difference between me configuring my servers to optimize our sites on our front-end proxies, and having our CDN doing it on their front-end proxies?

I think you missed that this is a service Cotendo provides to its paying customers.

Now, if Cotendo was doing this without their customers' permission, then your objection might have some kind of relevance. I can't find anything to indicate that this is the case though, and it seems like a dumb and stupid business move if it is.

The new Page Speed service offered by Cotendo will be part of its proprietary new performance application platform Cloudlet(TM), which is able to execute both open source and any proprietary code. Cotendo's new platform is in production with select customers and partners, which will be announced soon.

This makes it sound like it may actually be optimising the output from applications running on their own servers, rather than as a proxy altering content sent from the customer's servers.

Re:Legal troubles?

[grcumb]

After a quick first glance, it seems like it isn't doing anything that a good web designer shouldn't have already have done. Then again, the percentage of well-designed pages out there mean this could still provide a speedup...

And then, you might find yourself in my position. I administer a website with over 100,000 static files, created using a variety of tools over the course of the last 8 years. And one of those tools was FrontPage.

Given the size of our shop, coupled with the need to handle new content coming in, the best I can realistically hope for is that the formatting of our new content doesn't suck quite as tremendously as the older stuff. On top of everything else, we provide important legal content to one of the most Internet-deprived regions in the world. Bandwidth around here is often measured in single-digit kilobytes.

... You can bet your boots I'm going to give this module a test-drive. I'd be crazy not to.

Re:Legal troubles?

[jimicus]

That's not an answer to his question. He asked why not start with tight and efficient code?

Fair point.

I think the last time I saw anything tight and efficient was back when the nature of the computer it was running on forced that. IME, code efficiency is inversely proportional to the power of the system on which it is expected to run.

Re:Oh please

[SavedLinuXgeeK]

Isn't that the point of using Google's copy of jQuery for your sight, in lieu of hosting it yourself. You can share the cache with any other site that is pulling the jQuery lib from a trusted 3rd party. After looking at the link you posted, that code may be simpler with respect to size, but in terms of maintenance or having a novice manage it (without introducing cross platform issues), it seems like it may be a nightmare. What would be nice, and Adobe has done this for flash, is to have a separate cache for trusted libraries. It would be nice if I could query to see if jQuery were available in a browser lib cache, and use it from there if available.

Re:Legal precedent

[psmears]

If I were a content provider whose HTML was being modified in-flight, I'd invoke a law that already exists for that sort of thing - it's called copyright. My customer requested information from me; I provided it, and as such it is automatically copyrighted. Any modification in transit without authorization is illegal already, IMHO.

The article is about a content distribution network. That means that the content provider is paying them to make sure that their content reaches the customers quickly.

If the content provider doesn't like the content being modified, they should just ask their CDN provider to stop doing it - and if they won't, then just use another one! No need for legal action here :-)