Performance loading /results/

[gsnedders]

Loading, e.g., https://wpt.fyi/?label=master&product=chrome%5Bstable%5D&product=edge%5Bstable%5D&product=firefox%5Bstable%5D&product=safari%5Bstable%5D&product=safari-18.0%20%2820619.1.26.31.6%29&product=firefox%5Bbeta%5D&product=firefox%5Bexperimental%5D on a bad network connection is a pretty awful experience, even on second load when everything is in cache, with a total transfer size of 1.85MB.

This shows up a variety of issues (which I'm not going to try and file separate issues for, given… bad internet):

• We make a POST request for /api/search (1.14MB response), which means there's no way it can ever be cached. With IE and Edge/EdgeHTML now confined to history, there's no reason we shouldn't also use GET requests for structured queries, as request URL length limit is no longer such a concern. (The current HTTP specs recommend a limit of 8000 bytes, but I doubt we often go over that?) This is especially true at the moment when even moderately long structured queries typically fail (Complex search query results in 400 error unless sub-query is already cached #2357).
• Even with our current API design, we don't fallback to GET requests to /api/search when they suffice. For example, in the above, the request body is: {“run_ids":[5115373848625152,5074180146200576,5124359993950208,5206109143171072,5134437983715328,5067816430731264,5073651663896576]}, which could just be a GET request to /api/search?run_ids=5115373848625152,5074180146200576,5124359993950208,5206109143171072,5134437983715328,5067816430731264,5073651663896576.
• We don’t send any headers that would determine cache eligibility for GET /api/search, despite the return value only changing if we change the run results (which I believe we never do?) and the fact that we let storage.googleapis.com serve the per-run results with cache-control: public, max-age=3600 (honestly I’m surprised we have such a short max-age there because when do we ever update them?).
• Moving on, /api/metadata?includeTestLevel=true&products=chrome%2Cedge%2Cfirefox%2Csafari%2Csafari%2Cfirefox%2Cfirefox is the next largest response (480KB). Thankfully, it appears the redundant products in the list don’t lead to redundant data being sent back, so that merely wastes a few bytes in the request. It is, however, not cacheable. It should be. We cache it on the wpt.fyi side, rather than constantly redownloading it from GitHub, and it doesn’t change that often and we should absolutely let clients cache it; even if we make them always revalidate their cache, that’s a lot of data saved.
• Then, /api/bsf?experimental=true (133KB) is likewise not cacheable and something we don’t change frequently. Once again, even caching with must-revalidate would be a big win.
• Beyond this things start to get silly. We have requests to: https://wpt.fyi/api/shas?label=master&product=chrome%5Bstable%5D&product=edge%5Bstable%5D&product=firefox%5Bstable%5D&product=safari%5Bstable%5D&product=safari-18.0+%2820619.1.26.31.6%29&product=firefox%5Bbeta%5D&product=firefox%5Bexperimental%5D, https://wpt.fyi/api/shas, https://wpt.fyi/api/shas, https://wpt.fyi/api/shas
  We certainly don’t need to make a request to /api/shas with no query string three times near-simultaneously. We arguably don’t need to make any of these, as these are just used for the autocomplete in the test-runs-query-builder as far as I can tell, and until that’s opened there’s absolutely no need to make these requests (and many other webapps only load autocomplete data once the appropriate field has focus!).
• We have requests to: https://wpt.fyi/api/versions?product=chrome, https://wpt.fyi/api/versions?product=edge, https://wpt.fyi/api/versions?product=edge%5Bstable%5D, https://wpt.fyi/api/versions?product=edge%5Bstable%5D, https://wpt.fyi/api/versions?product=firefox, https://wpt.fyi/api/versions?product=chrome%5Bstable%5D, https://wpt.fyi/api/versions?product=chrome%5Bstable%5D, https://wpt.fyi/api/versions?product=safari, https://wpt.fyi/api/versions?product=safari, https://wpt.fyi/api/versions?product=safari%5Bstable%5D, https://wpt.fyi/api/versions?product=safari%5Bstable%5D, https://wpt.fyi/api/versions?product=firefox%5Bbeta%5D, https://wpt.fyi/api/versions?product=firefox%5Bstable%5D, https://wpt.fyi/api/versions?product=firefox%5Bstable%5D, https://wpt.fyi/api/versions?product=firefox%5Bbeta%5D, https://wpt.fyi/api/versions?product=firefox%5Bexperimental%5D, https://wpt.fyi/api/versions?product=firefox%5Bexperimental%5D
  This is again utterly silly, and we again arguably don’t need to make any of these until the product selector is open, because again this is about autocomplete. I have no idea why make 17 requests here. I’m pretty sure this is even worse than it looks because I’m pretty sure product=safari[stable] is a subset of product=safari.

[gsnedders]

See also #1581, about us loading very many different small JS files on first-load. But those are all cached, so that's purely a first-load problem. (I mean also a more minor performance issue in general, but not really so relevant to this issue.)