mediaelement.js high CPU usage triggered by the buffering CSS animation

[afercia]

Noticed by @iseulde, see discussion here:
​https://wordpress.slack.com/archives/core-editor/p1433862939000659

Also reproduced on my (very old) machine that makes things very evident. Looks like mediaelement.js audio uses a linear gradient animation on the mejs-time-buffering element which triggers a Firefox bug. I remember similiar issues in Firefox reported years ago and probably never fully fixed. Should probably be reported upstream. See screenshot:

Removing that element from the DOM makes the CPU usage go down to 0.

[Hareesh Pillai]

Hi @iseulde and @afercia,

The mediaelement.js library has been updated to v4.2.13 in #46681
Can you please confirm if this bug still exists?

[afercia]

@hareesh-pillai just tested with latest Firefox 69 on a macBook Pro. Seems when the mejs-time-buffering element is hidden with display: none; the CPU usage is normal. So this seems to be improved, as previously the CPU usage increase was happening also with the element hidden.

As soon as the element with its animation gets visible, the CPU usage increases to ~ 20% on my machine. On less powerful hardware the increase is likely way higher. Normally, mejs-time-buffering should be visible for a few seconds or even less but I'd say it still produces an undesirable side effect.

[desrosj]

I'm not sure how this could be improved on WordPress' side of things without a change upstream in mediaelements (perhaps a new option to disable this buffering animation). It ​does not seem like the animation can be disabled in the current version of the library.

@afercia is there any way to confirm that the ~20% CPU increase is being caused by the animation itself and not the fact that the window begins downloading and processing the audio file? Also, can you confirm that this does not just happen in the Classic Editor, but in the block editor and on the front-end as well?

Also, I attempted to find the Firefox issue that you referenced but did not have much success. If you are able to recall the issue, can you please share the link here?

I am going to mark this with a close recommendation with a suggestion to report-upstream unless it becomes apparent how to fix this on the WordPress side.

Noting #51315 as related, as this will update the library from ​4.2.12 to the latest release, 4.2.16, though nothing in the changelog references the performance issue documented here.

[afercia]

@desrosj googling for "firefox bugzilla css animation cpu" ​returns some related bug reports on the bugzilla bug tracker.

For the records, historically Firefox had problems also with animated GIFs, see googling for ​firefox bugzilla animated gif cpu.

Spinner icons and animated GIFs already cause problems in the past, see for example #33322. I guess this is no different for CSS animations.

is there any way to confirm that the ~20% CPU increase is being caused by the animation itself and not the fact that the window begins downloading and processing the audio file?

Test it and hide the animated element with display: none or removing it from the DOM? :) As I wrote in the ticket description: "Removing that element from the DOM makes the CPU usage go down to 0".

Also, can you confirm that this does not just happen in the Classic Editor, but in the block editor and on the front-end as well?

If the animation is shown, I don't see why it should not happen also there.

I'm not sure how this could be improved on WordPress' side of things without a change upstream

Hiding the animated element with display: none should work. Reporting upstream and asking for a fix is also an option.

[desrosj]

Replying to afercia:

googling for "firefox bugzilla css animation cpu" returns some related bug reports on the bugzilla bug tracker.

Thanks for the link. The wording of your report made it seem like you had a specific bug in mind.

Test it and hide the animated element with display: none or removing it from the DOM? :)

I should have clarified that I am unable to reproduce the issue locally in trunk using Firefox nightly (82.0a1 (2020-09-15)) on MacOS 10.15.x. My machine surely has more resources than the older machine you mentioned in your original report, but I did not observe any significant increase in memory usage (at most, a few MB).

My recommendation to close still stands. Helping to fix this in Firefox or requesting a less problematic loading indicator in MediaElements would have a much greater impact.

Leaving this open until someone that can reliably reproduce the issue is able to open a report upstream or follow up on an existing ticket.

[afercia]

Leaving this open until someone that can reliably reproduce the issue

There you go (see attached screenshot).

Tested on a MacBook Pro end 2015 (not a brand new one but still powerful enough). Notes:

• this now happens only with posts made with Classic Editor, as the block editor uses the native <video> element thus browsers use their own players
• worth noting that these posts will use mediaelement.js also in the front end so the high CPU usage will happen also on the front end, which is unfortunate

To reproduce:

• use Classic Editor
• add an audio
• mediaelement.js will display its player
• the easiest way to reproduce is by _not_ playing the audio and instead:
• search in the browser's dev tools for an element with CSS class mejs-time-buffereing
• make it visible by unchecking display: none (see screenshot)
• the buffering CSS animation will appear
• monitor the CPU usage with Activity Monitor (on macOS) or other tools if on Windows
• in my case, testing with Chrome 85, the CPU usage goes up to 63%, which is crazy high

This can be a huge problem when the network is unstable and buffering kicks in or when, as mentioned in the Slack conversation linked in the ticket description, a post is left open in a browser tab for some time.

Worth also noting this ticket is 5 years old but it's still a problem for millions of posts published with previous versions of WordPress where the front end still uses mediaelement.js

[afercia]

Lastly: it appears it's not only Firefox, as the test above was ran using Chrome. Updating the ticket title.

[desrosj]

Just noting that it's been 4 years since this ticket received attention. It would be great to retest this with the latest version of trunk to confirm it's still an issue, and document any differences in the behavior.

Also of note, ticket:56320#comment:6 points out the latest version of mediaelement.js is 7.0.4 and contains a performance specific fix.

[afercia]

This ticket was created on June 2015, almost 9 years ago. It's May 2024 now and, although hardware has evolved and modern devices use more powerful CPUs and GPUs, the high CPU usage can still be reproduced by following the steps from comment:8.

It is triggered by the CSS animation of the mejs-time-buffering element. It's especially noticeable with Firefox but it occurs with other browsers as well. See attached screenshots (Firefox).

It is worth noting the new WordPress editor uses native HTML audio and video elements. As such, this issue only impacts pages created with the Classic editor but that's likely still a very large number of web pages.

Since the CSS animation that triggers high CPU usage is unnecessary, I'd like to propose to just disable it with a CSS rule that overrides the mediaelement CSS.

[afercia]

Firefox high CPU usage when the buffering animation is visible

[afercia]

Firefox normal CPU usage when the buffering animation is not visible

Trac ticket: https://core.trac.wordpress.org/ticket/32597

[oglekler]

This ticket was discussed during bug scrub.

We have related ticket #56320 that can possibly solve this issue. So, it needs to be tested with the new version of the library and if it will resolve the issue, all other testing can be conducted there. If not - we need to understand how this fix is affecting other browsers. The whole discussion can be checked out in the Slack via link above.

Because the #56320 ticket is scheduled to the 6.7 milestone, most likely this ticket should go there too, if needed.

Thank you!

add props to @hellofromTonya and @desrosj

[oglekler]

In accordance with the comment about, I am moving this ticket to the next milestone.