Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Why Parse the User Agent?

jefftk.com

Post reply on HN
Print view View original

61–70 of 78 posts

Re: Why Parse the User Agent?

#61

Post by [deleted] »

takeda wrote: post #43
anon1385 wrote: post #40

I do find it slightly strange that saving a few bytes from the size of an image is suddenly of such pressing importance that we need to resort to all these hacks. JPEG2000 has been available in some browsers for years and years now, but I've yet to see any site selectively sending it to supporting browsers to save bandwidth, or anybody advocating for doing that. JPEG2000 first became available in browsers 10+ years a…

Also the appropriate way of declaring what browser supports should be done through the Accept http header.

[deleted]

Re: Why Parse the User Agent?

#62

Post by WallWextra »

anon1385 wrote: post #40

I do find it slightly strange that saving a few bytes from the size of an image is suddenly of such pressing importance that we need to resort to all these hacks. JPEG2000 has been available in some browsers for years and years now, but I've yet to see any site selectively sending it to supporting browsers to save bandwidth, or anybody advocating for doing that. JPEG2000 first became available in browsers 10+ years a…

JPEG 2000 isn't actually better than plain old jpeg.

Re: Why Parse the User Agent?

#63

Post by LocalPCGuy »

On any decently sized site where you expect a user to visit multiple pages, you would load the optimized JPG on the first load, but also detect whether WEBP is supported, and if so, set a flag that will load WEBP for any additional loads.

Re: Why Parse the User Agent?

#64

Post by anon1385 »

WallWextra wrote: post #62
anon1385 wrote: post #40

I do find it slightly strange that saving a few bytes from the size of an image is suddenly of such pressing importance that we need to resort to all these hacks. JPEG2000 has been available in some browsers for years and years now, but I've yet to see any site selectively sending it to supporting browsers to save bandwidth, or anybody advocating for doing that. JPEG2000 first became available in browsers 10+ years a…

JPEG 2000 isn't actually better than plain old jpeg.

That has become the modern accepted wisdom among some people, yes. There are some people today (e.g Mozilla) arguing that WebP isn't better than plain old jpeg either. So maybe in 5-10 years everybody will "know" that WebP was never better than jpeg.

Anyway, it would clearly have had one very significant advantage: support for transparency.

Re: Why Parse the User Agent?

#65

Post by anon1385 »

idlewan wrote: post #47
anon1385 wrote: post #40

I do find it slightly strange that saving a few bytes from the size of an image is suddenly of such pressing importance that we need to resort to all these hacks. JPEG2000 has been available in some browsers for years and years now, but I've yet to see any site selectively sending it to supporting browsers to save bandwidth, or anybody advocating for doing that. JPEG2000 first became available in browsers 10+ years a…

> JPEG2000 first became available in browsers 10+ years ago Apart from Safari ( https://en.wikipedia.org/wiki/JPEG_2000#Application_support ), I'm not sure it's supported at all.

Chrome is the only browser to support WebP, as far as I know (I don't really count modern Opera or Chrome on Android as separate browsers). That was why I made the comparison.

Re: Why Parse the User Agent?

#66

Post by markbnj »

drdaeman wrote: post #48
markbnj wrote: post #25

Earlier quoted context omitted.

There's a whole class of old ASP sites that break if you take "like Gecko" out of the UA. It would be funny if it hadn't made me cry so often.

Why not just break them?

It's not our call. We run a specialty aggregating search engine for a certain class of professionals, and the sites we pull data from were mostly developed when Clinton was president, as far as I can tell. We had a set of probably ten or fifteen sites that just wouldn't work right until we added "like Gecko" to the UA. Like I said, it would have been funny if we hadn't been tearing our hair out trying to figure out why the postback call wasn't firing.

Re: Why Parse the User Agent?

#67

Post by makomk »

spdustin wrote: post #28

Asp.Net 2.0 (and up to 3.5, which is still framework 2.0) sites use UA sniffing to determine which markup to emit for many built-in controls, like Asp:Menu. When Yosemite / iOS 8 / Safari 8 was released, anyone with a SharePoint 2007/2010 site had their navigation get all screwy. I know first hand how infuriating someone's badly designed UA sniffing can be; it happened to me, and I wrote up a fix for it [0]. Why did…

Due to using a moderately obscure browser, I've had problems with ASP.NET sites just plain refusing to include any version of the JavaScript they required for form submissions to work.

Re: Why Parse the User Agent?

#68

Post by cbr »

anon1385 wrote: post #65
idlewan wrote: post #47

Earlier quoted context omitted.

> JPEG2000 first became available in browsers 10+ years ago Apart from Safari ( https://en.wikipedia.org/wiki/JPEG_2000#Application_support ), I'm not sure it's supported at all.

Chrome is the only browser to support WebP, as far as I know (I don't really count modern Opera or Chrome on Android as separate browsers). That was why I made the comparison.

And I guess if Safari had supported WebP back when Chrome and Safari were on the same codebase you would haven't counted them as separate browsers either?

Re: Why Parse the User Agent?

#69

Post by cbr »

pornel wrote: post #55

The whole thing isn't worth as much as it as it seems. In this case PageSpeed generated JPEG at significantly higher quality than WebP, so most of the file size difference is due to quality difference, not codec compression efficiency (distortion measured with DSSIM for JPEG is .009 and for WebP is .015) If you make the comparison fair by creating JPEG (using mozjpeg) at the same quality as WebP it's 22539 vs 20158 b…

We set default quality parameters for PageSpeed with the goal of producing equal quality images between WebP and JPEG, on average (quality 80 for WebP, 85 for JPEG), but you're right that in this case the WebP image is more distorted as measured by SSIM. Sorry, and thanks for catching this!

Testing now with this image, to bring the DSSIM-measured distortion on the JPEG up to 0.015 [1] I need to encode it at quality=69, which gets me a file size of 24317 [2] bytes to the 20158 [3] I had for the WebP. This is 17.1% improvement for WebP over JPEG, as opposed to the 47.7% improvement I found before. This is all with libjpeg-turbo as included by PageSpeed 1.9.

Running mozjpeg (jpegtran) with no arguments built at commit f46c787 on this image, I get 23870 bytes with no change to the SSIM [4]. This is a 15.6% webp-over-jpeg improvement.

It looks like:

1) We should run some timing tests on the mozjpeg encoder, and if it's in the same range as the WebP encoder or not too much worse switch PageSpeed from libjpeg-turbo to mozjpeg.

2) We should check that quality-80 with WebP is correct for getting similar levels of distortion as quality-85 with JPEG. Is this image just a poor case for WebP or is it typical and something's wrong with our defaults?

[1] Technically, 0.014956 with JPEG compared to 0.015060 for the WebP.

[2] http://www.jefftk.com/kitten-demo--ssim15--pagespeed.jpg?Pag...

[3] http://www.jefftk.com/kitten-demo--ssim15--pagespeed.webp?Pa...

[4] http://www.jefftk.com/kitten-demo--ssim15--mozjpeg.jpg?PageS...

Re: Why Parse the User Agent?

#70

Post by jmarantz »

This is a great debate. I've thought about this quite a bit lately when the PageSpeed team was contacted by Microsoft [1] about the conflict between PageSpeed assuming that Android 4.0 can handle webp, and mobile IE masquerading as Android thus breaking on PageSpeed enabled sites.

The debate will never end but it's nice to understand the perspectives.

PageSpeed, plus other WPO tools and complex sites, want the first view to be fast and small. We measure our effectiveness on first-view speedup. The most effective way to get this is by UA sniffing. We know about the other mechanisms and use them too at times, but they don't produce results that are as good for metrics we care about. However we are pretty serious about doing a good job about robust UA parsing; we put more energy into getting this right than a web developer should be expected to expend. The downside (as Microsoft points out) is that when we have to make an update we can't push it to all our users instantly. We should consider mechanisms to dynamically load an updated UA-mapping from a server we control when PageSpeed starts up, but haven't started such an effort.

Browser vendors have their own legitimate motivations. Microsoft IE11 developers don't want to be punished for the shortcomings of earlier versions of IE, and want users of IE11 to get the best, most modern web sites possible, not the IE6 version. Microsoft justifiably wants servers to send mobile versions of sites to Windows Phones. I totally sympathize with their perspective. Chrome was in the same boat when it first launched so it has all kinds of masquerading in its UA and unfortunately still does. Same story, different decade.

[1] https://code.google.com/p/modpagespeed/issues/detail?id=978

Post reply on HN