The pages list in the Site Editor — and the experimental posts list — currently fetch entire entity records, including fields that aren't used in the current view. As we add more fields — especially ones that are computationally expensive or require additional queries — this results in more data being fetched "just in case."

Let's try to optimize these listings so that only the data needed for the current view is loaded by leveraging the _fields and _embed parameters from the REST API.

• When using _fields, permission checks for individual records aren't cached, leading to N additional REST requests. core-data: Try using cached permissions even when _fields is present in the query #70738
• Add REST API _field and _embed dependencies to the Field type definition.
  • Most common fields (like slug, status, date) map directly to REST API fields. But complex DataViews fields might depend on multiple _fields and _embed parameters.
• Implement a mechanism to resolve a group of field/embed dependencies into the appropriate query parameters.
• Investigate cross-endpoint dependencies that cannot be resolved with _embeds (e.g., a post-related Field that needs data from a non-post endpoint).
• Ideally, improve core-data to resolve partial records and cache individual fields.
  • With the changes above, we would make a request every time the view changes. For example, if we added Field C to a DataView with columns A and B, there would be a request with _fields=A,B,C, which avoids fetching many unnecessary fields and improves load performance. If core-data supported partial caching, the resolver could request C and reuse the cached A and B fields.