Front End Performance Case Study: GitHub
blog.jphpsf.com
blog.jphpsf.com
This is a really good writeup and touches on many of the frontend issues we've had our eye on for a while. In fact, the <script> related bits are already dated. We've just rolled out defer support for these for instance.
I really liked the wrap up section on choosing which aspects of performance to concentrate on and can maybe answer some questions here:
> Yet, I am wondering what would be the performance business > case for GitHub? Even if GitHub does not feel slow, faster > is always better.
We want GitHub to be insanely fast and are pouring a significant amount of time and energy into this. We think it's more important than a lot of feature-type additions we also have planned.
(I also left a similar comment on JP's blog that's waiting for moderation.)
https://secure.gravatar.com/avatar/e7e8748f7897c2d9a3da0afe4... 32kb
vs
https://secure.gravatar.com/avatar/e7e8748f7897c2d9a3da0afe4... 2.71kb
Making this one change alone will make a huge difference.
JP
That said, what I find surprising about GitHub in my admittedly infrequent usage is the amount of time spent waiting for the server to respond to requests.
At the URL cited in the article, Chrome reported a ~800ms round trip time for the initial request. Clicking on the "View file" link resulted in a request that took ~1,200ms. Clicking "Network" on the navigation resulted in a request that waited ~5,500ms until a response arrived that then painted an animation of an encircled cat while the real work started.
Even presumably semi-static pages such as github.com/about reported ~400ms round-trip. /features = ~400ms.
For fun, I decided to see how some other sites behaved by way of comparison. Here's some anecdotal measurements from my PC:
microsoft.com = ~175ms; https://www.microsoft.com/ = ~175ms; microsoft.com/about = ~75ms; microsoft.com/windows = ~100ms.
google.com = ~75ms; https://google.com/ = ~100ms; google.com/about = ~75ms; investor.google.com = ~75ms.
apple.com = ~100ms; https://www.apple.com/ = ~150ms (note: assets will not load, site is not intended to be loaded with https); apple.com/ipad = ~40ms; store.apple.com = ~175ms.
https://stripe.com/ = ~800ms;
In my experience, yes, GitHub "feels" slow. Not agonizing, but slow enough to be annoying. For me, the feeling comes from the hesitation that I feel before a response starts arriving from the server. To an extent, I'm comfortable with the browser continuing to download slow assets (large images, analytics JavaScript, etc.) as long as the principal UI gets painted and I can get my click on.
Using GitHub sometimes feels like using my AT&T U-Verse DVR. Okay, that was an unfair low blow; nothing is as slow as an AT&T DVR.
I'm glad to hear that the GitHub guys are hard at work to tune things up. Thanks!
I definitely do: enough that I tend to avoid browsing code on GitHub like the plague, and clone the repositories instead.
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:
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.)