PWA: Investigate API requests & caching

[ryelle]

We're currently pulling ~615k of data every 60 seconds, which will use a ton of cellular data. That should be paired down to only the fields that actually get used.

This depends on the API response, but we are attempting to call 3 API endpoints every 60s. Right now this is mitigated by the service worker, so it's only passing through to the server every 15min.

Probably better to have day-of-event.php register a caching route specifically for this endpoint, so that the dependencies are clear and explicit. that may make some of service-worker-caching.php redundant for this request, but that's ok b/c better to make the code self-documenting. add an inline comment w/ that route registration though, noting that it complements things done in service-worker-caching.php

source

API requests themselves can be slow, too:

this is REALLY slow, takes almost 10 seconds on reasonably fast connection need to pair down to only fields being used, maybe other optimizations

source

[westonruter]

The service worker gating requests to 15 minute intervals can be eliminated in favor of implementing conditional requests. If the REST API response includes a Last-Modified header (or ETag) then requests from the page can include a If-Modified-Since (or If-None-Match) request header, allowing the REST API to respond with a 304 Not Modified response, which would have no body, thus saving bandwidth. It would also allow content updates to appear faster for the user.

Refs:

• Pre-merge review wceu/wordcamp-pwa-page#6 (comment):
• Finish service worker caching #129 (comment)
• https://core.trac.wordpress.org/ticket/47676

[ryelle]

I like the idea of If-Modified-Since, but if I'm reading correctly it would still need to hit the server to get the modified time, so we'll probably want to have some extra server caching in place too.

A good ETag could be the max post_modified date of whatever is being queried.

@westonruter is there a difference between using If-Modified-Since vs an ETag? I see you've recommended both/either, but TBH I'm not sure if there's a reason to choose one over the other.

[westonruter]

That's a good question. It seems that ETag conditions override Last-Modified conditions. Per docs on If-Modified-Since:

When used in combination with If-None-Match, it is ignored, unless the server doesn't support If-None-Match.

See also relevant discussions on https://core.trac.wordpress.org/ticket/47676 namely it is easier to ensure generate a reliable ETag generally versus Last-Modified, since with Last-Modified it is not feasible to track all of the possible last modified times for all the data that may be added to a response. An ETag is easy since it can just be hashed. But then generating ETag is more expensive from a server standpoint, since the full output needs to hashed and that needs to be used after generating the full response to then decide whether or not to just respond 304 Not Modified whereas with just Last-Modified it would be more feasible to check up-front before generating the response. If the REST API output is being cached anyway (e.g. via Varnish) then this is largely irrelevant, and using ETag seems like a safer option.

[ryelle]

Thanks for explaining that, I think I have a better idea how this all works now :)

We only have 3 places that would support being cached by the service worker– tagregator, the live schedule block (session endpoints), and the manifest itself. Of those, tagregator & the live schedule should update as frequently as we set in their code, restricting those to only 15min breaks expectations somewhat. Those endpoints should be cached by the server, so that they're also cached for other clients who request them (browser caching only caches for repeat visits, not distinct users).

So… I still wonder if it makes sense to remove the API caching– in #243 we're only making the API request every 5 minutes, and can add server-level caching to make sure these requests don't overload the server. For the sites that don't have the PWA yet, we'll need to make sure those don't cause problems too.

We can improve the API to make conditional requests, but that would be a separate task from getting the PWA to a "launch ready" state.

@iandunn @coreymckrill what are your thoughts?

[iandunn]

We're currently pulling ~615k of data every 60 seconds, which will use a ton of cellular data. That should be paired down to only the fields that actually get used.

Related: https://make.wordpress.org/core/2019/10/10/filtering-nested-rest-response-_fields-in-wp-5-3/

So… I still wonder if it makes sense to remove the API caching– in #243 we're only making the API request every 5 minutes, and can add server-level caching to make sure these requests don't overload the server.

WFM, just make sure to add the server-layer caching first.