Skip to main content

Impact of Kameleoon on your website's performance

You can use various performance analysis tools to evaluate your site’s efficiency. Consult our guidelines below to identify and implement necessary improvements based on the results.

Checking when the snippet loads

Check the timing of the kameleoon.js tag after the page reload, as shown in the screenshot below. If the started at metric is above 1s, make sure that you enter the Kameleoon script higher in the <head> tag and set fetchpriority="high". This makes sure the Kameleoon script loads in less than 1s.

note

When the page first loads, the Kameleoon script takes longer, usually under 60ms, as it is downloaded directly from the CDN. During subsequent reloads, the script is downloaded from cache.

performance

Checking performance score, powered by Kameleoon's Chrome Extension

Depending on the Performance score shown on the extension (see screenshot below), take one or all of these actions:

  • Stop any experiments or personalizations that have been running for more than 2 months and transfer the code to your site’s source code based on the experiment or personalization result.
  • Archive any experiments or personalizations that have been stopped.
  • Remove any unused goals, including their code if they are custom goals.
  • Remove any unused segments.
  • Remove any unused custom data.
  • Optimize the Global Custom Script to remove all unused/deprecated code.

For details, checkout our help documentation for Chrome extension.

chrome

Tracking performance with PageSpeed insights

The Performance tab in the browser's developer tools helps analyze how a web page performs by recording and visualizing key data such as page load times, memory usage, and resource consumption. It provides detailed insights into rendering, scripting, and layout processes in the form of timelines and flame charts. This can help identify bottlenecks, slow-loading scripts, and other factors impacting speed.

Google PageSpeed Insights analyzes the content of a webpage and provides performance insights and suggestions for improvements. It gives a score and suggestions based on Core Web Vitals, such as loading time, interactivity, and visual stability. The results are displayed in a report format with metrics like "FCP," "LCP," "INP," and "CLS."

tab tab2

FCP (First Contentful Paint)

It measures the time between the beginning of the loading page and the moment where a part of the page content is displayed on the screen.

Possible impact: The anti-flicker could impact the FCP since it delays the first element display on the page

Action: Lower the timeout of the anti-flicker from 1000ms to 500ms or remove the anti-flicker script if Kameleoon loads very early (started at ≃ 500ms). The following example code snippet demonstrates how to achieve this:

var kameleoonLoadingTimeout = 1000;

LCP (Largest Contentful Paint)

It measures perceived loading speed. It marks the point in the page load timeline when the main content of the page has probably loaded.

Possible impact: The anti-flicker could have an impact on the LCP since it delays the display of the largest element on the page

Action: The same as for the FCP above. ****

INP (Interaction To Next Paint)

It measures responsiveness of the page. To provide a good user experience, strive to have an INP of less than 200 milliseconds.

Possible impact: as long as Kameleoon loads early, there should be no negative impact. However, tests that change the behavior of an interaction might have an impact on this metric. Action: You can use Kameleoon Chrome Extension or the code below in the console to check what are the experiments / personalizations that are active on the concerned page to find the possible source of the impact. The following example code snippet demonstrates how to achieve this:

Kameleoon.API.Experiments.getActive()
Kameleoon.API.Personalizations.getActive()

CLS (Cumulative Layout Shift)

It measures the biggest position change of an element during all the duration of the life of the page. Note that layout shifts only occur when existing elements change their starting position. If a new element is added to the DOM, or if an existing element changes size, this does not count as a layout change, as long as the change does not result in a change to the starting position of other visible elements.

Possible impact: The Kameleoon tag has no impact on this index. experiments / personalizations on the other hand, can have a negative impact if they cause a change in the starting position of an element.

Action: The same as for the INP above.

Speed Index (ContentSquare metric)

It measures the time of when the vast majority of graphic elements above the waterline are displayed.

Possible impact: The anti-flicker could impact the Speed Index since it may delay the display of the elements above the waterline. Also, if you run experiments / personalizations that make a changes to the top of the page, the Speed Index will be negatively impacted (it will increase).

Actions: The same as for the FCP and INP above.

Kameleoon script characteristics at a glance

  • Asynchronous snippet →The page loading won’t be blocked in case of CDN side problem or Kameleoon snippet.
note

Make sure you have the async attribute on Kameleoon script installed on your site. Please refer to the snippet below:

<script src="[//SITE_CODE.kameleoon.eu/kameleoon.js](https://v0eikkqi7f.kameleoon.eu/kameleoon.js)" **async="true"** fetchpriority="high”></script>
  • Browser caching → In order to not generate any additional calls, the Kameleoon engine is set in cache from the first session page.
  • Script’s compression → The combination of typescript and the Brotli compression library results in a 28.7 Kb script, minimizing the loading of the landing page resource.
  • CDN speed → The Kameleoon monitoring CDN available here, show his response time, which supports the previous 3 points.
  • Beacon calls (204) → HTTP request that allows asynchronous sending of small amounts of data to a server without blocking the page unload or navigation and do not need to return any content in response. It significantly reduces the number of networks calls, improving the site performances which execute a large amount of experiments / personalizations.
  • Delayed experiments →**Allows to load the experiments code only if the visitor is targeted and allocated to a variation, or otherwise 10s after the initial page load. Follow this documentation for more info.