Has anyone applied an autoresearch loop (successfully or not) to a Ruby project outside of Shopify yet? I would like to cover it in my RubyKaigi talk.

The #1 most important performance work in almost any web app is converting full navigations into SPA/route changes/Turbo Drive clicks. You are converting a ~4 second experience into a 400ms experience every single time. Nothing else comes close.

Super common mistake I see in Ruby setups: don't allocate more than 1 CPU core to background job containers. You're only running one process in there (usually) so there's no reason to allocate > 1 core.

After ~9 months of experimentation (synthetic and in prod), I can say definitively that MALLOC_CONF has no measurable effect on any Ruby workload that I've seen. Don't bother.

50% of what I'm doing at clients these days is addressing unclear expectations of what queue latencies are allowed to be in background work. Almost no one has the proper suite of alerts and observability, queues routinely ballooning without anyone realizing.

It's pretty rare these days to be on a version this old, but if you're still running Ruby 3.1 in production: it's worth upgrading to 3.2+ purely to get YJIT.

LCP is not a good top-level frontend metric to base your entire frontend perf efforts around _unless_ you are specifically targeting search rankings. LCP is not captured on route change/SPA nav or on Safari at all, which means ~50%+ of clicks go unmeasured.

Datadog's continuous profiling product is now best-in-class. Took them a while but Ivo Anjo has really put in a ton of work here for Ruby and the profiles you get now are so, so good. Being able to see gc activity (as well as the reason!) for GC is so cool.

LLM slopcannons are putting pressure on top of already broken software dev team cultures. The problem isn't the slop generator, so much as your process was only handling low volumes of human-generated slop until now.