Since you are getting 403 due to default GET servlet, this means that the URL is not mapping to a resource. It is possible the "provided navigation option" was generated wrong. It is possible the trailing / is to blame and could be checked first. Additionally see if the servlet (as a component) and the bundle are active.

Found the answer, but it took a while dealing with environments with restrictive permissions.1) The dispatcher filter rules were correct. 2) No need to remove the vanity URLs section3) Found that the DNS routed the traffic to a different vhost in this multi-vhost environment4) And this routed the traffic subsequently to wrong dispatcher farm. In short, dispatcher behaved correctly as expected - meaning it got a 404 in filters and thus routed to vanity URLs - just that it happened in the wrong di...

@sashi_mulugu does dispatcher treat xml extensions as vanity URLs? All other URLs are not treated like this and are getting rendered fine.

You might want to uncheck isDeep property. This is explained here - https://helpx.adobe.com/experience-manager/6-3/sites/administering/using/tc-rules.html

You would want to verify what @Jaideep_Brar suggests. Assuming you are talking about page load time in your "site", there might be other factors at play as well Cache ratioSpecific component logicVolume of trafficClientlibs load time in browserbreaking JSIf in author, also look at the "developer mode". It should give you component wise breakdown on loading time.

It is possible Chrome would be expecting some headers that is missing in 6.5 vs 6.4. You might want to scan the response headers in 6.4 vs 6.5 and find if something might be missing.