I'll take a look at this. I don't know if there are any easy fixes sadly, but I have a few ideas I can try.

One idea would be to detect if multiple results are viewed and then pre-load the next n ones. Not sure if that is practical but might help reduced the perceived latency.

I made a prototype of something which should improve overall load time.

https://13974-821eb23-tainted-martiniss-dot-test-results-test-hrd.appspot.com/data/layout_results/win10_blink_rel/6259/layout-test-results/results.html is an example of this. It does server side caching via memcache to cache the individual results files. I made it so that when it loads the initial results.html page it puts files it thinks will be requested into memcache. The initial page load takes a bit longer; about 7 seconds by my count. I might be able to speed it up a bit, but I think that'll be the extent of it.

If you want to demo this yourself, you'll need to find a new page, since that page is already in the server cache. 

Another thought: is there any bottleneck preventing test-results.appspot.com from quickly serving files, that we can eliminate? The response time of several seconds seems abnormal for a file download request.

The biggest problem is that it has to download and unzip the entire layout test results zip file every time it wants to serve one file. The example in #1 is a 100 MB zip file. Downloading and unzipping is taking up the majority of the response time. 

We could have the server unzip the results zip and dump it into cloud storage, and then just have the test results server redirect clients there. That would be essentially moving the recursive upload from the CQ bot to test results. We'd have to make some sort of service to monitor that and make sure it happens correctly all the time, which I'm wary of.

What I implemented in #4 was to take advantage of the server fetching the zip file. When it fetches the zip file, it also looks for other files it should try to cache, and caches them in memcache on the server. 

How about mounting the zip file temporarily using something like 

https://bitbucket.org/agalanin/fuse-zip

It mounts a zip as a file system, and claims to be memory efficient.

That's written in C++, which doesn't work on app engine, which is what test results is written in. It also would require a persistent server as far as I can tell, which would me we'd have to monitor it and make sure it's working all the time.

Have people looked at the prototype in #4? Is that still too slow?

The #4 prototype feels fast to me. Thanks!

#4 is plenty fast.

The following revision refers to this bug:
  https://chromium.googlesource.com/infra/infra/+/528319156bf4dd184f430f153079762665296576

commit 528319156bf4dd184f430f153079762665296576
Author: Stephen Martinis <martiniss@chromium.org>
Date: Fri Feb 16 20:40:06 2018

Test results zip: Cache failed test files

Bug:  812303 
Change-Id: I6d34bec93c3193f592d22fd8240aba383deca3ea
Reviewed-on: https://chromium-review.googlesource.com/920789
Commit-Queue: Stephen Martinis <martiniss@chromium.org>
Reviewed-by: Sean McCullough <seanmccullough@chromium.org>

[modify] https://crrev.com/528319156bf4dd184f430f153079762665296576/go/src/infra/appengine/test-results/frontend/zip_test.go
[modify] https://crrev.com/528319156bf4dd184f430f153079762665296576/go/src/infra/appengine/test-results/frontend/zip.go

I've landed and deployed the changes. Everything should be faster.

Feel free to re-open this bug if it's too slow, or file other bugs if you notice anything.

The following revision refers to this bug:
  https://chromium.googlesource.com/infra/infra/+/cde1645f886fa531a0599b5482e8c607989c4bc5

commit cde1645f886fa531a0599b5482e8c607989c4bc5
Author: Stephen Martinis <martiniss@chromium.org>
Date: Fri Feb 16 21:48:56 2018

Test results zip: Handle js tests

Properly strip .js extension from javascript layout tests

Bug:  812303 
Change-Id: I6bb8aaa44df037dd8e3995a118ef732acabfe003
Reviewed-on: https://chromium-review.googlesource.com/924446
Reviewed-by: Sean McCullough <seanmccullough@chromium.org>
Commit-Queue: Stephen Martinis <martiniss@chromium.org>

[modify] https://crrev.com/cde1645f886fa531a0599b5482e8c607989c4bc5/go/src/infra/appengine/test-results/frontend/zip.go