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 <yastrak...@wikimedia.org>wrote: > 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 <bvib...@wikimedia.org>wrote: > >> 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 <dz...@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 > >
_______________________________________________ Mobile-l mailing list Mobile-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mobile-l
