Help Center

Attributer is slowing down my website

If you’ve added the Attributer code to your website and it seems like your website speed is slower, then this article is for you.

It explains technically why that is highly unlikely to be the case, and also provides some remedies if you do believe something needs to be done.

Why Attributer isn’t actually slowing down your website for your real users

Here are a few reasons why it is highly unlikely that Attributer is slowing down your website:

1. It’s a very small script

The Attributer Javascript code that you place on your website is small by modern web standards. The file itself is only 90kb uncompressed, which then gets compressed down to 25kb when it is served.

This is small by modern web standards. Depending on what website builder/theme you are using, it’s probably already serving 500kb+ JavaScript files just as part of the basic functionality of your site.

Similarly, it’s also smaller than most other JavaScript files from products in the same category (analytics). Here’s a comparison table from ChatGPT:

Source: ChatGPT

As you can see, the Attributer code is relatively lightweight and therefore unlikely to be impacting page load speed in a way that is noticeable by the user.

2. It doesn’t change the page content

Most perceived page load speed issues from JavaScript happen when the JavaScript is responsible for changing the content of the page or is used to power interaction.

This means that if the Javascript doesn’t load quickly, the content that it is showing (I.e. an embedded video) is delayed or the interaction that it is powering (I.e. opening a popup when a button is clicked) won’t work.

However, Attributer does neither of those things. Everything it does happens in the background and the user is unaware it even happens (it looks at where they came from and saves the data in a cookie in their browser).

So even if the Attributer code did load slowly, it would not have any impact that is noticeable by the user.

3. It is served from the closest data center to the user to ensure fast delivery

The Attributer JavaScript file is stored on Amazon Cloudfront, which means there are copies of the script hosted in 100’s of locations around the world and it is served from the nearest location to the user.

To help you understand the significance of this, let’s imagine if the Attributer Javscript file was only stored in a data center in Sydney. If a user visited your website from London, the file would have to be sent all the way from Sydney to London, and it would take much longer to reach their computer and be executed by their browser.

But because there are copies of it stored all over the world, your website visitor from London receives the copy stored in London, while your website visitor from New York receives the copy stored in New York.

This means that regardless of where your website visitors are located, their browser is retrieving a copy of the Attributer code from a nearby location.

So in summary, the Attributer code is small, it is served from a location close to the user (from hundreds of data centers worldwide), and it doesn’t change the page content in any way. For these reasons, it’s highly unlikely that the addition of the Attributer code to your website is causing any noticeable delays in page load for your real website visitors.

The reality of pageload speed testing tools

Tools like Google Pagespeed Insights and GTMetrix don’t actually measure the page load experience for real users.

They run simulated tests of your website, often in the most pessimistic of environments, and give you a worst-case scenario. This is by design, and it makes sense they do this. Every visitor to your website is going to be on a different device, in a different location, with a different internet speed, so they need to give you the worst-case scenario so that you can work with that as a baseline.

To illustrate, here is a screenshot from a test I just ran in Google PageSpeed Insights:

As you can see from the screenshot, they ran the test on a Moto G Power (which is a cheap $199 phone), with the CPU of the phone throttled by 1.2x, and on a 4G internet connection that was further throttled. These are not real-world conditions for the vast majority of visitors to your website.

But even in these extremely pessimistic environments, sites with the Attributer code installed can still perform extremely well in these tests. For instance, we have the Attributer code installed on our website at Attributer.io, and the site performs well in all these tests.

Performance report from GTMetrix for Attributer.io
Page load speed report from Google Pagespeed Insights

So in summary, even if some page load speed tool is suggesting your site is loading slowly (and that the presence of the Attributer code is contributing to this), it isn’t necessarily an issue.

The actual visitors to your website are not experiencing the same page load speed as these tools are suggesting, and search engines like Google use real-world data to measure page speed for ranking purposes (they do not take into account results from simulated tests).

Options for improving page load speed

If, after everything presented above, you do believe that the use of Attributer on your website is slowing it down, then you can set the Attributer code to be loaded asynchronously.

Setting Attributer to load asynchronously tells the browser to keep loading your page content (images, text, etc.) while Attributer downloads in the background, rather than waiting for it to finish first. It essentially makes it impossible for Attributer to hold up your content or slow down what visitors see, because the browser won’t wait for it to be loaded before showing other elements.

To do this, you simply need to make a slight modification to the Attributer code snippet you added to your site.

When you first installed Attributer on your website, you placed a bit of code that looks like this:

<script type="text/javascript" src="https://d1b3llzbo1rqxo.cloudfront.net/attributer.js"></script>

You just need to slightly modify this to add the ‘async’ attribute to it. So it should ultimately look like this:

<script async type="text/javascript" src="https://d1b3llzbo1rqxo.cloudfront.net/attributer.js"></script>

The addition of the async attribute essentially tells the browser to load this code asynchronously.

It should be noted, though, that making this change can reduce the accuracy of the data you receive in extreme circumstances. Here’s an example to explain why:

  1. A user navigates to your homepage with UTM parameters in the URL after clicking one of your Google Ads
  2. Attributer is set to load aynschronously, which in 99% of cases is going to be fine, but this person is on a slow internet connection and they very quickly click from the homepage to another page on your site, which means the Attributer code wasn’t able to fully run on this first page.
  3. Attributer loads properly on the second page of your site but the UTM parameters are no longer in the URL, so therefore Attributer doesn’t see them and categorises the visitor as coming from Direct Traffic
  4. When the user submits the form, Attributer passes through Channel = Direct Traffic as opposed to Channel = Paid Search.

This isn’t going to happen often, as the Attributer JavaScript file is small and loads quickly, but it theoretically can happen, which is why we don’t enable it by default.

So if you are going to set the Attributer code to be loaded asynchronously, it’s worth doing some testing (particularly on slower mobile devices) to make sure it still loads fast enough on the initial landing page to accurately track where the user is coming from.

Can't find the answer you need? Contact us!

Our team are available to answer any questions you have

Support Team Pics