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 #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:

• gather some data (or track loading times if not tracked yet). ref. Instrument editor startup performance #1988
• 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, #1660 (comment)). 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):

[designsimply]

In 3608700-zen a user reported:

I have been unable to open two of my blog posts using your mobile app. […] When I try to open them the screen goes blank and then goes back to the Posts page. If I try it again I get the error on the attached image.

• Reported on December 29, 2020 18:47
• WordPress - 16.3 - Version code: 968
• Android device name: Samsung SM-G960F
• The attached image they refer to shows an ANR (application not responding) error.

The app logs show something similar to what Rachel mentioned in #1888 (comment) starting with:

[Dec-30 17:37 EDITOR] 'locale', 'en-gb', { '100': [ '100' ],
  'Template name\u0004Singular': [ 'Singular' ],

Followed by approximately 2,010 mentions of "TOO BIG formatValueCalls ### exceeded limit"—here are a few lines to illustrate:

  'Browse all templates. This will open the template menu in the navigation side panel.': [ 'Browse all templates. This will open the template menu in the navigation side panel.' ],
  'Description: %s': [ 'Description: %s' ],
  'Name: %s': [TOO BIG formatValueCalls 201 exceeded limit of 200],
  'Template details': [TOO BIG formatValueCalls 202 exceeded limit of 200],
  'Show %s details': [TOO BIG formatValueCalls 203 exceeded limit of 200],
  'Edit %s:': [TOO BIG formatValueCalls 204 exceeded limit of 200],
  'Template name\u0004Search Results': [TOO BIG formatValueCalls 205 exceeded limit of 200],

Here some additional details about the post from the error in the logs that I reviewed:

• blog_id: 163851521
• post_id: 1620
• Characters: 11,223
• Words: 1,949
• Blocks: 33 (all look to be supported blocks such as heading, image, paragraph, separator)

I also noticed the following oddities in the logs:

• After the post is opened, the logs show a line starting with '[Dec-30 17:37 EDITOR] Running "gutenberg"' that has an "initialData" field containing the content of the post and also, in the same line, a "translations" field containing what appears to be more than 10,000 characters of template data (I think) and I am not sure why that is there or if it is needed.
• In the line that starts with "[Dec-30 17:37 EDITOR] 'locale', 'en-gb', { '100': [ '100' ]," there are exactly 100 lines that look normal but then the 101st line begins to show "TOO BIG" errors including what seem like translations of editor settings but also template data such as: "'The rest of it went in a doublet of fine cloth and velvet breeches and shoes to match for holidays, while on week-days he made a brave figure in his best homespun. He had in his house a housekeeper past forty, a niece under twenty, and a lad for the field and market-place, who used to saddle the hack as well as handle the bill-hook. The age of this gentleman of ours was bordering on fifty; he was of a hardy habit, spare, gaunt-featured, a very early riser and a great sportsman.': [TOO BIG formatValueCalls 420 exceeded limit of 200],"—again, I don't know why those are saved there or if they are needed but it does appear the editor in the app cannot handle so many of them (over 2,000).

^{(internal references: see notes in 3608700-zen for a link to open the logs, see paaHJt-1ms-p2 to learn how to look up unencrypted logs)}

@hypest do you think this can be look looked into again now that #1660 has been closed? Why are there thousands of mentions similar to "TOO BIG formatValueCalls 201 exceeded limit of 200" for one post in the app logs and why do the "translations" for that post contain what appears to be sample content even though the post content is totally different? Could these things be the cause of the app opening extremely slowly or even returning ANRs in some cases?

[hypest]

Hey @designsimply! The [TOO BIG formatValueCalls XYZ exceeded limit of 200] messages seem to be a non-issue by itself, and attributed to excess logging.

This looks like a different kind of performance-impacting issue so, may I suggest putting it in its own ticket? Thanks!