Upgrade to Pro — share decks privately, control downloads, hide ads and more …

LDNWebPerf February 2018 - Joel Webber

LDNWebPerf February 2018 - Joel Webber

Beyond Load Times: Performance Analysis for Modern Web Apps
A session presented by Joel Webber

On Tuesday, 6th February 2018

Skill level: Intermediate

Traditional web performance analysis often focuses on loading metrics -- time to first render, interactivity, onload, etc. This is important as far as it goes but increasingly limited as web "pages" become "apps" in their own right. While loading metrics remain important, it's becoming crucial to understand what's happening after the page is rendered.
To this end, we'll focus on using Chrome's performance timeline to understand everything that a page does, from the initial page load to ajax requests and client-side rendering. We'll also discuss the tools and techniques at our disposal to eliminate performance bottlenecks, or at least sweep them under the rug when they're unavoidable.

London Web Performance Group

February 06, 2018
Tweet

More Decks by London Web Performance Group

Other Decks in Technology

Transcript

  1. Beyond Load Times
    Performance Analysis for Modern Web Apps

    View Slide

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

    View Slide

  3. 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

    View Slide

  4. 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!

    View Slide

  5. “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

    View Slide

  6. 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

    View Slide

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

    View Slide

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

    View Slide

  9. User’s time!
    CPU
    GPU
    Memory
    Bandwidth
    Precious Resources

    View Slide

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

    View Slide

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

    View Slide

  12. “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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

  16. 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

    View Slide

  17. Less detail than the network
    tab
    See requests in context
    Network

    View Slide

  18. User input
    Animation
    Useful for context & finding
    events
    Interactions

    View Slide

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

    View Slide

  20. 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!

    View Slide

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

    View Slide

  22. 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

    View Slide

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

    View Slide

  24. 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.

    View Slide

  25. 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

    View Slide

  26. 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!

    View Slide