Embedding, Page Loading, Performance & Best Practices

Article author
Matt Hanan
  • Updated

Learn about best practices for loading TVPage social commerce widgets on your web site.


TVPage social commerce widgets can be loaded and displayed within any part of any web page. When deploying a widget, it is important to ensure that best practices are taken into account to ensure that page load and performance are not adversely affected. Areas of consideration include widget placement, network conditions, browser asset pipeline, blocking javascript, tag managers and server-side rendering vs client-side rendering.


First, let’s review specific test case results for load speed of a widget.


Performance Testing

Below you will find widget performance test data illustrating the minimal impact of our widgets on page load. To effectively test different scenarios, we ran the test 10 times to achieve a statistically reliable average speed, noting that conditions may vary for each network speed. 


We simulated 3 different network speeds: WiFi (Fast), LTE (Medium) and 3G (Slow).


These tests show page load performance without a widget and with a widget across different platforms / operating systems. In all tests, we measured the time for the page to load from initial page request until the “Load” event.


Wi-Fi (Fast)



LTE (Medium)



3G (Slow)



The above results illustrate a negligible delta with respect to page load time, ensuring that the customer experience is not adversely affected. The above were performed in Q4 2020. The best practices outlined below should be followed to achieve a similar result.


Widget Placement - Above the Fold vs. Below the Fold

When a widget is to be displayed above the fold, it is important that the widget code is implemented as early as possible in the asset load order of the web page. This ensures that the widget assets and dynamic API calls are able to execute as quickly as possible, enabling the experience to be rendered while other elements are being “painted”, offering an optimal user experience.


Our Recommendation: For optimal speed/load time, the following implementation steps should be utilized.

  1. Preload the widget library by inserting the following code as high up in the <head></head> section of the HTML page as possible:

    <link rel="preload" href="//video.yourdomain.com/tvpwidget/xxx-yyy/index.js" as="script">

    Note that the href asset will be different for each widget, you can find the correct asset URL in the embed code within the TVPage dashboard.

  2. Insert the widget's target <div> element where you wish the widget to be rendered within the page.

  3. Insert the <script></script> portion of the widget embed code right after the opening <body> tag of the HTML page. 


Network Conditions

Network conditions can affect how a page is loaded and rendered. On low bandwidth connections with high latency, assets can load slowly or out of order creating a less than desirable experience. We have minimized the number of initial requests made and assets needed to load and display a Widget. Initially, only 2 requests are made, the first is for the widget javascript library and the second is a call to our API to retrieve video and product data. Subsequent requests are then made for thumbnail images and other supporting assets.


Our Recommendation: Keep initial page asset loads to an absolute minimum. It is a good idea to load non-essential scripts via a tag manager so that they load after all of the experience level assets have had a chance to load. Separately, additional best practices should be utilized: code minimization, GZIP compression and device-specific assets, all of which are native to our widgets.


Browser Asset Pipeline

It is important to understand the asset pipeline that web browsers use to load assets to support page rendering. This can include any request made to an external asset: Javascript, CSS, Images, Web Fonts, AJAX (XHR) and Iframe requests. Upon initial download of a web page, the browser will parse the HTML and make requests to these external assets. The number of assets being loaded can have a drastic effect on overall page load time. Some browsers place limitations on concurrent requests made from the asset pipeline. This can cause queuing to occur, delaying subsequent requests and increasing page load time.


Our Recommendation: Place all “above-the-fold” experience-level assets at the “top” of your load order & HTML. This will ensure that the requests for these assets are made first. Additionally, you can utilize DNS prefetching to speed up the individual requests from domains that are commonly used.


<link rel="dns-prefetch" href="//embed.domain.com"> 


Blocking Javascript

Some external / 3rd party Javascript libraries pose a risk to page load because they “block” execution of other elements on the page until they have finished executing.


TVPage has utilized best practices with all widgets and loads all Javascript asynchronously, without any code execution or blocking of the page load.


Our Recommendation: Prior to deploying a new script to your production website, it is important to verify from the script provider that it loads in an asynchronous manner and does not contain any code that will block execution of any other javascript. If a script does not load asynchronously or contains blocking code, depending on where it is placed in your HTML source code, it may add delays to page rendering.


Tag Managers

Tag Managers are excellent ways to easily manage many 3rd party scripts without involving a developer. Our widgets have been tested and work with Tag Managers such as Google Tag Manager, Tealium, Ensighten and others.


Our Recommendation: If you are placing a widget “above the fold”, it would be best to include the widget script just inside the opening <body> tag of the page as opposed to using a Tag manager. This will ensure that the minimal requests that need to be made are performed immediately so that the visual elements can be rendered. However, when placing “below the fold”, best practices dictate a “lazy-load” approach to ensure minimal impact on the initial user experience, in which case a Tag Manager is beneficial.


Server-side vs Client-side Rendering

Another option for rendering widgets is to utilize server-side rendering. All widgets utilize client-side javascript rendering. Server-side rendering is a technique that can be used to include experience elements directly within the initial page request. This type of rendering is often cached via a CDN and offers quick visual rendering to the web browser. To render on the Server-side, a widget would need to be constructed using traditional web code and techniques familiar to your developers. This process delivers an additional performance benefit over client-side rendering.


Our Recommendation: For deployment to any environment, client-side rendering is the easiest and quickest method with negligible impact as illustrated above. If you are looking to improve page performance / speed, server-side rendering is a great path to follow. This can be achieved by making data requests to the TVPage API for video data and then statically rendering into a page or utilizing a TVPage “reverse feed” - a data digest that is provided to you from your account containing all of the relevant video and associated product metadata required to render any social commerce experience.


Embed Codes

Each social commerce widget comes with a dedicated embed code for placement on a webpage or template. Below is an example of a widget embed code.


<div id="carousel"></div>
(function(d, s) {
  __TVPage__ = window.__TVPage__ || {};
  __TVPage__.config = __TVPage__.config || {};
  __TVPage__.config["carousel"] = {
    loginid: "1234567",
    channel: {"id":"987654321"},
    targetEl : "carousel"

  window.addEventListener("load", function() {
    var js = d.createElement(s),
    fjs = d.getElementsByTagName(s)[0];
    js.src = '//domain.com/widget-name/index.js';
    fjs.parentNode.insertBefore(js, fjs);
  }, false);
}(document, 'script'));

The above sample embed code can vary slightly based upon the experience (different experiences can be fueled by different dynamic parameters passed to the embed code). The code itself comes in 3 parts.


  1. A target <div> element, where the widget will render into. This can be any element in the page.

  2. A configuration block of settings that are used to instantiate the widget.

  3. An execution block that executes the widget javascript.

Additional configuration options can be passed to the __TVPage__.config["carousel"] object to control the behavior and features of the widget:


  1. autonext - Boolean - enables/disables playing the next video, after current one ends.

  2. autoplay - Boolean - enables/disables autoplaying the video at first load.

  3. videos_feed - Boolean - enables/disables video feed shown on the left of the Modal.

  4. fix_page_scroll - Boolean - when widget modal is open, it prevents parent document from scrolling up or down.

  5. items_per_page - Number - changes the number of videos to be called at each iteration. (when loading more videos if "videos_feed" opt enabled).

  6. menu_item_play_category_tag_attribute - String - changes the attribute tag to be shown below item thumbnails. (if "videos_feed" option is enabled).

  7. player_version - Number - Changes the Player library version Widget use