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(a)wikimedia.org>wrote;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 <bvibber(a)wikimedia.org>wrote;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 <dzahn(a)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(a)lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mobile-l
_______________________________________________
Mobile-l mailing list
Mobile-l(a)lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mobile-l