Assets are fetched through a redirect

LowConfirmedQuick winperf.assets.asset-redirects

What this check looks for

‹count› of the files this page loads answer with a redirect before the real file is served. Each redirect costs the visitor a full round trip to the server before the download even starts.

Why it matters

A redirected asset is pure waiting: a connection, a request and a response that carry no content. On a slow mobile connection each one is a fraction of a second added to every visit, and they are almost always the result of a stale URL in the markup rather than anything intentional.

When the check passes, your report says: “Assets are served directly, with no redirect in the way”.

What it costs your score

When this check fails it removes 3 points from your Performance score, before the status, confidence and repeat multipliers are applied. Performance carries a weight of 8 in the overall score.

It shares the performance.assets family ceiling of 25 points: however many findings that family produces, together they cannot remove more than that from Performance. One underlying problem showing up in several places is still one problem.

Severity: low
Default confidence: confirmed
Status when triggered: warn
Deduction: 3 points
Family cap: performance.assets · 25
Category: Performance
Module: Perf assets
Fix owned by: user
In the ruleset since: 2026.09

How the whole score is calculated

How to fix it

Point the page's markup at the URL the server actually serves, so no asset needs a redirect.

Each file listed above costs the visitor an extra round trip before its bytes begin to arrive, and the fix is a string in your template.

Take each URL from the list above and request it yourself. The location header in the response tells you the URL the server would rather serve.
Replace the URL in your template, theme or bundler configuration with that one, including the trailing slash if the redirect adds one.
Write https:// rather than http:// for any absolute asset URL. A protocol redirect is the most common cause of this finding and the easiest to miss, because the page still works.
After a migration, fix the markup rather than relying on the rewrite that keeps the old path alive. The rewrite should be a safety net for old links, not the path your own pages take.
Check asset URLs that are built by string concatenation in code; those are where a stale hostname usually survives a redesign.

How to confirm it worked

Re-run this scan and confirm the redirected-asset count has dropped to zero.
curl -sSI https://‹host›/path/to/asset — expect a 200, not a 301 or 302

A named slot like ‹domain› — and the braces left in the configuration below — is filled in with your own values when this rule appears on a report.

Remediation by platform

Page HTML

<!-- Costs a redirect: the server sends 301 to the https URL. -->
<link rel="stylesheet" href="http://‹host›/css/site.css">

<!-- Costs a redirect: the server sends 301 to add the trailing slash. -->
<img src="/assets/logo" alt="">

<!-- No redirect: the URL the server actually serves. -->
<link rel="stylesheet" href="https://‹host›/css/site.css">

A protocol-relative //host/path avoids the scheme redirect but reintroduces an old problem on pages served over http; write the scheme out. Both examples still render correctly today, which is exactly why they survive unnoticed.

Technical detail

Subresources answered through a redirect: ‹count›.

‹summary›

‹detail›

**How this was measured, and what it could not see.** We fetched the page and then the subresources its HTML declares, and read what the server sent back. No browser was involved, so nothing here depends on how fast our machine is — but equally, **a resource that a script loads after the page arrives is invisible to this check**. A page that assembles its own asset list at runtime will look lighter here than it is. The number of subresources the page declared, and how many of those we asked about, are both stated in the page-weight finding; where they differ, this section examined a prioritised sample rather than the whole page.

**We report the hop count, not a time cost.** How long a redirect costs depends on the visitor's latency to the server, which we cannot know and will not model. What is certain is the shape: each hop is one extra request-and-response before any of the file arrives, and on a new connection it may also carry the cost of a fresh DNS lookup and TLS handshake.

The usual causes are worth checking in this order: a URL written without its trailing slash that the server then redirects to add; http:// in the markup on a site that redirects to HTTPS; an old asset path kept alive by a rewrite after a migration; and a CDN hostname that redirects to its canonical form. All four are fixed in the same place — the markup — by writing the URL the server actually serves.

A redirect on the **page itself** is a different matter and is reported separately under the HTTP redirect checks, which look at the chain, its length and whether it downgrades. This finding is only about the page's subresources.

Standards and references

Test this on your domain

Run the check that produces this finding, on its own, against any domain.

Open the perf assets checker