Product Documentation



Radar forms the backbone of the data collection methodology.Radar uses a JavaScript script embedded within a content page or application provider’s pages to collect information about the performance and availability of a data center or delivery platform.

The Radar client is a JavaScript application that runs on customer web pages and inside mobile applications. Its core purpose is to gather network performance data used to drive intelligent routing decisions via Openmix, as well as provide optional plugins to enable other Intelligent Traffic Management services, such as Page Load Time, Page Resource Timing, and Video Playback Metrics.

The Radar client is full-featured, yet lightweight and unobtrusive.The client waits until after most of the page resources have downloaded before performing the bulk of its work, and all network communication is performed in an asynchronous manner wherever possible.

To make it as small as possible, the JavaScript is compiled with advanced optimizations using the Google Closure Compiler.Advanced optional features are delivered as plugins for customers opting to use them.

Radar Tag

The Radar tag can be integrated using a JavaScript snippet. To navigate to the Radar Tag page, do the following:

  1. Sign in to the Citrix Intelligent Traffic Management Portal.
  2. From the left navigation menu, select Radar > Javascript Tag.

Radar JavaScript Tag

The Radar Tag page opens.

If you haven’t configured the Radar tag yet, you will see an orange horizontal bar on the top of the screen telling you that Radar measurements were not detected.

This orange bar will also appear if the tag was not configured correctly.

Radar Tag

Alternatively, if the Radar Tag is working as expected, you will see a green horizontal bar telling you that Radar measurements were successfully obtained.

On this page you can select the tag version that is applicable to your usage and copy it to the clipboard.

Note: It is important to not change this JavaScript snippet. The code includes important information which if changed could create unexpected or unreliable behavior.

Integrating the Radar Tag

Integrating the Radar tag is relatively simple. All you need to do is add one of the JavaScript snippets below to your site markup. Place it in the HTML of the pages you want to measure. We recommend placing it at the bottom of page before the closing body tag </body>.

Default Radar Tag

This is the recommended version of the Radar tag. This version waits until the load event is complete before downloading and executing the Radar Client, ensuring that the load event is uninterrupted.

if (typeof window.addEventListener === "function") {
    window.addEventListener("load", function() {
        if (window.cedexis === undefined) {
            var radar = document.createElement("script");
            radar.src = "//"; // replace with user specific value

This version of the tag keeps the download of the Radar Client from blocking further parsing of the page, but executes it before the load event has fired. It is mainly for customers using Content Security Policy settings preventing the use of inline JavaScript. It is also for customers using the Video QoS plugin, where the Radar Client needs to load as early as possible.

<script src="//" async></script>

Recent Measurements

The Recent Measurements table allows you to view the latest measurements that were taken using Radar.

Radar Recent Measurements

Click on the Recent Measurements button. It gives you the following information:

  • Date and time when the measurement was taken in UTC.
  • Country where the measurement was taken.
  • The platform that was used for taking the measurement.
  • The ID of the platform.
  • The type of measurement taken i.e. Connect Time (in milliseconds), Response Time (in milliseconds), or Throughput (in Kilobits Per Second)
  • The actual value of the measurement in milliseconds (for connect time and response time) or Kilobits Per Second (for throughput).

Radar Tag

The Radar measurements bar will also appear in the Radar Dashboard page when you first log into the ITM portal.

Radar Dashboard

Integration with Mobile Apps

Integration with mobile apps takes place via wrappers around hidden web views that run the JavaScript client.This ensures that data collected in browsers and mobiles apps is consistent.

Instructions for integrating Radar with iOS app This following GitHub repository contains the wrapper code and step-by-step instructions for integrating Radar with iOS app:

Radar Runner for iOS

Instructions for integrating Radar with Android Android Radar is a client library that makes it easy to integrate Radar into Android apps. It can be found here:

AndroidRadar Library

Radar Tag Configuration

You can configure Radar on the Radar Tag Configuration page.

  1. Sign in to the Citrix Intelligent Traffic Management Portal.
  2. From the left navigation menu, select Radar > Tag Configuration.

Radar Navigation

The Radar Tag Configuration page opens. Here you can set various options to customize Radar measurements.The Radar JavaScript has parameters that you can customize to adjust timing and delay elements; number of tests completed by end-users for community and private measurements; and time out values to measure availability, etc.

Radar Configuration Options

The following table provides information on what the configuration options are and the default settings for each.When making changes, be sure to click Update Radar Settings at bottom of the screen to apply the changes.

Function Parameter Description Default Setting  
Timing Options Startup Delay The delay, in seconds, between the page onLoad event and when Radar records navigation timing. 2 Seconds  
    Repeat Delay The delay, in minutes, between measurement sessions.If the value is greater or equal to 5, the Radar tag will take additional measurements after each repeat delay interval.If the value is 0 the Radar Tag will not take any additional measurements. 5 Seconds
Protocol Options Always Allow Private HTTPS Measurements Allows Radar client to take HTTPS measurements even from an HTTP website. Takes measurements of platforms with URL protocols that match the page where the Radar client is running.  
    Allow private HTTP measurements on HTTPS connections. Allows Radar client to take HTTP measurements from an HTTPS website. Takes measurements of platforms with URL protocols that match the page where the Radar client is running.
Sample Rate Radar Sample Rate The percentage of pages where the Radar tag is activated to take measurements. Disabled  
Private Measurements Maximum Private Measurements per Page Load The maximum number of private platforms that Radar will measure per page load.** Auto*  
  Maximum Private Throughput Measurements The maximum number of throughput measurements of private platforms per page load.** 4  
Community Measurements Maximum Community Measurements per Page Load The maximum number of community platforms that Radar will measure per page load.** Auto*  
  Maximum Community Throughput Measurements The maximum number of throughput measurements of community platforms per page load.** 4  

*Auto means that Intelligent Traffic Management determines how many platforms should be measured for a certain session, based on the end user’s location. We try to measure more platforms per session for small networks, where data is sparse, rather than from large networks, where it is dense.

**This is the maximum number of measurements attempted per session.For example, Radar could measure 4 private platforms per session, all of them being configured to measure both RTT and throughput. But if Maximum Private Throughput Measurements is set to 2, then the client will stop including the throughput measurements after measuring the first 2 private platforms.For the final two platforms, it will only measure RTT.

Timing options allow you to set the length of time that Radar should wait before starting to take measurements.

Note: Startup Delay is in seconds, while Repeat Delay is in minutes.

Radar Timing Options

Protocol Options

Normally, the Radar client only measures platforms with URLs whose protocols match that of the the page where it is running.These options allow you to override that behavior for private platforms.For example, enabling “Always Allow Private HTTPS Measurements” allows the client to measure from, while “Always Allow Private HTTP Measurements” allows the client to measure from

These options should generally be avoided except for extreme use cases.The best way to ensure that you’re getting adequate private measurement density is to have your platforms configured to measure the platforms and protocols that you actually use in production (and no more), and to have the Radar tag deployed on as many production pages as possible.We sometimes refer to this as “Putting Radar where it’s needed.”

Radar Protocol Options

Sample rate enables you to set a percentage of web pages (viewed by users) to collect measurements from.For example, if your website gets a 100,000 page views a day, and you set a 5% sample rate, Radar will only collect measurements from 5% of the 100,000 page views.

Radar Sample Rate

Private measurements

These settings apply to measurements of your private platforms. Private platforms are those that you set up in the Platforms section to measure specific CDNs, cloud providers, and other parts of your infrastructure. See Platforms section for more information.

Radar Private Measurements

This option allows you configure Radar’s behavior when providing information back to the community.

Radar Community Measurements

Turn Off Radar Testing

If there is a requirement to quickly turn off Radar measurements should something unexpected occur, you can do so within the Portal to avoid emergency code changes to your site.

On the Radar Tag Configuration page, switch off Private Measurements, Community Measurements or both by clicking the Enabled toggle button to Disabled.

Click Save Radar Configuration to confirm the changes.The changes may take a minute or two to propagate after which Radar measurements will stop.

Radar Toggle Private Measurements Radar Toggle Community Measurements

Radar Client Methodology

A fundamental dimension of client behavior is the session. All data that the client sends is associated with a session. Sessions are created by making a call to Citrix servers, known as the initialization request. Sessions expire rather quickly, helping to ensure that only valid Radar data is accepted. Because of this feature, Radar measurements always come in batches associated with their session transaction ID, and we often refer to a “Radar session” to describe the measurements associated with it.

Radar session

A Radar session is the main unit of work that the client performs. It consists of a request to Citrix servers to obtain customer configuration and a set of platforms to measure, followed by requests to measure those platforms, and report the results.These take place in an asynchronous and serialized fashion, so that only one request takes place at a time.A typical session completes in under 10 seconds.

Probe Types

Every report that the client sends has an associated probe type, which tells the system what kind of measurement it is and how to treat it.

Cold Start

Cold start probes are intended to allow services to warm their caches. Although there is a measurement value associated with this probe.We use the cold start probe to determine whether the provider is available.

If a platform is not configured to perform a cold start probe, we use the results of the RTT probe in place of a cold start report to provide availability metrics.

Similarly, for dynamic objects that measure site acceleration services, the client downloads the small test object once and reports the measurement value for both cold start and response time.

Test Object Definition
Standard Using Resource Timing timestamps: responseStart - requestStart
Dynamic Using Navigation Timing timestamps: responseEnd - domainLookupStart
Test Object Interval API Description
Standard responseStart - requestStart Resource Timing The time for a single packet to be returned in response to an HTTP request.
Dynamic responseEnd - domainLookupStart Navigation Timing The time for a request to be served, including connection time, DNS lookup time and response time based on a small test object.
Test Object Interval API Description
Standard File size (kilobytes) * 8 / (responseEnd - requestStart) Resource Timing The throughput measured (kilobits per second) for an entire request and response based on a large test object download.
Dynamic File size (kilobytes) * 8 / (responseEnd - domainLookupStart) Navigation Timing The throughput measured (kilobits per second) for an entire request and response based on a large test object download. Usually does not include connection time or DNS lookup time in the event that a small test object was already downloaded.

Test objects are files that are hosted on platforms and downloaded by the client to generate measurements. This section describes the different kinds of test objects that the client supports. Not all object types apply to every platform.


The standard test objects are media, which the client downloads by setting the src attribute on an Image object. Once downloaded, the client uses the Resource Timing API to gather performance data. These test objects should be served with the Timing-Allow-Origin response header. See the Timing-Allow-Origin Header section for more information.

Standard Small

The standard small test object is a single pixel image file, generally used when the client needs to make a lightweight network request.

The standard small test object is used in the following use cases:

  • Non-dynamic cold start probes
  • Non-dynamic round trip time probes
Standard Large

The standard large test object is a 100KB image file used to measure a platform’s throughput.

Large Object Naming: To calculate throughput, the client needs to know the size of the test object.The client determines the file name by looking for KB somewhere in the file name; r20-100KB.png, for example.Customers can measure image files of different sizes as long as the name contains the file size in the same manner, e.g.myimage-2048kb.jpg.


Dynamic test objects are used to measure the performance associate with site acceleration services. Each is an HTML file containing JavaScript capable of gathering timestamps from the Navigation Timing API and posting them to the parent page. The client downloads the test object using an iframe and obtains these timestamps, which it uses to calculate measurements.

Difference between dynamic and standard test objects:

For standard Radar measurements, we try to isolate only the primary request activity associated with downloading test objects, whereas for site acceleration services our goal is to measure more of the activity. Therefore DNS lookup and connection time is included as well. Also, dynamic measurements are intended to measure the request performance when hitting the service origin, not just an edge cache.

In the Portal, you can choose this methodology by doing the following:

  • From the left navigation menu, go to Platforms.
  • Click the Add Platform icon on the top right corner of the page.
  • Go to Private Platform > Category > Dynamic Content.
  • In the Radar Test Objects dialog box, click the Customize Probes check box.
  • Enter the Response Time and choose Webpage Dynamic from the Object Type drop-down list.

The dynamic small test object is used to measure:

  • Cold start for site acceleration services
  • Round trip time for site acceleration services

Dynamic Large

The dynamic large test objects is the same as the dynamic small test object, except that it includes 100KB of padding data designed to be difficult to compress.

It is used to measure throughput for site acceleration services.


The iNav test object is a static HTML file containing JavaScript able to perform a number of tasks. The client indicates which task it would like performed by including query string parameters in the URL that loads the HTML file in an iframe. The iNav test object supports the following use cases: iNav cold start iNav round trip time


The iUNI test object is used to detect the UNI value associated with a set of Radar measurements for a platform (the other method being CORS AJAX which doesn’t require a separate test object).


The AJAX GET methodology can generally be used with any URL that the customer wants to measure, provided that it is served with the Timing-Allow-Origin header and an appropriate Access-Control-Allow-Origin header. In the Portal, you can choose this methodology by doing the following:

  • From the left navigation menu, go to Platforms.
  • Click the Add Platform icon on the top right corner of the page.
  • Go to Private Platform > Category > Dynamic Content.
  • In the Radar Test Objects dialog box, click the Customize Probes check box.
  • Enter the Response Time and choose AJAX (GET) from the Object Type drop down list.

Timing-Allow-Origin Header

The Timing-Allow-Origin response header is required in order to permit JavaScript access to the low-level timing data supplied by the Resource Timing API. The recommended setting is Timing-Allow-Origin: *, which indicates that permission to access the resource’s timing data should be granted to JavaScript running on any domain.

Radar Reports

Radar reports provide powerful visibility into the dynamic data collected through the Radar Tag.Each report is defined below, but here are important aspects of all of the reports:

Primary and Secondary Dimensions


The primary dimension of the chart is selected through a drop-down selection list above the chart.Use this as a powerful pivot on the report.A secondary dimension can be chosen as well to further refine the reporting.

Visualization Background Toggle

Background Toggle Dark Background Toggle

Charts are set to a white background by default.Toggle the background to a dark color for high contrast monitors using the background toggle.

Data Export

Data Export

In addition, the end-user is able to download the Chart and Table data via the download link at the top of the report.

Filter: Report Time Range

Time Range

The Radar reports can be generated with a time range of Last 60 Minutes, Last 24 Hours, Last 48 Hours, Last 7 Days, Last 30 Days, or a custom range.The default view is the Last 24 Hours.

Filter: Platform and Location


The reports vary slightly in terms of which filters are appropriate based on the data.The following are the most common:

  • Platform – Select one or more platform (provider) to include.
  • Continent – Select one or more continent to include.
  • Country – Select one or more country to include.
  • Region – Select one or more geographic region (where applicable) to include.
  • State – Select one or more geographic state (where applicable) to include.
  • Network – Select one or more network (ASN) to include.

Filter: Resources

  • Data Source - Include data from the entire Radar Community or from your site visitors only.
  • Location Source - Select the Client IP or the Resolver IP as your location source.
  • Radar Client Type - Select the Radar Client Type as a JavaScript Tag, iOS SDK, or Andriod SDK.


My Page Views Geo Location Report

This report shows the volume of Page Views for each country.This map view can be viewed over time (based on the time range chosen for the report) by selecting the ‘Play’ button at the bottom of the chart.

My Page Views Geo Location Report

Performance Report

This report shows the trend of performance for each of the Platforms defined.

Performance Report

Statistical Distribution Report

This report shows the statistical breakdown for each of the Platforms defined for the account.

Statistical Distribution Report

Single Platform Geo Location Report

This report shows the distribution of Radar traffic by country over time for a single platform at a time.

Single Platform Geo Location Report

Single Platform Statistical Distribution Report

This report shows the distribution of Radar traffic over time by response time.

Single Platform Statistical Distribution Report