Blog Post

Using Catchpoint to Analyze Third-party Impact

Learn how to use Catchpoint website performance monitoring in this step-by-step guide.

Modern websites are increasingly dependent on third-party services for most of the features it provides like widgets, ads, social marketing tags, page analytics, conversion tracking, etc. Performance optimization is no longer limited to managing the size and format of the images embedded on a webpage and the page itself; it also boils down to the number of third-party tags, hosts, and number of requests on that page.

Third-party tags are a performance overhead. We have discussed the toll third-party components take on performance in multiple blogs, listed below.

In short, the more third-party tags you have on your website, the more requests will have to take place on the page, which will likely lead to a delay in page load. If not optimized, such tags can cause:

  • the page to load slower
  • the page to not render properly
  • the page to display errors or not load at all

Getting to the Root

A website outage or degraded performance can be the result of many different factors. The root cause analysis can get tricky when the page is complex with multiple hosts and third-party components. Resolving such performance issues becomes difficult when third-party services are involved; it requires specific tests and targeted troubleshooting.

Catchpoint has assisted many customers in analyzing and understanding performance slow-downs caused by third-party services. Our solutions are built to make it easier to drill down to specific components of the page to aid in faster resolution time.

Let’s look at two specific Catchpoint features that allow you to identify third-party issues easily.

1. Request Block

Catchpoint allows you to add/modify the headers that are sent during a test. These are configured under the “Request” section when creating a test.

The Request Block option allows you to specify the requests to be blocked when executing the test; this will help determine if a particular request is causing the performance degradation. The image below shows where to set this up:

This is an important feature when troubleshooting third-party tag’s performance. You can measure the impact specific requests have on the overall load time. For example, in the image below we compare the Render Start and Document Complete metrics of a website before and after blocking requests.

The page takes almost 7 seconds to start rendering. Compare this to the metric values after the requests are blocked: the page loads within 7 seconds versus the 12-13 seconds it took without request block enabled. By breaking down the data by “Hosts” and “Zones,” we can drill down even further and identify the exact requests that have become a performance bottleneck.

2. Request Delay

Another Request Header we can use is “Request Delay.” This forces the browser to delay specific requests for a set interval. We can see the difference this makes to the load time in the images below:

These two features can also be used in A/B testing to evaluate the performance of third-party services that you plan to implement on your website.

Are tag managers the answer?

When it comes to optimizing third-party components, one of the recommended options is the use of a tag management system. Tag managers have several advantages:

  • Checks if all the tags are updated
  • It helps load tags faster and asynchronously
  • Ensure tags load only on pages that need it
  • If a tag doesn’t work then it gives you the option to disable or remove the tag

But all these advantages don’t translate to better performance if the tag management itself is not optimized. Take the example below:

The graphs illustrate the impact the tag manager has on page load. Graph A denotes the load time of the tag manager asset and Graph B denotes the time taken for the page to render. There is a clear correlation between the two; the higher the load time of the tag manager, the longer the page takes to render.

In this scenario, the tag manager does not maintain uniform performance across different locations. It works well for users accessing the website from US and Italy, but the tag manager degrades the site performance for users accessing from China and Hong Kong.

A tag management system can make it easier to keep track of all the different third-party tags on your website, but it is important to ensure that it is optimized to handle users from across that globe and doesn’t hamper site performance at different locations.

Conclusion

There’s no debating the fact that unoptimized third-party components can drag your website down. It has a direct impact on page speed and should not be ignored when trying to analyze a sudden performance degradation or outage. Once you have isolated the third party causing the issue using the methods described above, the next step is to ensure you have the following points in place:

  • Always place third-party tags after Document Complete.
  • Use asynchronous JS when implementing the third-party components.
  • Remove unnecessary JS tags from your webpage.
  • Ensure the third-party tags you are using are updated and don’t throw errors.
  • Ensure all the different third part tags load correctly and work without conflicting with other scripts on the page.
  • Finally, if you are using a tag management system then ensure it is optimized and doesn’t degrade website performance.
Synthetic Monitoring
SLA Management
This is some text inside of a div block.

You might also like

Blog post

Mastering IPM: Key Takeaways from our Best Practices Series

Blog post

Mastering IPM: Protecting Revenue through SLA Monitoring

Blog post

Adobe Experience Cloud Outage: The Impact of Relying on Third-party Services