Complaining about WordPress 4.2’s inline Emoji script is to complain about the biggest front end performance gain of the feature.
You see, that tiny script does two things:
- check if your visitors browser supports Emoji, and,
- asynchronously load the JavaScript to polyfill Emoji if the visitor’s browser requires it.
Asynchronously loaded JavaScript means that the browser does not slow down to load it, it loads your content whiles the script loads in the background.
I really care about performance, I consider the commit that switched to loading the script in the manner one of the most important commits in the feature.
When I enabled Emoji on my site, my PageSpeed went from 93 to 93, my time to render (according to WebPageTest) went from under one second to under one second. The emoji script has no affect on a site’s visitors.
Disabling WordPress’s emoji feature is possible via a plugin in the w.org repository. You should feel free to do so in the knowledge it will only affect your browser impaired visitors, as they attempt to ? or ? in the comments.
Comments
13 responses to “Intuition is ?”
@pwcc if you scream about performance you should know what you’re talking about you ignorant fool, whilst accurate, was a less catchy title.
Hahaha you’re priceless! ????
Wait what?!?! No emoji in comments :( #tears
I managed to break them for a few days, ??. They’re back now.
@pwcc link me to the ignorant fool please. I’d like a chuckle.
@bobearth Ha, there’s a few whingers if you search WordPress emoji on Twitter. It’s been a common theme throughout the 4.2 cycle though.
I came by this post since I had a huge performance hit since the 4.2 update. I did not debug i completely but was able to solve the problem for now by just disabling it. I must say I only have a problem for logged in users, and I consider that it might be a combination of plugin + 4.2 (WPML/ACF?).
Second the debuging is a bit harder, because as you explained, the loading of the script is perfectly fine (you won’t see the hit in the network tab).
The problems lay in the javascript itself… it can take a hell of a time to run the script (i’m using the latest stable Chrome on OSX). Well the proof:
logged in user 8.51 seconds to run
anonymous user 9.327 ms to run
So yes my pagespeed will not take a hit…. but there is a huge performance hit!
Already found the anwers, it was this line in emoji.js
parse( document.body );Well I did had the debug bar enabled plus the transient debug bar plugin, so my dom is about 10.000 lines when logged in (in development mode).
We’re using wordpress as a CMS for websites that don’t have comments enabled, and that don’t use emoticons in any of their content.
I know there are a lot of sites out there using wordpress that will be in the same situation (wordpress have pushed development to make it more than just a blogging platform over the years of course).
For such sites adding emoji support to the core in the way it has been is more of a hindrance than a help as it’s downloading code (whether asynchronously or not doesn’t matter) that isn’t needed.
Or am I missing something?
Why add code when you will never use it?
The javascript code added increases the page size by 1.5 kb i think.
I like to minimize html/css code as much as possible. They should add a feature to enable/disable emoji support and should be disabled by default.
@Preetinder @John,
The misconception is Emoji is a site feature.
Emoji is a browser feature that needs to be polyfilled in many browsers today, as support is added the polyfill included with WordPress will stop running. Including the detection script inline saves 100 ms for an additional HTTP request on a typical DSL connection, longer on the crappy mobile connection most people have in their pocket.
Scott Jehl at the Filament Group wrote a really good post on perceived performance last week, the key idea behind – what Scott calls – responsible web design.
I firmly believe WordPress loads the Emoji polyfill responsibly.
performance aside, whos responsibility is it for the polyfill to be loaded? is it wordpress? why is wordpress assuming responsibility for browsers failings? IMO its a bad precedent to set. its not wordpress’ job.
I’m shutting comments down on this post as I don’t wish to host this discussion here. It’s off topic.
Given the sexist, racist and conspiratorial comments in a related post hosted elsewhere in the last few days, such a discussion could only end badly.