Philippe Bernard, Author at Favicon's blog

MacBook Pro Touch Bar icon preview, and why it matters

The new MacBook Pro comes with a Touch Bar. This touch-screen-as-a-keyboard element is programmable and all macOS applications are expected to provide some contextual content. Safari is no exception. What does it display and how is your web site impacted?

Long story short: Safari is reusing the mask icon, specified a year ago by Apple while releasing macOS X El Capitan. Basically, if you have created your favicon with RealFaviconGenerator less than a year ago, your web site already has an icon to fit the Touch Bar.

The new Touch Bar preview

From day one, RealFaviconGenerator has aimed at providing a preview for all platforms, so you know in a blink how your favicon looks like everywhere. This is the update for the Touch Bar:

Why it matters

One could say the Touch Bar preview is no more than a nice to have. After all, as soon as you know how the icon is rendered as a pinned tab site, you get a good idea of how it should fit the Touch Bar. Well, this is not that simple.

The pinned tabs area background is light grey and Safari uses the color provided with the icon to fill the icon itself. The Touch Bar behaves differently, with dark contours, white icon and the color used as the icon background. Consequence: a dark color, which would have been a sensible choice a few months ago, is now doubtful when applied to the Touch Bar. In the example below, the Touch Bar icon is too dark and will not fit along with the more colorful icons:

Once again, the safest path is to keep your favicon up-to-date in minutes by using the WYSIWYG editor of favicon.

Alpha feature

Oh, this is an alpha feature. The MacBook Pro with Touch Bar is not available yet even for a demo, as confirmed yesterday when I visited the Apple Store of Opera, Paris, France.

So how do you implement this kind of feature when you can’t even know for sure how it looks like on the final device? Clues and guesswork. For example, take this unboxing video on YouTube:

We can clearly see how icons are displayed. Plus they reflect their Pinned Tabs counterparts. Except for one icon: eBay. The icon is not monochromatic in the Touch Bar, which is normally not possible with the mask icon (the monochromatic SVG icon specified by Apple and used for pinned tabs). At this point, it is hard to know how Safari behaves. Apparently, it embeds predefined icons for well known sites such as Facebook and YouTube (a browser’s classic to introduce a proprietary web site presentation, in bookmarks for example). This make the underlying mechanism biased and less reverse-engineerable.

The feature will be updated as soon as possible to reflect the real appearance of the icon in the Touch Bar. Hopefully, that will only mean removing the “(alpha feature)” caption.

RFG’s WordPress plugin and performance

RealFaviconGenerator’s favicon plugin for WordPress is the most convenient way to install a favicon in a WordPress site with RFG. But it regularly raises a question: how does the plugin affect performance? This is a legit question. You certainly don’t want to slow down your site just for a neat favicon.

TL; DR

RFG’s plugin itself doesn’t affect the performance of a WordPress site. The public side was designed to be very lightweight, so your visitors won’t notice any change before/after you installed the plugin.

As an aside: for the favicon to work, the plugin must be kept activated. As soon as you deactivate it, the favicon markups are not injected anymore. From your visitors point of view, this is as if you didn’t have favicon at all.

Benchmark

Never trust a developer who simply tells you he has written efficient code. Ask for a proof.

The methodology for this benchmark is:

Install a vanilla WordPress 4.6.1. No additional plugins or theme, no fresh content. Just an up-and-running, minimalist WordPress.
Benchmark the homepage and the default post page.
Install and activate Favicon by RealFaviconGenerator. Setup a favicon.
Benchmark the homepage and the default post page again.

… and compare the “without plugin” and “with plugin” results.

As expected, the site is a bit slower when the plugin is installed and active. This is normal: it asks for a bit of processing time to inject the favicon markups in the page and the page becomes larger, taking more time to be transmitted.

And now, some figures. The original homepage is 11497 bytes large. In my benchmark, the average time per request is 26.366ms. Once the favicon is setup, the homepage is 12304 bytes large, a 7% gain. That sounds like a huge increase but it’s not considering how light the original homepage is. Plus, the plugin had no real influence at that point: this is just a reasonable amount of code to declare a Touch icon, a manifest file for Android, etc. Any other solution (like hacking wp-header.php) would do the same. What about the response time? With the favicon installed, it is 26.669ms. The increase is about 1.1%, a small increase probably mostly due to the additional amount of transmitted data.

As a comparison, when Yoast SEO is installed (along with Favicon by RealFaviconGenerator, still active), the page is now 13533 bytes (17.7% increase) and the average response time is 35.597ms (35% increase). This time, the augmentation is significant, although widely accepted across the WordPress community.

Appendix

The following outputs were obtained by running ab -n 1000 -c 5 http://mylocalsite.com/ or ab -n 1000 -c 5 http://mylocalsite.com/index.php/2016/09/19/hello-world/.

Vanilly WordPress

Fresh install, absolutely no plugin.

Homepage

This is ApacheBench, Version 2.3 <$Revision: 1528965 $>
Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
Licensed to The Apache Software Foundation, http://www.apache.org/

Benchmarking 10.0.0.87 (be patient)
Completed 100 requests
Completed 200 requests
Completed 300 requests
Completed 400 requests
Completed 500 requests
Completed 600 requests
Completed 700 requests
Completed 800 requests
Completed 900 requests
Completed 1000 requests
Finished 1000 requests


Server Software:        Apache/2.4.7
Server Hostname:        10.0.0.87
Server Port:            80

Document Path:          /wordpress4benchmark/
Document Length:        11497 bytes

Concurrency Level:      5
Time taken for tests:   26.366 seconds
Complete requests:      1000
Failed requests:        0
Total transferred:      11784000 bytes
HTML transferred:       11497000 bytes
Requests per second:    37.93 [#/sec] (mean)
Time per request:       131.832 [ms] (mean)
Time per request:       26.366 [ms] (mean, across all concurrent requests)
Transfer rate:          436.46 [Kbytes/sec] received

Connection Times (ms)
              min  mean[+/-sd] median   max
Connect:        0    0   0.3      0       4
Processing:    57  132  11.6    130     249
Waiting:       50   91  12.1     90     171
Total:         57  132  11.6    130     249

Percentage of the requests served within a certain time (ms)
  50%    130
  66%    134
  75%    136
  80%    138
  90%    144
  95%    151
  98%    160
  99%    168
 100%    249 (longest request)

Default post

This is ApacheBench, Version 2.3 <$Revision: 1528965 $>
Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
Licensed to The Apache Software Foundation, http://www.apache.org/

Benchmarking 10.0.0.87 (be patient)
Completed 100 requests
Completed 200 requests
Completed 300 requests
Completed 400 requests
Completed 500 requests
Completed 600 requests
Completed 700 requests
Completed 800 requests
Completed 900 requests
Completed 1000 requests
Finished 1000 requests


Server Software:        Apache/2.4.7
Server Hostname:        10.0.0.87
Server Port:            80

Document Path:          /wordpress4benchmark/index.php/2016/09/19/hello-world/
Document Length:        15825 bytes

Concurrency Level:      5
Time taken for tests:   30.330 seconds
Complete requests:      1000
Failed requests:        0
Total transferred:      16239000 bytes
HTML transferred:       15825000 bytes
Requests per second:    32.97 [#/sec] (mean)
Time per request:       151.652 [ms] (mean)
Time per request:       30.330 [ms] (mean, across all concurrent requests)
Transfer rate:          522.85 [Kbytes/sec] received

Connection Times (ms)
              min  mean[+/-sd] median   max
Connect:        0    0   0.2      0       3
Processing:    57  151  13.6    149     284
Waiting:       48   93  12.1     91     212
Total:         57  152  13.6    149     284

Percentage of the requests served within a certain time (ms)
  50%    149
  66%    153
  75%    156
  80%    159
  90%    166
  95%    173
  98%    186
  99%    213
 100%    284 (longest request)

WordPress + Favicon by RealFaviconGenerator

Favicon by RealFaviconGenerator is installed and enabled.

Homepage

This is ApacheBench, Version 2.3 <$Revision: 1528965 $>
Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
Licensed to The Apache Software Foundation, http://www.apache.org/

Benchmarking 10.0.0.87 (be patient)
Completed 100 requests
Completed 200 requests
Completed 300 requests
Completed 400 requests
Completed 500 requests
Completed 600 requests
Completed 700 requests
Completed 800 requests
Completed 900 requests
Completed 1000 requests
Finished 1000 requests


Server Software:        Apache/2.4.7
Server Hostname:        10.0.0.87
Server Port:            80

Document Path:          /wordpress4benchmark/
Document Length:        12304 bytes

Concurrency Level:      5
Time taken for tests:   26.669 seconds
Complete requests:      1000
Failed requests:        0
Total transferred:      12591000 bytes
HTML transferred:       12304000 bytes
Requests per second:    37.50 [#/sec] (mean)
Time per request:       133.345 [ms] (mean)
Time per request:       26.669 [ms] (mean, across all concurrent requests)
Transfer rate:          461.05 [Kbytes/sec] received

Connection Times (ms)
              min  mean[+/-sd] median   max
Connect:        0    0   0.3      0       6
Processing:    78  133   9.4    132     210
Waiting:       60   85   9.3     85     165
Total:         78  133   9.4    132     215

Percentage of the requests served within a certain time (ms)
  50%    132
  66%    136
  75%    138
  80%    140
  90%    144
  95%    148
  98%    153
  99%    160
 100%    215 (longest request)

Default post

This is ApacheBench, Version 2.3 <$Revision: 1528965 $>
Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
Licensed to The Apache Software Foundation, http://www.apache.org/

Benchmarking 10.0.0.87 (be patient)
Completed 100 requests
Completed 200 requests
Completed 300 requests
Completed 400 requests
Completed 500 requests
Completed 600 requests
Completed 700 requests
Completed 800 requests
Completed 900 requests
Completed 1000 requests
Finished 1000 requests


Server Software:        Apache/2.4.7
Server Hostname:        10.0.0.87
Server Port:            80

Document Path:          /wordpress4benchmark/index.php/2016/09/19/hello-world/
Document Length:        16632 bytes

Concurrency Level:      5
Time taken for tests:   30.391 seconds
Complete requests:      1000
Failed requests:        0
Total transferred:      17046000 bytes
HTML transferred:       16632000 bytes
Requests per second:    32.90 [#/sec] (mean)
Time per request:       151.955 [ms] (mean)
Time per request:       30.391 [ms] (mean, across all concurrent requests)
Transfer rate:          547.74 [Kbytes/sec] received

Connection Times (ms)
              min  mean[+/-sd] median   max
Connect:        0    0   0.0      0       0
Processing:   113  152  12.4    150     246
Waiting:       71   94  11.5     93     189
Total:        113  152  12.4    150     246

Percentage of the requests served within a certain time (ms)
  50%    150
  66%    154
  75%    156
  80%    157
  90%    163
  95%    169
  98%    192
  99%    208
 100%    246 (longest request)

WordPress + Favicon by RealFaviconGenerator + Yoast SEO

Favicon by RealFaviconGenerator and Yoast SEO are installed and enabled.

Homepage

This is ApacheBench, Version 2.3 <$Revision: 1528965 $>
Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
Licensed to The Apache Software Foundation, http://www.apache.org/

Benchmarking 10.0.0.87 (be patient)
Completed 100 requests
Completed 200 requests
Completed 300 requests
Completed 400 requests
Completed 500 requests
Completed 600 requests
Completed 700 requests
Completed 800 requests
Completed 900 requests
Completed 1000 requests
Finished 1000 requests


Server Software:        Apache/2.4.7
Server Hostname:        10.0.0.87
Server Port:            80

Document Path:          /wordpress4benchmark/
Document Length:        13533 bytes

Concurrency Level:      5
Time taken for tests:   35.597 seconds
Complete requests:      1000
Failed requests:        0
Total transferred:      13820000 bytes
HTML transferred:       13533000 bytes
Requests per second:    28.09 [#/sec] (mean)
Time per request:       177.985 [ms] (mean)
Time per request:       35.597 [ms] (mean, across all concurrent requests)
Transfer rate:          379.14 [Kbytes/sec] received

Connection Times (ms)
              min  mean[+/-sd] median   max
Connect:        0    0   0.3      0       4
Processing:   116  178  13.6    176     262
Waiting:       87  114  12.1    112     186
Total:        116  178  13.6    176     262

Percentage of the requests served within a certain time (ms)
  50%    176
  66%    180
  75%    184
  80%    185
  90%    194
  95%    200
  98%    220
  99%    227
 100%    262 (longest request)

Default post

This is ApacheBench, Version 2.3 <$Revision: 1528965 $>
Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
Licensed to The Apache Software Foundation, http://www.apache.org/

Benchmarking 10.0.0.87 (be patient)
Completed 100 requests
Completed 200 requests
Completed 300 requests
Completed 400 requests
Completed 500 requests
Completed 600 requests
Completed 700 requests
Completed 800 requests
Completed 900 requests
Completed 1000 requests
Finished 1000 requests


Server Software:        Apache/2.4.7
Server Hostname:        10.0.0.87
Server Port:            80

Document Path:          /wordpress4benchmark/index.php/2016/09/19/hello-world/
Document Length:        17630 bytes

Concurrency Level:      5
Time taken for tests:   40.536 seconds
Complete requests:      1000
Failed requests:        0
Total transferred:      18044000 bytes
HTML transferred:       17630000 bytes
Requests per second:    24.67 [#/sec] (mean)
Time per request:       202.682 [ms] (mean)
Time per request:       40.536 [ms] (mean, across all concurrent requests)
Transfer rate:          434.70 [Kbytes/sec] received

Connection Times (ms)
              min  mean[+/-sd] median   max
Connect:        0    0   0.0      0       0
Processing:   128  203  14.5    201     289
Waiting:       90  122  12.4    121     199
Total:        128  203  14.5    201     289

Percentage of the requests served within a certain time (ms)
  50%    201
  66%    205
  75%    209
  80%    212
  90%    220
  95%    229
  98%    242
  99%    250
 100%    289 (longest request)

RFG enters the 21th century with its new Navigation Bar

When RFG was released 3 years ago, it barely had more than a few pages. So it started with no navigation at all if not for a few links in the footer of each page.

With its modules for Gulp, Grunt, RoR and others, with its API and other pages, the footer was definitely not enough to handle all this content. So here it comes: a Navigation Bar. And that’s fantastic.

And the old header (with a big RFG logo) is gone, leaving more room for the content. Oh, and what about the ad that used to be in the top right corner of each page? It’s gone, too.

New favicon package – Less is more

Did you see the latest favicon package created by RealFaviconGenerator? It’s only 5 lines of HTML!

The initial promise: support everything

RealFaviconGenerator was created with the intent of providing support for all platforms. Not only a single favicon.ico for desktop browsers, as other generators did at the time. To achieve this goal, it generated as many icons as possible: all icons for iOS, from the very first iPhone to the latest iPad. All tile icons for Windows 8 and 10. All icons for Android Chromes. And support for all known platforms, such as Google TV.

The outcome? 20 lines of HTML code and almost 30 icons.

The promise was fulfilled: follow RealFaviconGenerator’s instructions and you actually support everything.

This package has become a kind of reference. Soon after the release of RealFaviconGenerator, half a dozen of generators were created. All took this code snippet as a reference. Some existing generators followed the same path.

Although that was a good start, this package was not satisfying. If you’re like me, you don’t like this huge HTML snippet. In particular, the repetitive Apple Touch icon declarations. Too much lines, and also too similar. Something was wrong.

The new deal: support everything, and keep it pragmatic

When RFG was written, support for all platforms was the big plan. This came with a drawback: this huge bunch of HTML lines and this set of files you didn’t want to put in your root directory. This is because two points were completely left behind.

Some platforms don’t deserve to be supported

Whatever the audience of your website, you want support for all major browsers and platforms. Windows Firefox. iOS Safari. Internet Explorer. Android Chrome. And all the others. But some platforms simply don’t deserve support (or not anymore).

The first victim here is Google TV. It’s 96×96 PNG icon is not generated anymore. That’s final. This product didn’t succeed, plus the original reference that described the icon is gone. “Okay but this icon didn’t hurt, why removing it?” Well, it had side effects. Because Firefox loads too many icons, you could have your almost-never-useful 96×96 Google TV icons loaded by your visitors using Firefox. Thus the cost was much higher than the benefit.

There are also deprecated icons. Android Chrome M38 and prior used to pick a 192×192 icon declared in the HTML code. Current version is M51 and it doesn’t need this declaration anymore. And remember the issue with Firefox? Yep, this 192×192 icon was also regularly loaded by FF. So this declaration is gone (although the icon itself is still present and declared by the Web App manifest).

Last item of this list is the tile icon for Windows 8.0 and IE 10. Windows 8.0 has a market share of 2.62% and no chance of growing. This is very low compared to the 26% share of Windows 8.1 and 10 combined. It is not effective to use two lines of HTML code for such platform when W8.1/10 use only one, or even none when browserconfig.xml is in the root directory.

Platforms don’t need all icons

Apart from a few exotic ones, all platforms and browsers must be supported. So how can we significantly reduce the size of the package? An obvious answer, for a given icons family, is to generate only a single, high resolution icon. For example, could we create only a single 180×180 Apple Touch icon, instead of the full range, starting at 57×57? The answer comes in two parts.

First, yes, iOS devices can deal with a high resolution icon. They are able to scale it down to fit their screen (think: non-Retina screens, small screens…). That was the obvious part.

So iOS can scale icons down, but does it do it well? This is not trivial. We could suppose iOS is using a fast, lightweight scaling algorithm, such as nearest neighbor. That would make sense. But if this hypothesis was true it would lead to poor results when an iPad Mini turns a 180×180 icon to a 144×144 one. Tests were run and the conclusion was: iOS does a great job art scaling down. It does as well as any image edition tool such as Photoshop, or ImageMagick to name the tool behind RFG. All in all, by providing a single, high resolution icon, we support all iOS devices and we support them well.

What about Android Chrome? Same conclusion: Android Chrome is using a compelling scaling algorithm. By providing a single icon, Android Chrome support is as great as before.

Windows tiles are another story. Microsoft defines four icons, which serve different styles: three squares icons (small, medium and big) and a rectangular icon. While RFG used to create the full set, it now produces only the medium, square icon. That should be enough for most web sites.

In the end, the new code is only 5 lines of HTML. And we still support everything. No catch with Firefox. This is much better.

New package. Five lines of pure satisfaction.

Creating a smaller package is the best solution for most websites and developers. However, there are a few drawbacks. What if you want the four Windows tiles icons? What if you are concerned with 404 when iOS devices keep asking for Touch icons in the root directory? (don’t know what this is? Check your server’s logs and look for /apple-touch-icon and 404. See?). All icons and HTML markups are still available, only a few clicks away.

From 1 to 17 icons with only thee clicks

Actually, RealFaviconGenerator will give you up to 40 files if you ask for everything. Hurray!

How RFG’s favicons are tested

RealFaviconGenerator is not a mere claim, a promise that all these icons will (probably) find they way in the tabs, bookmarks and home screens or your visitors. The generated code and icons are actually tested before being released.

The compatibility test

RealFaviconGenerator quality starts with the favicon compatibility test. This is a three-forms process that allows anyone to test the generic package created by RFG on his own device(s). The test exposes your browser to two scenarios:

Favicons files are in the root directory of the web site
Favicon files are in a sub-directory

Basically, you visit a random site which is equipped with RFG’s code, do a few operations (add to bookmark, add to home screen…) and note the results. When it’s done, I get an email.

Different pics

It’s not enough to check that the tested browser displays an icon. We must find out which icon is displayed. Does Windows Firefox takes a PNG icon declared with a link tag or one of the embedded icons of favicon.ico? Does Android Chrome really takes the icons declared in the Web App manifest or an Apple Touch icon? To be certain, the compatibility test comes with different icons, so you can quickly see which one is chosen.

Which icon does Windows Chrome use?

A dedicated domain name

If you play with favicons, you know how browsers can be stubborn regarding caching. Once they load your favicon for the first time, they won’t reload it before a while. So annoying. For this reasons, the compatibility test is always mounted on a particular domain name, so that each test is run in isolation. At the time of writing, the first test is located on test01-v0-13-attempt-5.test.realfavicongenerator.net. As the name says, we are testing the upcoming package v0.13, and this is the 5th attempt.

Running the tests

Tests are run by generous contributors. Simply go to https://realfavicongenerator.net/favicon_compatibility_test and take the two-minutes tour. When a release is incoming, a little tweet usually ask for help.

Would you help testing the next version? We need non cutting edge devices such as iPhone 4, first generation iPad… https://t.co/2Oti6bkkdA

— RealFaviconGenerator (@RealFavicon) 29 juin 2016

Before a release, there is always a special trip to an Apple Store in order to fill the empty cells.

Results

The compatibility of the current version is available, so you know what you can expect from a set of icons got from RFG.

And yep, next package should be released in a couple of days.

Photoshop user? Why not RealFaviconGenerator?

Photoshop is a great tool. Use it and you can expect your pictures to be just perfect. Well, almost perfect.

Let’s see what Apple got when they created their own Touch icon:

$ wget -o apple-icon.png http://www.apple.com/apple-touch-icon.png
$ ls -l
-rw-rw-r-- 1 philippe philippe 4506 Aug 12  2015 apple-icon.png

4506 bytes for a Touch icon? Sounds legit. Now let’s have a look to its metadata:

$ exiftool apple-icon.png
ExifTool Version Number         : 9.46
File Name                       : apple-icon.png
Directory                       : .
File Size                       : 4.4 kB
File Modification Date/Time     : 2015:08:12 19:51:29+02:00
File Access Date/Time           : 2016:05:17 17:00:31+02:00
File Inode Change Date/Time     : 2016:05:17 17:00:31+02:00
File Permissions                : rw-rw-r--
File Type                       : PNG
MIME Type                       : image/png
Image Width                     : 152
Image Height                    : 152
Bit Depth                       : 8
Color Type                      : RGB
Compression                     : Deflate/Inflate
Filter                          : Adaptive
Interlace                       : Adam7 Interlace
Software                        : Adobe ImageReady
XMP Toolkit                     : Adobe XMP Core 5.5-c021 79.155772, 2014/01/13-19:44:00
Original Document ID            : xmp.did:15d8a979-1097-4474-accc-90fc2b02fc58
Document ID                     : xmp.did:25F46708355311E580E8DA1A4BE6CE82
Instance ID                     : xmp.iid:25F46707355311E580E8DA1A4BE6CE82
Creator Tool                    : Adobe Photoshop CC 2014 (Macintosh)
Derived From Instance ID        : xmp.iid:d4dcd418-cd4f-4a8e-a9eb-670e43ff2ee8
Derived From Document ID        : adobe:docid:photoshop:3a0c5b59-7dbd-1178-bb27-91c7aa683e3f
Image Size                      : 152x152

Apparently, this icon was generated by Photoshop.

These are a lot of information… What happens if we remove all EXIF data?

$ exiftool -all= -o apple-icon-no-exif.png apple-icon.png
$ ls -l
-rw-rw-r-- 1 philippe philippe 3555 May 17 17:04 apple-icon-no-exif.png
-rw-rw-r-- 1 philippe philippe 4506 Aug 12  2015 apple-icon.png

We’ve just decreased the size of the Apple Touch icon by more than 20% just by removing the metadata!

Now let’s do the same of, say, the Alphabet Touch icon, wisely generated by RealFaviconGenerator:

$ wget -O alphabet-icon.png https://abc.xyz/apple-touch-icon-152x152.png
$ exiftool -all= -o alphabet-icon-no-exif.png alphabet-icon.png
$ ls -l
-rw-rw-r-- 1 philippe philippe 3714 May 17 17:09 alphabet-icon-no-exif.png
-rw-rw-r-- 1 philippe philippe 3714 Apr 21 05:17 alphabet-icon.png

(yep, we took the 152×152 version, because this is the size of Apple’s Touch icon)

Now, the image is 3.7KB, with or without EXIF, simply because RFG does not produce verbose metadata.

Okay, it’s not entirely Photoshop’s fault. It probably has options to not be that verbose. Plus you’re responsible of post-processing your assets before deploying them. But if Apple did the mistake, others probably made it too. But at least not RFG users.

How Android Chrome scales down icons

TL; DR

Android Chrome behaves almost like iOS: it scales down the icons correctly when it cannot find an icon that exactly matches its screen, producing excellent results using an algorithm similar to Blackman or Lanczos. Just mind special icons, such as pixel art icons that need a particular kind of algorithm such as Nearest Neighbor. But even in that case, Android Chrome offers a decent result.

The problem

The issue all explained here. Plus it’s always a concern when you try to reduce the amount of icons.

The test

I made a test with my old Galaxy S5. When Android Chrome is given a manifest declaring all documents icons for homescreen and splashscreen (9 icons, ranging from 36×36 to 512×512), it takes the 144×144 icon for the home screen and 384×384 icon for the splashscreen. Which is a good thing: as it is suggested to declare only two 192×192 and 512×512 icons, the Galaxy S5 is a good candidate to check the scale down in a real life situation.

For this test, I used this sample 512×512 icon and declared it, alone, in a manifest:

Here is what my Galaxy does with it:

Added to home screen : the icon is now 144x144 — Added to home screen : the icon is now 144×144

Splash screen, the image is now 384x384 — Splash screen, the image is now 384×384

In both cases, we can see that the results are great (despite of my suboptimal choice of theme and background colors).

As for iOS, I couldn’t find an exact match with any of the 40 algorithms provided by ImageMagick. The closest ones are Blackman, then Lanczos.

Visually, I can’t see any difference between what Chrome creates and the 512×512 icon resized to 144×144 by ImageMagick with Blackman and Lanczos:

What about a pixel-art icon, one that shouldn’t be interpolated?

It’s okay, really:

As with iOS, you can spot differences between what you get and what you could expect by providing the icon with the right size (eg. 384×384 for splashscreen and my Galaxy S5) and scaled with the right algorithm (eg. Nearest Neighbor). But it’s no big deal.

How iOS scales the Apple Touch icon

TL; DR

When iOS Safari encounters an Apple Touch icon too large for the screen, it scales it down. Which scaling algorithm does iOS use for this task? It’s not clear. Maybe something close to Lanczos2. The main issue is when the icon requires a particular algorithm, such as Nearest Neighbor: iOS doesn’t exactly produce the expected result. But it’s no big deal.

What is the problem?

There are a lot of Apple Touch icons, ranging from 57×57 to 180×180. If you really want the full story, you can generate up to almost 20 icons! However, when an icon is missing, that’s not a blocking issue. iOS scales the icon down.

As suggested by several users and “summarized” in issue #211, it would be great to generate only one Touch icon (or only a few ones) and let the devices do the scaling. Issue solved, right?

Not so fast. There is one tiny question to answer before dropping almost redundant 20 icons: how good is iOS at resizing pictures?

Finding iOS scaling algorithm

The methodology:

Create a sample 180×180 icon with a diagonal line in it:
Push this image in a web site and add it to the home screen of my iPad Mini running iOS 9:

Here, iOS resizes the pic to 76×76.
Crop the rounded corners to remove all traces of background:
For each algorithm supported by ImageMagick (come on, more than 40!), repeat the same steps with Image Magick commands (ie. scale with the tested algorithm and crop the result), then compare iOS and ImageMagick.

And the result is… iOS doesn’t use any of the algorithms offered by ImageMagick. After studying the results returned by the ImageMagick’s compare command, this is apparently close to Lanczos2. But it’s not exactly the same. In other words, iOS applies a small anti-aliasing effect. Most of the times this is just fine.

Small issue with specific Apple Touch icons

Some images require a specific scaling algorithm. For example, you don’t want the classic scaling with pixel art pictures. Quite the contrary, you want to retain the pixelization. In this case, iOS doesn’t do what you want.

When we zoom the icons, there is clearly a difference:

On the left, a 180x180 icon scaled down by iOS. On the right, a 76x76 icon prepared with RFG and the Nearest Neighbor alforithm. — On the left, a 180×180 icon scaled down by iOS. On the right, a 76×76 icon prepared with RFG and the Nearest Neighbor alforithm.

Yet, at normal scale, it’s nearly not visible. I frankly can’t see the difference between the two:

Conclusion

If you are careful enough to pick a particular scaling algorithm when generating your icons (eg. Nearest Neighbor), then you might want to keep all the icons to make sure your visitors really get the icon you want. Else, you can safely drop smaller icons. iOS will do just well.

Your favicon with Gulp plugin for RealFaviconGenerator

After Grunt, here is the Gulp plugin for RealFaviconGenerator and also the dedicated page to generate your favicon with Gulp.

Creating a favicon should always be a quick and easy task. This is the promise of the Gulp plugin for RealFaviconGenerator. When using this plugin, you don’t have to learn RealFaviconGenerator’s API. Instead, go to RealFaviconGenerator.net and create your favicon as usual. In the result page, click the Gulp tab.

Here, you find step-by-step instructions to setup your favicon in your Gulpfile. A few minutes later, your favicon is fully integrated to your Gulp build!

You have three Gulp tasks at hand:

generate-favicon: the task you run once and each time there is an update on RealFaviconGenerator.
inject-favicon-markups: the task you run constantly, each time you modify one of your pages.
check-for-favicon-update: the task you run from time to time to make sure your favicon is up-to-date.

I’m eager to get your feedback!

GruntJS plugin for RealFaviconGenerator is back, simpler than ever

A year ago, the GruntJS plugin for RealFaviconGenerator was released. The plugin itself was usable, but it missed one important feature: the ability to be used easily, without reading RealFaviconGenerator’s API and testing.

Want to handle favicon with Grunt? Here is how to do it:

Go to RealFaviconGenerator to create your icons for Grunt: iOS, Android and friends.
On the next page, follow the instructions. A copy/paste later, your Grunt project is ready.

I’m confident this feature will have success, at least in the long run, because:

It is about Grunt, which is one of the tools that make web development more professional. For years, manual, error prone deployment has been the norm, and this is still a common practice. In a few years, these bad habits will be over, at least among professionals.
It is about serious asset management. A few years ago, the regular way of adding jQuery to a project was to download it manually and putting its files right in the middle of the homemade material. Now more ad more people use Bower or other tools to manage these resources. It should be the same for the favicon and related icons: getting a favicon.ico and dropping it somewhere in the website project is (should be) a practice from the past.
As a mundane task, favicon should be done quickly. We spend hours crafting HTML pages, tailoring CSS and writing unit tests. But how much time would you dedicate to the favicon? Only a few minutes. This is a small task by nature. Anything that excess 5/10 minutes is flawed.

RFG addresses all this points.

Monetization

Right now, you can use this new feature for free. However, this won’t last. As I announced it in January, I want to make money with RealFaviconGenerator. I have run ads for months and the conclusion is: ads don’t even pay for the hosting costs. I actually makes more money from donations (thank you all!!), which are greatly appreciated but not very significant in total.

So I want to offer additional, paid options. What I told a few months ago still apply: what was free will remain free. We are only talking about new stuff.

Right now, I don’t know which model is the best: a classic subscription or pay-as-you-go? This is the purpose of the feedback form showed just after the instructions for Grunt:

Your feedback would be very appreciated!