Browser Monitoring for GitHub.com

http://githubengineering.com/browser-monitoring-for-github-com/

by samlambert • 11 years ago

174 25 11 years ago

robbles• 11 years ago

This is an incredibly useful post for anyone looking to implement their own custom client-side performance metrics and error tracking. I've worked on solutions to both these problems before and needed to piece together a solution from multiple half-baked, error-prone sources. Having a reference implementation in one post is very helpful.

Thanks, GitHub team!

iDemonix• 11 years ago

I'm glad GitHub have started this blog, it's great when an organisation as large as theirs shares information about how they're tackling common problems.

benihana• 11 years ago

We still support some older browsers that don't implement the Navigation Timing API

This is legitimately surprising to me. I would think the overwhelmingly vast majority of github's customers use an evergreen browser.

Already__Taken• 11 years ago

They do offer a large amount of enterprise support I assume that's what makes old browser data important.

realityking• 11 years ago

The lack of support in mobile Safari (http://caniuse.com/#feat=nav-timing) may be a significant part of that.

daddykotex• 11 years ago

I think the text color on that page could be a little darker. It is hard to read here and I have no eyes issues.

Raphmedia• 11 years ago

#727272 on a background of #FFFFFF is a contrast ratio of 4.81:1 and fail WCAG AAA which requires a ratio of 7:1 for normal text.

That being said, it passes WCAG AA which requires 4.5:1 for normal text.

hk__2• 11 years ago

Same here, hard to read so I won’t try. Why do people use light gray on white? If you want people to read what you write, make it easy.

ashmud• 11 years ago

Reiterating: http://contrastrebellion.com/

ksk4• 11 years ago

Questions:

* Does the user have a choice in this?

* Does anyone have any metrics on all the CPU time that's taken up by potentially useless analytics scripts running on users' machines?

stavrus• 11 years ago

Why would you consider these analytics scripts useless? The article mentioned several reasons they want to be tracking this timing information (monitoring of slow backends/CDNs and the performance of their own scripts) - having that information is vital for ensuring the usability of the site [1]. If a portion of your userbase all of a sudden starts loading the webpage much slower than usual (e.g. from issues as diverse as bad network routing or just a specific browser choking on your scripts), having the information available to you to quickly diagnose and fix the problem is a lifesaver. After all, the website is their product, so they need to ensure it's always available and usable for all their customers.

[1] http://timkadlec.com/2014/01/fast-enough/

ksk4• 11 years ago

All that is nice, but simply stating the reasons does not cause me to think that something is actually beneficial in a way thats real and tangible to me. In practice, I often find that disabling analytics scripts improves the performance of many websites. My RAM and CPU usage goes down, and the site feels much more responsive. Other times, disabling JS completely causes websites to fall back to their html/non-js pages, which are significantly better to me from a performance standpoint. YMMV.

Nothing against websites who are trying to improve user experience, but if I'm donating my CPU time and RAM for someone else's business needs, I'd want a way for me to opt out of that.

tonyarkles• 11 years ago

An interesting thing about this is that it appears to just use window.performance.timing, which is filled in by the browser automatically. They're just grabbing data that the browser is generating anyway and forwarding it along to themselves.

On my machine, calling `JSON.stringify(window.performance.timing).length` generates 623 bytes of text. Pretty much 0 overhead here.

why-el• 11 years ago

A little meta, but it's a good decision that Github has separated their technical blog posts from the rest (previously they used to combine all posts in github.com/blog). This was much needed given the nature of their customers.

taylorfausak• 11 years ago

I thought the engineering category did a good job separating their blog posts: https://github.com/blog/category/engineering

gdi2290• 11 years ago

CoffeeScript

stillsut• 11 years ago

Could anyone link me a HelloWorld for the following use:

    Chrome extension that can use the devtools.network api
    (Bonus points) if it shows how to work with Selenium

edwinnathaniel• 11 years ago

If anyone wants to have similar end-user performance monitoring, AppNeta has the solution for you: http://www.appneta.com/blog/rum-vs-synthetic/

They have both RUM (requires injecting 3rd-party script, in this case, AppNeta)) and Synthetic (does not require any modification of your client-side artifacts).

Disclaimer: I used to work on the Synthetic side.

phleet• 11 years ago

Thank you for posting this!

We've done similar performance analysis at Khan Academy by using the navigation timing API and throwing the data into graphite. The most interesting part of this post for me is seeing that the numbers (server side times, median client times) are roughly the same as ours (http://i.imgur.com/wKglMTc.png)

One thing that I see in both GitHub's data and our data is this daily-periodic increase in both server and client times. Is that just load? We had theories that the clientside spikes may be caused by users in less CDN covered areas, or an increase in mobile usage, but were never fully satisfied by those explanations.

alexatkeplar• 11 years ago

Cool post! After a fair bit of trial and error, we've got a pretty robust JSON Schema for the PerformanceTiming API here:

https://github.com/snowplow/iglu-central/blob/master/schemas...

We send that in as a custom context in the Snowplow JavaScript Tracker:

https://github.com/snowplow/snowplow-javascript-tracker/blob...

arohner• 11 years ago

Gratuitous plug: I'm working on a hosted service that does basically the same thing: http://rasterize.io.

My email is in my profile. Let me know if you're interested in beta-testing.

Browser Monitoring for GitHub.com

Related Stories