Description

As the rules are handled sequentially, and they're most often written from general utility ones at the top to specific rules later down the list, the path instead of resolving the most specific redirect right away does a set of 301 + 302 ceremony to… add a default locale in one hop, then add a trailing slash in another hop… only then to resolve the actual effective redirect:

(and this is with correct https:// and www… already, otherwise there's more;D)

Ideally, the fixups would be done on the request evaluating the rules without the actual redirection, and applied with the effective rule — or somewhat "cached" before returning them, to "squash" the request/redirect evaluation if there are further hits for the response to be served. Basically some smarts that would check the resulting path again against the rules whether there's not more to be done before serving it.

There definitely would be ancient redirect rules that go through multiple hops as frozen in time and these are really not an issue — this mainly slows down common "vanity" short URL aliases for deeper pages or variable permalinks that are used from product or support surfaces that go through such exercise all the time.

Success Criteria

• Improved latency by eliminating multiple request–response cycles for trivial redirections.
• Possibility of either evaluating the rules from the most specific, or appending the common fixups to the effective redirection to serve in one response