In the modern web world, no website stands alone. We rely on a complex web of third-party resources. This includes analytics, fonts, ad tech, consent managers and other third-party services to build rich experiences. But while these tools are transformative, they introduce a critical risk: you are putting your site’s speed and uptime in someone else’s hands.
Recent analysis of 15.7 million websites from the HTTP Archive reveals a startling fragility in how the web is built: 67% of websites request at least one render-blocking third-party resource. Depending on how that resource is loaded, if the provider experiences an outage, websites that rely on them may also be impacted.
At Fastly, we believe that while you may rely on third parties, you ultimately own your availability. Here is how to identify your risks and use the edge to take back control.
The “accidental” dependency
Many organizations intentionally use a multi-CDN strategy for redundancy. Hosting your site’s assets on a separate CDN-enabled domain is also common. However, thousands of companies are implementing an unintentional multi-CDN strategy that actually increases their risk.
We analyzed the top 1 million sites and found that 11,186 Fastly customers load render-blocking content from a CDN other than Fastly. This creates a hidden back door: you might trust your delivery to Fastly, but if you host critical assets elsewhere, your uptime is tied to their network.
Most notably, we found 5,476 Fastly-hosted websites that rely on render-blocking content from a CDN that recently experienced a few major outages.
For these sites, a disruption on that CDN can cascade into a failure on their own website. This risk is compounded by complexity: 56.5% of Fastly customers loading render-blocking content from other CDNs are loading it from multiple different CDNs
The 30-second white screen
What happens when a critical dependency fails? It’s not just a simple error to your end-users.
If a browser encounters a synchronously loaded render-blocking script or stylesheet hosted on an unresponsive external domain, it pauses rendering to wait for the resource. In many browsers, this results in a blank white screen until the connection times out.
This isn't theoretical. We saw this recently during a TikTok outage, where a failure in their analytics script (analytics.tiktok.com) caused headaches across the web. For some major retailers, it broke the favicon loading spinner; for others, it blocked the user experience entirely. Similarly, widespread outages at major CDNs have taken down thousands of sites that weren't even direct customers of that CDN, simply because they relied on a third-party widget hosted there.
Test your dependencies
You don't need to wait for the next vendor outage to see how your site handles failure. We recommend testing your third parties immediately, from within your browser:
DevTools blocking: In Chrome, you can block individual network requests or even a whole domain, to simulate a complete outage. In Firefox you can also block individual network requests.
DevTools throttling: In Chrome 145 and later, you can throttle individual network requests to simulate extreme latency (e.g., 10 seconds) on specific third-party tags to observe the impact on your First Contentful Paint (FCP).
If these tests leave you staring at a blank screen, you have a Single Point of Failure (SPOF).
The solution: from third-party to first-party
The most effective way to eliminate this risk is to move these assets under your control, under your own domain, by proxying third-party scripts through your own domain on Fastly. This technique offers three massive benefits:
Resilience: If the third-party origin fails, Fastly can serve a stale cached version of the script, keeping your site online.
Performance: Loading a script from your-site.com/analytics.js instead of third-party.com/analytics.js eliminates the need for a DNS lookup, TCP connection and TLS handshake. It allows for better HTTP prioritization because the connection is already open.
Control: If the request is delivered by your Fastly service, you are in control of how long the response can be cached on the CDN and browser and how it is compressed. Using Fastly to Brotli compress third party scripts could reduce their payloads by 10-15%
Privacy: Proxying allows you to strip sensitive headers like Cookie, X-Forwarded-For, and Fastly-Client-IP before the request reaches the vendor, preventing data leakage.
How it works
Some third-party scripts offer an easy way to serve them under your domain. Others you can transform using this pattern:
The third party is added to your Fastly service as a new backend.
The <script> tag in the HTML is modified to load from a local path, e.g. /services/analytics.
Requests to that path are transformed into the correct backend path by Fastly and routed to that backend.
The library code served by the third party is fetched into Fastly and transformed as needed, for example, to find and replace the third party's data collector URL with your proxy endpoint.
Subsequent requests made by the third-party script are sent to your Fastly service, inspected, and filtered as needed, then forwarded to the third party.
Dig into the details with Andrew as he covered this pattern in detail in Taming third parties with a single-origin website.
Conclusion
Third-party outages are inevitable, but their impact on your business doesn't have to be. Whether it's a social script or a font file, if it blocks your rendering, it threatens your revenue.
Audit your site for render-blocking third parties today. If you find them, let’s talk about how Fastly can help you proxy those assets, ensuring that even when the internet has a bad day, your site doesn’t.