Front-End Performance Still Matters

6e0ba5b45dafe063b98db2a1d5391433?s=47 Sia
February 24, 2018

Front-End Performance Still Matters

Help! My app bundle is 5MB! My users are angry that my app is so slow! It’s easy to forget that performance matters when we are under pressure to deliver features quickly. What things should we always do versus only do when performance is slow? What data should we use to inform our decisions? From code splitting, lazy loading, and tree shaking to image optimization and store architecture, come learn how you can deliver a better experience to your users with high-performing front-end apps. This talk uses Webpack and ES6 but is library-agnostic (React, Angular, Vue, etc.).



February 24, 2018


  1. 2.

    WHO AM I? Sia Karamalegos Developer, Clio + Calliope Twitter

    and Medium: @thegreengreek Github: siakaramalegos New Orleans Owns crazy dogs
  2. 3.

    Perception vs reality Why should I care? Analytics & dev

    tools Biggest bytes Most expensive asset WHAT ARE WE TALKING ABOUT?
  3. 7.

    53% of mobile site visits are abandoned if pages take

    longer than 3 seconds to load. - DoubleClick by Google, 2016
  4. 13.
  5. 14.

    Learn browser dev tools already! Learn your framework's dev tools

    too. Analyze your Webpack bundles. Simulate average network speed and devices with LAZINESS TOOLS FOR SUCCESS
  6. 17.

    Images account for 60% of the bytes on average needed

    to load a webpage. - Google
  7. 18.

    Use the right image type (png vs jpeg) Use the

    right size and src sets Use loaders to auto-build src sets Compress your images with ImageOptim Set your build tool to optimize for you IMAGE TOOLS FOR SUCCESS
  8. 23.

    Optimize for the device and network conditions your users have.

    2-5x difference in fastest vs slowest phones 75% of worldwide mobile connections on 2G or 3G ABSOLUTE TIME: USERS VS DEVELOPERS
  9. 24.

    ~$200 Android device on a slow 3G network No more

    than 5s rst-load time to interactive No more than 2s for subsequent loads Budget of ~130-170KB (gzipped) of critical-path resources (more JS requires smaller bundle) This con guration is available on PERFORMANCE BUDGETS AT GOOGLE
  10. 25.

    Version Size (mini ed) Size (mini ed + gzipped) Parse/eval

    time (avg) ES2015+ 80K 21K 172ms ES5 175K 43K 367ms THE COST OF UNNECESSARY TRANSPILING
  11. 27.

    Optimizing Time to Interactive Analyze your bundles! Don't over-optimize! Only

    ship what's immediately needed - use code splitting, lazy load, and provide ES2015+ bundles for modern browsers Minify - speeds up both download and parse/compile Compress with gzip and brotli Remove unused code - tree shaking and using module imports effectively JAVASCRIPT TOOLS FOR SUCCESS
  12. 28.

    import _ from 'lodash'; _.isEmpty({}); import isEmpty from 'lodash/isEmpty'; isEmpty({})

    import moment from 'moment'; import addMinutes from 'date-fns/addMinutes'; MODULE IMPORTS
  13. 29.

    Eliminate Download and Compilation For subsequent loads, set up caching,

    and Use service workers and of ine- rst strategies. Prefetch future execution paths while user on current page (Next.js). JAVASCRIPT TOOLS FOR SUCCESS ciency/http-caching
  14. 30.

    Most of your time is spent using the app, not

    waiting to load. - Devin Villegas, Net ix senior dev ops engineer, former New Orleanian
  15. 31.

    Increase Responsiveness Don't block the main thread! Avoid memory leaks

    - garbage collection can pause execution Avoid long-running JS - chunk into smaller pieces with requestAnimationFrame() or requestIdleCallback() for scheduling Use up-to-date frameworks that prioritize user input (like React Fiber starting in React v16.0) JAVASCRIPT TOOLS FOR SUCCESS
  16. 32.

    TL;DR: SHIP LESS CODE less code = less load +

    less parse/compile/eval holy grail = load only code needed for what's in view
  17. 34.

    Are you better off making the site load faster or

    ensuring that users complete their tasks? - Christine Perfetti, The Truth About Download Time 2006