Performance loading /results/ #4136
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.) |
|
WPT.fyi has always been slow. But I came here after loading it on a connection a decently fast connection (it's fibre-backed wifi) but slow ping times to much of the internet (because it's based in New Zealand). The site (home page) took 13 seconds to load. One additional thing I noticed is that WPT.fyi seems to be using Polymer which is notorious slow even when properly bundled, and I wonder if perhaps this is one of those circumstances where a rewrite to new tech stack (both in terms of bundling and the client-side framework) might be justified. Although the ~300 http requests is probably the bigger issue. |
|
Looking into this further, I think the most impactful change we could make would probably be an API that can send back summary results for "folders" of tests (such as the page for the "css" folder pictured below) without sending back results for each individual test. Ideally we would precompute the summary data for each run, but it could also likely be done on demand by the backend much faster than sending the whole test result over the network and then processing on the frontend. 
|
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: