ForwardJS '19 - The Need For Speed: Measuring Latency In Single-Page Applications

You've launched your application, and now you've been asked to optimize it. How do you know how fast it is? Is your data accurate and actionable? We'll explore both generic and framework-specific approaches to instrumenting your application, along with real-world examples of how to put these techniques in practice!

Transcript

1. The Need For Speed MEASURING LATENCY IN SINGLE-PAGE APPLICATIONS Jordan Hawker Staff Frontend Engineer
3. Why Do We Care? Poor performance impacts business metrics • Bounce Rates • Conversions • Feature Throughput • Revenue Impact • User Satisfaction
4. Implementation Before Optimization • You don’t know what to optimize without data • Backend Instrumentation • Mature tooling already exists • Detailed information about services • Doesn’t provide the full picture • Can we track performance across the whole stack?
5. Web Application Performance • Rate of Requests • Resource Consumption • Efficiency • Latency • Response Time • Throughput • Availability • Responsiveness WHAT DOES THAT EVEN MEAN?
6. Interactivity USER-PERCEIVED LATENCY
7. The time it takes for the critical content of a page to load such that the user believes they can engage in their primary purpose visiting that page Interactivity
8. Priority: User Experience • Each metric has its own use, but… • Real-world impact is paramount • Know what your users are seeing • Gather data on different devices/browsers • Understand variance across global regions • Great data will reflect improvements across the stack
9. Third-Party Tools
10. Page Speed Insights
11. WebPageTest
12. Lighthouse
13. Evaluating Third-Party Tools • Great overviews of app performance • Detailed suggestions for optimization • They don’t understand how SPAs render • Data is a rough approximation at best • How can we leverage framework internals?
14. Architecture
15. Critical Path • Each page has primary activities • Components related to that content are “critical” • Secondary components • Also rendered on the page • Not tied to the primary activity • Don’t need to finish rendering
16. DOM is a tree… • …and so are your apps! • Pages are nested layers of components • Each route or component has direct children • Components with no children are leaf nodes • Each parent waits on its children to render
17. Subscriber-Reporter Relationship • Relies on child components to complete render • Subscribes to updates from its children • Complex conditions for interactivity Subscriber Reporter • Reports its own render times • Child of a subscriber • May also be a subscriber itself
18. Implementation
19. Approach • Leverage hooks to approximate rendering • Account for async behavior (e.g. requests, images) • Capture per-component events & roll up to page • Tie parents to their children to bubble data • Work up from the bottom of the tree • When child reports, check parent interactivity • Common method to check complex conditions
20. React • componentDidMount • Invoked immediately after a component is mounted • Create a higher-order component (HOC) • Provides components with this latency behavior • Parent/Child Relationship • this.props.children gives access • Pass a parent reference down to children
21. Ember • Routes: didTransition • Components: didInsertElement • Leverage Runloop • run.scheduleOnce(‘afterRender’, this, this.reportInteractive) • Parent/Child Relationship • this.parentView is a direct reference • Ember-Interactivity: jhawk.co/interactivity-demo
22. Angular • ngAfterContentInit • Called after Angular fully initializes all content of a directive • Parent/Child Relationship • this.parentInjector.view.component
23. Vue • mounted • Called after the instance has been mounted • this.$nextTick • Called after all children have been rendered • Parent/Child Relationship • this.$parent
24. Developer Tooling
25. Performance API • Browser interface that provides performance info • performance.mark • Creates a timestamp in the performance buffer • performance.measure • Creates a measure between two timestamps • Data can be inspected, tracked, and visualized
26. Performance Recording
27. User Timing
28. Timings In Third-Party Tools
29. Key Takeaways
30. What We Learned • Define the critical path • Identify bottleneck components • Defer non-critical components • Holistic user-centric metrics reflect improvements across the stack
31. The Path Forward • Leverage multiple tools for instrumentation • Measuring each layer of the stack is useful • Capture real user metrics to understand impact • Virtual machines are insufficient simulations • Use framework-aware tools for granular data • Be cognizant of the performance impact of leveraging framework internals
32. JordanHawker elwayman02 www.JordanHawker.com Slides: jhawk.co/forwardjs19 All images courtesy of Unsplash