Skip to content

Instantly share code, notes, and snippets.

@matthewstokeley

matthewstokeley/tti.md

Last active January 10, 2020 04:19
Show Gist options
  • Star 0 You must be signed in to star a gist
  • Fork 0 You must be signed in to fork a gist
  • Save matthewstokeley/676e447dd19031d1d2f331cd1c7a1ab4 to your computer and use it in GitHub Desktop.
Save matthewstokeley/676e447dd19031d1d2f331cd1c7a1ab4 to your computer and use it in GitHub Desktop.
Download ZIP
Time to interactive
Raw
tti.md

JavaScript and time-to-interactivity notes

Javascript is expensive - must be downloaded, then parsed, compiled and executed

  • Code Splitting

    • Webpack options (some of these can be used without webpack)
      • Manually use entry points to remove unused codes
      • Use a plugin to check for code duplication
      • Dynamic imports
        • Asynchronous library loading using promises

  • Tree Shaking

    • Only import necessary modules from libraries
    • Well written modules with no side effects can easily be shaken

  • Loading all scripts in the main thread

Lazy Load scripts

Use less javascript

  • Unnecessary files / code - polyfills, libraries, etc

The affordability calculation

  • Prefer to have every page load in under a second
  • Not possible on real-world networks

TTI - time to interactive

  • 5 seconds for first load
  • Under 2 seconds for subsequent loads
  • 3.4s after subtracting 1.6 for dns lookup and tls handshaking
  • 400kbs = 50kb/s. 50kb/s * 3.4 = 170kb
  • Gzip compression is between 5 and 6x - 170kb becomes 850kb - 1mb
  • Subtract connection setup time for cdn ~1.6s, “further limiting how much of our 5s we actually get to spend on network transfer and client-side work”
  • Critical path resources
  • 170kb for sites without much js
  • 130kb for sites built with js frameworks

PRPL pattern

  • we.go
  • ele.me
  • Service workers
  • Offline first

Performance Testing

https://infrequently.org/2017/10/can-you-afford-it-real-world-web-performance-budgets/

webpagetest.org/easy:

  • This is our go-to tool for one-off analysis.

  • WPT scripting: for teams that don’t want to set up a custom WPT instance and have public URLs for their WIP apps, integrating with WPT scripting can be a great way to get regular “checks”

  • WPT private instances: teams that want to integrate WPT directly into their CI or commit-queue systems should investigate setting up a private WPT server and hardware

  • Scripted Lighthouse: not ready for a full WPT instance? Scripting Lighthouse can help your CI automate analysis of your site and catch regressions

  • grunt-perfbudget is an even-easier, automated WPT testing for your CI. Use it!

  • Speedcurve and Calibre: these hosted services automate tracking performance over time, delivering an outstanding real-world gut-check

  • Webpack Performance Budgets: for teams using webpack in their build steps, enabling this configuration can provide great development-time warning for resources that exceed budgets. bundlesize and pr-bot let you set per-script budgets which can be automatically enforced as part of your pull-request process. Recommended!

Javascript Interactivity https://philipwalton.com/articles/why-web-developers-need-to-care-about-interactivity/

Javascript Start Up Performance https://medium.com/reloading/javascript-start-up-performance-69200f43b201#24ef

Performance budget https://infrequently.org/2017/10/can-you-afford-it-real-world-web-performance-budgets/

Code Splitting https://webpack.js.org/guides/code-splitting/

https://developers.google.com/web/fundamentals/performance/optimizing-javascript/tree-shaking/

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment