[wp-trac] [WordPress Trac] #41405: Only output Emoji JS when emoji used on page

[WordPress Trac]

#41405: Only output Emoji JS when emoji used on page
-------------------------------+------------------------------
 Reporter:  jhabdas            |       Owner:
     Type:  defect (bug)       |      Status:  new
 Priority:  normal             |   Milestone:  Awaiting Review
Component:  Emoji              |     Version:
 Severity:  normal             |  Resolution:
 Keywords:  reporter-feedback  |     Focuses:
-------------------------------+------------------------------
Changes (by pento):

 * keywords:   => reporter-feedback
 * version:  trunk =>
 * component:  Formatting => Emoji


Comment:

 Thank you for the bug report, @jhabdas!

 So, there are two parts to the emoji rendering code. The first part is the
 tiny bit of JavaScript you see inline at the top of any WordPress page.
 This is the minified version of [source:/trunk/src/wp-includes/js/wp-
 emoji-loader.js wp-emoji-loader.js], it detects if the current browser
 renders emoji correctly.

 There are a few things to note about this code:
 - It's intentionally very small, to affect page download size as little as
 possible.
 - It's intentionally very fast, generally executing in a single browser
 tick (around 3ms), to affect page render speed as little as possible.
 - When it needs to load `wp-emoji-release.min.js`, it does so
 asynchronously, so that it doesn't get in the way of the page's primary
 render path.

 Any changes need to be considered against those requirements.

 Unfortunately, detecting emoji use is not as simple as checking for emoji
 in `the_content`, as they can appear anywhere on the page - in widgets,
 menus, headers, or even hardcoded in plugin or theme strings. So, the only
 option is to do what [source:/trunk/src/wp-includes/js/wp-emoji.js wp-
 emoji.js] (which is part of `wp-emoji-release.min.js`) does - check the
 entire page content on the client side for emoji, and watch for any
 changes that include emoji.

 The down side of `wp-emoji-loader.js` being loaded so early is that it
 blocks rendering for the time it's running, so if we were to move the
 content check to the loader (so we could make a smarter decision about
 loading `wp-emoji-release.min.js`), it's very likely that we'd be making
 the initial page render significantly slower for every page on every
 WordPress site.

 And so, what we currently have is what we consider the best trade-off
 between performance, and unnecessary downloads.

 We also find that the problem swings back and forth between loading, and
 not loading, depending on when we roll out support for new emoji, vs. when
 OSes roll out support - when new version of Android, iOS, and macOS are
 released, browsers on those platforms won't download the script anymore,
 because they're able to render the full range of emoji.

 If you're absolutely certain that your site will never have emoji on it,
 and the emoji scripts are causing unacceptable performance issues, the
 best option is to install [https://wordpress.org/plugins/disable-emojis/ a
 plugin to disable WordPress' emoji rendering]. This plugin is super
 simple, it just unhooks the actions and filters that WordPress uses to add
 emoji rendering support, so I wouldn't expect it to cause any security
 issues.

 Now, all that said - have you noticed any particular performance issues
 with either the loader or the full emoji script? Is it blocking rendering
 for longer than it should, or causing unnecessary jitter while things are
 rendering? These are problems that we can, and absolutely should address.
 The emoji rendering script should be as invisible as possible to the
 normal end user experience.

--
Ticket URL: <https://core.trac.wordpress.org/ticket/41405#comment:2>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform