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/

Transcript

1. stefan.wintermeyer@amooma.de
   

   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
    stefan.wintermeyer@amooma.de
    Please join us at https://www.vutuv.de
    

    View Slide