RealFaviconGenerator brings the best Facebook meta editor to Yoast SEO

You know Yoast. This is one of the first plugins you installed in your WordPress blog. This module comes with a stunning set of options to make your site SEO-friendly.

Yoast gives your the ability to setup the way your posts will look like once shared via Facebook.

Share on Facebook

In its free version, Yoast SEO offer a simple form where you can type the post title and description, and submit an image. It is basic but straightforward.

Yoast (Free) - Facebook editor

In its Premium version, Yoast let you see in real time how your post will look like in the Facebook newsfeed. Until a few months ago, that was the best solution in the market.

Social by RealFaviconGenerator replaces Yoast’s Social editor.

RealFaviconGenerator integrated into Yoast SEO

What does it add?

  • Preview for desktop, Android and iPhone – Your post will likely appear on Facebook native mobile apps, so better know how your post will be displayed on these platforms.
  • Pixel precise preview – The editor is using the same fonts and styles as Facebook clients. It also replicates their policy regarding title/description cropping. So you know what your visitors friends will see (or not).
  • Edit the image – You can zoom in/out and move the image. So you are in control of the post appearance.
  • Choose between the various formats – Did you know Facebook can display you posts with a square image? A tall image?

Now Yoast and Social by RealFaviconGenerator form the perfect duo for SEO and social optimization for WordPress.

Major sites that think they have their Facebook image right but don’t

The Facebook Open Graph image is the image linked to a web page and displayed by Facebook in the news feed when the said page is shared:

Open Graph image example

This image has special requirements, in particular its dimensions. We already saw that many web sites did it wrong. What about the biggest web sites, the ones everyone know? This article focuses on the Alexa’s 500 worldwide top sites.

The results

65% of the top sites have no Open Graph image. As simple as this. You could expect such sites to be at the bottom of the list, but actually even the first ones lack of it:

Wikipedia - No Facebook Open Graph image
Wikipedia – No Facebook Open Graph image
LinkedIn - No Facebook Open Graph image
LinkedIn – No Facebook Open Graph image
Reddit - No Facebook Open Graph image
Reddit – No Facebook Open Graph image

What about the remaining 35%? Well, 8% don’t match Facebook ratio requirements. For example, Vimeo is using an image which is roughly 5:3.

Vimeo Open Graph image
Vimeo Open Graph image

Facebook expects 19.1:10, so it crops 13% of it to make it fit its news feed:

Vimeo Open Graph image cropped by Facebook
Vimeo Open Graph image cropped by Facebook
Vimeo on Facebook
Vimeo on Facebook

Some other sites have the ratio right, but the images are too big. This is not documented anywhere, but when Facebook gets a small square picture, it displays it as is in the news feed. But when the image is big, Facebook processes it as a wide image. 7% of the top sites fall in this trap. Among them, YouTube (the 2nd most visited web site in the world) and Amazon:

YouTube Open Graph image

Amazon Open Graph image and on Facebook

Conclusion

That leaves us with only 20% of sites that:

  • Have an Open Graph image for Facebook
  • Have a ratio Facebook knows
  • Have the image displayed as is and not cropped by Facebook

Results

Suffice it to say that this result is rather poor.

In one hand, one could think that YouTube homepage sharing is not that important. After all, what is heavily shared across Facebook are YouTube videos (and this part is done right). In the other hand, we need to consider that someone at YouTube created an image for the second most visited website in the world, and this image is not that great. And 80% of the top sites are more or less in this situation.

Thank’s to Meta Chart for the neat online tool!

Why does the Favicon by RealFaviconGenerator WordPress plugin need to be activated all the time?

Here is how to use the Favicon by RealFaviconGenerator WordPress plugin:

  • Install and activate the plugin
  • Go to Appearance > Favicon
  • Design and setup the favicon. Well done!
  • Forget about it

Now, it is tempting to say “Hey, the mission of the plugin is completed. Let’s deactivate it”. Bad move. The plugin needs to be active all the time.

Granted: most of the work is done at creation time, when the favicon is setup. However, the plugin has something to do every time to fulfill its purpose: it must inject special HTML markups in all pages served by WordPress. This is done dynamically. In other words, each time a visitor views a page of your site, Favicon by RealFaviconGenerator is triggered and sends him the favicon markups.

“Wait, doesn’t it slow down my site?” you are wondering. Don’t worry, the plugin was designed to be extremely lightweight and does not affect the performance of WordPress.

If you ever install a favicon manually in WordPress, you may have edited a file called header.php. So you may wonder why the plugin does not behave in a similar fashion. Modifying header.php is actually a bad practice. The major issue is a theme switch. Because header.php comes from the current theme, it is changed whenever you change or update your theme. This is when things start to be messy and you wish your plugins had a better, modular design.

We aim at providing the best experience for favicon on WordPress. If you have questions, please leave us a comment.

Website builders and their lame favicon support

What is the easiest way to setup a good-looking, efficient website? Use a website builder. In a matter of hours, you can create a compelling website and go live.

How good are these websites on mobile? Excellent, actually. Major website builders use responsive templates.

1&1 templates are presented in desktop and mobile configurations
1&1 templates are presented in desktop and mobile configurations

And you probably expect the favicon support to be as great as the templates themselves. Oh, my sweet summer child…

You won’t have anything but the plain old, desktop favicon

For this research, we analyzed 6 website builders and focused on their demos sites:

Long story short: all of them support the basic, old school favicon for desktop browsers. And none of them have anything more to offer, with the exception of Strikingly. It is interesting to look at their solution:

Strikingly "favicon editor"
Strikingly “favicon editor”

On the right, the favicon itself. Upload an image et voilà! Fair enough. On the right, an image labeled “Social Share Image”. The image here actually serves two purposes:

  • Facebook Open Graph image
  • Apple Touch icon

These two images are supposed to be completely different. They should have different dimensions and content.

And this is the best solution around.

Website builders have no favicon for modern platforms

Alright, users cannot create icons for all platforms. It is interesting to note that website builders have not even setup their own homepage: all come with classic desktop icon, nothing more:

The exception here is Squarespace, which has its own Apple Touch icon (for some reasons, it is ill-declared: the 180×180 is declared as the 152×152 icon, etc.).

How to fix

The major issue here is the gap between website design (excellent) and favicon support (minimalist). With the iPhone celebrating its 10th anniversary this year, users can expect an full-fledged favicon support, not only the one that was okay at least 4 years back.

Hum… What if the website builders could leverage the power of RealFaviconGenerator to finally offer to their users the solution they deserve? Wait a minute, we are working on it right now and we call it favicon web components! This is how website builders could look like:

Wix + RealFaviconGenerator
Wix + RealFaviconGenerator
Weebly + RealFaviconGenerator
Weebly + RealFaviconGenerator
Squarespace + RealFaviconGenerator
Squarespace + RealFaviconGenerator
Jimdo + RealFaviconGenerator
Jimdo + RealFaviconGenerator

Facebook Open Graph image: You’re (probably) doing it wrong

If you use Facebook, you must be used to this kind of thing in your news feed:

Facebook Open Graph Image example

Someone (a friend maybe) shared some content and here you are with a title, a description, a link to click. And an image. This image is important because it has the power to grab the attention and generate visits.

This image is usually provided by the shared page, via specific HTML markups. Facebook sticks to the Open Graph specifications and adds a few more requirements, for example regarding the image dimensions.

For many sites, like blogs, the Open Graph image should be a classic, along with the page title and description. Facebook is often of critical importance to generate traffic. Is the Open Graph image correctly created?

An issue (among others)

To answer this question, let’s focus on a particular point. Facebook displays 19.1:10 images in its news feed (eg. 1200×630, because 1200/630=1.905; close enough). When it finds an image of another ratio, it automatically crops it to turn it to 19.1:10.

For example, let’s consider this 540×619 image:

crop_example_1

When the related page is posted to Facebook, the image becomes:

crop_example_2

It is easy to understand how Facebook proceeds. It simply crops the image as much as necessary to make it 19.1:10. To do so, it normally removes the same amount of border on each side to keep the center of the image:

crop_example_3

Now the deal is clear: if you don’t provide a 19.1:10 image to Facebook, it will be cropped automatically. Which can be okay or plain wrong, depending on the image. Take this NCB News article about Macy’s. Its Open Graph image is:

share_planned_3

We can clearly see the name “Macy’s” and the showcase, so this is probably a good photo to illustrate the article. However, when shared on Facebook, the outcome is rather poor:

share_actual_3

“Macy’s” was entirely stripped and the photo is now quite dark.

Open Graph image in the wild

To investigate how the Open Graph images are prepared, 40 sites were selected, 10 in each of the following categories:

  • News sites (Yahoo News, CNN, etc.): They are high traffic sites everyone know. Facebook can be a major source of traffic for these sites, so they are likely to pay attention to the Open Graph images.
  • Tech blogs (TechCrunch, Mashable…): Same as news sites, plus they are tech-related. Can’t be wrong!
  • Blogs about WordPress (WPTavern, wplift…): As WordPress-related blogs, they must know about the right tools to have everything right, including Open Graph images.
  • Social Media blogs (Buffer blog…): Because social media is their core business, they must be especially careful with Facebook-related material.

Results (**drum roll**)

And now, the shocking truth: out of these 40 sites, only 3 are doing it right. Hat off to TechCrunch, Mashable and the New York Times. The later must have a dedicated tool or process for this, because its Open Graph images not only have the right dimensions, they are also cropped manually. I have no strong opinion about TechCrunch and Mashable but I suspect them to auto-crop the images, making the process less relevant: the goal is to do it manually in order to achieve the best result. Not to leave this to an automated tool.

What about the other sites?

Out of 40 sites, only one does not have any image (ITBusinessEdge). All the others come with an og:image markup. This is the sign that web site editors have plans for the Facebook metadata.

However, things are not that crisp when going into the details: 36 sites do not follow Facebook requirements and are exposed to auto-crop.

The next question is “how much?”. After all, removing a single row of pixels cannot hurt. On average, 13% of the surface of the analyzed images is cropped. This is significant, especially from high traffic and/or specialized sites.

Some sites seem to have no particular policy regarding Open Graph image dimensions. For example, on WPTavern, out of 10 posts, the average cropped surface is 18%, with a standard deviation of 14% (and a maximum of 41%). I suspect this is because the featured image (a term WordPress users should be familiar with) is used as the Open Graph image as is. This pattern must be encountered very often.

Some other sites apparently have a “fixed dimensions” policy, but ones that are not accurate. Both CNN and NBC News always expose the same image size. CNN has a systematic 7% of cropped surface, 21% for NBC News. The sad winner is HowToGeek with 43%. The Open Graph images are actually so small that Facebook ignores them and rather picks images right from the shared pages.

Conclusion

This small study shows how sites handle Facebook sharing: they support Facebook, but they do not support it well. This is the purpose of the new RealFaviconGenerator Facebook metadata editor: do it, and do it perfectly.

And for those who know what RealFaviconGenerator is in the first place, you probably recognize the pattern: a few years ago, favicon generation was very poorly addressed. But folks were used to it. Once RealFaviconGenerator came in with the favicon editor the community deserved, the expectations started to change and nowadays everybody want “all the icons”. And the smarter among them use RealFaviconGenerator 🙂

Methodology

The tested sites were obtained by googling something like “most popular news sites” and picking the first sensible list. In the end, the tested sites are not guaranteed to be the most relevant, but the outcome should be good enough.

Then, for each tested site, a sample post was randomly picked (eg. a news site headline article, a WordPress blog latest post, etc.).

News Sites

Tech Sites

Blogs about WordPress

Social Media Sites

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?

example

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:

Touch Bar preview

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:

Touch Bar - Too dark

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:

Touch Bar in action

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.

Navigation bar

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.

Old package. Loads of icons.
Old package. Loads of 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.
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
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?
Which icon does Windows Chrome use?
Apparently, the 32x32 PNG icon
Apparently, the 32×32 PNG icon

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.

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

"Hello Sir, So you are interested in iPads?" "Leave me alone, I'm in the middle of my favicon tests"
“Hello Sir, So you are interested in iPads?” “Leave me alone, I’m in the middle of my favicon test session”

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.