FE scale audit: loading big files in search results list bogs down the browser - strategic readiness

[AlicjaSuska]

Description

According to feedback from one of our customers (slack thread for more context) the large files bog down the browser while doing syntax highlighting and rendering.

Plan

• Research the described behavior (so far @philipp-spiess hasn't tested with files that big for the FE scale audit yet)
• Understand if using codemirror will solve the problem
• If not, explore potential UI solutions (ex. the download button suggested by the customer) - potential design input needed

[philipp-spiess]

The experience for large files is going to be much much improved with the rollout of CodeMirror. I know that the customer in question will be getting CodeMirror soonish, so let's wait to hear the feedback.

There are, of course, additional improvements that we can do. We recently shipped #44199 which allows the streaming of git blame related data. We should do the same with text files! We can stream from the first lines and start rendering as soon as we have enough data to fill the view. This will require additional UI indicators though to convey the state. I do think this is a bit out-of-scope for the scale-readiness data.

What we can (and should) do for now is to improve the loading state for CodeMirror (the other implementation will hopefully not stick around for too long). This is what we currently show:

A few ideas:

• Add some text if loading takes over xxx ms or when a large file is shown that explains why it takes so long
• Show a progress indicator (@philipp-spiess to figure out how we could do this technically) including how many kb have been downloaded already?
• Add support for streaming the content

cc @AlicjaSuska

[philipp-spiess]

I looked into the progress indicator option (wip code here).

Overall, I don't think this improvement would yield great results because a majority of the delay is happening while the server is assembling the response and hasn't sent a byte yet. In my tests, even with a throttled network condition (Fast 3G profile), about half of the response from Sourcegraph is spent waiting for the server. During this time, we have zero information about what's going on and we can't show any reasonable progress indicator (i.e we don't know how large the file is):

As soon as the first bytes are sent from the server, we know the response file size and we can get an accurate download indicator based on this. Here's a prototype where you see how long it takes for us to finally get streaming response data (onProgress events in the logs):

progress.mov

I think in real world conditions (without network throttling) it's likely that the time before possibly showing a progress indicator is much larger than the actual downloading part (with the current implementation at least), so a progress indicator does not provide much improvements in UX.

[philipp-spiess]

I still think that streaming the blob content would be super helpful here though but the change would require a lot of changes on the backend. We've recently done something similar with git blame (https://github.com/sourcegraph/sourcegraph/pull/44199) and I think we should at least wait and get some feedback on that implementation first before considering this. We'd also need a strong champion for the backend to make this change. I think this change is out of scope for the effort of the front-end scale testing audit.

---

There are still two reasonable next steps, though:

• Enable CodeMirror for everyone. This is something that the Code Exploration team is actively working on (unrelated to the front-end scale testing efforts). Code Mirror is much faster at rendering the file ones it's downloaded as it doesn't need to render all potential thousand lines of code but instead can render only the visible part. This is being championed by @taras-yemets at the moment.
• Improving the status quo of loading indicators and maybe set a timeout after a second or so that explains that the viewer is downloading a large file. This would need design work as a next step, cc @AlicjaSuska

---

Long term I recommend that we invest either in a streaming API so that we can increase the initial rendering screen since we only need to wait for the first few hundred lines or an API that allows us to specify line ranges.

[taras-yemets]

@philipp-spiess, I like the idea with blob streaming (though I'm not sure about the implementation effort). We can get back to it after we enable the CodeMirror blob view by default and audit the large files performance again.

[AlicjaSuska]

@philipp-spiess given the @taras-yemets comment - is this issue on hold now until we have the codemirror implemented or, in the meantime, we still need the design for:

Improving the status quo of loading indicators and maybe set a timeout after a second or so that explains that the viewer is downloading a large file. This would need design work as a next step

[philipp-spiess]

@AlicjaSuska I think it still makes sense to see if there's some quick fix that we can do design wise to make it clearer to the user what's going on. What do you think?

[AlicjaSuska]

Sure, I'll get back to you when I have the design ready. Thank you!

*I'm working in this file

[AlicjaSuska]

Update: @philipp-spiess please see this loading sequence (already reviewed by @quinnkeast)