Loading VisualEditor involves fetching HTML from RESTBase and page metadata from the action API, which makes it only as fast as the slower of the two requests, which is typically the one to the action API.

We could obviate the need for the action API request by embedding the metadata that VisualEditor currently gets from the API in the view page HTML. The total size of this data appears to be negligible: for Barack Obama, it is 2.3 kB uncompressed; adding it to the view page HTML would increase its total size by about 0.23%. (The data also looks like it could be trivially reduced to a much smaller size by serializing it differently.) That's a very modest price to pay for what would likely be a big win for VisualEditor.

We do need to make sure we don't make the backend response time for uncached page views worse by forcing MediaWiki to do a lot of work it would not otherwise need to do. This seems doable. Most of the data is already needed for rendering the page, so it's simply a matter of making sure VisualEditor's PHP code can see it. Fetching the remaining data can in many cases be deferred until after the editor loads.

Here is a breakdown of the data that is produced by the action API endpoint for VisualEditor:

• Edit notices
  • Anon edit warning
  • Read-only warning
  • New page notice
  • Title protected warning
  • Protection warnings
  • Permissions errors
  • User pages of missing user
  • User pages of blocked user
  • Blocked notice (if editor is blocked)
  • Global blocks

• Checkboxes (expensive to compute but probably deferrable)
  • Minor
  • Watch
  • FlaggedRev

• Red links Fixed a while ago
• Protection classes
• Watched status
• Base timestamp
• Start timestamp
• Old ID