Instead of guessing, let's find out -- it should be easy enough to wipe browser state and test while connected through a computer running WireShark. :)
The server's probably not configured to gzip .ico files by default, so that's not a huge surprise, but would likely be an easy configuration tweak.
I kinda wish we could just replace the .ico with a .png but per the article you linked there's some IE problems with that. We might double-check if it's ok to serve a different favicon for mobile though, if we know desktop IE won't be an issue...
-- brion
On Tue, Feb 11, 2014 at 8:18 AM, Yuri Astrakhan yastrakhan@wikimedia.orgwrote:
FYI, a good ICO optimization article from 2 years ago: http://zoompf.com/blog/2012/04/instagram-and-optimizing-favicons
Brion, it showed up in my history tab - I don't know when that got populated, but i am guessing at the same time as i went to the site, because otherwise it wouldn't have shown any other icons for previously visited sites (or would have to download all of them at once) Also, I am guessing that it follows the regular caching policy that server provides, probably similar to all other static resources like javascript, css, and icons. And we should try to optimize everything if we can, right? We need to make a very good (quick) first impression :)
Judging by how many grayscale colors are being used by the icon, we should easily be able to reduce it to 4 bit, and yes, lets kill 32x.32. I doubt any system out there won't work with 8x8 or 64x64.
Also, there seems to be a problem with the server -- the icon is not being gziped in response:
Request URL:http://bits.wikimedia.org/favicon/wikipedia.ico Request Method:GET Status Code:200 OK
Request Headers Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8 Accept-Encoding: gzip,deflate,sdch Accept-Language: en-US,en;q=0.8,ru;q=0.6 Cache-Control: max-age=0 Connection: keep-alive DNT: 1 Host: bits.wikimedia.org User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/33.0.1750.70 Safari/537.36
Response Headers Accept-Ranges: bytes Age: 22 Connection: keep-alive Content-Length: 15086 Content-Type: image/x-icon Date: Tue, 11 Feb 2014 16:11:22 GMT ETag: "3aee-4eec784a2b180" Last-Modified: Mon, 30 Dec 2013 21:56:38 GMT Server: Apache Via: 1.1 varnish X-Cache: cp1057 hit (3817) X-Varnish: 39968843 39876658
On Tue, Feb 11, 2014 at 9:24 AM, Brion Vibber bvibber@wikimedia.orgwrote:
IIRC they were recently bumped to improve appearance on high-density displays etc (hence the 32x32 and 64x64 sizes) yes. If we can reduce the file size without dumping the larger sizes that'd be nice.
Not sure how badly we really need the 32x32 if we have 64x64, that's true....
-- brion
On Tue, Feb 11, 2014 at 6:21 AM, Daniel Zahn dzahn@wikimedia.org wrote:
Didn't a volunteer from a Google project recently work on all the favicons and make them nicer?
Mobile-l mailing list Mobile-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mobile-l
Mobile-l mailing list Mobile-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mobile-l