Don’t Sink Your Website With Third Parties — Smashing Magazine

The Hidden Cost of Built-In Extras

Most teams pour effort into first-party performance: optimized images, lean CSS, carefully tuned JavaScript. Yet the average page today is crowded with requests that have nothing to do with your own servers. These third-party resources — analytics scripts, advertising tags, custom fonts, social widgets — are often added by marketing colleagues or embedded through third-party tools, and they can silently erode the experience you worked so hard to build.

Two questions follow. First, how do you measure the impact of these requests? Second, how do you control what you don't own? The answers matter because nearly every modern site depends on third-party code to some degree, and the trade-offs are rarely reviewed once a script is live.

Defining the Parties Involved

Any HTML, CSS, JavaScript, image, or font that you host and serve from your own domain is a first-party resource. Everything else that loads when a visitor opens your pages comes from another party — usually another commercial enterprise. Infrastructure services like cloud platforms or CDNs are a separate category; this discussion focuses instead on third-party resources that are embedded directly into your page design and execute in the visitor's browser.

The HTTP Archive's 2021 Web Almanac quantified the scale of the problem: 94.4% of mobile sites and 94.1% of desktop sites use at least one third-party resource, and roughly 45% of all requests on both mobile and desktop are third-party requests.

These services share three defining characteristics:

• They are hosted on a shared and public origin.
• They are widely used across many different sites.
• They are uninfluenced by any individual site owner.

The convenience is obvious — you don't have to build every feature yourself, and tools can be added or removed without code changes. The downside is equally clear: a page loaded with dozens of third-party calls can take longer to render and longer to become interactive.

Beyond the Third Party

Most early third-party services were simple 1x1 tracking pixels. Today, nearly all of them load JavaScript, and JavaScript makes more network requests. When those follow-on calls go to a different host, you're dealing with what is effectively a fourth-party service. In turn, a fourth-party service may make requests to yet another domain, creating fifth-party traffic. Technically all of them are third parties — neither you (the first party) nor the visitor (the second party) — but each step moves further from your control.

Advertising is the most common place this chain appears. If you serve ads through a broker, you often don't know which service will ultimately deliver the image displayed in the browser.

There is another kind of network activity you can't control at all. A visitor's browser itself can be the origin of requests when they run extensions — coupon-code finders, malware scanners, messaging tools, or games. These second-party requests fire mid-page-load and are impossible to prevent. The best you can do is know they exist so you can ignore them when troubleshooting performance issues.

Mapping Your Request Graph

Request maps are a useful discovery tool for identifying the source of multi-party traffic and spotting long redirection chains. Consultant Simon Hearne, co-organizer of the London Web Performance Group, maintains an online Request Map tool that pairs WebPageTest data with Ghostery for visualization.

The Performance Case for Ad Blocking

Users install ad blockers for many reasons, but faster page loads are a major part of the appeal. Research published by Opera's Maciej Kocemba found that a typical site with ads can render 51% faster when those ads are blocked.

That finding is concerning for any publisher that monetizes impressions. The irony is that slow third-party and fourth-party requests give users another motivation to block ads — which suggests that improving page performance can reduce the incentive to use blockers in the first place.

Weighing Value Against Engagement

Even sites without advertising face business consequences from slow third-party code. Published case studies from researchers and major companies show a consistent relationship between slower page loads and worse conversion rates, revenue, and bounce rates.

The decision to keep or remove a third-party service should therefore be a business calculation: the value the service provides must be measured against lost visitor engagement. A custom font might deliver a distinctive look, but if conversion rates dip as pages load slower, the aesthetic wins may not justify the cost.

Pinpointing the Third Parties That Hurt

On a typical page, roughly half of all resource requests come from third parties. The first task is simply identifying which of those requests are causing measurable harm to the user experience.

Choosing the Right Measurement Toolset

No single performance tool answers every question about third-party impact. The practical approach is to combine tools from a few categories.

Auditing tools, led by Google Lighthouse (built into Chrome Developer Tools) and Google Page Speed Insights, provide deep analysis of a single page load. They excel at diagnosing specific problems but are not designed for continuous tracking.

Synthetic measurement tools run scripted visits to your pages from controlled probe locations. Because they operate in a lab-like environment, you control variables such as browser type, network conditions, geographic origin, cache state, and test frequency. With conditions held constant across runs, synthetic tools are ideal for measuring the effect of a change, though they provide a benchmark rather than a true picture of real visitor experiences. Popular options include WebPageTest, SiteSpeed.io, Splunk Synthetic Monitoring, and Dynatrace.

For a complete view of actual visitor experience, you need Real User Measurements (RUM). A RUM system injects a small JavaScript payload into every page, using industry-standard browser APIs to collect high-resolution performance data on the page and each of its resource requests. RUM data has limits: you can only gather what the APIs expose, and CORS restrictions often obscure details about third-party requests. Major RUM providers include Akamai, New Relic, Dynatrace, and AppDynamics.

Key Risks to Look For

Third-party impact varies depending on when a request fires during the page lifecycle. Focus your analysis on these failure modes:

• Delaying initial render. Requests that block the first paint are often the most damaging; visitors react more strongly to delays before any visual feedback appears. Watch for third-party requests that force new DNS lookups, open connections to unfamiliar origins, trigger redirect chains, or carry heavy client-side processing.
• Other blocking effects. Any JavaScript that prevents subsequent resources from being requested until it finishes is a red flag. Render-blocking third-party fonts are a common example. Also look for scripts that block non-async resources or compete with first-party content for limited bandwidth and CPU. If a blocker is slow or fails, the entire page suffers.
• Single points of failure (SPOFs). A request becomes a SPOF when its failure or a time-out (say, 60 seconds) delays initial render for that entire duration. If the page cannot recover without that resource, the dependency is unacceptable.

Isolating a Specific Request's Impact

Measuring the individual effect of one third-party request is hard. Requests run in parallel with first-party and other third-party calls, all competing for the same network, CPU, and memory. Even rich RUM or synthetic data rarely lets you separate one request's contribution cleanly.

The reliable method is applied testing: compare an identical page with and without the target third-party service. Synthetic tools make this straightforward by letting you blackhole a particular domain so the browser never makes those requests. WebPageTest, a free synthetic service, supports this easily.

A more advanced alternative is multivariate testing on your live site. Serve the page with the third-party tag to one visitor segment and a clean version to another. With RUM in place, you can compare real-world performance and business metrics — bounce rate, conversion, session length — between the segments. This setup is a significant engineering investment, but it delivers the most accurate view of a third party's true cost.

Cutting the Cost of Third-Party Requests

Once you have a performance baseline and tooling to measure how individual third-party requests affect load times, the next step is applying strategies that reduce their impact. Some of these moves are technical; others are organizational.

Audit and Prune

The single most effective optimization is removing tags you no longer need. No request is faster than one that is never made. In practice, this is often the hardest change to push through because third-party tags usually have multiple internal owners. A few steps make it manageable:

• Set a recurring audit schedule. Run an audit quarterly using a Real User Monitoring (RUM) service that captures every page view. If an unfamiliar third-party domain appears in a meaningful share of views, investigate immediately. It might be a new tag added by a colleague, or a fourth-party request introduced by an existing service changing behavior. Either way, identify who uses it.
• Maintain a register of third-party services. For each one, record the internal owner, how it gets onto the page (hard-coded, injected via CDN config, or through a tag manager), and when the contract expires. You need to know how to suspend or remove any service quickly if it breaks or slows the site down.
• Hold periodic stakeholder reviews. Discuss every active third-party service and weigh its business value against its cost. If a service is no longer used, consider removing it even when it is under contract.

Align Geographies and Load Order

Third-party hosts are not always positioned close to your audience. A service serving from the United States to mostly European visitors forces traffic across the Atlantic twice per request. Some services run their own CDN; others do not. Check with a tool like CDN Finder to see which CDNs, if any, a tag uses, and adjust the hostname or parameters you request accordingly.

Parser-blocking scripts are one of the most damaging behaviors a third party can exhibit. Browsers historically block subsequent resource requests while a script loads and evaluates, which keeps page-load behavior predictable but slow. WebPageTest and PageSpeed Insights both highlight resource requests that block others. Run them against a representative set of URLs to find all offenders on your site.

Depending on how the tag is added, you may be able to convert it from blocking to non-blocking. Modern browsers support three modes:

• <script> — Without an attribute, most browsers pause parsing until the script loads and evaluates. This creates not just a performance hit but also a single point of failure (SPOF).
• <script async> — Downloads in parallel with HTML parsing, evaluates immediately on completion. Use this when the script must run early in the load.
• <script defer> — Downloads in parallel, evaluates only after the document is parsed. Choose this for tags whose execution matters less than how fast the page renders.

Render-Blocking CSS and Fonts

CSS blocks rendering by design; browsers will not paint content that might need restyling mid-load. Best practice is still to load CSS as early as possible so the browser has everything it needs to render promptly.

Third-party CSS is rare outside custom font delivery, but when it exists, load it directly in the page HTML or through your own CDN rather than via a tag manager, which adds an extra hop for a critical resource.

Custom fonts present a similar render-blocking problem because browsers avoid swapping typefaces mid-load. Google Fonts and Adobe Typekit are the most common third-party sources. Consider these options:

• Question the need for custom fonts. System fonts in modern browsers are often visually close to popular webfonts. If the brand lift is marginal, dropping custom fonts improves load time directly.
• Self-host if licensing allows. Serving fonts from your own domain removes the SPOF, gives you control over caching headers, and spares visitors a connection to yet another host. The trade-off is extra bandwidth cost on your CDN.
• Use font-display properties. Setting font-display: swap shows system fonts until the custom font is ready, then swaps it in. The fallback value introduces a short blocking period before behaving like swap. CSS-Tricks documents the options well.

Shifting Work Off the Main Thread

One emerging approach is moving third-party scripts to Web Workers, keeping the main thread for your own critical code. This is not straightforward: Web Workers can only communicate asynchronously, while many third-party scripts expect synchronous access to the document and window.

Partytown is an open-source library that builds a communication layer to enable this. It is early-stage, so plan for extensive testing, and note that it may conflict with tag manager setups.

Akamai Script Management takes a different path using Service Workers. It acts as an in-browser proxy with a policy engine for handling third-party requests. Policies can block, defer, or shorten the timeout for specific requests. If a render-blocking third party goes down, for example, the policy can reduce how long the browser waits before giving up, mitigating the impact on the visitor experience.

Sustaining the Gain

Third-party requests are a permanent part of the modern web, and they bring real business value. The key is managing their cost to user experience.

Start with an audit to catalogue which third-party domains appear on your pages, then measure which of those degrade performance via render blocking, resource contention, or SPOF risk. As you make changes, build a routine of ongoing testing with RUM services to catch regressions from your own site changes and from third-party services altering their behavior without notice.

The cheapest fixes happen at design time. The most durable protections come from monitoring that surfaces new problems early, before they sink the user experience.