Resource Domain Count

This check is informational and does not affect your score (weight 0). It is the broader companion to External Script Count: that one counts third-party domains serving JavaScript; this one counts ALL distinct external domains contacted by the page (scripts, CSS, images, fonts, XHR/fetch, iframes, web fonts, video sources). Each domain is a separate trust dependency, DNS lookup, and potential privacy leak.

How the check works

Per primary host, the check walks the response HTML and tallies unique non-same-origin domains across all resource types. Bands:

• 0-5 distinct domains: 1.0 (informational pass).
• 6-10 domains: 0.67. Reason: moderate_external_resources.
• 11-20 domains: 0.33. Reason: high_external_resources.
• 21+ domains: 0.0. Reason: excessive_external_resources.

Verdict and score are reported but do not affect the overall RedScore. Reasons appear in evidence as advisory findings.

How the verdict maps to evidence

Evidence shows third_party_resource_domain_count plus resource_domains_by_type, which breaks the count down by resource kind so you can see which categories are dominant.

Special states

• Not Applicable: response is not HTML, or primary serves a default/empty placeholder.
• Degraded: probe data unavailable.

How to interpret each band

0-5 (healthy)

Self-contained site or one main CDN plus a few specific integrations. No structural concern. Audit the by-type breakdown for any surprises (an unfamiliar font CDN, an unexpected image host).

6-10 (moderate)

Typical pattern: own CDN, font CDN (Google Fonts), analytics, tag manager, image CDN, plus a couple of integrations (chat, support widget). Operationally normal. The audit question is which are essential vs accumulated.

11-20 (high)

Marketing-heavy or aggressive integration sprawl. Each domain compounds DNS lookup latency on first paint, expands the privacy surface, and adds a supply-chain risk. Run a dedicated audit:

• Use the resource_domains_by_type breakdown. Heavy on scripts? See External Script Count. Heavy on images? Self-host or consolidate to one CDN. Heavy on XHR? Audit which APIs are still in use.
• Trace each domain to a business owner. Anything without an owner is a candidate for removal.
• Look for substitution opportunities: 5 ad-platform pixels can often consolidate via one tag manager domain (without reducing functionality).

21+ (excessive)

Structural issue. News sites, ad-monetized content, and aggressive marketing pages typically land here. The fix is not just trimming individual scripts; it is reconsidering how the page is built.

• Page-load performance is almost certainly poor; DNS / TLS overhead alone can dominate.
• Privacy compliance is hard to track when this many third parties are involved; document each one's data flow.
• Consider a reverse-proxy strategy: serve all third-party assets through your own CDN at the same origin, eliminating both the domain count and the cross-origin privacy leak.

Reduction strategies

• Self-host static assets. Fonts, jQuery, Bootstrap, image libraries: serve them from your own CDN. Each removed external domain is one less DNS lookup, one less trust dependency, and (for fonts) one less privacy leak (Google Fonts shares IP with Google).
• Consolidate CDNs. One CDN for all your assets is simpler than one per type. Most CDN providers accept arbitrary content via their object-storage or origin-pull integrations.
• Tag manager strategy. Many marketing scripts can be consolidated under a single tag manager domain. Reduces the count even though the same scripts run.
• Reverse-proxy third-party assets. Serve external scripts and fonts through your own domain by proxying them; can also enable SRI on otherwise-dynamic content. Be mindful of caching and ToS implications.
• Audit on a schedule. Quarterly resource-domain audit: which are still needed, which are still firing, which are stale.
• Lazy-load and gate behind consent. The count does not change, but the actual blast radius and privacy impact does. Pair with consent gating from the Tracker Presence guide.

Verify

• DevTools → Network. Group by domain (some browsers offer this directly; otherwise sort by Initiator or Domain).
• curl -sL https://yourdomain.tld | grep -oE '(src|href|action|data-[a-z0-9-]+)="https?://[^"]+' | grep -oE 'https?://[^/]+' | sort -u listing every external URL host.
• Browser extensions that visualize third-party domains (BuiltWith, Wappalyzer, Privacy Badger).
• Re-run the RedScore lookup. Domain count updates immediately on the next scan.

Common pitfalls

• Treating informational as no-action. Score does not move, but the structural risk is real. Use this check as input to your platform team's reduction backlog.
• Overlap with External Script Count. The two checks share data; resource_domain_count is the superset (all resource types vs just scripts). Findings often correlate.
• Subdomain double-counting. Two scripts from cdn.example.com count as one domain; two from cdn.example.com and assets.example.com count as two. Subdomain consolidation is real reduction; merging .example.com subdomains under one host drops the count.
• Reverse proxy without freshness. If you proxy external assets through your own origin and they update upstream, your cached version stales. Plan refresh cadence.
• Self-hosting third-party JS / CSS without licensing review. Most open-source libraries permit redistribution; commercial scripts may not. Read the ToS.
• Privacy improvement only if scripts also stop firing. Consolidating tracker domains via a tag manager reduces the count but the same data still flows. The privacy improvement comes from removing trackers, not relabeling them.