Front End Performance Case Study: GitHub(blog.jphpsf.com)
blog.jphpsf.com
Front End Performance Case Study: GitHub
http://blog.jphpsf.com/2012/04/28/front-end-performance-case-study-github/
4 comments
In reference to the Gravatar icons in the post. You guys are always asking for the 140x140 sized icons and they are then re-sized to 20x20 or 30x30. You have the ability to ask for the gravatar icons in your specified format, which will save a lot of bandwidth.
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.
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.
That is a great tip. Thank you! I just mentioned it in the comment thread of the blog post.
JP
JP
The client-side execution time and transfer time of large image assets is interesting, and I'm glad the article covers those matters in-depth.
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!
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!
> In the end, is GitHub slow? I actually don’t think so. When I use GitHub, I don’t have a perception of slowness or lag.
I definitely do: enough that I tend to avoid browsing code on GitHub like the plague, and clone the repositories instead.
I definitely do: enough that I tend to avoid browsing code on GitHub like the plague, and clone the repositories instead.
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
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 do most of my browsing on my iPhone (where honestly GitHub is so slow as to be unusable, even on an iPhone 4S). On my laptop (a 2010 11" MacBook Air) I use Chrome.
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
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
I feel the same way, I wonder if this has anything to do with fact that github has their servers only in the US (even though it's east coast) and this therefore adds some latency for us over in Europe.
I had very much the opposite reaction while reading the article. Page loads on GitHub aren't especially fast (though not annoyingly slow either, I'd never really noticed the speed until I tested just now), but browsing code is almost instantaneous.
Would have been interesting to see if the quotes made an impact or not, as well. I can't see it making that much of a difference...
If someone suggests removing quotes to reduce download size, chances are they don't understand compression.
Yeah. I mean 4,517 seems like a big number to humans but meh. You're talking about a highly optimized parser. It's likely going to rip through those quotes in about the same time it takes to dispatch a single unjit'd/unoptimized javascript function invocation at runtime.
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.)