The user in 7651806-zen appears to be running into this issue. They noted they've used the app for years but only began to run into issues around mid-January. I'm not certain why this would be, as their posts prior to January were also media-heavy, but potentially related to poorer WiFi connection while travelling.

As far as I investigated, the issue seems related to the block processors executed for each media associated to the post when saving (reference 1, reference 2). I haven't narrowed down yet if the culprit is a specific preprocessor, I'll share more details after finishing the investigations.

Block processing benchmark

I benchmarked the function updateReferences that is invoked before saving the post (reference). This function is the one that uses the block processors to ensure that the media referenced in the post content is properly formed. For the test, I used a post with 2 Gallery blocks and 18 Image blocks (included in the Gallery blocks):

Media Item 1:
Duration of updating references: 0.19202925 seconds

• Processor WordPress.GutenbergFileUploadProcessor: 0.005576291 seconds
• Processor WordPress.GutenbergImgUploadProcessor: 0.142444625 seconds
• Processor WordPress.GutenbergGalleryUploadProcessor: 0.025316208 seconds
• Processor WordPress.GutenbergCoverUploadProcessor: 0.003687166 seconds
• Processor WordPress.GutenbergMediaFilesUploadProcessor: 0.003554458 seconds

Media Item 2:
Duration of updating references: 0.175285958 seconds

• Processor WordPress.GutenbergFileUploadProcessor: 0.003587833 seconds
• Processor WordPress.GutenbergImgUploadProcessor: 0.137310417 seconds
• Processor WordPress.GutenbergGalleryUploadProcessor: 0.025347833 seconds
• Processor WordPress.GutenbergCoverUploadProcessor: 0.003575958 seconds
• Processor WordPress.GutenbergMediaFilesUploadProcessor: 0.003627542 seconds

...

Media Item 18:
Duration of updating references: 0.173225209 seconds

• Processor WordPress.GutenbergFileUploadProcessor: 0.003594291 seconds
• Processor WordPress.GutenbergImgUploadProcessor: 0.1359345 seconds
• Processor WordPress.GutenbergGalleryUploadProcessor: 0.024892208 seconds
• Processor WordPress.GutenbergCoverUploadProcessor: 0.003528042 seconds
• Processor WordPress.GutenbergMediaFilesUploadProcessor: 0.003521333 seconds

Total duration of processing media (18 media items): 3.128310333 seconds

As you can see, each media item takes around 175 ms to be processed. This is a very long duration, especially considering that posts might have several media items. The total time is above 3 seconds, which is aligned with the issue shared.

Delay estimations

One of the main problems is that the duration grows linearly, the more media items the longer the delay. Here's an estimation of the delay in saving post durations based on the number of media items:

• 5 media items: 0.875 seconds
• 10 media items: 1.75 seconds
• 15 media items: 2.625 seconds
• 20 media items: 3.5 seconds
• 25 media items: 4.375 seconds
• 30 media items: 5.250 seconds

A delay of one second is high but may be unnoticeable by users. However, beyond that value, I think the experience is subpar.

Potential solution

I profiled the editor using Xcode instruments and confirmed that the delay is caused by using NSRegularExpression. I presume we could improve and optimize the block processing, but still, I think relying on regular expressions to parse the HTML content will always be a bottleneck. I checked the approach we use on Android and saw that the HTML is parsed using an HTML parser library (code reference) instead of regular expressions. I haven't benchmarked Android but since the issue can't be reproduced, I understand that using a parsing library is more optimal.

That said, I propose using an HTML parser like SwiftSoup. However, I'd like to note that this approach implies refactoring all the processors.