[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:  (none)
     Type:  defect (bug)             |     Status:  new
 Priority:  normal                   |  Milestone:  6.3
Component:  Emoji                    |    Version:  4.2
 Severity:  normal                   |   Keywords:
  Focuses:  javascript, performance  |
-------------------------------------+--------------------
 When doing a performance analysis of the WordPress frontend, Chrome
 DevTools on wordpress-develop and WebPageTest for a production site both
 identify a [https://web.dev/optimize-long-tasks/ long task] while the page
 is loading. A task is considered long when it exceeds 50 milliseconds, and
 the long task showing up during a WordPress page load is around double
 that: ~100ms.

 Chrome DevTools identifies the long task as coming from
 [https://github.com/WordPress/wordpress-
 develop/blob/6.2.2/src/js/_enqueues/lib/emoji-loader.js emoji-loader.js],
 specifically the [https://github.com/WordPress/wordpress-
 develop/blob/52226e0308918474a0ac4ab8017e091ed3ae692a/src/js/_enqueues/lib
 /emoji-loader.js#L12-L36 emojiSetsRenderIdentically() function]. This
 function paints two strings of text onto a canvas and then compares them
 to see whether they are identical. This is a relatively slow synchronous
 operation and it is called up to four times with every page load. The long
 task is negatively impacting the Largest Contentful Paint (LCP) metric in
 Core Web Vitals (CWV). It has the same effect of increasing TTFB by 100ms
 via `usleep(100000)` on the server.

 There are two key opportunities for improving performance of the emoji
 loader script to stop causing this long task and delaying LCP:

 First, the results of the expensive computation in
 `emojiSetsRenderIdentically()` can be stored in `sessionStorage` so that
 when the user navigates to the next page, the browser doesn't have to
 recompute whether the emoji sets still render identically (which of course
 they still do). This speeds up navigations between pages on a site, but it
 does not improve the first page visit.

 Second, and more importantly, instead of rendering the emoji in a canvas
 on the main thread it can instead leverage [https://developer.mozilla.org
 /en-US/docs/Web/API/OffscreenCanvas OffscreenCanvas] in a worker thread to
 do the same. This API is currently supported by 83.69% of browsers
 globally ([https://caniuse.com/offscreencanvas Can I use?]), including the
 current versions of Chrome, Edge, Safari, and Firefox.

 Implementing these changes should give a significant boost to all
 WordPress installs regardless of server performance.

 See also #37788 (especially
 [https://core.trac.wordpress.org/ticket/37788#comment:4 comment 4]) and
 #35498.

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