[wp-trac] [WordPress Trac] #31701: Emoji: Avoid enqueueing JS by default

WordPress Trac noreply at wordpress.org
Fri Mar 20 01:40:11 UTC 2015


#31701: Emoji: Avoid enqueueing JS by default
--------------------------+--------------------------------------
 Reporter:  obenland      |       Owner:
     Type:  defect (bug)  |      Status:  new
 Priority:  normal        |   Milestone:  4.2
Component:  General       |     Version:  trunk
 Severity:  normal        |  Resolution:
 Keywords:  emoji         |     Focuses:  javascript, performance
--------------------------+--------------------------------------

Comment (by pento):

 We have a handful of options for dealing with this:

 1. The current method, which detects browser support for emoji in JS. We
 can potentially optimize the JS, for example by combining `wp-emoji.js`
 and `twemoji.js` during the build process, removing a HTTP request.
 2. There's potential for a `require.js` based solution - having a tiny
 shim for checking for emoji support, then lazy loading the rest if needed.
 This will mean a huge wait for emoji to actually be rendered, though, and
 it won't cut down the number of HTTP requests (it will reduce the download
 size by a few KB for browsers that support emoji, increase it by ~15KB for
 browsers that don't).
 3. Checking for emoji in the post content (and other content areas, like
 widgets), and only loading the emoji JS if they're found. I've tried
 solutions like this in the past, and they always seem to have painful edge
 cases. For example, VideoPress tries to do exactly that, but it can't
 detect videos embedded in themes, for example.
 4. Using server side browser sniffing to decide if we should load the
 emoji JS. We've moved away from browser/OS version sniffing, because it's
 inherently unreliable - we have to keep updating the support matrix as
 browsers add emoji support. We could potentially make it a dynamic matrix,
 maybe by having the W.org API return an up-to-date copy for sites to use,
 but I'm still quite wary of the idea.

 I'm leaning towards option 1 as the sanest solution. By combining the two
 scripts, we could potentially set the script to `async`, as it has no
 other dependencies.

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


More information about the wp-trac mailing list