Front End Performance Case Study: GitHub

I'm a developer at GitHub.<p>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 &#60;script&#62; related bits are already dated. We've just rolled out defer support for these for instance.<p>I really liked the wrap up section on choosing which aspects of performance to concentrate on and can maybe answer some questions here:<p>&#62; Yet, I am wondering what would be the performance business &#62; case for GitHub? Even if GitHub does not feel slow, faster &#62; is always better.<p>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.<p>(I also left a similar comment on JP's blog that's waiting for moderation.)

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.<p>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.<p>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.<p>Even presumably semi-static pages such as github.com/about reported ~400ms round-trip. /features = ~400ms.<p>For fun, I decided to see how some other sites behaved by way of comparison. Here's some anecdotal measurements from my PC:<p>microsoft.com = ~175ms; <a href="https://www.microsoft.com/" rel="nofollow">https://www.microsoft.com/</a> = ~175ms; microsoft.com/about = ~75ms; microsoft.com/windows = ~100ms.<p>google.com = ~75ms; <a href="https://google.com/" rel="nofollow">https://google.com/</a> = ~100ms; google.com/about = ~75ms; investor.google.com = ~75ms.<p>apple.com = ~100ms; <a href="https://www.apple.com/" rel="nofollow">https://www.apple.com/</a> = ~150ms (note: assets will not load, site is not intended to be loaded with https); apple.com/ipad = ~40ms; store.apple.com = ~175ms.<p><a href="https://stripe.com/" rel="nofollow">https://stripe.com/</a> = ~800ms;<p>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.<p>Using GitHub sometimes feels like using my AT&#38;T U-Verse DVR. Okay, that was an unfair low blow; nothing is as slow as an AT&#38;T DVR.<p>I'm glad to hear that the GitHub guys are hard at work to tune things up. Thanks!

&#62; 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.<p>I definitely do: enough that I tend to avoid browsing code on GitHub like the plague, and clone the repositories instead.

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