|
|
|
|
|
|
by rtomayko
5158 days ago
|
|
|
Wow, really? Really sorry to hear that. Moving through trees is one of the fastest page level operations on the site as far as perceived performance. We'd like to make it faster but it's definitely in the area of perceived performance we're shooting for with the entire rest of the site. Is there maybe something I'm missing here? What browser do you use? Are you primarily slowed down on the first request or when browsing layers deep. Also, we wrote up the details on how we optimized tree browsing a while ago. Might be interesting from a general frontend perf perspective: https://github.com/blog/760-the-tree-slider |
|
|
I find the experience of the first page load to be slow, and clicking links between different code views to be agonizing as it does some trendy-but-slow AJAX update with horizontal transition animation to the next page. I am not able to check right now (as I'm on my iPhone: left laptop at home), but I also remember the code browser getting tripped up of you want to do fast forward/back interactions: sometimes it would even just get wedged, but the core performance problem is simply that it doesn't take advantage of the browser's page cache and instead rebuilds the DOM in JavaScript and runs another useless animation every time you navigate. :(
Finally, if there is a folder with a lot of files in it (such as the definition files for Homebrew, which I'm occasionally in a position where I need something quickly verified or checked) you are pretty much screwed (and on MobileSafari I've had the browser run out of memory and simply crash).
The result is that it is infinitely easier to just check the code out and edit it locally (yes: even and especially so on an iPhone, where git itself works great). In addition to having clicking through the code be reasonably fast, you have much more powerful search operations available.
(edit:) Back at my laptop (aforementioned Air with Chrome), and to demonstrate part of the problem: go to the Formula folder for Homebrew, click any file, and then hit back. This takes multiple seconds to occur: hitting back is something that you are going to do constantly while browsing files, and is something that normally is instantaneous.
https://github.com/mxcl/homebrew/tree/master/Library/Formula
The reason for this is that the mechanism GitHub is using to supposedly speed up browsing (and I take severe issue with this: the surrounding content and resources should entirely be in the request cache, and there is almost no dynamic content on the page, so there should be more intelligent ways of improving the performance for clicking forward that are server-side) totally ruins the page cache.
To be clear: the page cache is not the same as the request cache. The page cache is what is used when the user hits back or forward, and it stores all of the state associated with a rendered page. This way, when you click a link, you don't destroy all of that work, and when you hit back you get the previous contents as fast as possible.
http://www.webkit.org/blog/427/webkit-page-cache-i-the-basic...
(Note: this page states that pages that use HTTPS, such as apparently all of GitHub, are not able to be stored in the page cache. However, this was only true of WebKit, not Firefox's equivalent cache, and this was changed recently to bring the behavior in line: only if the page has Cache-Control: no-{store,cache} will the page be kept from the page cache.)
http://trac.webkit.org/changeset/107607