Understanding Frontend Performance

One of the first things to do when working on performance improvements is to start measuring. We cannot improve what we don’t measure, and things that are measured and watched tend to improve over time. The earlier talks in this track discussed which metrics were important to measure. In this talk, we’ll go over how to measure performance, and how to get useful diagnostics out of our tools.

We will cover:

* Tools to measure web performance
* Understanding waterfalls
* Understanding browser diagnostic data
* Measuring RUM data
* How do modern web applications complicate the situation?
* Single Page Applications (SPAs)
* Accelerated Mobile Pages (AMP

Transcript

1. Understanding Frontend
   Performance
   The tools and methods for debugging performance issues
   

   View Slide

2. Philip Tellis
   Principal RUM Distiller @ Akamai
   Author of the OpenSource boomerang RUM
   library
   twitter:@bluesmoon ⦿ github:@bluesmoon
   speakerdeck:@bluesmoon
   

   View Slide

3. Agenda
   ● Tools to measure web performance
   ● Understanding waterfalls
   ● Understanding browser diagnostic data
   ● Measuring RUM data
   ● How do modern web apps complicate things?
   

   View Slide

4. WebPageTest.org
   

   View Slide

5. Select these two
   

   View Slide

6. Select this
   

   View Slide

7. Select this
   

   View Slide

8. RequestMap.WebPerf.Tools
   

   View Slide

9. Google Lighthouse
   

   View Slide

10. Chrome Network Waterfall
    

    View Slide

11. mPulse Beacon Waterfall
    

    View Slide

12. mPulse Aggregate Waterfall
    

    View Slide

13. boomerang: https://developer.akamai.com/mpulse/whats-in-a-beacon
    

    View Slide

14. SPAs & AMP complicate measurement!
    

    View Slide

15. No JavaScript on AMP
    ● Analytics code cannot run as usual
    ● Register an amp-analytics tag to collect whitelisted data
    src="https://cdn.ampproject.org/v0/amp-analytics-0.1.js">
    
    
    
    https://developer.akamai.com/tools/mpulse/amphtml#Introduction
    ● Alternately, use amp-pixel
    
    

    View Slide

16. SPAs Are Different
    ● Some user actions result
    in a soft navigation
    ● No browser event to tell
    you when a soft navigation
    ended
    ● Resource Timing Buffer fills
    up
    ● WebPageTest works with
    scripting
    Page transitions without a full
    reload means most APIs don’t
    have relevant data.
    

    View Slide

17. Our approach to measuring SPAs
    ● Look for network activity or DOM mutations that happen soon
    after a user action
    ● Keep listening for more activity until we hit a timeout.
    ● If images or CSS, or other renderable assets were fetched, wait for
    them to complete
    https://www.slideshare.net/nicjansma/measuring-the-performance-of-single-page-applications
    

    View Slide

18. Our approach to measuring SPAs
    ● Additionally, if the browser supports Resource Timing, we can use
    values from there to construct navigation time points.
    ● We need to clear the resource timing buffer after each beacon.
    This is easier to see with a quick demo
    https://www.slideshare.net/nicjansma/measuring-the-performance-of-single-page-applications
    

    View Slide

19. Summary
    ● There are many tools freely
    available for developers to study
    their site’s performance
    ● Looking at Waterfalls individually
    and in aggregate gives different
    insights
    ● Modern development frameworks
    require creative ways to study
    performance
    Boston Shipyard Artist’s Community
    

    View Slide

20. References
    ● WebPageTest.org
    ● RequestMap
    ● Lighthouse
    ● github.com:boomerang
    ● mPulse Aggregate Waterfall
    ● What’s in an mPulse beacon
    ● AMP in mPulse
    ● AMP does it really make your site faster
    ● Measuring the performance of Single Page Applications
    ● Scripting WebPageTest
    ● https://virtualglobetrotting.com/
    

    View Slide

21. Thank You!
    

    View Slide