REST API: Omit `content.rendered` from preloaded post data

[mikeselander]

Describe the bug

The Block Editor is pre-loading API requests into the store via this set of logic and this REST API function. This is a very good thing for initial editor load times, but it has a strange side-effect of triggering the full rendered post content to be preloaded with the request.

Loading in the rendered post content has some strange side effects and can cause unintended behavior. As an example, any shortcodes or dynamic blocks are fully rendered in this request. This means that any API requests or heavy computations that either undertake are performed on the server (affecting TTFB) and then again in ServerSideRender in the case of dynamic blocks. Additionally, it means that the blob sent to the client is significantly larger, but that's a much smaller issue.

This is likely not an easy fix and would involve adjusting the way that the REST API returns fields in a given context. It sounds like this may be somewhat in hand already after talking to @kadamwhite.

Related: #18394 is caused by this behavior and is a good example of unintended side effects.

Expected behavior
I would expect that post content is rendered only on the client side when editing a given post.

[aduth]

Thanks for opening this issue. It's a topic which has been discussed in a few of the recent REST API meetings, and has been on my mind to explore. I don't think there's been an issue yet created to encompass the effort, so I think this can serve well for that purpose.

A few points of relevant context off the top of my head:

• The addition of nested _fields filtering as a new feature in WordPress 5.3 is key in enabling this to be possible. The editor only makes use of the content.raw field. As of WordPress 5.3 and the new nested field filtering, we can now effectively "omit" the rendered field to avoid the_content from being run.
• However, this can have some impact on reusability of the preloaded data, if there are consumers of the data which may need the rendered field, or otherwise express their data needs in a way which the generalized framework will treat as distinct from the editor's own needs of content.raw. Data: Consider optimizing aggregate of _fields requests #15114 is one of the tasks associated with this.

References:

• Recent #core-restapi chat discussion on this topic (2019-11-21, link requires registration): https://wordpress.slack.com/archives/C02RQC26G/p1574361923322500
• An original summary of this observation in on older generalized performance issue: Performance: Improve the initial loading time and the feeling fo smoothness while typing in blocks. #11782 (comment)