Probably. We’re looking at three roundtrips here: one to fetch the HTML, one for the JS, and at least one for the packfiles (and that’s if you can do that in parallel). If the latency is high, the result can be... not great. HTTP/2 should help with this a bit, but it’s better to not have this problem at all IMO.

Of course, there’s also the argument that if you’re self-hosting a repo, you’re more likely to care about users that have disabled JS (which is a good idea, tbh).

If you render the repo home/tree/readme statically but serve the JS application upfront with that, then successive clicks into files/commits/diffs will only have to pull packfiles, and then only if the content isn't already present locally. Packfiles are obviously immutable so they can be set for infinite caching, which should mean that even successive visits could be pretty speedy.

Yeah, the question is basically which entry pages you want to support. I think it’s nice to be able to link to a particular file on the master branch and have it load instantly, too. Loading older verisions, on the other hand, has its uses but is less important.

For a repo with thousands of files, it might make sense to limit entry pages to only directories and .md files (and other prose files), which are more likely to be linked to. You can also skip shipping a Markdown renderer this way!