[wp-trac] [WordPress Trac] #58472: Emoji loader script causes ~100ms long task

[WordPress Trac]

#58472: Emoji loader script causes ~100ms long task
-------------------------------------+-------------------------------------
 Reporter:  westonruter              |       Owner:  westonruter
     Type:  defect (bug)             |      Status:  accepted
 Priority:  high                     |   Milestone:  6.3
Component:  Emoji                    |     Version:  4.2
 Severity:  normal                   |  Resolution:
 Keywords:  has-patch changes-       |     Focuses:  javascript,
  requested                          |  performance
-------------------------------------+-------------------------------------

Comment (by westonruter):

 In comparing the performance gains with the changes, I was surprised when
 I tried turning off the condition to offload the canvas logic to the
 worker, that the performance was basically the same as if the updated code
 ran in the main thread. (I tested in Chrome.)

 It appears that the main performance benefit here ais ''not'' actually
 from offloading to the worker after all. Rather, the performance gains are
 primarily achieved by enabling the `willReadFrequently` option on the
 canvas `context`. The bare minimum to achieve the performance gains is
 this patch:

 {{{#!diff
 diff --git a/src/js/_enqueues/lib/emoji-loader.js b/src/js/_enqueues/lib
 /emoji-loader.js
 index 536b839f0e..7fefb03bdc 100644
 --- a/src/js/_enqueues/lib/emoji-loader.js
 +++ b/src/js/_enqueues/lib/emoji-loader.js
 @@ -7,7 +7,7 @@

         // Create a canvas element for testing native browser support of
 emoji.
         var canvas = document.createElement( 'canvas' );
 -       var context = canvas.getContext && canvas.getContext( '2d' );
 +       var context = canvas.getContext && canvas.getContext( '2d', {
 willReadFrequently: true } );

         /**
          * Checks if two sets of Emoji characters render the same
 visually.
 }}}

 Interestingly, I only discovered this `willReadFrequently` option when
 switching from comparing the return value of `canvas.toDataURL()` to
 instead comparing the return value of `canvas.getImageData()`. When I made
 this switch, Chrome DevTools gave me a warning:

 > Canvas2D: Multiple readback operations using getImageData are faster
 with the willReadFrequently attribute set to true. See:
 https://html.spec.whatwg.org/multipage/canvas.html#concept-canvas-will-
 read-frequently

 This warning was not emitted when using `toDataURL()`, which seems like an
 oversight in Chrome DevTool's performance auditing.

 Nevertheless, the `willReadFrequently` option is not supported yet in
 Safari ([https://caniuse.com/mdn-
 api_htmlcanvaselement_getcontext_2d_context_options_willreadfrequently_parameter
 Can I use?]).

 Therefore, it seems beneficial to retain offloading the canvas logic to
 the Worker.

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