For the complete documentation index, see llms.txt.

How the tag is delivered

Dernière mise à jour Voir en Markdown

The Contentsquare tag loads as two JavaScript files. This page explains what each file does and what it means for the security and performance of your site.

After you install the tag, the Network tab of your browser's developer tools shows two Contentsquare scripts:

FileRole
https://t.contentsquare.net/uxa/<YOUR_TAG_ID>.jsThe loader. A small file specific to your project. It contains your project's settings.
https://t.contentsquare.net/releases/<VERSION>/<TARGET>/<HASH>.jsThe tag runtime. The Contentsquare tag code itself, shared by all projects running the same version.

For example:

https://t.contentsquare.net/releases/15.270.0/es2019/170040c-382ea1aa.js
  • <VERSION> is the tag version, for example 15.270.0. Hotfix builds can carry an additional suffix.
  • <TARGET> is the JavaScript level served to the visitor's browser: es2019 for modern browsers, es6 for older browsers. Contentsquare selects it automatically based on browser support.
  • <HASH> identifies the exact file content.

Seeing both files is expected. You don't need to change your installation, and the snippet you installed stays the same.

Why the tag is delivered this way

Section titled Why the tag is delivered this way

Separating the project settings from the tag code means that the two parts can be cached independently:

  • The runtime is static. A given runtime file never changes after it's published. When a new tag version is released, it's published at a new URL. Browsers and CDNs can therefore cache it for a long time.
  • The loader is small. It holds your project's settings. When you change a setting, only this small file updates. Visitors don't need to download the tag code again.
  • The runtime is shared. It's the same file for every project on a given version, which improves cache hit rates across sites.

This delivery model doesn't add any security risk:

  • Both files are served over HTTPS from Contentsquare's CDN on t.contentsquare.net, the same domain that has always served the tag.
  • The runtime contains no data specific to you or your visitors. It's the same code Contentsquare has always delivered.
  • The data the tag collects and sends is unchanged. See Collected data and Requests.
  • If you use a Content Security Policy, the *.contentsquare.net entry in your script-src directive already covers both files. No new domain is needed.
  • Contentsquare's tag checker continuously verifies the integrity of both the loader and the tag runtime served from the CDN, and Contentsquare is alerted immediately if a file is compromised. See Security.

This delivery model doesn't negatively affect the performance of your site, and it can improve it:

  • Longer caching. The runtime is static and changes only when a new tag version is released. It can stay in the visitor's browser cache much longer than before, and a settings change on your side doesn't invalidate it.
  • Smaller updates. When your project settings change, visitors download only the small loader.
  • Negligible cost for the extra request. Both files are served from the same host, t.contentsquare.net, over HTTP/2. The loader's request already opens the connection (DNS lookup, TCP, and TLS handshake). The runtime request reuses that same connection, so it doesn't pay that setup cost again. HTTP/2 also multiplexes requests on a single connection, so the second request doesn't wait for or block other downloads. The additional request has a negligible effect on loading time.
  • Same loading behavior. Both files load asynchronously, as before. The tag still doesn't affect paint metrics such as FCP or LCP.
  • Right-sized code. Modern browsers receive the es2019 build. Older browsers receive an es6 build.

For more details, see Impact on performance.