As a general guideline, we use Google's Page Speed Web Performance Best Practices for optimizing our Seal technology. We use these techniques, and more, to make sure your page content loads as fast as possible.

Yes, we are using the Akamai content delivery network to accelerate our web traffic. If you're not familiar with how CDNs work, here's a quick summary:

• Akamai manages web servers all around the United States (and the world), that intelligently cache Norton Shopping Guarantee (NSG) content.
• No matter where they're located, your site visitors will automatically load NSG content via the nearest (fastest) Akamai server available to them.
• This technique dramatically reduces the time to deliver NSG content to the browser.
• Akamai also accelerates non-cacheable traffic, making our API interface even faster!
• Best of all, you don't need to do anything special to leverage this capability; it's all done seamlessly behind the scenes.

In the unlikely event of a Norton Shopping Guarantee (NSG) system failure, the JavaScript code that we ask you to place on your site is specifically designed to fail-safe so that it will NOT affect the speed, functionality, or visibility of your site. We have designed multiple levels of redundancy and error correction into the system to ensure your site is unaffected. Here's how it works:

The first NSG element that you add to your site is the <SCRIPT> tag that loads our initial "Guarantee JavaScript" library (or "gjs"). This library is hosted via the Akamai CDN, which not only serves it up VERY quickly, but also provides ultra-redundancy and reliability. Even if NSG systems are unavailable, Akamai continues to serve "gjs" to the user's browser without any errors or warnings.

After "gjs" is loaded, the second NSG element comes into play and executes the inline JavaScript code where you specify your _GUARANTEE.Hash value. This code automatically detects if "gjs" loaded successfully and will not generate any errors if it failed to load. The inline code only executes if the full NSG JavaScript library has loaded successfully. So, even if both NSG and Akamai are unavailable, your page will not show any JavaScript errors and will continue to function normally with no performance impact.

The optimal placement for "gjs" and the corresponding seal HTML code is as low in the page as possible, preferably just before the </BODY> tag. This placement allows the browser to load and render as much of your page content as possible before loading Norton Shopping Guarantee's "gjs" JavaScript file. This minimizes and virtually eliminates any impact on the visible page load speed.

Even though our code is explicitly designed to have minimal impact on page load time, we recommend that you do NOT place the "gjs" script tag in the HEAD of your document(s). When the browser encounters a script tag, it must fully download, parse, and execute the JavaScript before proceeding. If the script tag is in the HEAD, the browser must fully execute the JavaScript before even beginning to render the BODY of your document. Placing the Norton Shopping Guarantee code very late in the document allows the browser to draw as much of the page as possible before it starts with our code.

The "gjs" JavaScript file is under 2k in size, and since we transmit the file using gzip compression, it's actually (currently) only about 1200 bytes long! (That's the 1.17 KB vs. 1.80 KB in the image below.) This minimizes the amount of code that the browser must execute in-line before the page load completes.

Here's where it gets interesting! The full Norton Shopping Guarantee JavaScript code library is actually a bit larger (approx 14k compressed currently). This larger library is loaded in a deferred fashion in the background, allowing the browser's rendering thread to continue to load your page in the foreground. The result is that 2 JavaScript files are loaded instead of 1. At first glance, this goes against Google's suggestion of (combining external JavaScript).

However, looking at the "Recommendations" within that very section reads: "Partition the JavaScript into 2 files: one JS containing the minimal code needed to render the page at startup; and one JS file containing the code that isn't needed until the page load has completed."

This is precisely what we are doing! Further details on Deferred Loading.

There are several bugs in several browsers related to Flash that cause the Flash objects to ignore z-order. Without a fix, the Flash will "appear-through" anything else on the page. The workaround for these browser flaws requires placing an iframe directly beneath the Norton Shopping Guarantee Seal and Rollover. This forces the browser to keep Flash objects in their appropriate z-order. We use these iframes to ensure that any Flash you may have on your site doesn't interfere with the NSG elements. The NSG iframes have no content or scripting and are added dynamically to the page.

The deferred library load is achieved by dynamically appending the new JS file to the <HEAD> of the document. This location is used for browser compatibility reasons, and none of the penalties that normally go along with statically linked JavaScript in the document HEAD apply. To be clear, even though the browser shows rollover.core.js in the HEAD section of the document, it's actually being loaded well after the <HEAD> section of the document has been processed. The HEAD is merely a safe place to locate the library as it loads in the background.

After the main library is loaded in the background, the Norton Shopping Guarantee (NSG) Seal is added to the page via additional background-delayed code. This code is designed to load slowly in the background, so it does not interrupt your page load. It's not uncommon for this process to complete after the page onload event has fired, which means that the page has completely finished loading and rendering, while we quietly run in the background.

Wherever possible, highly optimized PNG images are used in place of GIF images, as they generally compress to a smaller size. We use an optimization program called PNGout to squeeze as much space as possibly out of the PNG images without losing image quality. Further, the NSG Rollovers use a technique called CSS Sprites to combine several images into one, reducing the number of image downloads.

This is a complex answer, as NSG's code executes and loads in several pieces at different delayed times. The best way to visualize what components are loading when, and how they relate to the page completion time, is to use a testing tool like WebPagetest.org.

The key time to look for is the Document Complete marker - which is currently a blue vertical line that you'll see in the WebPagetest.org results graphs. Anything that you see happening after this marker line is actually "free time". The browser has already fully completed your page and is just finishing up its background tasks. The user can fully use and navigate around your page while this is happening. This is where you'll often find the final stages of the NSG code - running in the background where it doesn't affect your page load time.

We use Google-recommended caching response headers to direct the browser to aggressively cache our relevant content, including JavaScript and image files. Because of the dynamic nature of our content, we expire our content after 1 day. This gives the browser plenty of opportunity to use cached objects during a single session while allowing fresh content to be delivered in reliable fashion.

The script tag that loads our "gjs" code uses a technique called a "protocol-relative URL". This type of URL, instead of specifying a protocol of http:// or https://, specifies simply //. Like any other relative URL, the browser fills in the blank and uses the same protocol that the page itself has used. Thus, the browser automatically uses SSL only when required by the page. So, when your page is not using SSL (http), our objects will also use http and skip the SSL encryption overhead. If your page requires SSL (https), our code automatically uses https as well.

Feel free to contact your Integration Manager with any questions you may have.