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

WebPerformance Meetup in Cologne (Feb. 2017)

WebPerformance Meetup in Cologne (Feb. 2017)

At the WebPerformance Meetup in Cologne I presented this talk about how we tackle WebPerformance at https://www.vutuv.de

https://www.meetup.com/de-DE/cologne-germany-high-performance-website-optimization-group/events/236635872/

Stefan Wintermeyer

February 02, 2017
Tweet

More Decks by Stefan Wintermeyer

Other Decks in Technology

Transcript

  1. View Slide

  2. I’m not going to cover
    all the basics. I’m going
    to cherry pick 4 topics.
    To cover the basics:

    http://hpbn.co

    View Slide

  3. vutuv differentiates itself
    from other business
    networks by speed.

    View Slide

  4. Fully Loaded: 700 ms (DSL in Germany)

    View Slide

  5. We jump through
    hoops to achieve this.
    Make no mistake: This is not easy.
    Spoiler alert: We don’t use JavaScript.

    View Slide

  6. Why is speed important?

    View Slide

  7. Jakob Nielsen’s book
    „Usability Engineering“ from 1993
    Delay User reaction
    0 - 100 ms Instant
    100 - 300 ms Feels sluggish
    300 - 1000 ms Machine is working…
    1 s+ Mental context switch
    10 s+ I’ll come back later…

    View Slide

  8. Web Search Delay
    Experiment
    Type of Delay Delay (ms)
    Duration
    (weeks)
    Impact on Avg.
    Daily Searches
    Pre-header 100 4 -0.20 %
    Pre-header 200 6 -0.59%
    Post-header 400 6 0.59%
    Post-ads 200 4 0.30%
    Source: https://www.igvita.com/slides/2012/webperf-crash-course.pdf

    View Slide

  9. View Slide

  10. View Slide

  11. Network latency is
    paramount.
    Why?

    View Slide

  12. TCP
    Source: http://en.wikipedia.org/wiki/Transmission_Control_Protocol
    Latenz

    View Slide

  13. Download a 58 kB file from a US east cost server to a
    client in Frankfurt. Protocol: HTTP
    Roundtrip Time: 80 ms
    Zeit client server
    0 ms SYN -->
    <-- SYN,ACK
    80 ms ACK -->
    GET -->
    <-- 10 TCP Segmente (14.600 Bytes)
    160 ms ACK -->
    <-- 20 TCP Segmente (29.200 Bytes)
    240 ms ACK -->
    <-- 40 TCP Segmente (15.592 Bytes)
    320 ms ACK -->
    Time to download a 58 kB file: 320 ms

    View Slide

  14. TCP Slow-Start
    KB
    0
    55
    110
    165
    220
    Roundtrip
    1. 2. 3. 4.
    213
    99
    42
    14
    114
    57
    28
    14

    View Slide

  15. SSL adds at least 

    one roundtrip.


    HTTP/2.0 needs SSL.

    View Slide

  16. HTTPS
    KB
    0
    50
    100
    150
    200
    Roundtrip
    1. 2. 3. 4.
    199
    85
    28
    0
    114
    57
    28
    14
    SSL

    View Slide

  17. Above the fold target: 28 KB
    KB
    0
    50
    100
    150
    200
    Roundtrip
    1. 2. 3. 4.
    199
    85
    28
    0
    114
    57
    28
    14
    SSL

    View Slide

  18. Latency is king!
    Bandwidth is not important
    for normal websites.

    View Slide

  19. Frankfurt, Germany Sydney, Australia
    Sydney: https://www.webpagetest.org/result/170130_3H_S13/

    Frankfurt: https://www.webpagetest.org/result/170130_YJ_SRS/
    DSL

    View Slide

  20. Frankfurt, Germany Sydney, Australia
    Frankfurt: https://www.webpagetest.org/result/170131_CX_B7D/

    Sydney: https://www.webpagetest.org/result/170131_XZ_B7P/
    3G

    View Slide

  21. View Slide

  22. Dulles, VA, USA
    https://www.webpagetest.org/video/compare.php?tests=170131_QQ_BHG,170131_9F_BHH,170131_49_BHJ
    DSL

    View Slide

  23. How it’s done?

    View Slide

  24. Set a time budget
    and stick to it!
    Our time budget is 1 second for Germany.

    View Slide

  25. Start Render
    Document Complete

    View Slide

  26. Important:
    We can not control the
    network!

    View Slide

  27. What we can control:
    • Transfer Protocol (e.g. HTTP/1.1 vs. HTTP/2.0)
    • Compression (e.g. gzip vs. zopfli vs. brotli)
    • Amount of files
    • File size
    • Time the server needs to generate the HTML
    • Content (e.g. HTML, CSS, JavaScript, Images)

    View Slide

  28. View Slide

  29. File size
    Time on the server

    View Slide

  30. The Server

    View Slide

  31. We use the Phoenix Framework.

    www.phoenixframework.org

    View Slide

  32. Phoenix is about 

    10 times faster 

    than Ruby on Rails or Django.
    The functional programming language Elixir has a lot of more advantages,
    but today I’m only talking about speed.

    View Slide

  33. We avoid serving freshly
    generated HTML when
    not needed.
    Hard Drives are much cheaper than CPU.

    View Slide

  34. /var/www/vutuv/
    cache
    - index.html
    - index.html.gz
    users
    - xyz.html
    - xyz.html.gz
    No Cookie = Static Content

    View Slide

  35. 1,000,000 users x 28 KB
    = 26 GB

    View Slide

  36. Rendering a user’s profile: 50 ms.
    Serving a static file: less than 1 ms.

    View Slide

  37. The Avatars

    View Slide

  38. View Slide

  39. View Slide

  40. View Slide

  41. View Slide

  42. View Slide

  43. View Slide

  44. guetzli -quality 75 a.jpg /tmp/q75-a.jpg
    convert a.jpg /tmp/q75-a.jpg -fx
    'hypot(65-i, 65-j) < 65 ? u : v' new_a.jpg
    https://github.com/google/guetzli

    View Slide

  45. By that we save
    15-20% of file size.
    BTW: We optimize during off peak times.

    View Slide

  46. Compression

    View Slide

  47. /var/www/vutuv/
    cache
    - index.html
    - index.html.gz
    users
    - xyz.html
    - xyz.html.gz
    Always provide a
    compressed version of a
    static file.

    View Slide

  48. html-minifier --case-sensitive
    --collapse-boolean-attributes
    --collapse-whitespace
    --remove-comments
    --remove-optional-tags
    --remove-tag-whitespace
    --sort-attributes
    --sort-class-name
    --collapse-inline-tag-whitespace
    --conservative-collapse a.html > b.html
    Optimize before compress

    View Slide

  49. Use zopfli instead of gzip.
    https://github.com/google/zopfli

    View Slide

  50. For live content use brotli.
    https://github.com/google/brotli

    View Slide

  51. Inlining

    View Slide

  52. HTTP caching is good
    but for our time budget
    not good enough.

    View Slide

  53. We inline a lot.

    View Slide

  54. We inline all the CSS.

    View Slide

  55. We inline many
    images.

    View Slide

  56. View Slide

  57. View Slide

  58. Fill the Steps
    KB
    0
    50
    100
    150
    200
    Roundtrip
    1. 2. 3. 4.
    199
    85
    28
    0
    114
    57
    28
    14
    SSL

    View Slide

  59. Prefetch

    View Slide

  60. Analyse your workflow and
    prefetch stuff that you’ll
    need in the next step.

    View Slide

  61. View Slide

  62. We’re never done with
    optimizing vutuv.de

    View Slide

  63. Q&A
    [email protected]
    Please join us at https://www.vutuv.de

    View Slide