Having just added some fragment caching as well as cache headers (basically cache do...end around view fragments and some fresh_when in controllers) - at a glan

Having just added some fragment caching as well as cache headers (basically cache do...end around view fragments and some fresh_when in controllers) - at a glance it looks like there's a lot of low-hanging fruit for increasing performance in the thredded code-base. The project i adjusted was an old rails 3.2 code base, and in addition to fixing some missing db indeces - the caching sped things up significantly (10-100x, from atrocious to acceptable). I sometimes get the feeling that no-one using rails ever read the cache section in the guide. https://guides.rubyonrails.org/caching_with_rails.html https://guides.rubyonrails.org/caching_with_rails.html Caveat: there may be callbacks and authorization hooks in thredded that hamper this approach in practice. For a new project i would probably try and go with "fresh when" (http caching) and varnish or fastly.com in front. But fragment caching can make a lot of difference too. More than I expected. Ed: although I can see why it might be missing - the upstream demo feels plenty snappy - so for most uses, extra caching might just be extra complexity for little gain.