I was looking at the page sizes, and noticed that the wikipedia.icohttp://bits.wikimedia.org/favicon/wikipedia.ico file is 15KB, which is about 14% of the average m. page size. Unfortunatelly, this download is not reported by either firefox or chrome dev tools due to know http://comments.gmane.org/gmane.comp.mozilla.firefox.firebug/9253 bugs https://code.google.com/p/chromium/issues/detail?id=110449, so it might have been overlooked in our site performance review.
Can we shrink it somehow? Or is there a reason to keep it as is?
I tried shrinking it with GIMP to 4bit - and got a 5x reduction. There are some color changes, but I don't know much about images, so possibly some pixel hunting by a designer is needed. Also, I tried 4bit+PNG option, which might not be supported by every browser, especially some mobile ones, and it got me an extra 569 bytes (21%)
Lastly, do we really need 3 different sizes - 16,32,64? Can we do 16 & 64?
Is it actually fetched by actual mobile browsers? Does it block loads, is it in the background, or does it happen at time of bookmarking? Does it happen once ever, or over and over again?
-- brion
On Tue, Feb 11, 2014 at 5:09 AM, Yuri Astrakhan yastrakhan@wikimedia.orgwrote:
I was looking at the page sizes, and noticed that the wikipedia.icohttp://bits.wikimedia.org/favicon/wikipedia.ico file is 15KB, which is about 14% of the average m. page size. Unfortunatelly, this download is not reported by either firefox or chrome dev tools due to know http://comments.gmane.org/gmane.comp.mozilla.firefox.firebug/9253 bugs https://code.google.com/p/chromium/issues/detail?id=110449, so it might have been overlooked in our site performance review.
Can we shrink it somehow? Or is there a reason to keep it as is?
I tried shrinking it with GIMP to 4bit - and got a 5x reduction. There are some color changes, but I don't know much about images, so possibly some pixel hunting by a designer is needed. Also, I tried 4bit+PNG option, which might not be supported by every browser, especially some mobile ones, and it got me an extra 569 bytes (21%)
Lastly, do we really need 3 different sizes - 16,32,64? Can we do 16 & 64?
Mobile-l mailing list Mobile-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mobile-l
Didn't a volunteer from a Google project recently work on all the favicons and make them nicer?
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
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.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 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
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
On Tue, Feb 11, 2014 at 5:09 AM, Yuri Astrakhan yastrakhan@wikimedia.orgwrote:
I was looking at the page sizes, and noticed that the wikipedia.icohttp://bits.wikimedia.org/favicon/wikipedia.ico file is 15KB, which is about 14% of the average m. page size. Unfortunatelly, this download is not reported by either firefox or chrome dev tools due to know http://comments.gmane.org/gmane.comp.mozilla.firefox.firebug/9253 bugs https://code.google.com/p/chromium/issues/detail?id=110449, so it might have been overlooked in our site performance review.
Can we shrink it somehow? Or is there a reason to keep it as is?
I tried shrinking it with GIMP to 4bit - and got a 5x reduction. There are some color changes, but I don't know much about images, so possibly some pixel hunting by a designer is needed. Also, I tried 4bit+PNG option, which might not be supported by every browser, especially some mobile ones, and it got me an extra 569 bytes (21%)
Lastly, do we really need 3 different sizes - 16,32,64? Can we do 16 & 64?
So I don't know if all three sizes are really required for this, but on both Android and iOS remember that users can and do save a bookmark to their home screens which links to the mobile site. The current version was definitely designed with that use case in mind.
Munaf Assaf, who used to be a designer with us, is the one responsible for the most recent redesign that resulted in this look. He is still local and would probably be happy to explain the sizing choices and other parts, and maybe help work on any revisions as a volunteer. He's at munaf.assaf@gmail.com.
fwiw, there was an IRC discussion related to the favicons and their sizes, and it turned out that for IE9/MS one should have this:
Recommended16x16, 32x32, 48x48 Optimal16x16, 24x24, 32x32, 64x64
http://msdn.microsoft.com/en-us/library/ie/gg491740%28v=vs.85%29.aspx
Steven Walling, 12/02/2014 23:35:
Munaf Assaf, who used to be a designer with us, is the one responsible for the most recent redesign that resulted in this look. He is still local and would probably be happy to explain the sizing choices and other parts, and maybe help work on any revisions as a volunteer. He's at munaf.assaf@gmail.com mailto:munaf.assaf@gmail.com.
For those following from home, I assume "Munaf Assaf, who used to be a designer with us" is the last tongue-in-cheek code-name to refer to Odder & al., who have been the main mentors/"managers" of the GCI students (mainly M4tx, Tholam and Vldandrew) who fixed most of our icons, favicons and project logos, updating them to SVG and hi-res versions. :) https://bugzilla.wikimedia.org/showdependencytree.cgi?id=32101&hide_reso... https://bugzilla.wikimedia.org/show_bug.cgi?id=52019 https://bugzilla.wikimedia.org/show_bug.cgi?id=45036 https://gerrit.wikimedia.org/r/#/q/status:merged+project:operations/mediawiki-config+message:favicon,n,z https://gerrit.wikimedia.org/r/#/q/status:merged+project:mediawiki/core+message:%22SVG+version%22,n,z
Nemo
On Tue, Feb 11, 2014 at 8:18 AM, Yuri Astrakhan yastrakhan@wikimedia.org wrote:
Also, there seems to be a problem with the server -- the icon is not
being gziped in response:
On Tue, Feb 11, 2014 at 8:31 AM, Brion Vibber bvibber@wikimedia.org wrote:
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.
Submitted as https://gerrit.wikimedia.org/r/#/c/108484/4; sorry for taking a while to act on this.
On Thu, Feb 20, 2014 at 2:42 AM, Ori Livneh ori@wikimedia.org wrote:
On Tue, Feb 11, 2014 at 8:18 AM, Yuri Astrakhan yastrakhan@wikimedia.org wrote:
Also, there seems to be a problem with the server -- the icon is not
being gziped in response:
On Tue, Feb 11, 2014 at 8:31 AM, Brion Vibber bvibber@wikimedia.orgwrote:
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.
Submitted as https://gerrit.wikimedia.org/r/#/c/108484/4; sorry for taking a while to act on this.
Nope, beaten to it by Brion! https://gerrit.wikimedia.org/r/#/c/113687/ :D