$30 off During Our Annual Pro Sale. View Details »

Deep Dive into Web Performance

Deep Dive into Web Performance

We all know that your website’s performance is critical to the success of its mission. Conversion rates are proven to plummet if with every second of page load time.

What can we do about this? Why is the web still slow?

We’re going deep into modern web performance, and you will learn how to identify and fix performance bottlenecks in your website / webapp through topics such as:

Web performance metrics you should be measuring and how. Which are the most important?
How do I optimize my site for each of these web performance metrics
How browsers render web pages, and how to use this knowledge to optimize the loading experience.
What is the critical path? How do I account for this?
What is the JavaScript main thread? How can I optimize for this?
Identifying, profiling, and optimizing for third party scripts.
In order to get the most out of this session, the attendee will have to 1) have some knowledge of HTML, CSS, and JavaScript, 2) have a basic understanding of browser-based developer tools, and 3) find slow websites extremely annoying.

Michael Herchel

August 23, 2018
Tweet

More Decks by Michael Herchel

Other Decks in Technology

Transcript

  1. Mike Herchel
    Senior Front-end Dev at Lullabot // @mikeherchel
    Web Performance in 2019

    View Slide

  2. WHAT TO EXPECT
    ‣Why make webpages fast?
    ‣What is fast?
    ‣Quick rundown on how browsers work
    ‣How to measure performance
    ‣Tips and tricks to optimize each browser
    rendering stage.

    View Slide

  3. Mike Herchel
    Millie Herchel
    Dexter
    Herchel

    View Slide

  4. View Slide

  5. – https://www.doubleclickbygoogle.com/articles/mobile-speed-matters/
    53% of mobile site visits are
    abandoned if pages take
    longer than 3 seconds to
    load.

    View Slide

  6. – https://www.doubleclickbygoogle.com/articles/mobile-speed-matters/
    Mobile sites load in 5
    seconds earn up to 2x
    more mobile ad revenue.

    View Slide

  7. https://www.stevesouders.com/blog/2012/02/10/the-performance-golden-rule/
    80-90% of the end-user
    response time is spent on
    the frontend. Start there.
    — Steve Souders

    View Slide

  8. View Slide

  9. WHAT IS FAST?

    View Slide

  10. FRONTEND
    PERFORMANCE
    METRICS
    ‣Time to First Byte
    ‣Time to First Meaningful Paint
    ‣Time to First Interactive
    ‣Speed Index

    View Slide

  11. TIME TO FIRST
    BYTE
    ‣Time from when you begin navigation until the first byte of the
    html file hits your browser.
    ‣Delays here can indicate backend performance issues.
    ‣Effective caching really helps with this (Drupal FTW)
    ‣CDNs can dramatically help. They position content closer to the
    user.

    View Slide

  12. TIME TO FIRST
    BYTE

    View Slide

  13. TIME TO FIRST
    MEANINGFUL PAINT
    ‣Primary content is visible.
    ‣Marks the paint event that follows the most significant change to
    layout.
    ‣Can be ambiguous.

    View Slide

  14. TIME TO FIRST
    MEANINGFUL PAINT

    View Slide

  15. TIME TO
    INTERACTIVE
    ‣Load is finished, and main thread work is done
    ‣Consistently interactive

    View Slide

  16. TIME TO
    INTERACTIVE

    View Slide

  17. SPEED INDEX
    ‣Calculated value
    ‣Average time at which visible parts of the page are displayed
    ‣How quickly does the page approach visually complete?
    ‣Essentially the time it takes for average pixel to paint (milliseconds)
    https://sites.google.com/a/webpagetest.org/docs/using-webpagetest/metrics/speed-index

    View Slide

  18. SPEED INDEX
    https://sites.google.com/a/webpagetest.org/docs/using-webpagetest/metrics/speed-index

    View Slide

  19. SPEED INDEX

    View Slide

  20. HOW BROWSERS
    WORK: NETWORK
    DOWNLOAD
    1. Download index file
    2. Parse index file as it is downloading
    3. Prioritize critical content

    View Slide

  21. HOW BROWSERS WORK:
    PRIORITIZING CONTENT
    1. Highest
    ‣ Initial document
    ‣ CSS
    2. High
    ‣ Webfonts
    ‣ Script tags in the
    ‣ XHR
    3. Medium
    ‣ Script tags outside of the
    4. Low
    ‣ Images

    View Slide

  22. View Slide

  23. HOW BROWSERS WORK:
    PARSE / EXECUTE CSS & JS
    1. Browser parses and executes JS
    2. Will completely parse and execute JS in the head that is not
    async’d or deferred before rendering layout.
    3. Will execute synchronously or afterwards if JS is in the footer
    (or async’d or deferred).

    View Slide

  24. https://developers.google.com/web/fundamentals/performance/critical-rendering-path/constructing-the-object-model
    HOW BROWSERS WORK:
    CREATING THE CSSOM

    View Slide

  25. https://developers.google.com/web/fundamentals/performance/critical-rendering-path/constructing-the-object-model
    HOW BROWSERS WORK:
    CREATING THE DOM

    View Slide

  26. https://developers.google.com/web/fundamentals/performance/critical-rendering-path/render-tree-construction
    HOW BROWSERS WORK:
    CREATING THE RENDER
    TREE

    View Slide

  27. LAYOUT
    (AKA REFLOW)
    ‣Browser calculates how much space it takes to put elements on
    screen.
    ‣Calculates where to place the elements on the screen in relation
    to other elements and the viewport.
    ‣Expensive.

    View Slide

  28. View Slide

  29. PAINT
    ‣The process of filling in pixels.
    ‣Text, colors, images, borders, etc
    ‣Expensive.

    View Slide

  30. COMPOSITING
    ‣Multiple layers within browser get placed on the screen.
    ‣Think of these as Photoshop layers - they can easily be moved
    around
    ‣Cheap!

    View Slide

  31. MEASURING
    PERFORMANCE

    View Slide

  32. MEASURING PERF:
    DEVTOOLS AUDITS
    TAB
    1. Demo

    View Slide

  33. MEASURING PERF:
    DEVTOOLS
    PERFORMANCE
    1. Demo

    View Slide

  34. OPTIMIZATIONS

    View Slide

  35. OPTIMIZATIONS:
    NETWORK
    DOWNLOAD
    ‣Use less bandwidth
    ‣Limit the use of large images
    ‣Use responsive images
    ‣Limit network requests
    ‣ Especially if you’re not using HTTP/2 (aka h2)

    View Slide

  36. View Slide

  37. PRPL PATTERN
    ‣Push critical resources for the initial URL route.
    ‣Render initial route.
    ‣Pre-cache remaining routes.
    ‣Lazy-load and create remaining routes on demand.
    https://developers.google.com/web/fundamentals/performance/prpl-pattern/

    View Slide

  38. OPTIMIZATIONS:
    NETWORK
    DOWNLOAD
    ‣Use less bandwidth
    ‣Limit the use of large images
    ‣Use responsive images
    ‣Limit network requests
    ‣ Especially if you’re not using HTTP/2 (aka h2)

    View Slide

  39. View Slide

  40. View Slide

  41. View Slide

  42. RESOURCE HINTS
    ‣Link tags inserted in that tell the browser to reach out
    and download or connect to resources

    ‣ ‣ ‣

    View Slide

  43. PRELOAD IN ACTION
    ‣Preload Resource hints FTW

    View Slide

  44. View Slide

  45. PRECONNECT IN ACTION
    ‣Preconnect Resource hints FTW

    View Slide

  46. View Slide

  47. View Slide

  48. ALL TOGETHER NOW…

    View Slide

  49. START USING TODAY!

    View Slide

  50. PREFETCH
    ‣Prefetch links within the viewport, while the CPU is idle
    ‣For Drupal, use https://www.drupal.org/project/quicklink

    View Slide

  51. PREFETCHING
    LINKS

    View Slide

  52. LINKS ENTERING
    VIEWPORT

    View Slide

  53. OPTIMIZATIONS:
    NETWORK
    ‣Avoid chaining dependencies (eg. ES6 imports triggering file
    download, which triggers another file download etc)

    View Slide

  54. View Slide

  55. https://developers.google.com/web/fundamentals/performance/critical-rendering-path/constructing-the-object-model
    OPTIMIZATIONS:
    RENDERING

    View Slide

  56. WHAT IS THE
    CRITICAL PATH?
    ‣Anything and everything that prevents the webpage from
    rendering
    ‣ HTML
    ‣ CSS in the head
    ‣ JavaScript in the head
    ‣ Fonts!
    ‣You want to minimize everything that is in the critical path.

    View Slide

  57. CSS OPTIMIZATIONS
    ‣Avoid inlining images via Base64 encoding
    ‣Avoid large stylesheets
    ‣ Follow best practices and componentize your styles. Make them easy to
    delete
    ‣ Don’t worry about selector performance.
    ‣ Inline CSS for critical path
    ‣Split up monolithic stylesheets
    ‣ Chrome developer tools has a coverage tool that will help ID
    unused CSS (and JS).

    View Slide

  58. OPTIMIZE YOUR
    JAVASCRIPT
    ‣Less JavaScript the better!

    View Slide

  59. JAVASCRIPT
    MAIN THREAD
    EXECUTION

    View Slide

  60. https://medium.com/@addyosmani/the-cost-of-javascript-in-2018-7d8950fbb5d4
    2018 JAVASCRIPT
    PROCESSING TIMES

    View Slide

  61. OPTIMIZE YOUR
    JAVASCRIPT
    ‣Less JavaScript the better!
    ‣Identify unused code through Chrome DevTools coverage tool.
    ‣Identify third party scripts.
    ‣Code split
    ‣ Either automatically through build tool (webpack)
    ‣ or through (D7) drupal_add_js() or Libraries API (D8)
    ‣ Virtual DOM fixes this
    ‣Profile!

    View Slide

  62. PROFILING
    JAVASCRIPT
    1. Demo

    View Slide

  63. IDENTIFY 3RD
    PARTY SCRIPTS
    1. Demo

    View Slide

  64. KEY TAKEAWAYS
    (START DOING THIS TODAY!)
    ‣Learn how to identify performance issues
    ‣ Learn the metrics
    ‣ Practice measuring these
    ‣ Find the bottlenecks on your site!
    ‣Less JavaScript
    ‣Start using resource hints today!
    ‣ Preload your fonts!
    ‣ Async and then preload your scripts

    View Slide

  65. MAKE THE WEB A
    BETTER PLACE!
    Don’t let proprietary solutions win!

    View Slide

  66. “ THANK YOU!
    Mike Herchel
    Senior Frontend Developer at Lullabot
    @mikeherchel

    View Slide