To be honest, I don’t like the idea of using
<link prefetch > that much either.
As you said, it’s very convenient to have that data in the state as soon as possible, and on the other hand it won’t work with requests that require an additional fetch, like for example getting the category ID when only the category slug is known to then fetch the posts from that category.
I prefer your idea of prefetching in batches. To avoid a performance hit on the Time to Interactive metric, maybe we could use
requestIdleCallback instead of a
setTimeout. It is now supported on all major browsers except Safari. That way, this should not affect the LightHouse score at all.
What do you think?
We could also use
requestIdleCallback, or even React’s new
scheduler package, to populate the state once the data has been returned from the REST API. I’ll study that for the v2 of
A while ago I thought about that as well and I think the client logic to accomplish that would be too complex. There are two options though:
@frontity/wpgraphl-package, which is something we want to do, and make sure that we combine the requests. I’m not an expert on GraphQL but my understanding is that it should be because GraphQL supports multiple queries in the same request.
This is something we want to after we release Source v2. The main drawback is that setting up a cache for GraphQL is way more complex than for a REST API.
Create a new REST API endpoint that supports multiple requests.
This is more of an idea for the future: create a
@frontity/frontity-source package that uses the REST API but with a custom endpoint, like
/wp-json/frontity/v1. That endpoint could have these features:
- Get any entity only using the URL, to avoid the case where we now have to multiple requests (the example of the category I referred to earlier).
- Accept multiple requests.
- Merge all embeds (authors, categories, tags, media) together to avoid repetition.
Something like this:
// Posts of /category/one...
// Posts of /category/two...
// All the embeds together...
Using the URLs in the REST API request will also be very convenient to do instant caching invalidations, because if a caching plugin is telling the CDN to purge the
/category/one URL, it will also purge the REST API requests that contained it, like
/entities?url=/category/one. I know it’s probably not that simple, but at least it could be more similar to the way WordPress plugins invalidate the cache nowadays.
But of course, it’ll take a while until we can do something like that