Beta
×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

CDN Optimizing HTML On the Fly

timothy posted more than 3 years ago | from the speed-is-good dept.

Google 121

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?'"

cancel ×

121 comments

Sorry! There are no comments related to the filter you selected.

Legal precedent (1, Interesting)

rumith (983060) | more than 3 years ago | (#34133792)

It doesn't really matter if it's a technically good move; if this sticks, we might be getting lots of ISP-inserted ads, iframed toolbars and other "value-added" stuff in non-encrypted HTTP traffic pretty soon.

Re:Legal precedent (1, Insightful)

Anonymous Coward | more than 3 years ago | (#34133830)

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.

Re:Legal precedent (2, Interesting)

rumith (983060) | more than 3 years ago | (#34133886)

I think you missed the point in your rush to object. What's the legal difference (IANAL) between optimizing HTML and inserting ads? In both cases X leaves the source, Y arrives at the destination. Opera does something like this for their Opera Mini browser: the content that is delivered to the browser isn't even HTML, it's some proprietary format, although the browser usually correctly renders it to what the HTML would look like. However, in case of Opera Mini, I explicitly agree to such manipulations and to accompanying technical solutions.
Once again, this may be a good move on Cotendo's part that will lower their costs and improve end user experience, but it is a dangerous one, because if ISPs and CDNs automatically receive the right to manipulate transmitted content however they please, it will certainly lead to abuse in some cases.

Re:Legal precedent (5, Insightful)

totally bogus dude (1040246) | more than 3 years ago | (#34133920)

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 precedent (1)

pspahn (1175617) | more than 3 years ago | (#34134228)

and it seems like a dumb and stupid business move if it is.

Dumb business moves can often be overlooked because they provide other benefits that outweigh the negatives.

This also true for stupid business moves, as there can usually be found ways to counter the effects of such a decision.

However, if a business move is both dumb and stupid, you should probably go back and look at your decisions a little more carefully.

Re:Legal precedent (1)

Jane Q. Public (1010737) | more than 3 years ago | (#34136016)

The difference is that they are actually altering the content. What if the telephone company could re-order the words you speak, or perhaps substitute other words "as good as" your own, in order to make their voice-compression algorithms more efficient? Would you agree to that?

ISPs and carriers, are supposed to carry the content. Period. The moment they start altering that content, they have gone too far. I don't give the slightest damn what their justification is. It is not to be done.

I see nothing wrong with encouraging the sources of the content to use things like mod-pagespeed on their servers. But that's another matter entirely.

Re:Legal precedent (1)

totally bogus dude (1040246) | more than 3 years ago | (#34136838)

What if the telephone company could re-order the words you speak, or perhaps substitute other words "as good as" your own, in order to make their voice-compression algorithms more efficient? Would you agree to that?

If my telephone company offered me a service where their automated systems would re-order my words to make me sound like I actually knew what I was talking about, and I paid them to provide that service, then I would expect them do that. If they were to do it without my consent, then that would be another thing. But I haven't seen any indication that Cotendo is doing anything without their customer's blessing.

I see nothing wrong with encouraging the sources of the content to use things like mod-pagespeed on their servers.

But the CDN is the source. Technically true if the Cloudlet(tm) service is in fact running the customer's code on Cotendo's servers; but even if it's not, as far as most of the world is concerned, it is.

I think some people are taking the view that a CDN is somehow akin to an ISP or a carrier. In reality, it's more akin to a paid web hosting company. Sure it's a little more complicated and flexible than a regular webhost, but it is essentially the same thing. A CDN offering this service is no different than a CDN such as Akamai offering to process Edge Side Includes for their customers. It's a feature that allows a customer to improve their sites' performance by simply spending a little bit of money. Come to think of it, that's pretty much the entire business model of CDNs...

Closing point: a CDN is not a neutral third-party carrier. It is an integral part of an organisation's hosting arrangements, and has the ability to provide many more benefits than simply mirroring a bunch of content around the world (not that that in itself isn't valuable). Altering content as directed by their customer is part of the service they provide.

Re:Legal precedent (1)

Angostura (703910) | more than 3 years ago | (#34133974)

What's the legal difference (IANAL) between optimizing HTML and inserting ads?

This week on "Thin End of The Wedge" - "Why there is no difference between a Web server GZIPing content and a Web server replacing all images with Goatse".

Re:Legal precedent (1)

GameboyRMH (1153867) | more than 3 years ago | (#34136866)

Be aware that the old gzip package has been renamed gnu-gzip. The new gzip package is actually GoatseZIP.

Re:Legal precedent (1)

warrax_666 (144623) | more than 3 years ago | (#34134122)

What's the legal difference (IANAL) between optimizing HTML and inserting ads?

Intent. The law cares about intent (usually).

Re:Legal precedent (0)

Anonymous Coward | more than 3 years ago | (#34134192)

Legal difference, if there existed law restricting the modification of HTML by an ISP, would be the intent. In other words, the relevant law would likely be structured in such a way so as to differentiate intent: for example, to prohibit altering for commercial gain or advertisement, or to deceive the viewer. Or the law would blanket-ban all modification with some exceptions (very doubtful).

Anyways this is purely hypothetical and such a measure would be less specific about HTML probably, covering instead the Internet Protocol for instance.

Oh and your use of the word precedent is erm... awkward, and wrong when referring to legal matters.

Re:Legal precedent (1)

Muad'Dave (255648) | more than 3 years ago | (#34134350)

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.

What happens when I request data from a web service for the lowest price for an item from pricegrabber and some intermediate ISP decides to replace the real answer with the price of one of their paid sponsors?

I would also like to see movie directors/etc go after broadcasters that place those obnoxious network 'bugs' into the content stream of the movie. They're altering the movie for monetary gain.

Re:Legal precedent (3, Insightful)

psmears (629712) | more than 3 years ago | (#34136414)

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 :-)

Re:Legal precedent (1)

c6gunner (950153) | more than 3 years ago | (#34134274)

What's the legal difference (IANAL) between optimizing HTML and inserting ads?

What's the legal difference between a NAT gateway modifying packets in order to deliver content to you, and a NAT gateway modifying packets in order to insert ads? By your line of reasoning, every "home router" manufacturer should already be doing this.

Re:Legal precedent (0)

Anonymous Coward | more than 3 years ago | (#34134336)

What's the legal difference (IANAL) between optimizing HTML and inserting ads?

What's the legal difference between a NAT gateway modifying packets in order to deliver content to you, and a NAT gateway modifying packets in order to insert ads? By your line of reasoning, every "home router" manufacturer should already be doing this.

Belkin tried this back in 2003 [slashdot.org] .

I still haven't forgiven them for it (despite never owning the product in question), and I'm sure there are others who feel the same.

Re:Legal precedent (1)

rumith (983060) | more than 3 years ago | (#34134392)

There are plenty of home router manufacturers; if one would insert ads into processed traffic without compensating the user by substantially lowering the router price, people would just stop buying its hardware. Just being able to do something doesn't immediately make it a good business decision.

Re:Legal precedent (1)

tepples (727027) | more than 3 years ago | (#34134842)

There are plenty of home router manufacturers

Only one of which has an exclusive deal with your ISP to provide hardware.

Re:Legal precedent (1)

c6gunner (950153) | more than 3 years ago | (#34135758)

And there are plenty of CDN providers. So I guess you're taking abck your previous comment?

Re:Legal precedent (1)

DrXym (126579) | more than 3 years ago | (#34134796)

However, in case of Opera Mini, I explicitly agree to such manipulations and to accompanying technical solutions.

AOL used to do this too. If you loaded a page through their crappy client software, a transparent proxy would replace the original JPG / GIF with an equivalent ART image. ART was an AOL proprietary image format which was pretty good at compressing images at low data rates. I suppose the theory was they made their software more responsive and reduced bandwidth / phone charges for a largely unnoticeable drop in image quality.

Re:Legal precedent (1)

tepples (727027) | more than 3 years ago | (#34134818)

What's the legal difference (IANAL) between optimizing HTML and inserting ads?

Optimizing HTML does not appear to create a derivative work as defined in US copyright statute [copyright.gov] because the removal of data does not represent an original work of authorship by itself. Ads, on the other hand, are an original work of authorship; there's a reason that the text of an ad is "copywritten" before it's copyrighted.

Re:Legal precedent (1)

WarJolt (990309) | more than 3 years ago | (#34133880)

ISPs have been injecting ads for years. Have you ever tried one of those free isps? I don't think it's going to catch on with mainstream ISPs because people don't like to pay for something and still get bombarded by ads. It still amazes me that cable television can get away with it, but DVRs have almost solved that problem.

Re:Legal precedent (3, Interesting)

WrongSizeGlass (838941) | more than 3 years ago | (#34134088)

Though I agree with your point, what about the other side of the coin: CDN's service removing content from a page being delivered such as an infection? Could this be used to strip those nasty javascript code injections or Flash-based shenanigans from an infected site 'on the fly'? Removing infections would be as 'good' as inserting ads, toolbars, etc is 'bad'.

Re:Legal precedent (1)

rumith (983060) | more than 3 years ago | (#34134332)

If done properly, it would be great. However, the potential for misuse is still pretty high: in the "best" case, the CDN's antivirus software may glitch and trigger removal of harmless content, ruining someone's day. In the worst case, war crime reports may be magically cut out or replaced with pictures of rainbows and unicorns.

Re:Legal precedent (1)

datapharmer (1099455) | more than 3 years ago | (#34134506)

I think that would get them dropped pretty quick as there are quite a few CDNs out there to choose from. Cotendo isn't the only CDN looking into page optimization though. This is being blown horribly out of proportion. Could they: yes. Have they had the ability for at least a decade: yes. There is a big difference though between running an apache module that optimizes code automatically and running a script that inserts ads without a paying customer's permission.

Re:Legal precedent (1)

mldi (1598123) | more than 3 years ago | (#34136260)

You missed the point, but besides that, ISPs have already injected HTML into pages you view. Back on track, unless you can, as a customer, turn this "feature" off, I would never consider using them. I'll optimize my own HTML thankyouverymuch.

My content how it was intended (2, Interesting)

Pikoro (844299) | more than 3 years ago | (#34133798)

If I write a web page, however much it sucks, that's exactly how it should be delivered.

If I see a bad website that takes 20 minutes to load, then I will never buy anything from that site or it's company. If they can't hire a decent web programmer, they don't deserve my money.

However, if you change the page to make it render faster, the ISP is lying FOR the shitty company and their shitty website by making it appear to be a well crafted site.

tl;dr: Leave the shit shitty. It'll put bad programmers out of business which we need.

Re:My content how it was intended (1)

AtomicJake (795218) | more than 3 years ago | (#34133838)

If you pay a CDN to deliver your content, you see it probably as a good service, if it can actually optimize the code.

Re:My content how it was intended (1)

mjwalshe (1680392) | more than 3 years ago | (#34133862)

Indeed though this is a CDN service and not an ISP so the punter would presumably have to sign up to this. Just employ some professionals to develop and tune your website (which if you considering a CDN you should be doing any how).

If you get to the point where you need and can afford to pay for a CDN - you should already have some decent in house SEO who can do this for you.

Re:My content how it was intended (1)

Vegemeister (1259976) | more than 3 years ago | (#34133954)

If I see a bad jpeg processor that takes 20 seconds to rotate an image, then I will never buy anything from that software house or it's parent company. If they can't hire a decent SSE assembly programmer, they don't deserve my money. However, if you vectorize the algorithm to make it render faster, the compiler is lying FOR the shitty company and their shitty software by making it appear to be well crafted code.

No offense, but I took the liberty of mending your statement.

Re:My content how it was intended (0)

Anonymous Coward | more than 3 years ago | (#34134314)

You refuse to buy products from companies with bad marketing material? But... why? A website is not the end all of absolutely everything. It's there to make my life easier and promote the company. If they can't (or can't be arsed) to promoted themselves that still says nothing of their products. You silly silly person.

Re:My content how it was intended (1)

vrmlguy (120854) | more than 3 years ago | (#34134482)

It seems that they only follow best practices for the web to optimize JPEG and PNG files, and remove whitespace and comments from JavaScript and CSS. They also enable gzip compression of all text files.

Optimizing caching — keeping your application's data and logic off the network altogether
Minimizing round-trip times — reducing the number of serial request-response cycles
Minimizing request overhead — reducing upload size
Minimizing payload size — reducing the size of responses, downloads, and cached pages
Optimizing browser rendering — improving the browser's layout of a page

Re:My content how it was intended (0)

Anonymous Coward | more than 3 years ago | (#34134538)

One easy thing a website optimizer can do is remove all the whitespace that makes css, js, html easy for a human to read. That's less wasted bytes to send out. It could also rename all css classes andids and javascript variables to be smaller. Writing rules and code this way sucks as 'a' is nowhere near as helpful as 'upload_status' is for an identifier. You could also grab all CSS and JS and see which rules and code are actually used, then not include unused/overlapping rules and code. You could theoretically also resize/compress images etc, but that seems like a potentially very bad idea.

tl;dr: there is nothing wrong with having a 'source' form of a webpage for easy human understanding and a 'compiled' form for smaller file size

Re:My content how it was intended (1)

Hal_Porter (817932) | more than 3 years ago | (#34135304)

I'm amazed no one has invented a "Compiler HTML" format. You'd take HTML, run it through a compiler on the web server and spit out some compact binary representation of the page. I know people with forums that serve GBs of text every day - compiled HTML would cut their bandwidth costs significantly at the cost of more CPU time on the server. Or the HTML compiler machine could be a proxy in front of another server running PHP generated HTML. It's fetch pages and cache the compiler version and serve that. You'd need an open standard for compiled HTML and browser support of course and that would take time.

Then again maybe gzipping the page is almost as good and it works on all browsers.

Re:My content how it was intended (1)

JustSomeProgrammer (1881750) | more than 3 years ago | (#34136754)

I suppose you won't use any software that goes through a compiler that optimizes code to run faster transparently to the programmer either.

Too much work (3, Insightful)

FranTaylor (164577) | more than 3 years ago | (#34133800)

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 (1, Insightful)

Anonymous Coward | more than 3 years ago | (#34133822)

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:Too much work (3, Insightful)

KiloByte (825081) | more than 3 years ago | (#34133866)

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

Re:Too much work (1)

mounthood (993037) | more than 3 years ago | (#34138592)

So why doesn't the service do this: Fix the HTML, diff the original and result, alert the developers of the changes?

Re:Too much work (1)

zevans (101778) | more than 3 years ago | (#34133908)

CDN customers are likely to be large customers, and large customers don't have Web developers per se, except maybe one or two to address hotspots.

The rest of the time they are using a CMS, and all of the major CMSs have some ... sub-optimal code.

It's inevitable in code written by volunteers around the world with no real central co-ordination and decision making, and it's much better than not having free-as-in-beer CMSs at all.

BUT - if your site is on SuperFantasticCMS and you find that ten of the core modules have these kinds of issues, it's a no-brainer to elect to use this service instead of fixing those ten modules and then battling to get them folded in upstream.

Re:Too much work (2, Informative)

Toy G (533867) | more than 3 years ago | (#34134224)

CDN customers are likely to be large customers, and large customers don't have Web developers per se, except maybe one or two to address hotspots.

The rest of the time they are using a CMS, and all of the major CMSs have some ... sub-optimal code.

This. Newspapers are notorious for crappy sites, implemented 10+ years ago on top of expensive proprietary tools based on the use of table elements and "liberal" abuse of SGML properties. Even the much-admired BBC site is kept together by a hodgepodge of 15-year-old code, which is known to inflict brain damage after webdevs are repeatedly exposed to it.
These are big CDN customers, and they will jump on any opportunity to optimize without rewriting their legacy systems.

It's inevitable in code written by volunteers around the world with no real central co-ordination and decision making, and it's much better than not having free-as-in-beer CMSs at all.

Bollocks. CMSes built by OSS communities in the last 10 years (e.g. Wordpress) are invariably much, MUCH better at generating html than 99% of proprietary solutions.

Re:Too much work (0)

Anonymous Coward | more than 3 years ago | (#34136148)

This. Newspapers are notorious for crappy sites, implemented 10+ years ago on top of expensive proprietary tools based on the use of table elements and "liberal" abuse of SGML properties. Even the much-admired BBC site is kept together by a hodgepodge of 15-year-old code, which is known to inflict brain damage after webdevs are repeatedly exposed to it. These are big CDN customers, and they will jump on any opportunity to optimize without rewriting their legacy systems.

That.

Here's a real-world example [slashdot.org] from a few years ago. (I think they've fixed it since the original post, but talk about dailyWTF moment...)

Re:Too much work (1)

silentcoder (1241496) | more than 3 years ago | (#34134328)

>BUT - if your site is on SuperFantasticCMS and you find that ten of the core modules have these kinds of issues, it's a no-brainer to elect to use this service instead of fixing those ten modules and then battling to get them folded in upstream.

You know you raise a point, SuperFantasticCMS is really generating shittier html with each release now and their all snotty about accepting patches - so the users forked it. You really ought to be using HyperFantasticCMS instead - it's had major code cleanups, the generated html is actually quite slick, the new theme engine doesn't look like it was designed by Jabba the Hut's understudy and they finally fixed that horrible memory leak in the plugin loader too !

Re:Too much work (1)

nametaken (610866) | more than 3 years ago | (#34137070)

There are already ways to have your markup checked if you want that.

This is a paid CDN service. If the content provider doesn't want to use it, they don't.

Legal troubles? (4, Interesting)

cerberusss (660701) | more than 3 years ago | (#34133802)

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?'

I couldn't give a rat's ass about legal troubles. Slashdot is still a tech forum, right?

There are LOADS of much more interesting questions to ponder, such as: what is exactly the speed improvement? And does it work for Javascript and CSS too? And wouldn't it be much better to work on images instead? Or is that too computationally intensive? What kind of algorithm do they use? In what language is it implemented? Et cetera. Legal troubles shmegal smougles.

Re:Legal troubles? (5, Informative)

ThatGuyJon (1299463) | more than 3 years ago | (#34133840)

https://code.google.com/speed/page-speed/docs/rules_intro.html [google.com]

I think this link answers all your questions.
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...

Re:Legal troubles? (2, Funny)

Pharmboy (216950) | more than 3 years ago | (#34134012)

My first thought was "why not write good code to start with?" This is like worrying about a new liposuction method, when instead you should get off your fat ass and drop that Snickers bar. It is solving the symptoms, not the problem.

Re:Legal troubles? (1)

jimicus (737525) | more than 3 years ago | (#34134036)

My first thought was "why not write good code to start with?"

That's hilarious, that is. I don't think I have ever in my life seen code start bloated and move towards tight efficiency. Usually you find developers following the age-old rules about "Don't optimise" and "Don't optimise - yet" and by the time it is appropriate to start optimising, the product's already shipped.

Re:Legal troubles? (1)

somersault (912633) | more than 3 years ago | (#34134080)

That's hilarious, that is. I don't think I have ever in my life seen code start bloated and move towards tight efficiency.

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

Re:Legal troubles? (2, Insightful)

jimicus (737525) | more than 3 years ago | (#34134202)

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:Legal troubles? (1)

Splab (574204) | more than 3 years ago | (#34134174)

Because you are often on a tight schedule defined by someone so far away from programming he thinks it's done like in Swordfish.

Also a note on your fat ass comment - some might have it that easy, but quite a lot are fighting "programming" in their genes. Dropping 10% of your weight will cause all sort of hormones to fire, your body is programmed to think it's in distress and send hormones out trying to force you to regain weight. I know from experience how fucking hard it is, it is absolutely doable, but it does require a solid foundation of people helping you through it.

Re:Legal troubles? (1)

JustSomeProgrammer (1881750) | more than 3 years ago | (#34136634)

Sometimes good code != best client code. There are JavaScript optimizers out there that make your JavaScript much more compact and easier for clients to download. However they also make the JavaScript completely unmaintainable as they put all the code on one line get rid of any unneeded white space and rename functions/variables to be as few characters as possible. Think of it the same as compilers that will optimize out unneeded loops when compiling to bit code. I didn't look into this tool too much but thought it was doing something similar that would allow pages to be sent faster while making maintainability easier.

Re:Legal troubles? (3, Insightful)

grcumb (781340) | more than 3 years ago | (#34134064)

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.

Google Analytics (1)

bradley13 (1118935) | more than 3 years ago | (#34134674)

Interesting that this is from Google. One of the most frequent causes of delay I see are links to external sites. In recent times, I have specifically noticed lots of web-pages waiting for Google Analytics.

Re:Google Analytics (1)

AndrewNeo (979708) | more than 3 years ago | (#34134892)

That's mostly because the GA code needs to go at the bottom of the page, not the top.

Re:Google Analytics (1)

datapharmer (1099455) | more than 3 years ago | (#34135192)

or better yet be replaced by the non-blocking version that has been around for awhile now...

Re:Google Analytics (1)

Lennie (16154) | more than 3 years ago | (#34136650)

My problem with GA is that they add so many cookies.

For all the different domains (with and without www, etc.) seperate cookies and they are large.

This slows down the browser when doing requests to the server, because uploading large cookies takes more time because of the upload-/-download ratio of a lot of customer/business connections.

Re:Legal troubles? (1)

orange47 (1519059) | more than 3 years ago | (#34133842)

you are wrong, if they don't think about legal troubles, they might one day start inserting javascript viruses or something.

Re:Legal troubles? (0)

Anonymous Coward | more than 3 years ago | (#34133922)

Images - convert to j2k on the intermediate server & save 50% image bandwidth vs. optimal jpg.

Will require jpeg-2000 support in all major browsers, but well, it's about time anyway.

Come on guys, get with the program.

Re:Legal troubles? (0)

Anonymous Coward | more than 3 years ago | (#34134000)

Slashdot is still a tech forum, right?

Nope. Timothy is on duty.

Re:Legal troubles? (1)

SuricouRaven (1897204) | more than 3 years ago | (#34134032)

Transparently recompressing images has been done by ISPs before. First by AOL in the dialup days, and today a practice still used by some mobile-phone-network ISPs. Both situations in which the user has very little bandwidth available, so turning a 500k JPEG into a 100k JPEG will make it load quite noticeably faster at the expense of reducing quality. Worst case would be if someone deleted the originals without realising their only copies had been through the degrading proxy.

Re:Legal troubles? (1)

John Hasler (414242) | more than 3 years ago | (#34135204)

> I couldn't give a rat's ass about legal troubles.

Especially as there are none.

There are no legal issues (4, Insightful)

chrb (1083577) | more than 3 years ago | (#34133848)

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.

Re:There are no legal issues (0)

Anonymous Coward | more than 3 years ago | (#34134098)

>> consensual

Well, as long as both parties are legal adults, I guess it's okay...

Re:There are no legal issues (1)

gmuslera (3436) | more than 3 years ago | (#34134144)

The press release talks about "selected customers" so looks like an optional service, probably you could opt out without switching CDNs.

Oh please (4, Insightful)

gaspyy (514539) | more than 3 years ago | (#34133856)

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:Oh please (1)

metrix007 (200091) | more than 3 years ago | (#34133994)

How much do all these techniques alter the original code? Just curious

Re:Oh please (1)

JustSomeProgrammer (1881750) | more than 3 years ago | (#34136850)

Usually minified js is unreadable. Like with variables renamed to one or two characters all unneeded whitespace removed etc.

Re:Oh please (3, Insightful)

SavedLinuXgeeK (769306) | more than 3 years ago | (#34134404)

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:Oh please (1)

dj51d (20536) | more than 3 years ago | (#34135356)

In theory, Google's copy of jQuery is great for sharing the cache. In practice, I've found that if it isn't cached, Google's copy of jQuery causes a shocking amount of latency, often taking well over 500ms to begin downloading.

Re:Oh please (1)

Lennie (16154) | more than 3 years ago | (#34136738)

I agree, that free service isn't that fast and the cache-time isn't very long. The cache time in the HTTP-headers is set to just 1 hour, please, why ?

Re:Oh please (1)

gaspyy (514539) | more than 3 years ago | (#34135780)

Well, if JQuery were integrated with the browsers, it'd be great.

I keep wrestling with it because of lazy CMS (WP, Joomla) plugin developers. If you're not careful, you can end up with three requests to load JQuery, one local, one 1.3.x from Google and another 1.4.x from Google as well, plus various extensions like JQueryCycle AND some Scriptaculous as well. I've seen it.

And all of this for trivial stuff, like validating if a form field is not null, cross-fading a div or opening a pop-up. Come on.

JQuery is a really great tool for doing advanced stuff, but I find it sad that many devs no longer know how to use a simple .getElementById().

Re:Oh please (1)

Lennie (16154) | more than 3 years ago | (#34136902)

"if JQuery were integrated with the browsers"

if you mean, if features from jquery (and similair frameworks) were included in the browser, then that has already happend.

It is called the document.querySelectorAll

http://www.w3.org/TR/selectors-api/ [w3.org]

First we had webdevelopers who wanted to better seperate content, behaviour and style. And they started to implement that, they asked the browser developers to make such an API because it would be a lot faster if browser did that. The browserdevelopers didn't do so, because it would be slow. Then people create frameworks which did that too and a lot of people started using it. Then browserdevelopers said, let's make a spec and implement it, if people are using it anyway, might as well try to make it as fast as possible.

COTENDO TEAR DOWN YOUR WALL !! (0)

Anonymous Coward | more than 3 years ago | (#34133858)

They need a case of whupass opened up on them. What a bunch of maroons !! It's fucking idiots like this that give Canada a bad name !!

No legal trouble (3, Informative)

stephanruby (542433) | more than 3 years ago | (#34133860)

'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?'"

Why should there be? They're not selling bandwidth. They're selling an optimization service (at least, according to their press release, that's what they're selling). This seems to be a clear opt-in situation for their customers. Also, their customers are the ones who are going to be saving money because of this, probably not Cotendo.

Re:No legal trouble (0)

Anonymous Coward | more than 3 years ago | (#34135062)

Could the author of the HTML document claim copyright and assert that Cotendo is violating their rights by altering the document before delivery to the browser?

But what of the crypto possibilities? (2, Insightful)

Zawash (147532) | more than 3 years ago | (#34133872)

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:But what of the crypto possibilities? (1)

MichaelSmith (789609) | more than 3 years ago | (#34134162)

At least it has their email address [mailto] .

Yes it will cause browser quirks (0, Flamebait)

pinkushun (1467193) | more than 3 years ago | (#34133874)

... in browsers with an incomplete implementation of the rendering engine, of course. i.e. IE

Re:Yes it will cause browser quirks (1)

dave420 (699308) | more than 3 years ago | (#34136318)

It's a bit more intelligent than that. Maybe you should read about it before wading in with your opinion?

There isn't a problem here, move along (0)

Anonymous Coward | more than 3 years ago | (#34133936)

If you're paying a CDN to do this for you, then you obviously want them to do it, otherwise you'd take your business elsewhere. This literally has nothing to do with ISPs filtering web pages, because they aren't. It's a completely (useful) opt-in service.

Blind optimizations? (1)

gmuslera (3436) | more than 3 years ago | (#34133946)

Some "aggresive" optimizations could eventually do more damage than good, the extension in apache is very configurable in its features, and some of them have their risks, specially if you work with very dynamic html. Of course, their optimizations could be the safe ones mostly, and the one that makes the pages is the one hiring their services, in particular this one (as seem to be optional), clients be aware exactly of what optimizations they are doing and what they should take into account doing/maintaining their sites.

In general, it seem to be a good idea doing it, in a way or another. And if you can't go thru all the troubles doing the optimizations yourself, and your own servers for some reason can't run this module, the cdn could be your last chance to do that.

Optimized HTML (1)

advance-software (1770510) | more than 3 years ago | (#34134018)

Encode as binary HTML (fastinfoset or exi) & transcode jpg images to jpeg-2000 (approx. 50% saving on image bandwidth vs. optimized jpeg).

Simples.

Is rendering speed really a problem? (0)

Anonymous Coward | more than 3 years ago | (#34134160)

Computers are fast as shit these days. Most of my time is spent on news sites or community sites rendering mainly a wall of text anyway. The bottleneck is -delivering- the page (and all those goddamn barnacles from *.adservice.* that have to come down with the content I -actually- want to read. Once the page reaches my laptop rendering is instantaneous. So why bother altering the content?

Apache at CDN level? (1)

gmuslera (3436) | more than 3 years ago | (#34134164)

Is an apache module, so they should be using it in a reverse proxy role or something like that. Without taking merits from Apache, i tought that they would be using i.e. Varnish for that task.

Re:Apache at CDN level? (1)

Lennie (16154) | more than 3 years ago | (#34136934)

The summary said, doing what is similair to the apache-module.

Legally? yes (0)

Anonymous Coward | more than 3 years ago | (#34134198)

The design mechanisms of many ad-laden sites *cough*cough*cough*ebay*cough*yahoo*cough*google*cough*aol*cough*cough* are extremely inefficient, but they are still fast because of optimizations. However go to your average "I know how to use dreamweaver" idiot developed site and watch as all the broken tables and stuff make the browser client crawl.

Any site that allows user-submitted-content, eg wordpress, blogger, ebay listings, are like this. This is the very content that the apache module can fix, but it can only do so much against poor coding.

The ad companies, eg adsdaq/contextweb give their customers shitty javascript that looks like this:
-script src="http://tag.contextweb.com/TagPublish/getjs.aspx?action=VIEWAD&cwrun=200&cwadformat=728X90&cwpid=XXXXXXXX&cwwidth=728&cwheight=90&cwpnet=1&cwtagid=XXXXXXXXX"--/script-
Note lack of escape characters and required attributes.

If you need an answer... (1)

Stan Vassilev (939229) | more than 3 years ago | (#34134208)

the questions are 'Will this automatic rewriting cause other problems, i.e. browser quirks?'

A snippet out mod_pagespeed's "rewrite CSS" filter:

"CSS minification is considered moderate risk. Specifically, there is an outstanding bug that the CSS parser can silently lose data on malformed CSS. This only applies to malformed CSS or CSS that uses proprietary extensions. All known examples have been fixed, but there may be more examples not discovered yet. Without this the risk would be low. Some JavaScript code depends upon the exact URLs of resources. When we minify CSS we will change the leaf name of the file (although leave it in the same directory). This could break such JavaScript."

Yet their own examples show other risks, as they rewrite CSS selectors from longer selectors to completely different short selectors (i.e. from "div.class span" to "#id"), which even in their examples are only superficially equivalent, and not taking into account any dynamic content the page may render via JS. So any application utilizing JS would suffer a range of awkward issues, even if your code is perfectly valid.

Talking about valid code, one of their other filters:

"The quote removal filter eliminates unnecessary quotation marks (either "" or '') from HTML attributes. While required by the various HTML specifications, browsers permit their omission when the value of an attribute is composed of a certain subset of characters (alphanumerics and some punctuation characters)."

The rest is predictable and of little use: cache headers, image compression, JS minification, CSS/JS outlining/inlining, whitespace collapsing, and removing attributes that specify defaults. Those are all basic and low yield optimizations that any web developer would, for the most part, have done in his original source to begin with.

Unfortunately Google's expertise in searching doesn't automatically transfer into other areas, and this clumsy tool, which at best does little, and at worst produces broken code, is definitely one of their weaker efforts.

If Cotendo intends to force this option on their users without an opt-in (the press release doesn't clearly say), then that's one distribution network I'm definitely not using.

Re:If you need an answer... (0)

Anonymous Coward | more than 3 years ago | (#34134992)

I think there could be much more interesting projects out there to 'improve the web'.

I would start with zlib. Make it run 50% faster and say compress 5% better. Do the same with bzip and bzip2. Those 3 are used everywhere. It is used even in ssl sessions, graphics, compressed sessions, etc... Put in a few more compression types into html headers. Even simple 'I am going to give this to you as 7bit ascii' would probably save a ton.

Another way to really punish your web server is to use ? marks in your urls for items and not have static linked items. Web browsers do not have to cache anything like that (in fact the recommendation is to not cache them). Build in a 'yes your item is still good but I am serving you from a different server today' into html codes. Or something like here is a list of servers and they all contain this item pick a random one. Another way to punish your web link is to set low cache timeouts. Yes in many cases it makes sense. But that little graphic you got 10 years ago that you never change why does it have a 2 min timeout? Also why is it dynamic?

Honestly I think optimizing the text really does little other than make the browser wait longer for other things. A majority of traffic on the web is graphics and flash. I have the logs to back that up too. Think 40 gig of one type vs 200 meg total of the other.

Beware mod-pagespeed (1)

msclark (413170) | more than 3 years ago | (#34134236)

I installed mod-pagespeed recently on a server, and it had some unintended results to put it mildly.

Initial page-loads were slower, as perhaps page-speed was analyzing each page and figuring out an optimization plan. However, that wasn't the worst problem: mod-pagespeed sometimes BROKE javascript code. It attempted to combine and minify javascript files and code, and modern web browsers started producing javascript errors and not working as expected.

Needless to say, mod-pagespeed was immediately removed from our server. I expect that the Cotendo CDN will also have these sorts of issues, which will drive website owners and developers crazy. It will be interesting to see how major content providers react when their content breaks because of the CDN.

Matthew Clark
http://gorges.us/ [gorges.us]

Re:Beware mod-pagespeed (1)

dave420 (699308) | more than 3 years ago | (#34136390)

It doesn't attempt to combine JavaScript files.

Re:Beware mod-pagespeed (1)

Lennie (16154) | more than 3 years ago | (#34136948)

it doesn't ? that would be kind of defeat the reason of using it then.

Man In The Middle? (1)

Nameisyoung007 (1009935) | more than 3 years ago | (#34134554)

Sounds like a Man-in-The-Middle attack to me...

Re:Man In The Middle? (1)

swdunlop (103066) | more than 3 years ago | (#34135040)

Only if the customer was so naive as to use HTTP in the first place.. Oh, I see what you did, there. :)

Interesting Feature (1)

TheNinjaroach (878876) | more than 3 years ago | (#34134704)

I think it's an interesting feature that might help Cotendo stand out among the pack. Don't use them if this kind of feature bothers you. But if the changes don't introduce any bugs and your website loads faster for it, why would you possibly take that as a bad thing?

View Source (1)

drx (123393) | more than 3 years ago | (#34134752)

What happened to view source, the browser function that build the web?

I think it is not nice to deliver unreadable code to your users. Removed line breaks and indenting spaces, obfuscated javascript variables, automatic changing of meaningful file names to some hash-gibbeish ... do not like.

Re:View Source (1)

John Hasler (414242) | more than 3 years ago | (#34136944)

> I think it is not nice to deliver unreadable code to your users.

Then you dislike all systems such as CMSs that deliver generated code, I assume.

Re:View Source (1)

drx (123393) | more than 3 years ago | (#34137342)

Indeed! Most of them cannot even produce hypertext :)

However, with a bit of work it is possible to make them generate code that is more or less readable for the users.

Anyway, not-so-great readable code is still better than code that is only optimized for computers. Almost not different from going binary. And that is against my understanding of the web's spirit.

Easy to fix forced optimisation (0)

Anonymous Coward | more than 3 years ago | (#34136732)

Write a webpage that in a very inefficient way fails to display goatse.

That's not where time is going (1)

Animats (122034) | more than 3 years ago | (#34137432)

If pages load slow, it's very seldom because their HTML has too much white space.

Most page load delays today come from waits for loads from third-party sites. Usually ads, of course. Or because they're doing something in Javascript that's eating time in the browser.

Now, rewriting the page to remove ads - that would really speed things up. Or just replace all images from ad sites. The server still reads the image from the ad site, so the ad site thinks it delivered the image, but there's no need to ship it down the last mile to the user.

Load More Comments
Slashdot Login

Need an Account?

Forgot your password?