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

Incredibly fast web apps

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

Nico Hagenburger

April 07, 2016

More Decks by Nico Hagenburger

Other Decks in Programming


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

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

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

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

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


    ER /D ES IG N ER Front-end developer designer Ruby lover
  8. I heard Ruby is slow.

  9. Might not be true.

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

  11. Thank you so much!

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

    without touching Ruby.
  13. Which part of our application 
 actually is slow?

  14. Ruby?

  15. Rails?

  16. The database? 
 (rather your queries)

  17. Your connection?

  18. Your location?

  19. The Great Firewall?

  20. Blocking elements
 in HTML?

  21. Flickering?

  22. HTML

  23. Just use ERB. Everything else is slower. (Except helpers written

    in pure Ruby maybe)
  24. Put layout CSS into the HTML

  25. … and load the CSS 
 step by step https://jakearchibald.com/2016/link-in-body/

  26. Set image sizes
 Set CSS width/height

  27. Faster delivery

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

    in China:
  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
  30. Rails page caching

  31. Downsides ★ More than one server? ★ More than one

    domain? ★ Uses the same server
  32. Use Varnish https://www.varnish-cache.org

  33. Downsides −Do you know how to do it? −Do you

    want to maintain it? −Is it close to your customers?
  34. Use a content delivery network 
 as a service

  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
  36. YOUR CLIENTS Be close to

  37. The world

  38. The world

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

  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/
  41. Cache synching ★ Do all servers world wide need to

    request the page from your server? ★ Or do they share their cache?
  42. Purge requests

  43. Purge requests ★ Clears the cache at the CDN for

    a specific URL
  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
  45. User sessions

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

  47. Any page containing current_user is hard to cache

  48. This is a lot of work.

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

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

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

  53. User-related content

  54. None
  55. Complicated?

  56. Speed FTW!

  57. Log in/out ★ Just switch the CSS class ★ No

    need to reload the page free Bonus!
  58. Database

  59. Look at slow queries ★ Watch your logs ★ Use

    indexes ★ Cache calculated values (e.g.: a score) ★ Experiment with queries
  60. Some (Rails) application tipps

  61. Use remote partials

  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
  63. Loading remote partials

  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
  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
  66. Helpers ★ Sometimes plain HTML is faster ★ Especially in

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

  68. No Coffee-Script 
 in views ★ Do you really want

    to compile this with each request?
  69. Avoid too many URLs ★ /photos vs. /photos/ ★ /photos

    vs. /photos?size=m ★ /photos vs. /photos?utm_campaign=…&… ★ /photos?size=m&page=2 vs.
  70. CSRF token ★ Don’t include in the HTML on cached

    pages ★ (I should test all this in Rails 5)
  71. Summary

  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
  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
  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!
  75. Concepts ★ Build a MVP ★ Less features, more speed

    :) free Bonus!
  76. That’s not 
 all you can do.

  77. It’s just a good start.

  78. Remember: Only speed up bottlenecks

  79. As fast as Ruby 
 will get—not calling Ruby at

    all will always be faster.
  80. nico@hagenburger.net email twitter blog first name last name Salamat &