Resource Hints (preload / preconnect) Audit
Resource hints are how you tell the browser "I'm going to ask for this shortly, start getting ready". Set up correctly they speed up the first paint noticeably; set up wrongly they do quiet damage, with resources downloading twice, connections opening for nothing and critical files queueing behind them. This tool doesn't just count the preload, preconnect, dns-prefetch and prefetch tags on your page; it checks whether each one is configured correctly and whether it corresponds to a resource the page actually loads.
What does each hint actually do?
The four look similar but do different jobs. preload downloads a specific file that will be used on THIS page, at high priority. prefetch downloads a file for a FUTURE page at low priority, while the browser is idle. preconnect establishes the TCP connection and TLS negotiation to an origin in advance, paying the connection cost up front even before it's clear which file will be requested. dns-prefetch only resolves the domain name without establishing a connection; it's preconnect's lightweight relative. The common mistake is using them interchangeably: preloading a resource for a future page spends bandwidth now, while prefetching this page's critical font won't get it there in time.
Why is the as attribute essential?
The as attribute on a preload tag tells the browser what kind of request the resource is: script, style, font or image. That information is needed not just for prioritization but for MATCHING. Without as, the browser downloads the file, but when the page requests it in its real context (from CSS, say, or a script tag) it can't associate that with what it already downloaded, so it downloads it a second time. A tag added to make the page faster ends up doubling the bandwidth. Chrome reports this in the console as a warning, but the warning usually goes unnoticed.
crossorigin on fonts: the most expensive silent mistake
Font requests are subject to CORS rules even when the file comes from the same domain, which means the browser requests the font in "anonymous" mode. If your preload tag has no crossorigin attribute, the preload happens in normal mode and doesn't match the real font request the CSS starts. The font downloads twice: once for nothing, once for real. Worse, the first download consumes bandwidth and can delay the real request, so adding a font preload produces a slower page than not adding one. The correct usage is to include the crossorigin attribute with no value at all; you don't need to write one.
Why does an unused preconnect do harm?
Every preconnect starts three pieces of work: DNS resolution, a TCP handshake and, for HTTPS, a TLS negotiation. If the page genuinely loads something from that origin, the cost is paid up front and turns into a gain. If it doesn't, it's pure waste: the connection opens, sits idle for a while and closes. On top of that, the number of connections a browser can hold at once is limited, so connections opened for nothing compete with your critical resources. This tool compares the origins you preconnect to against the scripts, styles and images the page actually loads, and flags the ones with nothing behind them. In practice these hints get added once and forgotten for years, so when a third-party service changes, dead preconnects are left behind.
Restraint: few and targeted
"More is better" doesn't apply to resource hints. More than four preconnects strains the socket pool; more than ten preloads destroys the meaning of prioritization, because if everything is a priority nothing is. A healthy setup usually looks like this: a crossorigin preload for the one or two fonts visible in the first paint, a preload for critical CSS, and preconnects for the two or three third-party origins you genuinely use. Anything beyond that, added without measurement, is most likely doing harm.
Your Questions
Frequently Asked Questions
What's the difference between preload and prefetch?
preload downloads a resource used on this page immediately, at high priority. prefetch downloads a resource for a page the user is likely to visit next, at low priority, while the browser is idle. Using prefetch for this page's critical resource won't get it there in time; using preload for a future page's resource spends bandwidth now.
What happens if I leave crossorigin off a font preload?
The font downloads twice. Font requests are subject to CORS mode even from the same origin, so a preload made without crossorigin doesn't match the real request the CSS starts. The net effect is that adding the preload slows the page down rather than speeding it up.
How many preconnects should I use?
More than four is generally not recommended, and they should go only to third-party origins genuinely used in the first paint. Every preconnect consumes connection resources, and the ones with nothing behind them compete with your critical requests.
Should I write both preconnect and dns-prefetch?
No. preconnect already includes DNS resolution, so writing both for the same origin is unnecessary. The habit of adding dns-prefetch as a fallback for preconnect is a leftover from worrying about very old browsers; there's no practical reason for it today.
I don't use any resource hints. Is that a problem?
No. Resource hints are optional optimizations, and a badly configured hint is worse than none. If a font or third-party resource is directly holding up your first paint, a targeted hint gives a measurable gain; if not, leaving them out is the right call.
Does this tool measure whether the hints actually help?
It measures whether they're configured correctly and whether they correspond to resources the page loads, which is how it catches waste and double downloads. Measuring the gain in milliseconds requires a real load in a browser; for that, use the lab test in our PageSpeed portal.