第三方请求拦截演示 - 分析页面外部资源调用

Third-party requests are resource calls made by a webpage to domains different from the one you're visiting. Common examples include loading fonts from Google Fonts, analytics scripts from Google Analytics, social media widgets, CDN-hosted libraries, advertising pixels, and embedded videos. While many are harmless, some may track user behavior across websites.

Third-party resources can impact your website in several ways: Performance – each external request adds latency and may block rendering; Privacy – tracking scripts can collect user data; Security – external scripts may introduce vulnerabilities; Compliance – GDPR/CCPA regulations require disclosure of data-sharing practices. Auditing third-party dependencies is essential for responsible web development.

This tool uses the browser's Performance API (Resource Timing API) to capture all resource entries loaded by the current page. It compares each resource's domain against the page's primary domain. Resources from different domains are classified as third-party. Additionally, a built-in database of known tracker domains helps identify privacy-relevant requests. For demo purposes, simulated data showcases typical third-party scenarios.

Known trackers are domains commonly associated with user tracking, analytics, and advertising networks. Examples include Google Analytics (analytics.google.com), Facebook Pixel, DoubleClick, and various ad exchanges. The tool flags these based on a curated list. Note that not all flagged domains are malicious—many provide essential services—but transparency is key.

Yes, you can reduce or eliminate third-party requests by: self-hosting common libraries (jQuery, Bootstrap, fonts), using Content Security Policy (CSP) headers to restrict external resource loading, auditing and removing unnecessary plugins/widgets, and implementing Subresource Integrity (SRI) hashes for any remaining external scripts. Browser extensions like uBlock Origin can block trackers on the client side.

The Privacy Score (A–F) is a heuristic rating based on: the ratio of third-party to first-party requests, the number of known tracker domains detected, the total number of external domains contacted, and the types of data potentially exposed. A score of 'A' indicates minimal third-party exposure, while 'F' suggests extensive external data sharing. This is an educational metric and not a definitive security assessment.

1. Audit regularly – use tools like this one to identify all external resources. 2. Self-host – move fonts, JS libraries, and CSS frameworks to your own server. 3. Minimize plugins – each WordPress plugin or widget often adds external calls. 4. Use CSP headers to enforce loading policies. 5. Lazy-load non-critical resources. 6. Choose privacy-respecting alternatives (e.g., Plausible instead of Google Analytics).

The Performance API captures most resource loads—scripts, stylesheets, images, fonts, fetch/XHR requests, and iframes—that occur during page load and dynamic interactions. However, some requests may be missed: resources loaded in cross-origin iframes (without timing-allow-origin), service worker-cached responses, or resources blocked at the browser level before the API can record them. For a complete audit, server-side logging or proxy tools are recommended.