

Front End Performance Case Study: GitHub - fcoury
http://blog.jphpsf.com/2012/04/28/front-end-performance-case-study-github/

======
rtomayko
I'm a developer at GitHub.

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.)

~~~
xpose2000
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...](https://secure.gravatar.com/avatar/e7e8748f7897c2d9a3da0afe4deb6d14?s=140)
32kb

vs

[https://secure.gravatar.com/avatar/e7e8748f7897c2d9a3da0afe4...](https://secure.gravatar.com/avatar/e7e8748f7897c2d9a3da0afe4deb6d14?s=30)
2.71kb

Making this one change alone will make a huge difference.

~~~
jphpsf
That is a great tip. Thank you! I just mentioned it in the comment thread of
the blog post.

JP

------
bhauer
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!

------
saurik
> 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.

~~~
rtomayko
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>

~~~
saurik
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...](http://www.webkit.org/blog/427/webkit-page-cache-i-the-basics/)

(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>

------
theootz
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...

~~~
bluesmoon
If someone suggests removing quotes to reduce download size, chances are they
don't understand compression.

