Incredibly fast web apps

Get your web app extremely fast by optimizing it outside of the app itself. If done right, it’s possible to reduce your loading times to less than 50 ms by using a CDN in front of your app, moving some kind of code into JavaScript, setting the right headers, and using localStorage.

I gave this talk at RubyConf Philippines (http://rubyconf.ph) and RUG-B (http://www.rug-b.de).

Video recording: https://www.youtube.com/watch?v=V7ul3yIhz4o&index=8&list=PL0mVjsUoElSHRZWXz3VPo0vRUm75hNP7j

Follow me on Twitter for updates about speed, Ruby, design, CSS and Sass as well as living style guides: https://twitter.com/hagenburger

Transcript

1. Incredibly fast
   web apps
   WITHOUT TOUCHING RUBY (TOO MUCH)
   @hagenburger #rubyconfph
   

   View Slide

2. nico@hagenburger.net
   email
   twitter
   blog
   first name
   last name
   

   View Slide

3. View Slide

4. https://instagram.com/asaaki/
   https://instagram.com/p/54xnvhp9Hy/
   ORGA NI Z ER / DE SIG NE R
   

   View Slide

5. livingstyleguide.org
   @LSGorg
   OP E N -S OURCE DE VE LO PE R
   

   View Slide

6. ME NTOR
   https://instagram.com/langziehohr/
   https://instagram.com/p/5198hBm7hS/
   

   View Slide

7. FRE E LA NC E DE V E LO P ER /D ES IG N ER
   Front-end developer
   designer
   Ruby lover
   

   View Slide

8. I heard Ruby is slow.
   

   View Slide

9. Might not be true.
   

   View Slide

10. Thank you for all the
    speed improvements
    in Ruby.
    

    View Slide

11. Thank you so much!
    

    View Slide

12. But let’s have a look
    on how to improve
    speed without
    touching Ruby.
    

    View Slide

13. Which part of our
    application 

    actually is slow?
    

    View Slide

14. Ruby?
    

    View Slide

15. Rails?
    

    View Slide

16. The database?
    

    (rather your queries)
    

    View Slide

17. Your connection?
    

    View Slide

18. Your location?
    

    View Slide

19. The Great Firewall?
    

    View Slide

20. Blocking elements

    in HTML?
    

    View Slide

21. Flickering?
    

    View Slide

22. HTML
    

    View Slide

23. Just use ERB.
    Everything else is slower.
    (Except helpers written in pure Ruby maybe)
    

    View Slide

24. Put layout CSS
    into the HTML
    

    View Slide

25. … and load the CSS 

    step by step
    https://jakearchibald.com/2016/link-in-body/
    

    View Slide

26. Set image sizes

    Set CSS width/height
    

    View Slide

27. Faster delivery
    

    View Slide

28. Loading jQuery via
    Google?
    ★ Yes, it’s faster.
    ★ But in China:
    

    View Slide

29. Don’t just focus on
    cached assets
    ★ Cache everything (at least for a while)
    ★ Act like you have a static good old HTML
    page like it’s 1999
    

    View Slide

30. Rails page caching
    

    View Slide

31. Downsides
    ★ More than one server?
    ★ More than one domain?
    ★ Uses the same server
    

    View Slide

32. Use Varnish
    https://www.varnish-cache.org
    

    View Slide

33. Downsides
    −Do you know how to do it?
    −Do you want to maintain it?
    −Is it close to your customers?
    

    View Slide

34. Use a content
    delivery network 

    as a service
    

    View Slide

35. CDN providers
    +They know what they do
    +They have several servers
    +They might deliver from many locations
    −They can get expensive
    −You might hit their limits easily
    

    View Slide

36. YOUR
    CLIENTS
    Be close to
    

    View Slide

37. The world
    

    View Slide

38. The world
    

    View Slide

39. Our requirements
    https://www.cloudflare.com/features-cdn/
    

    View Slide

40. CDN locations
    ★ Just Europe and North America?
    ★ “The whole world”?
    ★ In or outside the Great Firewall?
    ★ Including the Philippines?
    ★ Akamai and MetaCDN seem to
    http://www.metacdn.com/cdn-coverage
    http://www.mb.com.ph/pldt-partners-with-akamai-for-content-delivery-network-solutions/
    

    View Slide

41. Cache synching
    ★ Do all servers world wide need to request
    the page from your server?
    ★ Or do they share their cache?
    

    View Slide

42. Purge requests
    

    View Slide

43. Purge requests
    ★ Clears the cache at the CDN for a specific
    URL
    

    View Slide

44. Purge requests
    ★ CloudFlare has strict API limits
    ★ Pages won’t get purged after you hit
    them
    ★ CloudFront charges per purge request
    ★ Can get pretty expensive
    ★ CloudFlare purges within 30 sec, 

    CloudFront might take 30 min
    

    View Slide

45. User sessions
    

    View Slide

46. CDNs don’t know
    about your user
    sessions.
    

    View Slide

47. Any page containing
    current_user
    is hard to cache
    

    View Slide

48. This is a lot of work.
    

    View Slide

49. Include both
    versions:
    – Logged in content
    – Logged out content
    

    View Slide

50. View Slide

51. Don’t show things,
    hide the others.
    

    View Slide

52. The opposite of
    display: none
    might be:
    display: flex
    

    View Slide

53. User-related content
    

    View Slide

54. View Slide

55. Complicated?
    

    View Slide

56. Speed FTW!
    

    View Slide

57. Log in/out
    ★ Just switch the CSS class
    ★ No need to reload the page
    free
    Bonus!
    

    View Slide

58. Database
    

    View Slide

59. Look at slow queries
    ★ Watch your logs
    ★ Use indexes
    ★ Cache calculated values (e.g.: a score)
    ★ Experiment with queries
    

    View Slide

60. Some (Rails)
    application tipps
    

    View Slide

61. Use remote partials
    

    View Slide

62. Remote partials
    ★ Cache the main HTML page (e.g. an article)
    ★ Load dynamic content separately:
    ★ Recommended articles
    ★ Comments
    ★ Global elements
    ★ Page and partials can have different
    caching strategies
    

    View Slide

63. Loading remote
    partials
    

    View Slide

64. Don’t check for a
    session
    ★ Skip before actions etc.
    ★ Most cached pages do not rely on a
    session
    ★ Some uncached requests just don’t need it
    

    View Slide

65. Asset hashes
    ★ /assets/my-a24d3.css
    ★ Will remain in cached HTML pages
    ➤ Requires purging the whole cache
    ★ Possible solution: Use redirects
    ➤ /a/assets/my.css > /assets/my-
    a24d3.css
    

    View Slide

66. Helpers
    ★ Sometimes plain HTML is faster
    ★ Especially in blocks
    

    View Slide

67. Cache HTML
    ★ Rails has a cache helper. Use it.
    

    View Slide

68. No Coffee-Script 

    in views
    ★ Do you really want to compile this with
    each request?
    

    View Slide

69. Avoid too many URLs
    ★ /photos vs. /photos/
    ★ /photos vs. /photos?size=m
    ★ /photos vs. /photos?utm_campaign=…&…
    ★ /photos?size=m&page=2 vs.

    /photos?page=2&size=m
    

    View Slide

70. CSRF token
    ★ Don’t include in the HTML on cached
    pages
    ★ (I should test all this in Rails 5)
    

    View Slide

71. Summary
    

    View Slide

72. Within Ruby*
    ★ Cache results/partials
    ★ Sometimes avoid blocks in HTML
    ★ Prefer ERB over Haml/Slim/…
    ★ Skip unused code
    * from a front-end coder’s perspective
    

    View Slide

73. Caching
    ★ Cache everything possible
    ★ Choose a CDN matching your
    requirements
    ★ Load dynamic parts via XHR
    ★ Be aware uncached requests remain slow
    ★ Set the right headers for the browser
    

    View Slide

74. JavaScript
    ★ Don’t use Coffee-Script in views
    ★ Use Vanilla.js if possible
    ★ Use it for session handling and displaying
    content
    ★ Be aware of Safari’s private mode!
    

    View Slide

75. Concepts
    ★ Build a MVP
    ★ Less features, more speed :)
    free
    Bonus!
    

    View Slide

76. That’s not 

    all you can do.
    

    View Slide

77. It’s just a good start.
    

    View Slide

78. Remember:
    Only speed up
    bottlenecks
    

    View Slide

79. As fast as Ruby 

    will get—not calling
    Ruby at all will always
    be faster.
    

    View Slide

80. nico@hagenburger.net
    email
    twitter
    blog
    first name
    last name
    Salamat & thank you!
    I’M NOT HIRING. BUT TALK TO ME IF YOU WANT TO WORK WITH ME ON SOMETHING.
    

    View Slide