
Browser Monitoring for GitHub.com - samlambert
http://githubengineering.com/browser-monitoring-for-github-com/
======
robbles
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!

------
phleet
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](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
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...](https://github.com/snowplow/iglu-
central/blob/master/schemas/org.w3/PerformanceTiming/jsonschema/1-0-0)

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

[https://github.com/snowplow/snowplow-javascript-
tracker/blob...](https://github.com/snowplow/snowplow-javascript-
tracker/blob/master/src/js/tracker.js#L706)

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

------
why-el
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
I thought the engineering category did a good job separating their blog posts:
[https://github.com/blog/category/engineering](https://github.com/blog/category/engineering)

------
stillsut
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
If anyone wants to have similar end-user performance monitoring, AppNeta has
the solution for you: [http://www.appneta.com/blog/rum-vs-
synthetic/](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.

------
ksk
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
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/](http://timkadlec.com/2014/01/fast-enough/)

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

~~~
drstewart
To piggyback on this, does anyone have any metrics on how much time is taken
up by restaurant servers asking me how my food is today? I'm paying for the
food and drinks, not to be spammed for analytics by the server.

~~~
seanp2k2
It seems like they could collect those metrics on the back-end (kitchen / food
processor(s)) too, or use tip % as a proxy metric for QoS. Not sure how they'd
track e.g. CTR, but straight conversions could be easy enough if you
instrument the servers such that they're tracking clients per table. Of
course, if you're trying to solve for optimal Drink Refresh Rate, you might
need something more granular along the lines of sugar.

~~~
ksk
The proxy metric you're looking for is - did the bar have multiple hot women
present at the same time as the customer.

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

------
arohner
Gratuitous plug: I'm working on a hosted service that does basically the same
thing: [http://rasterize.io](http://rasterize.io).

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

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

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

------
gdi2290
CoffeeScript

