This article explains browser content redirection feature in citrix.

Feature Requirements

Client operating system

• Windows 7, 8.x,or 10, and Internet Explorer 11
• Citrix Receiver for Windows 4.10 or higher
• Citrix Receiver for Linux 13.9 or higher

XenApp / XenDesktop 7.16 or higher

• VDA operating system: Windows 10, Windows Server 2012 R2, Windows Server 2016
• Browser on the VDA: Internet Explorer 11 (this is the only supported browser and version)

What is Browser Content Redirection?

Browser Content Redirection prevents the execution/rendering of web pages on the VDA side by creating a corresponding browser instantiated by Receiver that will be responsible for rendering the URL. The browser runs on the endpoint device instead of on the VDA. It will utilize endpoint CPU, GPU and RAM resources and will not require any graphics, video, or animation to be rendered over Thinwire.

Why is Browser Content Redirection Required?

We see very high CPU utilization caused by web browsing on the VDA side.  Most problematic are sites incorporating HTML5 video elements.  These can be handled by the HTML5 Video Redirection feature, except that it does not yet handle videos streamed using Media Source Extensions (MSE).  Sites may eventually incorporate Encrypted Media Extensions (EME), also, which could further complicate video redirection efforts. The most-noticed and complained-about site is YouTube, which is particularly hostile to our HTML5 Video Redirection feature, as it does complicated JavaScript processing and uses MSE extensively.

How Browser Content Redirection Works

This feature is an extension of existing HTML5 Video Redirection components to add support for entire-browser-content redirection, instead of replacing a single video. It is able to manipulate the browser in a way that can intercept page loads, inject our script, monitor for changes to browsing history, and amend it to match the client side.

Interaction between VDA and Receiver

1. VDA remotes IE 11 Web Browser instance to Receiver via Thinwire. User navigates to a webpage whitelisted in the Studio Policy Browser Content Redirection ACL Configuration. If the webpage has a matching entry in the Browser Content Redirection Blacklist Configuration Studio policy, the viewport will not be redirected to the client.
2. The procedure for redirecting webpages is initiated by JavaScript, communicating with an agent in the user’s VDA session over Secure WebSockets. HdxVideo.js is the javascript injected on the whitelisted webpage with the help of Internet Explorer Browser Helper Object (BHO) as the user browses the web on IE11 in the VDA. BHOs are a plugin model for Internet Explorer that provides hooks for browser APIs and allow the plugin to access the Document Object Model (DOM) of the page to control navigation.
3. VDA sends instructions to Receiver over a Virtual Channel to instantiate the local overlay browser (HdxBrowser.exe) present on the client.
4. Client-Side HdxBrowser.exe retrieves and renders content locally, using client resources instead of those of the VDA.

HTTP/S content can be retrieved directly by Receiver, or through the VDA (see scenarios 2 and 3 below).

There are three scenarios of how Citrix Receiver fetches content:

1. Server fetch and server render: There is no redirection because you didn’t whitelist the site through Citrix Studio policies or the redirection failed. We fall back to rendering the webpage on the VDA .High CPU, GPU, RAM, and bandwidth consumption on the VDA.
2. Server fetch and client render: Citrix Receiver contacts and fetches content from the web server through the VDA using a virtual channel. This option is useful when the client doesn’t have internet access. Low CPU, GPU and RAM consumption on the VDA, but bandwidth is consumed on the ICA virtual channel. A Proxy Server is required for this scenario (see Policy ‘Browser Content Redirection Proxy Configuration’).
3. Client fetch and client render: Because Citrix Receiver contacts the web server directly, it requires internet access. This scenario offloads all the network, CPU,GPU and RAM usage from your XenApp and XenDesktop Site.

Controlling Browser Content Redirection Fallback to the VDA

The existing Windows Media fallback prevention Studio policy supports BCR fallback behavior (as of XenApp And XenDesktop 7.17).

There might be times when client redirection fails. For example, if the client machine does not have direct internet access, an error response might go back to the VDA. In such cases, the Internet Explorer browser on the VDA can then reload and render the page on the server.

You can suppress server rendering of video elements by using the existing Windows media fallback prevention policy:

Set the Windows Media fallback prevention Studio policy to Play all content only on client or Play only client-accessible content on client:

• These settings block video elements from playing on the server if there are failures in client redirection.
• Setting this policy suppresses only the video elements and not the HTML content of the page. The HTML content is still rendered on the server.
• This policy takes effect only when browser content redirection is enabled and the URL that falls back is in the Access Control List policy.
• The URL can’t be in the blacklist policy

Posted in https://support.citrix.com/article/CTX230051

Fetching takes lot of network resources as it need to pull data(video or any content) from internet and render takes lot of cpu resource as it need to present it over browser. Ex, playing a youtube video. It need to pull video from internet and present it on browser.

More info here: https://docs.citrix.com/en-us/xenapp-and-xendesktop/current-release/multimedia/browser-content-redirection.html