A Website’s performance is key to SEO and user experience; however, the increasing amount of tags used on websites nowadays has an impact on loading times.
In this context, tags’ performance has become a strategic matter.
TagCommander’s “TagPerformance” module offers the possibility to measure your site’s performance based on the tags that are placed on it. It acts as a complementary tool to those used by IT departments to measure loading times of websites’ key elements (images, CSS …)
TagPerformance’s main features include:
A measuring tag executed on the end client’s browser and not by a robot.
Analysis of the START RENDER, DOM READY and DOM LOADED events to measure performance.
The possibility to visualize significant variations in tags and page types, free from the noise resulting from the analysis of micro-variations.
Information on loading times of partner solutions in relation with the average loading times of other solutions to ensure loading times are correct.
Data segmentation to identify sources of problems, if any, or to focus on a particular segment: container, page type (product, home page), device (mobile, tablet, PC), OS and browser.
TagPerformance is one of the additional modules for the TagCommander product: if you wish to use it on your website(s), please contact your account manager or reach out to our Support Department (support@commandersact.com)
TagPerformance allows you to analyze three events:
START RENDER or FIRST PAINT: This is when the first element is displayed on the page.
This metric is key to bounce rates (if initial visual elements take too long to load, users will most often leave a site) and SEO (“dwell time” metric).
DOM READY: this is when a page’s structure is loaded and analyzed by the browser.
PAGE LOADING TIME or ONLOAD or DOM LOADED: this is when the page’s content has finished loading. This metric is useful for SEO.
Loading order of a web page’s elements:
Example:
Page A and page B take both 12ms to load; DOM loaded is the same for both of them. However, Start Render and DOM Ready events are optimized for page A but not for page B.
The following diagram explains how TagPerformance works, technically speaking:
The page loads with the Commanders Act container.
The Commanders Act container calls the tags placed on the page and loads the “Commanders Act – TagPerformance” tag two seconds after the DOM Loaded event.
The “Commanders Act – TagPerformance” tag captures information provided by the browser thanks to the Navigation Timing API, which is compatible with 88% of existing browsers. The information that is captured includes:
Generic information about the page: Start Render, DOM Ready and DOM Loaded
Information about every tag that is executed on the page: hits’ aggregated loading time before Start Render, DOM Ready and DOM Loaded happen (separately).
Example:
This is the structure of a page from a website:
“Tag 1” sends 4 hits:
One that loads before the Start Render event (300ms)
One that loads before the DOM Ready event at (400ms)
One that starts loading before DOM Ready and finishes loading during the DOM Loaded event (600ms)
One that loads after the DOM Loaded event (100ms)
“Tag” 2 sends 2 hits:
One that loads during the Start Render event (700ms)
One that loads before the DOM Loaded event (200ms)
With the “TagPerformance” tag, Commanders Act will count the following loading times for tag 1:
Hits’ aggregated loading time before the Start Render event (300ms).
Hits’ aggregated loading time before the DOM Ready event: 1300ms (the first and second hit’s respective loading times of 300ms and 400ms are stored and added to the 600ms loading time of hit three, which is sent during the DOM Ready event).
Hits’ aggregated time before the DOM Loaded event: 1300ms (all hits’ loading times are stored: 300ms, 600ms and 600ms for hits one, two and three, respectively).
Total loading time of tag1 (1400ms)
The “TagPerformance” tag will count the following loading times for tag 2:
Hits’ aggregated loading time before the Start Render event (700ms)
Hits’ aggregated loading time before the DOM Ready event (700ms)
Hit’s aggregated loading time before the DOM Loaded event (900ms)
Total loading time of tag1 (900ms)
It will also count generic loading times on the page:
Start Render (700 ms)
DOM Ready (2000 ms)
DOM Loaded (2800 ms)
All this data will populate TagPerformance’s reports.
The TagPerformance tag must be included in each and every one of your containers.
If you have many containers on a given page and as many TagPerformance tags, only one hit containing information about your tags will be sent.
It is not necessary to place it in a particular order within your containers, as it will automatically execute two seconds after the DOM Loaded event, that is to say, after all the other tags have loaded.
In the tag library, select the “Commanders Act – TagPerformance” tag.
There is nothing to configure in the “EDIT” step: Generate a new container version and deploy it.
Advanced – Customizing the “TagPerformance” tag:
It is possible to force-measure a tag’s performance (for example, that of a tag outside the container, that of a custom tag whose URL paths are not recognized by TagCommander or that of a tag that is not present in the TagCommander tag library). If you wish to measure a new tag’s performance, place the following code block in the commented line (4 (1) tC.tagPerf.customPatterns.push({label:’Solution A’,p:’domain\.com.*js\.js’})
Example:
tC.tagPerf.customPatterns.push({label:’exelate’,p:’loadm.exelator.com’});
You can also add additional filters (in addition to default filters page type, container, device, OS and browser). If you wish to add a custom filter, place the following code block in the commented line (4): tc_vars[“custom_segment”] = #custom_segment#;
Note: You can only add one additional filter.
Example: to add a “page category” filter (tc_vars[“page_cat1”]) :
tc_vars[“custom_segment”] = tc_vars[“page_cat1”];
Finally, you can change the capturing method of the “Page Type” filter, which is available in the reports. This filter is based on the tc_vars[“env_template”] variable by default. If this variable is not available on your site, you can rely on a different variable by adding the following code block in the commented line (4) tc_vars[“env_template”] = #page_type#;
Example: if you wish to replace tc_vars[“env_template”] with tc_vars[“page_type”] :
tc_vars[“env_template”] = tc_vars[“page_type”] ;
If you notice that a tag is slowing down your pages, please try the following:
Have the tag load after the DOM Loaded event. Caution: not all tags are compatible with this method and the more you delay a tag’s execution the more you loose data in your reports.
This code block allows calling a tag during the DOM Loaded event:
tC_ready = function(){
// Code du tag
}
if (window.addEventListener)
window.addEventListener(‘load’, tC_ready, false)
else if (window.attachEvent)
window.attachEvent(‘onload’, tC_ready)
Get in touch with the tag’s editor and request they improve their tag in terms of size or server response. Note: it is possible to include the tag’s JavaScript file in the Commanders Act container while on the “EDIT” tab from the TagCommander interface.
Sample the tag from the “RULES” tab from the TagCommander interface. This will improve the average loading time of your site’s pages.
Shifting the tag’s execution order from the “GENERATION” (1) tab from the TagCommander interface (place the one taking longer to load at the end of the queue).
Use a timeout on your tags from the “GENERATION” (1) tab from the TagCommander interface. This feature interrupts the tag’s execution if it takes too long to load.
Deactivate the tag from the “GENERATION” (1) tab from the TagCommander interface (1)
Use your tag in a serverside configuration (this entails activating an additional module from the TagCommander product, please contact your account manager or our Support Department for further information). Caution: not all tags are compatible with this method.
For more detailed information on how to set up these methods, please contact our Support Department (support@commandersact.com).
In order to be able to visualize TagPerformance reports, you have to request the activation of this module, not included in the basic TagCommander offer. If you are interested in using TagPerformance, please get in touch with your account manager or our Support Department (support@commandersact.com).
To access the reports,
Log in to the TagCommander Interface and click the TagPerformance menu
You will be taken to the dashboard where three reports are available: “Dashboard”, “Report by Tag” and “Tags Hierarchy“.
The “Dashboard” report provides an overview of tags’ performance on your site:
You will find below a detailed explanation of the report’s analysis windows.
1)-The three main indicators (Start Render, DOM Ready, DOM Loaded):
Average Start Render (First Paint): average loading time on site of the Start Render event.
Average DOM Ready: average loading time on site of the DOM Ready event.
Average Page loading time (on load): average loading time on site of the DOM Loaded event.
Note: These three metrics consider the following filters “page type”, “container”, “device”, “OS” or “browser”.
Example: These three pages are loaded on your site:
Les 3 pages suivantes sont chargées sur votre site :
The three metrics would take the following values:
“Average Start Render (First Paint)”: 5 sec (700ms, 500ms and 300ms on average)
“Average DOM Ready”: 8 sec (2000ms, 2200ms and 1100ms on average)
“Average Page loading time (on load)”: 6 sec (2800ms, 2800ms and 2100ms on average)
2)-The Pie Chart:
The pie chart highlights tags that take longer to load in terms of the selected level of analysis in the available filters: Start Render, DOM Ready, DOM Loaded or Cumulated loading time.
Example: the pie chart above appears once the “Tags impacting start render (First Paint)” level of analysis is selected. It shows that the “Lengow lead validation” tag is the tag that delays the most the Start Render event, because it takes about 17% of total time preceding the Start Render event.
By clicking the “Others” part, you will be able to obtain more details about the remaining tags affecting your site’s loading time.
Note: the pie chart that appears next provides the proportion of each tag in relation with the “Other”’s total.
Example: Here below, the “Effiliation” tag takes about 14% of the “Other”’s total loading time (14% of the 21% of global loading time, which “Others” account for).
3)-Main Tag Variations:
The “Main Tag Variations” graphs allow you to identify tags whose loading time has varied (+/-10%) over a selected period of time in terms of the selected level of analysis in the available filters: Start Render, DOM Ready, DOM Loaded or Cumulated loading time.
The tag’s variation measures gaps in tags’ loading times in relation with the median (and not the average, in order for it to be less sensitive to extreme values). Calculation is based on the six previous identical periods.
Example:
We wish to analyze the variation of tags affecting the Start Render event on May 22nd.
In the screenshot below, we can see a 65% increase in AB Tasty’s loading time for that day. The tag does indeed take 61.96ms to load, whereas the median for the six previous days was of 37.65ms. (May 16th: 48.05ms /May 17th: 30.30ms / May 18th: 35.77ms / May 19th: 27.44ms / May 20th: 64.11 ms / May 21st: 39.53ms).
4)-Main Page Type Variations:
The “Main Page Type Variations” graphs allow you to identify the page types whose loading time has varied (+/-10%) over a selected period of time in terms of the DOM Loaded event only (the page’s loading time is defined with the arrival of the DOM Loaded event).
Note: The page type corresponds to the default “page type” filter available on the interface.
The page type variation measures gaps in pages’ loading times depending on their type and in relation with the median (and not the average). Calculation is based on the six previous identical periods.
Example:
We wish to analyze variations in types on May 2nd.
In the screenshot below, we see a 31% reduction in loading times for the “newsletter” page type on that day. It takes 5.23ms to load whereas the median in the six preceding days was of 7.6ms (April 26th: 7.58 ms / April 27th: 5.31 ms / April 28th: 8.16 ms /April 29th: 7.62 ms / April 30th: 7.84 ms / May 1st: 6.02 ms).
1)-The four main metrics
Average page loading time: average loading time of your website’s pages (= DOM Loaded). This loading time is compared to that of the previous period (ex: the previous day or week according to the selected period).
Average tag loading time: average loading time of the tags on your website according to the level of analysis that you selected in the filtering options (Start Render, DOM Ready, DOM Loaded, Cumulated loading time). This loading time is compared to that of the previous period (ex: the previous day or week according to the selected period).
Lowest impact tag: tag that takes the least time to load according to the level of analysis that you selected in the filtering options (Start Render, DOM Ready, DOM Loaded, Cumulated loading time).
Highest impact tag: tag that takes the most time to load according to the level of analysis that you selected in the filtering options (Start Render, DOM Ready, DOM Loaded, Cumulated loading time).
Note: These four metrics consider the selected filters among “page type”, “container”, “device”, “OS” or “browser”.
2)-TagPerformance by tags
The graph shows information about tags’ loading time on your website.
To select tags to analyze with the graph (1), check the corresponding tag in the “Tags” report (2) and reload (3).
You can compare this data to generic information about the page’s context. To do so, select the indicators you are interested in from the dropdown menu above the graph.
Metrics related to the analyzed tags:
Tag Loading time: tags’ loading time according to the level of analysis that you selected in the filtering options (Start Render, DOM Ready, DOM Loaded, Cumulated loading time).
Tag firing: number of times tags are loaded on the site (this metric is independent from the filters).
Metrics related to the page’s context:
Tag number: number of tags present in the last generated version(s) of a container.
Average start render (First paint): average loading time of the tart Render on the site.
Average page structure building (DOM Ready): average loading time of the DOM Ready on the site.
Average page loading time (OnLoad): average loading time of the DOM Loaded on the site.
Note: These six metrics consider the selected filters among “page type”, “container”, “device”, “OS” or “browser”.
Example:
You wish to know if a tag loading during the Start Render event has an impact on the site’s global Start Render.
Use the “Tags impacting Start Render (First Paint)” filter on your report:
Select the tag to analyze:
Select the following metrics from your graph: “Tag Loading Time” (the tag’s loading time) and “Average Start Render (First Paint)” (average loading time of the Start Render):
The result below shows that the selected tag has little impact on the site’s Start Render, as the increase in the tag’s loading time at 13h (1) did not cause the Start Render’s average loading time to increase as well at that very moment.
3)-Tags
The “Tags” section of the report provides deeper insight about the tags that are loaded on your site, according to the level of analysis you selected from the filters on the top left-hand side (Start Render, DOM Ready, DOM Loaded, Cumulated loading time) and top right-hand side of the page (“page type”, “container”, “device”, “OS” and “browser”).
You can analyze the following elements for each tag:
“Tag loading time” (ms): Loading time in milliseconds
“Tag firing”: Number of times a tag is loaded
If you click a tag’s name, a graph appears showing these items:
The tag’s loading time compared to the previous period (ex: previous day if the analysis is done by day).
The tags’ average loading time compared to the previous period.
The number of times a tag is loaded compared to the previous period (ex: previous day if the analysis is done by day).
The number of times tags are loaded on the site compared to the previous period.
Note: The current period is always displayed in green and the period of comparison in blue.
“Piggybacking”, consisting in triggering a tag with another, has widespread exponentially with the appearance of programmatic. The subsequent data leakage has generated legal issues and financial losses for companies.
Amid this context, the “Tag Hierarchy” report provides a global insight of requests happening while your website and its content load. You can thus better control calls issued from your website and exchanged data.
Report Structure:
1/Page type filter:
This report is filtered by page type (“page_type” option on the segmentation menu). The default selected page type is the first one appearing on the list (1) and is displayed on the top, left-hand side of the report (2):
You can at all times apply filters on different page types or deselect enabled filters to have an overview of your site (please note that in this case, the report might take a little longer to load, as it will combine all domains called on your website).
2/Request type (script/iframe/pixel)
The report highlights the request’s nature/type:
Script (URL called with <script> tag)
Iframe (URL called with an <iframe> tag)
Pixel (URL called with an <img> tag)
“Other” (in case the request type is not identified)
3/Request Detail
The “Tag Hierarchy” report allows you to visualize all domains called from your main domain and all other domains they call on different levels:
On the diagram above, sub-domain 2 (“sub-domain 2”) is called from your site’s main domain. It is a JavaScript file (blue circle) that in turn calls two pixels (green circles) and a JavaScript file. Waterfall calls stop here for this request, but this is not the case for sub- domain 1 (“Sub-domain 1”), which calls JavaScript files which in turn issue new requests.
In order to provide you with better readability, same-type “childless” requests (script/iframe/pixel) coming from the same domain are gathered under the same domain name, and a number between brackets next to the domain’s name indicates how many calls were issued from it:
By hovering over any of these domains (ex: ) you will see, with greater detail, which URLs are called by them:
You will also be able to see the URL structure and its parameters for certain requests, hence all the information sent to solutions called on your website:
4/Report dates
Displayed data is collected over the past 24 rolling hours.
This export is currently unavailable.
1)-Select your level of analysis:
“Tags impacting start render (First Paint)”: This corresponds to the aggregated loading time of hits that are sent prior to the Start Render event.
“Tags impacting page structure building (DomReady)”: This corresponds to the aggregated loading time of hits that are sent prior to the DOM Ready event.
“Tags impacting page loading time (Onload)”: This corresponds to the aggregated loading time of hits that are sent before the DOM Loaded event.
“Cumulated tag loading time”: corresponds to the aggregated loading time of all hits (including those sent after the DOM Loaded event).
Example: The following diagram shows an extract of tags present on the site:
These are the results you will obtain when you select the following levels of analysis:
“Tags impacting start render (First Paint)”: TAG1 (HIT1) + TAG2 (HIT1)
“Tags impacting page structure building (DomReady)”: TAG1 (HIT1) + TAG2 (HIT1) + TAG1 (HIT2) + TAG1 (HIT3)
“Tags impacting page loading time (Onload)”: TAG1 (HIT1) + TAG2 (HIT1) + TAG1 (HIT2) + TAG1 (HIT3) + TAG2 (HIT2)
“Cumulated tag loading time”: TAG1 (HIT1) + TAG2 (HIT1) + TAG1 (HIT2) + TAG1 (HIT3) + TAG2 (HIT2) + TAG1 (HIT4)
If you wish to know more about the “Start Render”, “DOM Ready” and “DOM Loaded” concepts please refer to the Definition of TagPerformance Metrics article.
If you wish to know more about the technical elements that are captured by TagPerformance, please refer to the Advanced: Technical functioning of TagPerformance article.
2)-Select, if need be, one of the default filters from the interface should you require a more detailed analysis of your site’s performance.
The page type: This filter allows you to display your tags’ performance in terms of the page template. It is based on the “env_template” variable’s values, which are automatically captured by TagPerformance.
Note: If you do not have an env_template variable on your site, you still can capture the values of other variables. Please refer to the Adding the TagPerformance Tag article.
The container name: This filter allows you to display how tags within one or more specific containers are performing.
The device: This filter allows you to display your tags’ performance in terms of the devices your visitors are using. The “device” metric is calculated automatically by our servers, based on the user agent.
OS: This filter allows you to display your tags’ performance in terms of the devices your visitors are using. The “OS” metric is calculated automatically by our servers based on the user agent.
The Bowser: This filter allows you to display your tags’ performance in terms of the browsers your visitors are using. The “browser” metric is calculated automatically by our servers based on the user agent.
Note: if you wish to add an additional filter, please refer to the Adding the TagPerformance Tag article.
3)-Click “Apply” to obtain filtered results and a different level of analysis.
