• 21 min read
• Performance , Optimization , User Experience
• Share on Twitter ,  LinkedIn

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.

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?

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 R eal U ser M easurements ( 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 C ross O rigin R esource S haring ( 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 .

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 more sophisticated approach is to perform multivariate testing on your production site. In a multivariate test, you serve a version of the page with the third-party tag on it to one segment of your visitor population, and the other segment gets a version of the page without the third-party tag.

By using RUM tools, you can directly measure the real-world performance differences between the two test segments as well as the effects on business metrics (such as bounce rate, conversion or session length). Managing multivariate testing is a significant undertaking, but it can pay off in the long run.

Design Optimizations

Once you have a baseline of your site performance and some tools to test the basic performance impact of key third-party resource requests, it is time to implement some strategies to mitigate the impact that third-party services can have on performance.

Consider Removing Unneeded Services

By far, the most impactful change you can make is to remove any obsolete, unused, or unnecessary third-party tags from your site. After all, no resource loads faster than not making a resource request at all. Ironically, this may also be the most challenging optimization to put into practice. In many organizations, third-party tags or services “belong” to a variety of stakeholders, and finding a way to manage them is as much a cultural challenge as a technical one. Some basic steps to take include:

1. Audit all third-party requests appearing on your pages on a periodic basis (for example, quarterly).
   To make sure you capture all third-party requests, use a RUM service that collects data about every page view. If a third-party domain is showing up in more than a small fraction of page views and you do not already know what it is, find out immediately. New third-party tags may have been added by some stakeholders within your organization, or you may be finding a fourth-party tag because a third-party service changed its behavior. Either way, you need to understand what the third-party tags are and who in your organization is using them.
2. Keep records on third-party services.
   Specifically, you want to know who the internal stakeholder is that “owns” that service and how it gets on the site. Is it hard-coded into the page HTML source? Is there JavaScript injected on the page by a CDN configuration? Are you using one (or more than one) tag manager? When does the contract with that service expire? The important thing is to have all the information on hand to know how to suspend or remove every third-party service if it becomes a performance issue or suddenly stops working, and who in your organization that is going to need to know.
3. Consider a periodic stakeholders meeting that includes a discussion of all third-party services to review the cost/benefit they introduce to the business. Even if it is still under contract, consider removing third-party services that stakeholders no longer use.

Geographically Align Your Third-Party Services With Your Visitors

If most of your visitors are in Europe, but a third-party service you are using is serving its resource content from the United States, those requests will likely have very slow load times as the traffic must cross an ocean each way. Some third-party services use a CDN of their own to ensure that they are serving requests from locations close to your visitors, but not all will do so. You may need to ensure that you are using appropriate hostnames or parameters in your requests. CDN Finder is a convenient tool to investigate which CDNs (if any) a third-party tag is using.

Loading Scripts Asynchronously

Blocking other resource requests from being made by the browser (often called “parser blocking”) is one of the most impactful (in a negative way) things a third-party resource can do. Historically, browsers have blocked while loading scripts to ensure that the page load experience is predictable . If scripts always load and evaluate in the same order, there are no surprises. The downside to this is that it takes longer to load the page.

Fortunately, identifying and blocking third-party script resources is relatively easy. Both WebPageTest and PageSpeed Insights (free-to-use tools) highlight resource requests that block other resource requests from being made. These tools work on one page (URL) at a time, so you will need to use them on a representative set of URLs to pick up all the blocking tags on your site.

Depending on how the third-party tag gets onto the page, you may be able to change a blocking script into a non-blocking script. Modern browsers support attributes to the script tag that gives the browser flexibility to load resources in a non-blocking manner. These are your basic options:

• 竞技宝(天津)积分APP v3.4 电竞王者注册直播(电竞王者抽注今日) pc加拿大28计划分析最稳网页 28加拿大记录下载开奖 pentaq电竞 大圣电竞