Understanding Frontend Performance

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

3de01a0c1a9c0e55efc6ecfa72b4eab3?s=128

Philip Tellis

May 22, 2019
Tweet

Transcript

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

    issues
  2. Philip Tellis Principal RUM Distiller @ Akamai Author of the

    OpenSource boomerang RUM library twitter:@bluesmoon ⦿ github:@bluesmoon speakerdeck:@bluesmoon
  3. Agenda • Tools to measure web performance • Understanding waterfalls

    • Understanding browser diagnostic data • Measuring RUM data • How do modern web apps complicate things?
  4. WebPageTest.org

  5. Select these two

  6. Select this

  7. Select this

  8. RequestMap.WebPerf.Tools

  9. Google Lighthouse

  10. Chrome Network Waterfall

  11. mPulse Beacon Waterfall

  12. mPulse Aggregate Waterfall

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

  14. SPAs & AMP complicate measurement!

  15. No JavaScript on AMP • Analytics code cannot run as

    usual • Register an amp-analytics tag to collect whitelisted data <script async custom-element="amp-analytics" src="https://cdn.ampproject.org/v0/amp-analytics-0.1.js"> </script> <amp-analytics type="mpulse" config="mpulse/api/amp-config.json..."> </amp-analytics> https://developer.akamai.com/tools/mpulse/amphtml#Introduction • Alternately, use amp-pixel <amp-pixel src="http://myserver.com/beacon?u= AMPDOC_URL&t=PAGE_LOAD_TIME">
  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.
  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
  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
  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
  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/
  21. Thank You!