Gutenberg-mobile: Performance: [GlobalStep] Android – Opening the Block Editor takes an unexpected long time

[wptester9845]

Description

While loading the Classic Post Editor is nearly instant, loading the Block Editor takes an unexpected long time.

Reproduction Rate

4/4 100%

Expected behavior

The Block Editor should load in a timely manner.

Actual behavior

Loading the Block Editor takes a long time.

Steps to reproduce the behavior

1. Install WordPress 14.2
2. Log in to an account.
3. Open the Post Editor.
   

   Tested on the following

Samsung Galaxy Note 8 (7.1.1)
Huawei P10 (7.0)

Please see the attached video and log for more information

AndroidBlockEditorPerformance.zip
BlockEditorPerformance.txt

Submitted by:

Luis Pimenta

[rachelmcr]

I noticed the same issue although even slower performance, with a spinner appearing for 15+ seconds every time I open the editor. Screencast: https://cloudup.com/csHAHn6aYyW

I noticed a huge section in the app logs when Gutenberg loads, which seems to output every translation for the locale (many lines omitted below, including just the first few and very last lines):

'locale', 'en-gb', { 'Show submenu icon for top-level items': [ 'Show submenu icon for top-level items' ],
  'Display settings': [ 'Display settings' ],
  'Choose variation': [ 'Choose variation' ],
...
'My post status info': [TOO BIG formatValueCalls 1450 exceeded limit of 200] }

(Tested on moto e5 play, Android 8.1.0, WPAndroid 14.2-rc-1, device locale set to en-GB.)

cc @hypest This seems like an excessive amount of time to load the editor when it's a new post / no content.

[hypest]

This is a known situation and might get better when https://github.com/wordpress-mobile/gutenberg-mobile/issues/1660 gets fully implemented.

There are no "clean" solutions to this one yet and that's why we are "accepting" the delay so far. It takes considerable time for the ReactNative runtime to load and boot the editor itself.

[elibud]

Which percentage of our user base is this affecting?

[maxme]

Using a Moto e5 play with Android 8.1.0, every time I open the block editor it takes ~15 seconds to load. If I exit and re-open the editor more than a couple times in a single session it feels impossibly slow to keep working in the app.

I don't know if there any trick to make this faster. I wonder if there is a way to strip the bundle or do some other optimization. We can also think about pre-loading it after app start or keep it in memory if the loading time was too slow.

First steps:

• [x] gather some data (or track loading times if not tracked yet). ref. https://github.com/wordpress-mobile/gutenberg-mobile/issues/1988
• [x] check if the bundle size got (abnormally) bigger. (went from 5Mb to 7.5Mb between from 1.0 to 1.23).
• [ ] check if Hermes performances are significantly better (or worse).

[koke]

Which percentage of our user base is this affecting?

These numbers aren't super reliable, but until we have better metrics from #1988, they might be a good starting point. I took a sample of android editor sessions in the last 7 days, and measured the lag between editor_opened and editor_session_start, which should be an OK approximation. I assumed that anything over 30 seconds or where the events happened in reverse was wrong data.

When I look at the percentile numbers for those launch times, the data is a bit worrying:

• About 2/3 of sessions take more than 0.5 seconds
• About 1/2 of sessions take more than 3 seconds
• 30% of sessions take more than 5 seconds
• 20% of sessions take more than 7 seconds
• 10% of sessions take more thank 10 seconds

With these numbers, I'm surprised we don't hear more about this from support, so I don't know what to think about them. In any case, it seems worth prioritizing, as we have experienced first hand how it performs in lower end devices, so there might be at least some truth to the data.

[hypest]

check if Hermes performances are significantly better

As a reminder, we haven't yet enabled one of Herme's performance features (bytecode support, https://github.com/wordpress-mobile/gutenberg-mobile/issues/1660#issuecomment-578666518). That is, the JS bundle is still text and parsed on load by the JS runtime (Hermes).

[maxme]

With these numbers, I'm surprised we don't hear more about this from support, so I don't know what to think about them. In any case, it seems worth prioritizing, as we have experienced first hand how it performs in lower end devices, so there might be at least some truth to the data.

Yes, I'm surprised as well.

@koke Can you plot the same data but group by app version (and also make sure the property user_info_gutenberg_enabled is true), I wonder if this is relatively new.

[koke]

Can you plot the same data but group by app version (and also make sure the property user_info_gutenberg_enabled is true), I wonder if this is relatively new.

The data above is from the past week only, so it would be mostly for the latest version and most users would have gutenberg enabled. I'd love to see the evolution over time, but since we don't have the right data, and the launch time has to be calculated from looking at the editor event stream for each user, this could take a long time to generate if we wanted to see the evolution over the past year.

I took another approach and re-run the analysis with 1 day of data for a number of weeks before, kind of like a git bisect. It looks like between July and September things started to go bad.

That green line for August 15 seems to be when 20% of users were on 13.0. From the release notes:

Block editor improvements: the editor is auto-enabled when you open a block post (unless you opted out in v12.9), or you can enable it on a per-site basis.

It looks like as soon as users started using Gutenberg, the numbers started to go bad. So I'd say it has more to do with more people using Gutenberg than Gutenberg getting worse.

[designsimply]

I'm comfortable with the block editor but it's slow, when opening the editor it takes roughly 16 seconds to be ready to use. It's toolbar (bold, italic, etc.) is also slow and often not responding on clicks. Please fix..

More info after a follow-up:

It seems to be a WordPress.com site. I created my site with the app. I activated Markdown support (from mobile browser), but other than that it should still have the default settings. I'm not quite aware of those parameters since my only environtment is mobile device, with this app. By the way, there wasn't any performance issue in block editor toolbar on earlier versions. Hope it could help!

• 3-star app review / beta tester feedback Sep 2, 2020 at 5:36 PM
• Galaxy Grand Prime Plus (grandpplte)
• App version 913 (15.6-rc-2)
• OS Android 6.0

^{(internal reference: play-store-feedbackid=gp:AOqpTOHmgh49hDw5j4PMQM-0Sf2mZ7yRdMLoDKMBi7UKbjmKo8y3voROqD1Qe4amIIOD6UQLkBOAFx1NLIogz7Ht)}

[designsimply]

Which percentage of our user base is this affecting?

^{(Also see internal reference: p9ugOq-1gR-p2#comment-2565.)}

[maxme]

I did a quick check recently on our startup_time data and put each entry point in a "bucket".

| Buckets | 0s → 2s | 2s → 5s | 5s → 10s | 10s → 20s | >20s |
| ------- | ------- | ------- | -------- | --------- | ----- |
| Android | 1.09% | 30.56% | 30.44% | 30.87% | 7.04% |
| iOS | 83.60% | 11.86% | 2.37% | 0.26% | 1.92% |

On iOS, 83% of loading times are faster than 2 seconds. Comparatively, on Android, the numbers are quite bad as ~37% of loading times are slower than 10 seconds.

[koke]

That looks pretty bad 😬 I got curious about that distribution and I was wondering if maybe it was better in some phones than others. I looked at September 1-14, removed some outliers, and plotted the 30 most common models:

There were over 5K different models, so I'm not sure how useful it is as a grouping, but here's also the worst offenders (with at least 100 sessions):