I have a page that redirects to another page:
//www.domainthatredirect.com/mypage
goes to:
//www.finaldomain.com/mypage
I am trying to figure out how will behave the prerender markup below:
<link rel="prerender" href="//www.domainthatredirect.com/mypage">
Will the browser follow the redirect and prerender the final page?
Disclaimer: I haven't tested your scenario in any modern browser.
¯_(ツ)_/¯
The specification does not say what UAs should do if a linked resource with a preload or pre-render hint requires following a redirection.
The behaviour of <link rel="prerender" is specified in the WHATWG HTML Living Specification (emphasis mine):
https://html.spec.whatwg.org/multipage/links.html#link-type-prerender
[...]
The
prerenderkeyword indicates that the specified resource might be required by the next navigation, and so it may be beneficial to not only preemptively fetch the resource, but also to process it, e.g. by fetching its subresources or performing some rendering. User agents must implement the processing model of theprerenderkeyword described in Resource Hints.
The linked Resource Hints specification is on the W3C's site and is (as of November 2020) still in the Editor's Draft phase (so it is not canon yet).
https://w3c.github.io/resource-hints/#prerender
The
prerenderlink relation type is used to identify a resource that might be required by the next navigation, and that the user agent SHOULD fetch and execute, such that the user agent can deliver a faster response once the resource is requested in the future.[...]
The user agent MAY:
[...]
Abandon prerendering due to high cost or resource requirements - e.g. high CPU or memory usage, expensive data access, and so on.
Abandon prerendering due to the type or properties of the fetched content: [...]
The user agent may implement other strategies
If I were a PM for a privacy conscious web-browser vendor1 I would only preload and/or pre-render pages that came from the same origin2 as the source webpage, which means that any URIs to different origins - or if a same-origin request resulted in a HTTP redirection to an off-site resource - then the link (or redirection) would not be followed.
That said, remember that <link rel="preconnect", <link rel="prefetch", <link rel="preload", and <link rel="prerender" are all just hints to UAs. You must not require nor assume that browsers will honour those hints.
1 Apple and Mozilla are both demonstrably privacy-conscious browser vendors, and Apple has a monopoly on browsers for iOS. Google will gladly tell you're they're defending their users' privacy but their business-model means they have conflicts-of-interest. Microsoft's Edge, despite now being based on Chromium and given that Microsoft shares Apple's position as a platform-vendor without a strong incentive to spy on monetize their users' habits, is actually the least private browser at-present.
2 An "origin" is a tuple of ( URI Scheme / Protocol ) + ( Host Address ) + ( Port ). Conceptually each Origin is analogus to a separate "website" (though often the same website is accessible through different hostnames and port-numbers, this is disallowed under current Same-Origin/Cross-Origin rules to protect users from malicious websites. See RFC 6454 for more details.