Slide 1

Slide 1 text

The Need For Speed MEASURING LATENCY IN SINGLE-PAGE APPLICATIONS Jordan Hawker Staff Frontend Engineer

Slide 2

Slide 2 text

No content

Slide 3

Slide 3 text

Why Do We Care? Poor performance impacts business metrics • Bounce Rates • Conversions • Feature Throughput • Revenue Impact • User Satisfaction

Slide 4

Slide 4 text

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?

Slide 5

Slide 5 text

Web Application Performance • Rate of Requests • Resource Consumption • Efficiency • Latency • Response Time • Throughput • Availability • Responsiveness WHAT DOES THAT EVEN MEAN?

Slide 6

Slide 6 text

Interactivity USER-PERCEIVED LATENCY

Slide 7

Slide 7 text

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

Slide 8

Slide 8 text

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

Slide 9

Slide 9 text

Third-Party Tools

Slide 10

Slide 10 text

Page Speed Insights

Slide 11

Slide 11 text

WebPageTest

Slide 12

Slide 12 text

Lighthouse

Slide 13

Slide 13 text

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?

Slide 14

Slide 14 text

Architecture

Slide 15

Slide 15 text

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

Slide 16

Slide 16 text

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

Slide 17

Slide 17 text

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

Slide 18

Slide 18 text

Implementation

Slide 19

Slide 19 text

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

Slide 20

Slide 20 text

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

Slide 21

Slide 21 text

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

Slide 22

Slide 22 text

Angular • ngAfterContentInit • Called after Angular fully initializes all content of a directive • Parent/Child Relationship • this.parentInjector.view.component

Slide 23

Slide 23 text

Vue • mounted • Called after the instance has been mounted • this.$nextTick • Called after all children have been rendered • Parent/Child Relationship • this.$parent

Slide 24

Slide 24 text

Developer Tooling

Slide 25

Slide 25 text

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

Slide 26

Slide 26 text

Performance Recording

Slide 27

Slide 27 text

User Timing

Slide 28

Slide 28 text

Timings In Third-Party Tools

Slide 29

Slide 29 text

Key Takeaways

Slide 30

Slide 30 text

What We Learned • Define the critical path • Identify bottleneck components • Defer non-critical components • Holistic user-centric metrics reflect improvements across the stack

Slide 31

Slide 31 text

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

Slide 32

Slide 32 text

JordanHawker elwayman02 www.JordanHawker.com Slides: jhawk.co/forwardjs19 All images courtesy of Unsplash