1. Instrumenting browsers to collect performance and error data provides visibility into how applications are used and any issues users encounter. 2. Analyzing the collected data can reveal problems like third party module failures, loading errors, and undefined variables. It also shows how users interact with features. 3. To better understand issues, developers should simulate failure modes during testing and collect additional metadata on users and deployments. Overall, browser monitoring is critical for web applications but must be implemented in a way teams will adopt.

1. What your javascript does when you’re not around
@eanakashima

2. about://
frontend / web / product
engineer @ honeycomb.io

6. Vue.js

9. Many of us are still more likely to be paged for a
server issue
that affects no one than
browser issue
that affects everyone

10. Building browser app visibility

11. How much javascript must I sit through
A saga in three parts
I. How we instrument Honeycomb
II. Making sense of your weird browser data
III. How this changes everything writing web apps

12. Honeycomb UI: React, SCSS, go templates, and lots of data

13. I. How we instrument Honeycomb

14. The MVP browser
monitoring toolkit
● Performance
● RAIL model
● Loading metrics: page load time,
resource load time, first paint.
● Errors
● An event per client-side javascript
error, with metadata like user id,
browser version, current page.

15. RAIL performance model
https://developers.google.com/web/fundamentals/performance/rail

16. The MVP browser
monitoring toolkit
● Performance
● RAIL model
● Loading metrics: page load time,
resource load time, first paint.
● Errors
● An event per client-side javascript
error, with metadata like user id,
browser version, current page.

17. The MVP browser
monitoring tools
● Performance
● Honeycomb
● We also use SignalFx
● Other TSDBs work great too
● Errors
● Sentry
● Bugsnag
● TrackJS, Rollbar, & many more

18. The MVP browser
monitoring code
● Performance
● Write a custom thing
● But actually, use Boomerang
● Errors
● Sentry’s Raven JS is o/s
● So is Bugsnag’s
● … or write a custom thing (no)

19. Browser instrumentation is different
What questions are we trying to answer?
● Regressions (performance, errors)
● Product usage (analytics)
● Device capabilities (???)

20. Browser instrumentation is different
What are we trying to find?
● The Ghost of Code Past
● The Ghost of Code Present
● The Ghost of Code Future (!!!)

21. Honeycomb UI: what we graph

22. // Example Browser Event
{
// Usage
type: "page-load",
page_type: "/:team/datasets/:dataset”,
request_id: 123456,
ab_group_touch_ui: true,
ab_group_multi_team_chat: false,
// Performance / Regression
page_load_time_ms: 2145,
asset_version: "1.232.90"
canary: false,
// Capabilities
user_agent: "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_12_6) SomeBrowser/123.45"
window_height: 900,
window_width: 1245,
feature_support_emoji: true,
feature_support_service_worker: false,
}

23. II. Weird browser data

24. Frontend errors: the easy ones
• Exception Class:
• Message:
• Stacktrace[0]:
• Timing:
• Trend:
ReferenceError
this.drawGraph is undefined
/static/components/timeline.jsx:19
Within 2s of page load
Constant low volume

25. Frontend errors: the less easy ones
• Exception Class:
• Message:
• Stacktrace[0]:
• Timing:
• Trend:
NS_ERROR_XPC_SECURITY_MANAGER_VETO
NS_ERROR_XPC_SECURITY_MANAGER_VETO:
JS frame :: <TOP_LEVEL>
Within 2s of page load
happened a handful of times
but to only 1 user

26. 1. It’s in a noisy room

27. 1. It’s in a noisy room
• Exception Class:
• Message:
• Stacktrace[0]:
• Release stage:
• Timing:
• Trend:
Error
cannot find module “bind-all"
https://cdn.[some 3rd party].com/analytics.js/v1/QTk.../analytics.min.js:1 - o
100% Production
Within 5s of page load
1 big spike

28. 1. It’s in a noisy room: Ghostery data

29. 1. It’s in a noisy room
• Exception Class:
• Message:
• Stacktrace[0]:
• Release stage:
• Timing:
• Trend:
Error
cannot find module “bind-all"
https://cdn.[some 3rd party].com/analytics.js/v1/QTk.../analytics.min.js:1 - o
100% Production
Within 5s of page load
1 big spike

30. 2. It’s wandered off someplace

31. 2. It’s wandered off someplace

32. // Don’t believe in this
var isProduction =
window.location.hostname === 'ui.honeycomb.io';

33. 3. It’s not showing up

34. 3. It’s not showing up

35. 3. It’s not showing up
• Exception Class:
• Message:
• Stacktrace[0]:
• Timing:
• Trend:
ReferenceError
Uncaught ReferenceError: App is not defined
/static/main.js:1 - anonymous
Within 5s of page load
Sporadic, many users

36. <!-- Synchronously load first file -->
<script
src="https://ourcdn.net/bootstrapper.js"
crossorigin="anonymous">
</script>
<script
src=“https://ourcdn.net/main.js"
crossorigin="anonymous"
async>
</script>

37. 3. It’s not showing up
• Exception Class:
• Message:
• Stacktrace[0]:
• Timing:
• Trend:
Warning
Warning: bootstrapping script failed to load
/static/main.js:1 - anonymous
Within 5s of page load
Sporadic, many users

38. 3. It’s not showing up
Simulate this failure mode in development

39. 4. It’s finding new use cases

40. 4. It’s finding new use cases
• Exception Class:
• Message:
• Stacktrace[0]:
• Trend:
“waking up dev”
😈
<anonymous>:1
Just once

41. 4. It’s finding new use cases
Developers are weird

42. 4. It’s finding new use cases
Developers are weird, part 2

43. 5. It’s forcing us to change how we do things

44. Our browser
monitoring toolkit
● Performance
● Honeycomb
● We also use SignalFx
● Other TSDBs work great too
● Errors
● Sentry
● Bugsnag
● TrackJS, Rollbar, & many more

45. Our browser
monitoring toolkit
● Metrics
● Server utilization stats
● Timings and counts
● Events
● Significant actions
● Have associated metadata
● Also timings and counts

46. Our browser
monitoring toolkit
● Metrics
● Server utilization stats
● Timings and counts
● Events
● Significant actions
● Have associated metadata
● Also timings and counts

47. Log all important events,
not just errors
○error warning info

48. UX monitoring: Refresh tracking

49. UX monitoring: Rage click tracking

50. • Installed fonts
• Screen dimensions & color depth
• Browser language
• Online/offline status
• Emoji support
• Page visibility (backgrounded?)
• Connection type
• Support for emerging browser APIs
• Geographical location (using a library)
Available via the browser
(now or soon)

51. • A/B test groups
• JS asset version
• CSS asset version
• Canary deploy?
• User ID / User Name
• Team ID / Team Name
• Plan type
• … more domain things relevant to your app
…plus data you provide

52. What now?

53. Browser monitoring
is ready now

54. Frontend devs should get paged

55. Testing everything everywhere is dead

56. The monitoring team doesn’t know the js

57. The best tool is the one your team will use

58. For web to win, browser visibility required
📱

59. Thank you!
@eanakashima
honeycomb.io