Cacher is the code snippet organizer for pro developers

There's an obvious goal to have a product feel quick while being navigated. This is important, but is usually obvious when it isn't achieved.

Even more important is to avoid H12 Heroku errors, unnecessary request queuing at the dyno. In combination these can lock up a dyno and result in a single or multiple dynos timing out every request sent to it. This 'zombie dyno' is an extremely high impact issue and very difficult to diagnose and fix. Achieving the following goal will help avoid this hellish scenario.

Practically Speaking

The common case for a page should be a server response within 250 ms. Sure there are pages where caching and/or other tradecraft will need to be utilized to achieve this result. The edge cases of these scenarios should still result in responses under 500ms.

A common example is fragment caching with a cold cache. That scenario happens commonly enough (and buffering a caching outage needs to be feasible) that even without caching a response will happen within 500ms.

The true 0.3% corner cases of response times should still be under 1500ms.

Keeping these numbers in mind throughout development, and testing against them with multiple scenarios in development is important for the long-term health of an application. Doing this as a part of iterative development is much more efficient than coming back later to address performance. 'Get it working then make it fast' is a fine adage, but only if the optimization is done during the initial development. We know from experience that if we move on to another feature before we optimize to an acceptable level, we are creating exponentially more work for ourselves in the long run.