Table block performance with large number of rows

[TylerB24890]

Description

The Core Table block has performance issues when it contains a large number of rows and data. I have several pages with 800+ table rows and 2-4 columns each. When attempting to edit text in the editor, the typing is a few seconds behind the actual keystrokes. It's almost as if there is a few seconds of latency before the editor can process what the user is typing. The tables contain pure text, with a text link in the last column for each row, so no very complex content included.

I have tested this on a fresh WP install with no additional plugins. The experience was slightly better, however there was still a noticeable delay when attempting to type. Instead of a ~3 second delay, there was a ~1-2 second delay. The client who reported this issue has experienced up to a ~5-10 second delay when editing large tables. On the production environment I would assume this to be longer due to the other blocks on the page, however in a fresh WP install I would not expect any kind of performance issues with this.

I am not sure if this is caused by the actual table block, or if this is a problem with the Block Editor in general when there is that much content. All of the other pages that do not contain a large table like this are loading and editing as expected, though.

Step-by-step reproduction instructions

1. Create 2 tables in the Block Editor using the Core Table Block.
2. Enter in ~400 rows and 3-5 columns each. Populate the columns with some content -- 1+ words per column.
3. Publish the page and refresh the block editor. You may see a slight delay in load times following the table addition.
4. Attempt to edit the table contents and observe the typing latency.

Expected behaviour

The expected behavior here is that the Block Editor will process typing as normal without any input lag.

Actual behaviour

When editing the contents of a large table, typing causes input lag between the keyboard and block editor. Clicking on any cell in a large enough table, and attempting to type additional words (or edit existing), you will see a delay between the keypress action and the character rendering on screen.

Screenshots or screen recording (optional)

In the GIF below, when the cursor disappears is when I begin typing. You will see my words show up when completed, rather than individually. This was taken on a completely fresh install of WP.

WordPress information

• WordPress version: 5.6 (also tested on 5.7)
• Gutenberg version: Core Version
• Are all plugins except Gutenberg deactivated? Yes
• Are you using a default theme (e.g. Twenty Twenty-One)? Yes

Device information

• Device: Desktop | MacBook Pro
• Operating system: OSx 10.15.7 - Catalina
• Browser: Chrome, Brave

[apieschel]

It's the table block. I start to see lag around 30 rows x 30 columns on a single table, even when entering data with all of the other cells empty. We also need a table block that can handle the editing of large datasets on the fly. We're currently looking into other react component libraries or a custom solution, but would love it if the core table block could be improved to handle more data.

[t-hamano]

One of the major performance impacts might be the RichText component's onFocus prop:

gutenberg/packages/block-library/src/table/edit.js

Lines 432 to 439 in e84b38d

	onFocus={ () => {
	setSelectedCell( {
	sectionName: name,
	rowIndex,
	columnIndex,
	type: 'cell',
	} );
	} }

As shown below, there appears to be a big difference in keyboard typing speed when this prop is present and when it is commented out.

When there is onFocus prop:

onFocus_enabled.mp4

when onFocus prop is commented out:

onFocus_disabled.mp4

Of course, if we remove this prop, we will not be able to update attributes properly, but I am wondering if there is an approach that can improve performance.

[t-hamano]

After investigating a little more, it seems that the cause might be that all cells (RichText component) are re-rendered by updating the state (selectedCell). When a table cell is focused, its status is updated via setSelectedCell. However, at the moment I don't know how to approach the problem...