You'd have to start by defining some things. Are we talking about AJAX request/response cycles being slow? Are we talking about SSR request/response cycles being slow? What was the app doing, CRUD? Something more interesting?

For reference, the Rails app that I am working on, almost literally right now, is responding to HTTP API requests, performing authentication and resource authorization, creating a background job (or 2 or 3), and posting an event to kafka, in 2-3 ms. This is on my work-issued dev laptop from 2016.

If I start hitting the SSR portions of this same app, I'm getting response times in the 70-80ms range pretty consistently across the 6 or so pages that I just hit to get a quick baseline. No front-end frameworks here. Just turbolinks, ERb, HTML, CSS, and sprinkles of ES6 (served via webpack(er)).

Here's the thing about performance: even "well written" code can be unperformant.

It could be a query that isn't optimised with an index in the db, it could be best practice code that doesn't work well in the context of your app, any number of things.

At my last job we had a page that looked to be very well written, but it was taking 30+ seconds to render the page. Turns out to be a method we were calling 10x too many, because someone had benchmarked it in isolation and it didn't have any performance impact. However in conjunction with some of the data that occasionally passed through that method, those 10x calls ended up being a couple of seconds each.

That's an extreme example but there's little things you can do everywhere on a rails app if you know what you're looking for, and I would expect this to be the case in any web framework.

have you tried Dinghy? Docker for Mac is exceptionally slow on OSX. i advise everyone to stay away from Docker for Mac and install Dinghy w/ xhyve instead.