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

Negotiating for performance

Negotiating for performance

As a developer you need to be able to champion performance to the business you work in. This is because performance matters and as a developer you are best placed to understand the implications things have on how fast a web page will load.

As part of championing performance, you need to be able to negotiate with the stakeholders of the site. This might involve working with the designers to work on building a user experience that loads fast and working with the project managers to put aside time to spend optimising the site performance.

Jonathan Fielding

August 02, 2016
Tweet

More Decks by Jonathan Fielding

Other Decks in Programming

Transcript

  1. Negotiating for
    performance
    Jonathan Fielding @jonthanfielding

    View full-size slide

  2. A bit about me…
    • Technical Architect at Beamly (WE ARE
    HIRING)
    • Author of ‘Beginning Responsive Design’
    • Regular contributor to open source, including
    SimpleStateManager, Echo.js, CriticalJS, FT’s
    Polyfill Service, Doccy among many projects
    • Here as a warm up prior to the Pizza

    View full-size slide

  3. Many talks about
    performance focus on
    implementation

    View full-size slide

  4. They look at the steps we take
    to make a site performant

    View full-size slide

  5. focusing on the techniques
    we use instead of the
    process we take

    View full-size slide

  6. So today we are going to
    be focusing on how we
    can make performance
    the centre of our process

    View full-size slide

  7. Looking at how we can
    raise awareness about
    performance within our
    teams

    View full-size slide

  8. We will identify how we
    can use performance as a
    competitive advantage

    View full-size slide

  9. We will look at this
    initially from the
    perspective of a new site

    View full-size slide

  10. Then looking at how we
    can retrospectively apply
    these techniques to our
    existing sites

    View full-size slide

  11. And ultimately we will start
    to understand the language
    we should use when trying
    to communicate with
    others about performance

    View full-size slide

  12. Situations you might
    have found yourself in

    View full-size slide

  13. “The client wants to use a
    background gif for each
    block on the homepage”

    View full-size slide

  14. “And they are 5MB EACH”

    View full-size slide

  15. “The designer used 6
    different fonts AGAIN”

    View full-size slide

  16. “and it’s already been
    approved by the client!”

    View full-size slide

  17. “The analytics team
    wants to track how users
    interact with the site”

    View full-size slide

  18. “and the tracking script is
    larger than the rest of my page”

    View full-size slide

  19. The thing is….

    View full-size slide

  20. Clients don’t ask for sites
    that take forever to load

    View full-size slide

  21. They ask for a site that
    will enable them to
    achieve specific goals

    View full-size slide

  22. Designers don’t design
    sites to be slow

    View full-size slide

  23. They design sites that are
    user focused, on brand and
    eye-catching

    View full-size slide

  24. Analytics teams don’t
    want to have any impact
    on your site

    View full-size slide

  25. They just need a way to
    track user behaviour

    View full-size slide

  26. Unfortunately, the
    requirements of our
    stakeholders are often at
    odds with performance

    View full-size slide

  27. Stakeholders aims are:
    • Feature rich
    • Tracked
    • On-brand
    • Achieve KPIs
    • Appealing design
    • Eye-catching

    View full-size slide

  28. Whilst we need to ensure it is:
    • Performant
    • Functional
    • Lightweight

    View full-size slide

  29. That’s why building a site
    starts to become a
    balancing act

    View full-size slide

  30. Where we need to engage
    with stakeholders to balance
    our site’s requirements

    View full-size slide

  31. We first need to look at
    how we make our
    stakeholders more
    aware of performance

    View full-size slide

  32. When I build a website I
    obsess over performance

    View full-size slide

  33. I do this because I
    understand the impact of
    performance

    View full-size slide

  34. Being aware of why
    performance matters can
    help your stakeholders
    get on board

    View full-size slide

  35. There are three key types
    of performance that you
    need to make your
    stakeholders aware of

    View full-size slide

  36. Render performance -
    The time it takes for the
    browser to start
    rendering the page

    View full-size slide

  37. Page load performance -
    The time it takes to fully
    load a page and be fully
    interactive

    View full-size slide

  38. Perceived performance -
    the perception of the
    user of the performance
    of our site

    View full-size slide

  39. Of these three the most
    important is perceived
    performance

    View full-size slide

  40. To designers the
    perceived performance
    has an impact on the user
    experience of the site

    View full-size slide

  41. It is the first impression
    the user gets when they
    visit your site

    View full-size slide

  42. To clients/product
    managers, performance
    can affect what they are
    trying to achieve

    View full-size slide

  43. The majority of clients/
    product managers are
    aiming to reach specific
    KPIs

    View full-size slide

  44. Performance however
    has an impact on all the
    KPIs of our site

    View full-size slide

  45. This is reflected in some
    studies carried out by
    some big brands

    View full-size slide

  46. Amazon found every
    100ms delay in loading a
    page cost them 1% in sales

    View full-size slide

  47. Google found an extra 500ms
    delay loading search results
    decreased traffic by 20%

    View full-size slide

  48. The Trainline reduced latency
    by 0.3 seconds and customers
    spent an extra £8 million a year

    View full-size slide

  49. Walmart saw for every 1 second
    decrease in page load they had a
    2% increase in conversions

    View full-size slide

  50. More examples of
    studies can be found at
    wpostats.com

    View full-size slide

  51. The site performance
    also has an impact on
    search engine ranking

    View full-size slide

  52. With Google, Bing and other
    search engines using it as
    part of the ranking algorithms

    View full-size slide

  53. With the benefit it brings to
    business, performance is
    clearly a competitive
    advantage

    View full-size slide

  54. We therefore want to
    ensure our site loads faster
    than our client’s
    competitors’

    View full-size slide

  55. To enable us to do this we
    need to test competitors’
    sites

    View full-size slide

  56. If we take Beamly for
    example, our site is a lot like
    Buzzfeed so we want to
    benchmark against that

    View full-size slide

  57. and due to the audience here
    today we will also throw the
    FT and Guardian into the mix

    View full-size slide

  58. To run our test we can
    use Web Page Test

    View full-size slide

  59. We then need to sit patiently
    while our tests are run

    View full-size slide

  60. We can also export the
    comparison from Web
    Page Test as video

    View full-size slide

  61. When running these
    benchmarks against our
    competitors we will want
    to do it for different
    types of page

    View full-size slide

  62. Having seen how our
    competitors perform we
    should aim to be faster

    View full-size slide

  63. Tim Kadlec
    “For example, say a competitor’s
    site loads in 5 seconds. 20% of 5
    seconds is 1 second. So to be
    perceived as faster than them, you
    need to have your pages taking no
    longer than 4 seconds (5 seconds
    load time - 20% difference).”
    https://timkadlec.com/2014/01/fast-enough/

    View full-size slide

  64. So we should expect to
    be a minimum of 20%
    faster than our
    competitors

    View full-size slide

  65. We shouldn’t only try to
    achieve this though, we should
    try our best to go further

    View full-size slide

  66. 80% of 10 seconds is still
    8 seconds and that is still
    a slow website

    View full-size slide

  67. In his book Usability
    Engineering, Jakob Nielsen
    identified response time limits.

    View full-size slide

  68. 0.1 SECONDS
    Feels instantaneous

    View full-size slide

  69. 1 SECOND
    Lets you think
    seamlessly

    View full-size slide

  70. 10 SECONDS
    Keeps your attention
    ….barely

    View full-size slide

  71. +10 SECONDS
    User is going to
    abandon your site
    in frustration

    View full-size slide

  72. This reinforces the need
    to ensure our site is
    performant

    View full-size slide

  73. You can use building a new
    site as a way to establish
    awareness

    View full-size slide

  74. Look at the existing site

    View full-size slide

  75. This enables you to
    identify strengths and
    weaknesses of the
    current user experience

    View full-size slide

  76. This should include
    looking at how the
    existing site performs
    when it comes to
    performance

    View full-size slide

  77. This data can then be
    used to link a increase in
    performance to an
    increase of KPI’s

    View full-size slide

  78. Ensure you’re planning
    performance as part of
    your build

    View full-size slide

  79. It is not uncommon for a
    developer to first see a
    design when they are
    asked to build it

    View full-size slide

  80. At this point it’s too late
    to start planning how to
    make the site performant

    View full-size slide

  81. The client has already
    approved the design

    View full-size slide

  82. They love the carousels,
    the 6 fonts, the crazy
    animated background gif

    View full-size slide

  83. This is happening every
    day across our industry

    View full-size slide

  84. The result is that our
    web pages are getting
    bigger and bigger

    View full-size slide

  85. Average
    Page
    Weight
    >

    View full-size slide

  86. This isn’t down to lack of
    knowledge in teams

    View full-size slide

  87. It is down to a problem in
    the processes we are
    going through to build
    our sites

    View full-size slide

  88. This is why you need to
    ensure that one of your
    project goals is for the
    site to be performant

    View full-size slide

  89. Development
    Design
    Research
    Business
    development
    Don’t start thinking of
    performance here

    View full-size slide

  90. Development
    Design
    Research
    Business
    development
    Think about it from
    the start of
    your project

    View full-size slide

  91. When working with your
    clients, include it within
    your statement of work

    View full-size slide

  92. Then as you carry out
    your research look at the
    connection speeds your
    users have

    View full-size slide

  93. During design and build,
    regularly get your team
    together to review work

    View full-size slide

  94. You should then aim to
    get your designs into
    build as soon as possible

    View full-size slide

  95. Encourage
    communication

    View full-size slide

  96. Having brought
    performance to the
    beginning of our process
    we need a common way
    to talk about it

    View full-size slide

  97. The way in which we do
    this is to use
    performance budgets

    View full-size slide

  98. A performance budget is
    a goal which guides
    design and development

    View full-size slide

  99. Tim Kadlec
    “The purpose of a performance
    budget is to make sure you focus
    on performance throughout a
    project. The reason you go through
    the trouble in the first place though
    is because you want to build a site
    that feels fast for your visitors.”
    http://www.timkadlec.com/2014/11/performance-budget-metrics/

    View full-size slide

  100. In order for you to determine
    what your performance
    budget should be, you need
    to determine what you’re
    going to measure

    View full-size slide

  101. In his post, Tim Kadlec
    identified four such
    metrics

    View full-size slide

  102. Milestone Timing

    View full-size slide

  103. Quantity based metrics

    View full-size slide

  104. Rule based metrics

    View full-size slide

  105. To put together our
    budget we can use a
    combination of these
    metrics

    View full-size slide

  106. Andy Davies
    To me a perf budget needs to be
    "an event that matters to the
    visitor within a set time under
    defined network conditions"
    Tweet: https://twitter.com/AndyDavies/status/534474109741465601

    View full-size slide

  107. To identify our metric we
    therefore need to
    identify the event that
    matters to our users on
    our site

    View full-size slide

  108. For Twitter this might be
    the time until the
    navigation is visible

    View full-size slide

  109. For Facebook this might
    be the time until the user
    is able to make a post

    View full-size slide

  110. The FT might simply
    want to lay out their page
    ready for content to load
    into as it loads

    View full-size slide

  111. For our site, an event
    that matters could be the
    user being able to start
    interacting with the page

    View full-size slide

  112. Therefore the time it
    takes until it gets to this
    point should be our
    performance budget

    View full-size slide

  113. So we might decide that
    we want our page to be
    interactive within 5
    seconds on a slow 3G
    connection

    View full-size slide

  114. In order to calculate our
    budget we need to define
    ‘slow 3G’

    View full-size slide

  115. WebPageTest defines
    this as 96 kilobytes per
    second

    View full-size slide

  116. So as we want to load our
    site in 5 seconds…

    View full-size slide

  117. 96KB x 5secs = 480KB

    View full-size slide

  118. We can then split 480KB
    across our assets

    View full-size slide

  119. Budget
    HTML CSS JavaScript Images
    30kb 40kb 50kb 360kb

    View full-size slide

  120. If we then decide we
    want to add web fonts to
    our website we then
    adjust our budget

    View full-size slide

  121. HTML CSS JavaScript Images Fonts
    30kb 40kb 50kb 300kb 60kb
    Adjusted budget

    View full-size slide

  122. You can have multiple
    performance budgets to
    handle different
    conditions

    View full-size slide

  123. HTML CSS JavaScript Images Fonts
    30kb 40kb 50kb 800kb 60kb
    Larger devices budget

    View full-size slide

  124. The budget only covers
    the data required until
    we reach the event the
    budget is based upon

    View full-size slide

  125. The budget this method
    produces is a bit rough

    View full-size slide

  126. It doesn't account for
    poor network conditions
    beyond being slow

    View full-size slide

  127. It does however provide
    you with a set of guides
    you can use

    View full-size slide

  128. Experimenting with
    different performance
    budgets

    View full-size slide

  129. Building a performance
    budget is about reaching
    the correct balance

    View full-size slide

  130. and creating the
    performance budget
    should be a collaboration
    between the various
    stakeholders

    View full-size slide

  131. One such tool that helps
    you do this is
    performancebudget.io

    View full-size slide

  132. Demo of
    performancebudget.io

    View full-size slide

  133. Measuring your
    performance budget

    View full-size slide

  134. For your performance
    budget to be successful it
    needs to be measured

    View full-size slide

  135. A tool we can use to do
    this is Web Page Test

    View full-size slide

  136. Building a performance
    budget for an existing site

    View full-size slide

  137. The problem with existing
    sites is that they likely have
    performance problems

    View full-size slide

  138. We should therefore
    create our budget based
    on our existing site

    View full-size slide

  139. To do this we need to find
    out what our site’s
    metrics are

    View full-size slide

  140. Using WebPageTest has
    given us a wealth of data
    that we can use to put
    together a performance
    budget

    View full-size slide

  141. Base Budget - 1483kb
    HTML CSS JavaScript Images Fonts Other
    20kb 98kb 632kb 658kb 46kb 29kb

    View full-size slide

  142. Having determined a
    budget for the existing
    site we now need to look
    at where we want to
    make improvements

    View full-size slide

  143. Firstly we identify areas
    of concern
    HTML CSS JavaScript Images Fonts Other
    20kb 98kb 632kb 658kb 46kb 29kb

    View full-size slide

  144. Adjusted Budget
    HTML CSS JavaScript Images Fonts Other
    20kb 98kb 632kb 358kb 46kb 29kb

    View full-size slide

  145. Adjusted Budget
    HTML CSS JavaScript Images Fonts Other
    20kb 98kb 600kb 358kb 46kb 29kb

    View full-size slide

  146. Maintaining your
    performance budget

    View full-size slide

  147. It is important that you
    don't forget about your
    performance budget

    View full-size slide

  148. You therefore need to
    ensure that it forms part
    of your process

    View full-size slide

  149. Document your
    performance budget

    View full-size slide

  150. At Beamly we started
    keeping our performance
    budgets in a PERF.md file

    View full-size slide

  151. # BeamlySite Performance Budget
    ## Expectation
    A page is expected to load in 5 seconds on a slow 3G
    connection.
    ## Budget
    | HTML | CSS | JavaScript | Images |
    |:----:|:----:|:----------:|:------:|
    | 30kb | 40kb | 50kb | 360kb |
    ## Contributors
    * Jonathan
    * Sasha
    * Izzy

    View full-size slide

  152. By storing the file in the
    repository it is version
    controlled

    View full-size slide

  153. We then ensure that it is
    available to all
    stakeholders

    View full-size slide

  154. We then use a style guide
    to communicate site
    changes

    View full-size slide

  155. Nicole Sullivan wrote a
    great post on how having
    a living style guide can
    help you improve
    performance

    View full-size slide

  156. She worked with a
    company called Trulia in
    2013 to improve
    performance

    View full-size slide

  157. Reduce their HTML
    payload by 48%

    View full-size slide

  158. Reduced load
    time by 21%

    View full-size slide

  159. Achieve a 60%
    improvement in
    time to first byte

    View full-size slide

  160. Reduce unused
    CSS by 135kb

    View full-size slide

  161. She also noted on her
    blog post that it also led
    to the design being used
    across their site being
    more consistent

    View full-size slide

  162. Ensure you educate
    anyone who joins your
    project

    View full-size slide

  163. Monitor your performance
    budget

    View full-size slide

  164. It is very easy to blow
    your budget

    View full-size slide

  165. You might implement a
    new component on your
    site

    View full-size slide

  166. Or you might simply have
    different content in live
    than you had on stage

    View full-size slide

  167. To help prevent this
    there are a number of
    tools you can use to
    monitor your budget

    View full-size slide

  168. Earlier we mentioned
    WebPageTest

    View full-size slide

  169. Aside from using it to run
    one off tests, we can also
    use it as part of our
    Continuous Integration

    View full-size slide

  170. If you want to regularly
    run tests you can use a
    service like SpeedCurve

    View full-size slide

  171. Demo of
    speedcurve.com

    View full-size slide

  172. Performant sites
    provide a better user
    experience and are a
    competitive advantage

    View full-size slide

  173. We should therefore be
    ensuring that performance is
    a goal of our project

    View full-size slide

  174. To make this possible we should
    use a common language that
    all stakeholders understand

    View full-size slide

  175. Ensuring that during our
    regular testing of our site
    we are also testing the
    performance

    View full-size slide

  176. Introducing monitoring
    where necessary to
    ensure we are able to
    maintain performance

    View full-size slide

  177. A special thanks goes out to to
    Charlie Fielding for being so patient
    and watching this talk 100x,
    Andrew Davies for design, Phil
    Nash for looking through and
    advice and Kate Montgomery for
    proof reading

    View full-size slide

  178. Thank you, any questions?
    Useful links
    https://wpostats.com/
    http://www.performancebudget.io/

    View full-size slide