Impact of 3rd Party Request on site's Performance

What Are Third-Party requests??

"First party" resources are those hosted and served from your own domain (HTML, CSS, JavaScript, images, fonts, and so on). You have control over what those resources are. All other requests made by a browser when it loads your web page are third-party requests.

Almost every significant website on the Internet depends to some extent on third-party services. In this instance, we won't be discussing infrastructure services like a content delivery network (like akamai / Cloudflare) or a cloud computing platform (like Microsoft Azure / aws). Understanding how these services affect the user experience is crucial because many websites leverage them to launch and manage their operations.

The advantage of using third-party services on your website is that you do not have to design everything yourself. In many cases, they can be extremely convenient to add or remove without requiring code changes to the site. The disadvantage is that third-party requests can have an impact on website visitors. Pages containing dozens or hundreds of third-party calls may take longer to render or become interactive.

While the earliest, most basic third-party services were simple 1x1 pixel images used for visitor tracking, almost all third-party requests today load JavaScript into the browser. And, of course, JavaScript can make requests for additional network resources. If the subsequent requests are to a different host or service, they are referred to as "fourth-party services."

Fourth-party requests are most encountered in advertising services, in my experience. If you serve ads on your website via an ad broker, you may not even know which service delivers the ad image that appears in the browser.

The experience of your visitors can be impacted by resource requests in at least one other way over which you have no direct control. It's possible for network activity to occasionally start with the visitor's browser. Users, for example, could install browser plugins to suggest coupon codes while shopping, or message friends, or do a variety of other things. There is nothing you can do if these plugins send "second-party" requests in the middle of your page load. In contrast to third-party services, the best you can do is be aware of what these second-party services could be and what to ignore when troubleshooting user experience problems.

You can use Catchpoint’s Web Page test to create a request map of your site, where you can plot all the request the browser makes when a user visits it.

Impact of 3rd Party resources on Performance:

Third-party requests can have a variety of effects on the user experience, depending on whether they load early in the page load process or after the page is mostly complete.

Resources that delay initial render:

Resources that load before the initial page render (or First Contentful Paint) will have the highest overall impact. Users are more sensitive to delays at this point in the page load experience than they are at any other point after some visual progress has been made.

Watch out for requests from third parties that are heavy, require fresh DNS lookups, needs connecting to fresh origins, introduce redirection chains, or take a long time to download.

?

Render Blocking Resources

Any JavaScript resource that prevents the request of other resources until it has finished processing raises red flags. Render blockage could result from a request for a third-party font or script.

Single Point of Failures

If the web page doesn't load or takes an excessively long time to load if the requested resource doesn't load, the resource request could be considered a SPOF.A SPOF would occur, for instance, if a third-party host is unavailable or the request takes 30 - 60 seconds to time out; resulting a delay in the initial rendering.

Measuring Performance Impact:

Third-party requests are frequently made in parallel with first-party requests or third-party requests to other hosts, and they are competing with one another for the limited network, CPU, and memory resources of the client.

Measuring the precise performance impact of those requests can be tricky once you have identified third-party resource requests from third parties that have the potential to be problematic.

?

Case Study

We have noticed a spike in Document Complete (onload event) time. Looking at the waterfall records for the runs with higher Document Complete, we noticed that a third-party retargeting java script request, fired before the onload event has posed a serious performance impact by increasing the overall page load time and the time to trigger the onload event.?

Waterfall showing the impact of the request in delaying the Document Complete (onload event)

?????????????Using Catchpoint’s request charting, we were able to plot the trend of the single third-party request, and corelate it to the performance volatility of the website.?

Optimization techniques

Here are few quick techniques you can implement to minimize the risk of impact of third-party services on your site’s performance.

·??????Load the scripts asynchronously

·??????Geographically align the requests

·??????Remove the requests for the services that are no longer needed

·??????Periodically audit all third-party services on the page and keep a record of internal stakeholder who owns each service