Faster and more robust editor asset management #233

kean · 2025-11-20T22:54:41Z

What?

The subsequent editor loads are now ~1.3s faster. The first launch is ~1s faster.

There are a few changes compared to the previous implementation:

Move code that fetches assets (manifest and files) to the new EditorService. The assets manifest is now fetched in parallel with the editor settings.
Only EditorService now triggers the actual download of the assets. The assets are put into a GutenbergKit/{siteURL}/assets folder.
Remove EditorAssetsProvider and instead inject the plugin styles and scripts in window.GBKit when launching the editor (the same way it's done for editor settings). It happens only if EditorService verifies that all the required files exist on disk. If not, the plugins are disabled until the next time.
EditorService reads editor settings and assets manifest in one atomic operation. When new manifest is loaded, it replaces the current one only after fetching all assets for it. Until then, the editor will always use the previous version of the manifest.
Remove editorSettings from EditorConfiguration. Add them to internal EditorDependencies types fetched by EditorViewController

Minor changes:

Remove editorAssetsEndpoint parameter from EditorConfiguration
Make logging a cross-cutting concern, so it could be configured once and would be easier to use across GBK

Planned future changes:

Cleanup unused assets on launch to make sure the disk usage does not grow
Improve how and when refresh and assets download is triggered
Cover with unit tests and generate the same code in Kotlin

Why?

How?

Testing Instructions

Accessibility Testing Instructions

Screenshots or screencast

Before / After

Note: the preparing editor message disappears quicker because "fetch editor settings" is now a step inside EditorViewController.

comparison.mp4

kean · 2025-11-20T23:01:53Z

ios/Sources/GutenbergKit/Sources/Service/EditorAssetsManifest.swift

+import CryptoKit
+import SwiftSoup
+
+struct EditorAssetsManifest: Codable {


This is an existing struct. I made no changes to it – just renamed the file.

…oaded

dcalhoun

Thank you for creating this!

This makes sense to me a high level. It feels like a worthwhile improvement overall, especially given the performance improvements.

I left a few thoughts to consider. Many are for bettering my own understanding.

ios/Demo-iOS/Sources/Views/AppRootView.swift

dcalhoun · 2025-11-21T14:05:27Z

ios/Sources/GutenbergKit/Sources/EditorConfiguration.swift

-    /// Endpoint for loading editor assets, used when enabling `shouldUsePlugins`
-    public var editorAssetsEndpoint: URL?


Why are we removing editorAssetsEndpoint? I believe it's useful in the future whenever we change the REST API endpoint used, it also allows alternatives for third-parties as needed.

I suggest to add it again in the future if it's needed. For now, I kept it simple as EditorService knows what endpoints to use, and the code in the app was duplicating the same endpoint.

Actually, I believe we must retain this to support WPCOM sites. They require setting a namespace endpoint—e.g., https://public-api.wordpress.com/wpcom/v2/sites/<site_id>/editor-assets.

From my testing, plugin loading currently fails for WPCOM Simple sites.

Good catch. So far, I've only tested it with an Atomic site as the demo doesn't seem to support Simple sites:

I'll probably revert it for now, but there has to be a better way to do it. I'm not completely happy with how the configuration is spread out between GBK and the app. I'm leaning towards centralizing this knowledge in GBK so it would work in both the app and the demo. The configuration code is also a bit hard to follow at the moment, but it seems like it's better be left for future PRs.

Correct, the demo app does not support WPCOM sites. I tested via integrating with the WordPress-iOS app.

I open to refactoring the API for configuring and starting the editor.

As much as possible, we should avoid WPCOM/Jetpack references in the GutenbergKit code base. There are few that exist today, but they need to be removed in the future.

ios/Sources/GutenbergKit/Sources/EditorConfiguration.swift

ios/Sources/GutenbergKit/Sources/EditorLogging.swift

dcalhoun · 2025-11-21T14:10:22Z

ios/Sources/GutenbergKit/Sources/EditorViewController.swift

            },
-            logLevel: '\(configuration.logLevel)'
+            logLevel: '\(EditorLogger.logLevel.rawValue)',
+            manifest: \(dependencies?.manifest ?? "undefined")


Any performance implications from adding this? 🤔 I suppose it is no larger than editorSettings, eh?

I wonder if it's worth spreading the properties over the top-level object. I could see one day allowing GBK configuration to control allowedBlockTypes.

Any performance implications from adding this? 🤔 I suppose it is no larger than editorSettings, eh?

I wouldn't expect it to be slower than the current implementation, but I already had some second thoughts yesterday. Is it safe to pass these larger strings directly in JS this way? Does it need escaping? Is there a more robust way to do it? Should we pass the whole pre-processed manifest as a separate object? Both settings and manifest seem to have <scripts> and <styles>, is there a better way to inject them? What about allowedBlockTypes? Should the app combine them (for core and plugins)?

I agree, my original performance concerns are likely invalid; I figured I'd share my thought nonetheless.

I do not have a better idea for injecting them at this time.

Regarding escaping, maybe there is benefit. That said, if the itself relies upon the same scripts we are retrieving, would site already be compromised? Is the mobile editor exposing anything that site does not already?

For allowedBlockTypes, I envision this eventually becoming an editor configuration option rather than a value returned from the editor assets endpoint. I consider its current location a stopgap solution while various blocks do not function in the mobile editor.

ios/Sources/GutenbergKit/Sources/EditorViewController.swift

dcalhoun · 2025-11-21T14:22:09Z

src/utils/bridge.js

+	const gbkit = getGBKit();
+
+	// iOS provides manifest directly in GBKit configuration
+	if ( window.webkit && gbkit.manifest ) {
+		return gbkit.manifest;
 	}

-	const { siteApiRoot, editorAssetsEndpoint, authHeader } = getGBKit();
+	// Android fallback - fetch from API
+	const { siteApiRoot, editorAssetsEndpoint, authHeader } = gbkit;


I don't believe there is a downside to de-structuring all values up front.

Suggested change

const gbkit = getGBKit();

// iOS provides manifest directly in GBKit configuration

if ( window.webkit && gbkit.manifest ) {

return gbkit.manifest;

}

const { siteApiRoot, editorAssetsEndpoint, authHeader } = getGBKit();

// Android fallback - fetch from API

const { siteApiRoot, editorAssetsEndpoint, authHeader } = gbkit;

const { manifest, siteApiRoot, editorAssetsEndpoint, authHeader } = getGBKit();

// iOS provides manifest directly in GBKit configuration

if ( window.webkit && manifest ) {

return manifest;

}

// Android fallback - fetch from API

Alternatively, I don't believe there is a downside to invoking getGBKit() multiple times, as it early returns with the cached value on the window.

Suggested change

const gbkit = getGBKit();

// iOS provides manifest directly in GBKit configuration

if ( window.webkit && gbkit.manifest ) {

return gbkit.manifest;

}

const { siteApiRoot, editorAssetsEndpoint, authHeader } = getGBKit();

// Android fallback - fetch from API

const { siteApiRoot, editorAssetsEndpoint, authHeader } = gbkit;

const { manifest } = getGBKit();

// iOS provides manifest directly in GBKit configuration

if ( window.webkit && gbkit.manifest ) {

return gbkit.manifest;

}

// Android fallback - fetch from API

const { siteApiRoot, editorAssetsEndpoint, authHeader } = getGBKit();

I reverted this change together with how manifest is passed to the editor (now it again uses separate post message scheme).

Would you please explain the rationale for reverting for my own education? 🙇🏻‍♂️

ios/Sources/GutenbergKit/Sources/Service/EditorService.swift

ios/Sources/GutenbergKit/Sources/EditorLogging.swift

kean · 2025-11-21T21:44:39Z

I made a few more changes:

Added unit tests and fixed a couple of issues (it explains most of the line additions)
Updated EditorService to store processed manifest on disk (it takes around 100ms to generate it)
Added support for cleaning up orphaned asset files, so we don’t take too much space on disk

With these changes, this whole step now takes 2ms.

I had to switch to a different task today and didn't have time to review the final PR. I'll do it when I have time. It should be good.

This restores the EditorAssetsProvider to handle manifest loading via WebKit message handler instead of injecting it directly into the configuration. Changes: - Restored EditorAssetsProvider.swift to handle manifest requests - Added EditorAssetsLibrary wrapper around EditorService - Removed manifest property from EditorConfiguration and EditorDependencies - Updated EditorViewController to use EditorAssetsProvider - Updated bridge.js to use message handler for iOS manifest fetching - Removed manifest from GBKit configuration

kean · 2025-12-01T21:14:01Z

I updated the unit tests and added a few more. It should be good for review and merge now.

dcalhoun

Overall, this tested well for me in the demo app.

As stated in a new inline comment, I believe we must retain the editorAssetsEndpoint configuration. I also noted a few oddities likely worth addressing.

This may be understood, but we need to open a sibling WordPress-iOS PR integrating these changes.

dcalhoun · 2025-12-02T12:15:49Z

ios/Demo-iOS/Sources/Views/AppRootView.swift

-            case .none: self.activeEditorConfiguration = nil
+            case .bundledEditor:
+                let config = createBundledConfiguration()
+                activeEditorConfiguration = config


Likely worthwhile consistently using self in this switch.

Suggested change

activeEditorConfiguration = config

self.activeEditorConfiguration = config

ios/Demo-iOS/Sources/Views/EditorView.swift

ios/Sources/GutenbergKit/Sources/Service/EditorService.swift

ios/Demo-iOS/Sources/Services/.swift

dcalhoun · 2025-12-02T13:22:53Z

ios/Sources/GutenbergKit/Sources/EditorConfiguration.swift

-    /// Endpoint for loading editor assets, used when enabling `shouldUsePlugins`
-    public var editorAssetsEndpoint: URL?


Actually, I believe we must retain this to support WPCOM sites. They require setting a namespace endpoint—e.g., https://public-api.wordpress.com/wpcom/v2/sites/<site_id>/editor-assets.

From my testing, plugin loading currently fails for WPCOM Simple sites.

jkmassel

After some discussion with @dcalhoun and @kean, I'm approving this to merge and we can deal with breakage later. This and #232 represent some pretty serious refactoring, so we should get them landed then incrementally adjust after.

kean added 17 commits November 20, 2025 13:01

Add EditorService

5ef6674

Remove editorAssetsEndpoint parameter from EditorConfiguration

e60b72d

Move assets management to EditorService

0d7305f

Add logging

b67f3b2

Add a way to clear loaded assets

be494ff

Inject manifest directly without EditorAssetsProvider

b8b92ae

Simplify CachedAssetSchemeHandler

d85b7e9

Move private methods below

e1ac3a9

Add manifest verification

463bc51

Make refresh non-throwing

4746e07

Add State file as an indicator where the request finished or not

5fb910a

Fix build errors

6ff7728

Remove EditorAssetsManifest

a55b1a9

Fix build errors

82d7dd3

Add shared EditorService instances

5b27865

Cleanup

e77b8e6

Do not refresh too often

28f03b0

kean commented Nov 20, 2025

View reviewed changes

kean marked this pull request as draft November 20, 2025 23:02

kean added 4 commits November 21, 2025 06:51

Use Application directory instead of Documents

daf5106

Make logging a cross-cutting concern

8073026

Cleanup

39b4200

Replace safeFilename with sha1

ad776c6

kean force-pushed the task/editor-assets branch from a9806a5 to 0b9616f Compare November 21, 2025 12:54

kean added 2 commits November 21, 2025 07:56

Cleanup

9e4a8de

Trigger refresh automatically in the background after teh editor is l…

dac7dc6

…oaded

kean force-pushed the task/editor-assets branch from 0b9616f to dac7dc6 Compare November 21, 2025 13:26

dcalhoun reviewed Nov 21, 2025

View reviewed changes

kean added 2 commits November 21, 2025 12:13

Fix typos

3dde90c

Add performance tracking for dependencies

2965a20

kean added 5 commits November 21, 2025 14:00

Simplify getCachedAsset

ac14d11

Add assertion to check that the assets are actually available

cae905c

Cache processed manifest (takes ~100ms)

378eccc

Add cleanupOrphanedAssets

2325b3b

Fix concurrency warnings

bff54bd

kean changed the title ~~WIP: Faster and more robust editor asset management~~ Faster and more robust editor asset management Nov 21, 2025

kean marked this pull request as ready for review November 21, 2025 21:43

kean requested a review from dcalhoun November 21, 2025 21:44

kean added 3 commits November 27, 2025 10:39

Revert createBundledConfiguration change

8ddface

Fix LogLevel references to use EditorLogLevel

7f0ddd0

kean requested review from dcalhoun and removed request for dcalhoun November 28, 2025 17:59

kean added 2 commits December 1, 2025 14:40

Update tests

1613171

Add more unit tests

1a35a1b

dcalhoun reviewed Dec 2, 2025

View reviewed changes

kean added 4 commits December 2, 2025 09:42

Remove empty file

25fdafb

Revert the preview change

40eff71

Restore editorAssetsEndpoint parameter

1b09406

Remove log for local files

680242d

kean mentioned this pull request Dec 2, 2025

Update GBK wordpress-mobile/WordPress-iOS#25044

Draft

jkmassel approved these changes Dec 2, 2025

View reviewed changes

Base automatically changed from task/editor-settings to trunk December 2, 2025 21:35

Clean up the merge mess

22ff2c8

jkmassel force-pushed the task/editor-assets branch from b4ddd7f to 22ff2c8 Compare December 2, 2025 21:58

jkmassel enabled auto-merge (squash) December 2, 2025 21:59

jkmassel merged commit 109fc5f into trunk Dec 2, 2025
9 of 10 checks passed

jkmassel deleted the task/editor-assets branch December 2, 2025 22:05

		/// Endpoint for loading editor assets, used when enabling `shouldUsePlugins`
		public var editorAssetsEndpoint: URL?

	activeEditorConfiguration = config
	self.activeEditorConfiguration = config

Faster and more robust editor asset management #233

Faster and more robust editor asset management #233

Uh oh!

Conversation

kean commented Nov 20, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

What?

Why?

How?

Testing Instructions

Accessibility Testing Instructions

Screenshots or screencast

Uh oh!

Choose a reason for hiding this comment

Uh oh!

dcalhoun left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

kean Nov 21, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

kean commented Nov 21, 2025

Uh oh!

kean commented Dec 1, 2025

Uh oh!

dcalhoun left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

jkmassel left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

4 participants

kean commented Nov 20, 2025 •

edited

Loading

kean Nov 21, 2025 •

edited

Loading