$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
Tweet

More Decks by Nico Hagenburger

Other Decks in Programming

Transcript

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

    View Slide

  2. [email protected]
    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. [email protected]
    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