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

[WordPress Trac]

#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:  major            |  Resolution:
 Keywords:  emoji has-patch  |     Focuses:  javascript, performance
-----------------------------+--------------------------------------

Comment (by azaozz):

 Looking at 31701.4.diff, some ideas:
 - Maybe we can use only one "settings" filter. No need to filter each
 setting separately (`emoji_url`, `emoji_ext`, etc.). Combine them in an
 array and pass it through one?
 - Sometimes widow.load fires much later than expected. Can take up to 5-10
 sec. etc. Usually caused by a slow loading image or script. Would it be
 better to run the emoji JS on DOM ready? Seems that `DOMContentLoaded` is
 supported in all browsers that also support, i.e. all except IE8 and
 older: http://caniuse.com/#feat=domcontentloaded,
 https://developer.mozilla.org/en-US/docs/Web/Events/DOMContentLoaded.
 - If the wp-emoji and twemoji scripts are concatenated together (which is
 a good idea), we won't need to wait for loading. In theory we can load
 late in the footer and run as soon as the file is loaded. In practice we
 can set a var from in wp-emoji-loader.js on DOM ready, then when wp-
 emoji.js loads, we can check that var and either bind to DOMContentLoaded
 or window.load, or run if that has already fired.
 - May be missing something but looks like `waitForTwemoji()` inserts
 another script node every 50ms while waiting.

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