Slide 1

Slide 1 text

Beyond Load Times Performance Analysis for Modern Web Apps

Slide 2

Slide 2 text

Co-founder, Fullstory Google - Web Toolkit - Chrome Web games - Quake - Angry Birds - Minecraft Reformed game developer Who am I?

Slide 3

Slide 3 text

App: “Single Page App” Plenty of great talks on making your pages load quickly. This isn’t one of those. Not all “pages” should be apps. But when they are, you need different tools and metrics. Apps, not Pages

Slide 4

Slide 4 text

App Architecture Load/Render User Input Traditional Web Apps Render UI User Input Native Apps Load/Save Install Load User Input Render UI Single-Page Apps Send/Receive Document Load Render Initial UI Roughly equivalent to VT-100 from the 60s!

Slide 5

Slide 5 text

“Loading” Your App Not the focus of this talk, but you should care: - Fast loading drives engagement - Slow drives users away - Google uses page speed in ranking - Smaller usually faster - less data on expensive networks Tools & Tech - Page Speed - Lighthouse - Progressive web apps #include

Slide 6

Slide 6 text

Rendering Initial UI Forget “load” time - “Document loaded” meaningless for apps - “onload” too early or too late Instead - Time to first meaningful paint - Time to interactivity

Slide 7

Slide 7 text

Page Load Milestones DOMContentLoaded - Document fully parsed - Non-async scripts loaded - Little or nothing rendered Load event - Resources in DOM loaded - No guarantee the app’s rendered First meaningful paint - Perceived as “loaded” Interactive - App’s Usable - Best defined in app code This app has “loaded” I bet the user disagrees

Slide 8

Slide 8 text

<= Rendering <= Local interactions <= Network interactions <= Hopefully nothing Our Goal Tight input-data-render loop Perceived latency: < 17 ms or “Janky” < 100 ms or ”Laggy” < 1 s or ”Slow” > 10 s or ”Off to Facebook” User Input & I/O

Slide 9

Slide 9 text

User’s time! CPU GPU Memory Bandwidth Precious Resources

Slide 10

Slide 10 text

Loading data & resources Javascript execution Garbage collection Rendering - Style recalculation - Layout - Rasterization - Compositing Things That Take Time

Slide 11

Slide 11 text

Documents DOM Nodes JS Heap Images GPU Memory Things That Take Space - Browser - GPU process - Tabs Task Manager

Slide 12

Slide 12 text

“Browser” process - Process management - Raw user input - Network/disk I/O “Compositor” process - Rasterization - Compositing “Render” processes - HTML Parser & DOM - Javascript VM - Style recalculation - Layout Detour: Browser Architecture

Slide 13

Slide 13 text

Chrome FPS Meter Gives a quick sense of “jank” Frame rate timeline and histogram GPU memory use Dig in further with the timeline

Slide 14

Slide 14 text

Looks complex, but worth understanding Captures details on everything the browser does Chrome Timeline View

Slide 15

Slide 15 text

Timeline subsumes old profiler Much clearer association of script time with other actions Mixes other events (e.g., GC) with script execution Script Execution

Slide 16

Slide 16 text

Frame rate meter Performance overview Markers for: - DOMContentLoaded - First meaningful paint - Load event Timing & Overview First meaningful paint (candidates) First meaningful paint DOMContentLoaded Load event Frame rate

Slide 17

Slide 17 text

Less detail than the network tab See requests in context Network

Slide 18

Slide 18 text

User input Animation Useful for context & finding events Interactions

Slide 19

Slide 19 text

Style recalculation Layout Event handlers Javascript execution Hierarchical “Flame Graph” Easy to pinpoint responsibility Main thread

Slide 20

Slide 20 text

Records each rendered frame With screenshots! Pinpoint the “janky bits” … and kill them with fire Frames tab shows layer tree Used in compositing Each consumes GPU memory Frames 60 frames / s = 1000 ms / 60 = 16.7 ms / frame!

Slide 21

Slide 21 text

JS Heap Documents (read: iframes) DOM Nodes Event Listeners GPU Memory Pinpoint leaks Unnecessary allocation (GC time!) Memory

Slide 22

Slide 22 text

API to mark timeline points/regions Use for application-level events - App now interactive - Updating views - Expensive computations - Etc. Some tools (e.g., React) do this automatically User Timing

Slide 23

Slide 23 text

Programmatic Tools Performance object - .timing - .memory - .mark/measure() - .getEntries() Server Timing

Slide 24

Slide 24 text

Measure “in the lab” - Lots of detail - Great for debugging - Can synthesize some constraints - But still not “real” Real User Monitoring Measure “in the wild” - Much less detail - Real users, devices, networks - Always more surprising than you expect! Learn from the wild, generate hypotheses, test them in the lab.

Slide 25

Slide 25 text

Fullstory implementing some perf & error analysis: - Page timing metrics - Resource & user-event timing - Javascript & resource errors - Frame rate ("jank detection") Come help us on our mission to make the web suck less! Shameless Plug

Slide 26

Slide 26 text

Resources First Meaningful Paint Page Speed Insights Lighthouse Progressive Web Apps Chrome dev tools Chrome performance tab Layers in Chrome Chrome compositing rasterization Javascript Performance object Scheduling, tasks, and microtasks React perf logging Server-side timing spec Fullstory Feel free to ask questions and request any other links, in the comments!