Don’t Sink Your Website With Third Parties

About The Author

Ken Harker leads a small team of web performance experts and data scientists at Akamai Technologies. He is on a mission to discover new ways to distill complex … More about Ken ↬

Email Newsletter

Weekly tips on front-end & UX.
Trusted by 176.000 folks.

Quick summary ↬ In this article, Ken Harker explains what third-party resource requests really are and which common optimization strategies can help reduce the impact on the user experience. By carefully considering how third-party requests will fit into your website during the design stage, you’ll be able to avoid the most significant negative impacts.

You’ve spent months putting together a great website design, crowd-pleasing content, and a business plan to bring it all together. You’ve focused on making the web design responsive to ensure that the widest audience of visitors can access your content. You’ve agonized over design patterns and usability. You’ve tested and retested the site for errors. Your operations team is ready to go. In short, you’ve done your due diligence in the areas of site design and delivery that you directly control. You’ve thought of everything… or have you?

Your website may be using more third-party services than you realize. These services use requests to external hosts (not servers you control) to deliver JavaScript framework libraries, custom fonts, advertising content, marketing analytics trackers, and more.

You may have a lean, agile, responsive site design only to find it gradually loaded down with more and more “extras” that are often put onto the site by marketing departments or business leaders who are not always thinking about website performance. You cannot always anticipate what you cannot control.

There are two big questions:

  1. How do you quantify the impact that these third-party requests have on website performance?
  2. How do you manage or even mitigate that impact?

Even if you cannot prevent all third-party requests, web designers can make choices that will have an impact. In this article, we will review what third-party resource requests are, consider how impactful they can be to the user experience, and discuss common optimization strategies to reduce the impact on the user experience. By carefully considering how third-party requests will fit into your website during the design stage, you can avoid the most significant negative impacts.

What Are Third-Party Services?

In order to understand third-party services, it may be easier to start with your own website content. Any resource (HTML, CSS, JavaScript, image, font, etc.) that you host and serve from your own domain(s) is called a “first-party” resource. You have control over what these resources are. All other requests that happen when visitors load your pages can be attributed to other parties.

Every major website on the Internet today relies — to some degree — on third-party services. The third-party in this case is someone (usually another commercial enterprise) other than you and your site visitors. In this case, we are not going to be talking about infrastructure services, such as a cloud computing platform like Microsoft Azure or a content distribution network like Akamai. Many websites use these services to deploy and run their businesses and understanding how they impact the user experience is important.

In this article, however, we are going to focus on the third-party services that work their way into the design of your web pages. These third-party resource requests load in your visitor’s browser while your web page is loading, even if your visitors don’t realize it. They may be critical to site functionality, or they have been added as an afterthought, but all of them can potentially affect how fast users perceive your page load times.

The HTTP Archive tracks third-party usage across a large swath of all active websites on the Internet today. According to the Third Parties chapter of their 2021 Web Almanac report, “a staggering 94.4% of mobile sites and 94.1% of desktop sites use at least one third-party resource.” They also found out that “45.9% of requests on mobile and 45.1% of requests on desktop are third-party requests.”

As it was noted in the report, third-party services share a few characteristics, such as:

  • hosted on a shared and public origin,
  • widely used by a variety of sites,
  • uninfluenced by an individual site owner.

In other words, third-party services on your site are outsourced and operated by another party other than you. You have no direct control over where and how the requests are being hosted online. Many other websites may be using the same service, and the company that provides it must balance how to run their services to benefit all of their customers, not just you.

The upside to using third-party services on your site is that you do not need to develop everything you want to do yourself. In many cases, they can be super convenient to add or remove without having to push code changes to the site. The downside is that third-party requests can impact website visitors. Pages loaded up with dozens or hundreds of third-party calls can take longer to render or longer to become interactive.

What About Fourth-party Or Second-Party Services?

While the earliest, simplest third-party services were simple 1x1 pixel images used for tracking visitors, almost all third-party requests today load JavaScript into the browser. And JavaScript can certainly make requests for additional network resources. If these follow-on requests are to a different host or service, you might think of them as “fourth-party services”. If the fourth-party service, in turn, makes a request to yet another domain, then you get “fifth-party service” requests, and so forth. Technically, all of them might be “third parties” in the sense that they are neither you (the “first party”) nor your site visitor (the “second party”), but I think it helps to understand that these services are even more removed from your direct control than the ones you work directly with.

The most common scenario I see where fourth-party requests come into play is in advertising services. If you serve ads on your website through an ad broker, you may not even know what service will finally deliver the ad image that gets displayed in the browser.

Feeling like this is a little bit out of control? There’s at least one other way that resource requests you have no direct control over can impact your visitors’ experience. Sometimes, the visitor’s browser itself can be the origin of network activity.

For example, users can install browser plugins to suggest coupon codes when they are shopping, to scan web pages for malware, to play games or message friends, or do any number of other things. These plugins can fire off “second-party” requests in the middle of your page load, and there is nothing you can do about it. Unlike third-party services, the best you can do is be aware of what these second-party services are, so you know what to ignore when troubleshooting problems.

Create Your Own Request Map

As a discovery tool, request maps are great for identifying the source of third-party, fourth-party, fifth-party, etc., requests. They can also highlight very long redirection chains in your third-party traffic. Simon Hearne, an independent web performance consultant and one of the co-organizers of the London Web Performance Group, maintains an online Request Map tool that uses WebPageTest to get the data and Ghostery to visualize it.

A picture of a graph of resource request chains on a typical news media website
Graph of resource request chains on a typical news media website. (Large preview)

Ad Blockers Makes Sites Faster

In addition to the browser plugins mentioned above, users love to install ad blockers. While many are motivated simply by a desire to see fewer ads, ad blockers also often make web pages load faster. Maciej Kocemba published research findings from Opera that showed that a typical website with ads could be rendered 51% faster if the ads were blocked.

This is obviously a concern for any website owner that monetizes page impressions with ads. They may not realize it, but users may be motivated to block ads partly to deal with slow third-party and fourth-party resource requests that lead to frustrating experiences. Faster page loads may reduce the motivation to use ad blockers.

The Revenue Trade-off You Need To Think About

Poor performance of third-party services can have other business impacts even if your website does not use advertising. Researchers and major companies have been publishing case studies for years, proving that slower page load experiences impact business metrics, including conversion rate, revenue, bounce rate, and more.

No matter how valuable you think a particular third-party service is to your business, that benefit needs to be compared to the cost of lost visitor engagement. Can a fancy third-party custom font give your site a new look and feel? Yes. Will the conversion rate or session length go down slightly as users see slower page loads? Or will visitors find the new look and feel worth the wait?

More after jump! Continue reading below ↓

How To Identify Problematic Third-Party Services On Your Website

If you are like most websites, about half of the resource requests that load in your customers’ browsers — when they load a page from your website — are third-party requests. Identifying them should be straightforward.

Measuring Performance Impact

To quantify the performance impact of third-party resource requests on the user experience, we need to start by measuring page load performance. Many web performance measurement tools can measure the network load times of individual resource requests, and others can measure the client-side impacts of JavaScript resource requests. You may find that no single tool will answer every performance question you have about third parties. These tools fall into several categories.

Some tools that can be helpful in evaluating the impact of third-party resource requests are what you might describe as auditing tools. The most popular, by far, is the Google Lighthouse report (available in Chrome Developer Tools) and Google’s Page Speed Insights. These tools generally work with data from a single page load but go into some greater depth on impact than the tools designed for ongoing monitoring.

Synthetic web performance measurements use scripts to visit one or more pages on your website from one or more probe locations. Much like a laboratory environment (and depending to some degree on the features offered by the particular tool), you have control over the variables of the measurement. You can adjust what browser is used, the kind of network connection to employ, the locations to test from, whether or not the browser’s cache is empty or full, how frequently to take the measurements, and more.

Because most of the variables remain fixed from one test run to the next, synthetic measurements are great for measuring the impact of change but less capable of accurately or comprehensively identifying real visitor experience. They are more of a benchmark than a true measurement of real user experience. Some of the popular synthetic measurement tools are WebPageTest, SiteSpeed.io, Splunk Synthetic Monitoring, and Dynatrace.

For a more comprehensive measurement of visitor experience, you need Real User Measurements (RUM). RUM systems embed a small JavaScript payload onto every page of your site. The code interacts with industry-standard APIs implemented by modern browsers to collect performance data, augments it with additional custom data collection, and transmits this very high-resolution data about the page as a whole and every resource request.

The data may have some limitations, though — the only data that can be collected is what the APIs support, and Cross Origin Resource Sharing (CORS) restrictions in the browsers limit some details, especially around third-party resource requests. Some of the more popular RUM services are offered by Akamai, New Relic, Dynatrace, and AppDynamics.

Example dashboard in Akamai’s mPulse Real User Measurement service
Example dashboard in Akamai’s mPulse Real User Measurement service. (Large preview)

What To Measure

Third-party resource requests can impact the user experience in several different ways, depending on whether they load early in the page load process or after the page is mostly complete. The risk you should be looking for with the measurement data you are collecting include:

  • Delaying initial render
    Resources that load prior to the initial page render (or First Contentful Paint) can be the most impactful overall. Many studies have shown that site visitors are more sensitive to delays at this point in the page load experience than any point after some visual progress has been achieved. Look for third-party requests that force new DNS lookups, require establishing connections to new origins, introduce redirection chains, include substantial client-side processing delay, or take a long time to download.
  • Other blocking effects
    Any JavaScript resource that blocks other resources from being requested until its processing is completed is a concern. A third-party font request could cause render-blocking. Look for third-party JavaScript resources that block other JavaScript resources that are not being loaded asynchronously from being requested in a timely manner. Avoid third-party requests that introduce contention for scarce resources like bandwidth or CPU utilization. If a third-party resource request is blocking, consider alternatives or approaches to mitigate the risk if the third party is slower than normal or fails.
  • Single Points of Failure (SPOFs)
    A resource request can be considered a SPOF if the web page fails to load or the load time is disastrously longer should the resource itself fail to load. For example, if a third-party host is down and your request takes 60 seconds to time out, if the initial render of the page is delayed 60 seconds as a result, then this is a SPOF.

Testing The Impact Of Specific Requests

Once you have identified potentially impactful third-party resource requests, measuring the specific performance impact of those requests can be challenging. Trying to separate the impact of a single request from all the others can be akin to trying to break down an alloy into its constituent metals because third-party requests are often made in parallel with first-party requests or third-party requests to other hosts, and they are competing with each other for the limited network, CPU, and memory resources of the client. Even with highly-detailed RUM or synthetic measurement data, it may not be practical.

The best way to approach the problem is through applied testing. Specifically, deliver pages with the third-party request or service as normal, and compare the performance to pages delivered without that particular third-party service but which are otherwise identical.

This is easiest to do with synthetic measurement tools. You can blackhole a particular domain so that the synthetic browser will never make the requests in the first place, simulating a page loading without that service on it. This can inform you about the performance (load times) impact of that third-party service. WebPageTest — a free synthetic measurement service (see the following three figures below for an example) — makes this easy.

A screenshot of configuring WebPageTest to run a test measurement that simulates a failure of the Google Fonts third-party service.
Configuring WebPageTest to run a test measurement that simulates a failure of the Google Fonts third-party service. (Large preview)
A screenshot with filmstripes with performance (load times)
Single Point of Failure: A website that relies on a third-party font service takes less than 2 seconds to get to the First Contentful Paint when everything works as expected (top filmstrip). (Large preview)
A screenshot with filmstripes with performance (load times)
Single Point of Failure: A website that relies on a third-party font service takes more than 30 seconds to get to the First Contentful Paint when that third-party fails to respond to requests (bottom filmstrip). (

A great way to start managing the impacts of third-party requests on your site’s user experience is to audit your site to see which and how many third-party domains and requests are being used. Next, use performance measurement tools to identify those that have the potential to degrade the user experience through render-blocking, resource contention, or single points of failure.

As you apply changes to mitigate the impact of third parties, develop a plan to use ongoing testing (such as Real User Measurement Services) to keep on top of site changes and unexpected changes to your third-party services.

By carefully considering how third-party requests will fit into your site during the design stage, you can avoid the most significant negative impacts. With ongoing performance monitoring, you can ensure that new problems with third-party requests are identified early. Don’t sink your website with third parties!

slots empire bonus codes
 Editorial (yk, il)