Beyond Load Times Performance Analysis for Modern Web Apps

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

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

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!

“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

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

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

<= 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

User’s time! CPU GPU Memory Bandwidth Precious Resources

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

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

“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

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

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

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

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

Less detail than the network tab See requests in context Network

User input Animation Useful for context & finding events Interactions

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

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!

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

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

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

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.

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

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!