Performance loading /results/ #4136
Labels
Comments
|
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.) |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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):
/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)./api/searchwhen 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.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 letstorage.googleapis.comserve the per-run results withcache-control: public, max-age=3600(honestly I’m surprised we have such a short max-age there because when do we ever update them?)./api/metadata?includeTestLevel=true&products=chrome%2Cedge%2Cfirefox%2Csafari%2Csafari%2Cfirefox%2Cfirefoxis 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./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.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!).
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 ofproduct=safari.The text was updated successfully, but these errors were encountered: