InfoSpace - CSR Best Practices and Tips
SDK Home | Client Side Results SDK - Home
Page last modified: 12 Feb 2018


With the explosion of internet browsers and JavaScript over recent years, it’s now easier to produce a site that does not work in every situation for every end user than it is to make one that works well. The following best practices and tips are intended to help avoid potential pitfalls, and possibly improve performance as well.

Best Practices for CSR

The following are best practice recommendations that can improve the overall performance of a site and avoid common pitfalls.

DNS Pre-Fetching

By performing DNS lookups early on in a page’s initialization will increase overall performance of a site. By adding these lines at the top of page, just below the opening <head> tag, it will allow modern browsers to pre-fetch DNS addresses for servers used by CSR, reducing the amount of time needed to load the CSR libraries.

<link rel="dns-prefetch" href="//" />
<link rel="dns-prefetch" href="//" />
<link rel="dns-prefetch" href="//" />
<link rel="dns-prefetch" href="//" />

So, the page would look like:


<link rel="dns-prefetch" href="//" />
<link rel="dns-prefetch" href="//" />
<link rel="dns-prefetch" href="//" />
<link rel="dns-prefetch" href="//" />

<title>Search Results</title>

<script type="text/javascript" src="//"></script>

Browser Support

We support IE7+. For Firefox and Chrome, we support the current version, and the most previous version (i.e., the current version - 1).

While we routinely check CSR against our set of supported browsers, even something as benign as an extra comma can cause IE7 to fail. One thing to do is look at JSLint or JSHint (a different take of JSLint) and ensure they do not find any errors with the JavaScript. The JSLint site will let you check JavaScript to make sure there are no warnings or errors that could cause older browsers to fail.

Tips when using CSR

The following are a list of tips to help weed out potential issues and improve performance with CSR.

#1 - Placement of the doSearch() call

The location of CSR in the page is important. You should:

  • Include the reference to the CSR javascript library in the <head> of your page.
  • Include the call to just before the closing </body> tag of your page.

#2 - Always include Top and Bottom Ad Regions for a SERP

CSR requires that there always be a Top and Bottom Ad region in order to render the SERP page properly, even if these regions are blank.

#3 - Do not invoke the doSearch() call more than once per query

CSR has been implemented to be called only once per user query. Invoking it more than once will yield unpredictable results.

#4 - Do not call doSearch() from jQuery

You cannot call doSearch() from the document.ready event, or from jQuery. The doSearch() call must be embedded in your html page (via <script> tags) just prior to the closing </body> tag.

#5 - Eliminate unnecessary parameters from the doSearch() call

CSR performs best with minimal number of parameters as possible. For example, if you are not using a parameter (e.g., isTest), remove it. Including a parameter that’s not being used, or contains the default value, can add unnecessary latency.

#6 - Click Tracking URL

Limit the length of the click tracking URL to 1,000 characters or fewer.

#7 - Signature generation

If the signature is not correctly calculated, a Partner Not Authorized error message will be displayed in the browser console.

  • Please trim any leading or trailing spaces before calculating your signature and requesting results - this can cause an error.
  • The query should be exactly the same in the call to doSearch() and in the signature calculation. When encoding the query term, ensure to do so prior to calculating the signature and passing it in the call to doSearch().
  • Make sure the search pages support UTF-8 encoding. Look for charset in the page source. The page header should include charset=utf-8.
  • To verify signatures are being generated properly, use the attachment below. Enter your access key in the token box and the keyword into this tool. The signature generated can be compared to the value generated by your server (within 1 minute) to ensure they match.

There are three things to keep in mind when creating the correct signature:

The query that is passed to the doSearch() call must be the same query term that is used to calculate the signature. For foreign characters, there should be no encoding/escaping/manipulation of the query term when calculating the signature.
To support foreign characters in a query term, the page must be delivered to the browser with utf-8 encoding. This is set on the web server and is verified by the content-type http header on the server's response. For more information on this topic, refer to this article. As an example, the content-type header for is: Content-Type: text/html; charset=utf-8
For web page safety, the query term should be JavaScript encoded before it's rendered to the page. Here's an example:
queryTermEncoded = '@HttpUtility.JavaScriptStringEncode(queryTerm)';
Escaping prevents vulnerabilities through script injection attacks. The list of potential threats is too long to describe accurately here, but this article is an excellent introduction to this topic.

xAD Details Usage

xAD is a local ad feed. These are tips intended to optimize the results. Contact your Partner Manager for more information.

  • xAD results were intended for mobile web segments, but will work on desktop. As such, these results will not work on IE7 as expected.
  • When a user clicks on an xAD result the other CSR dosearch() containers in the call will become hidden and only display the xAD details. This means any other HTML markup will still be rendered, and may or may not “look” the same based on how the partner has laid our their page. Partners will need to see if this will work with their site.
  • The BACK img button is the intended way to navigate back to the search results.