Broken page resources

A stylesheet: the page renders with browser default styles, which is unmistakable and usually reported within minutes.

A script: whatever it implemented stops working, silently. A form that no longer submits, a menu that no longer opens, an analytics tag that no longer records.

A font: the fallback is used, which is a visual change most people do not notice and a layout shift most measurements do.

An image: a gap or a broken-image indicator, depending on whether dimensions were declared.

The script case is the one that survives longest, because nothing about the page looks wrong.

Asset URLs are generated by a build, so a path change affects every page using that template simultaneously.

A deployment that publishes the HTML before the assets, or fails partway, leaves every page referencing files that are not there.

A CDN purge that removes files the new build has not uploaded yet produces the same window.

A third-party script whose provider changed a URL breaks for everyone the moment they do it, with no deployment on your side.

Which makes this an incident rather than a gradual degradation, and one that a cached page can hide from the person who deployed it.

Fingerprinted filenames are what let assets carry a long cache lifetime, and they change on every build.

A visitor holding a cached HTML page requests the assets it names, which the new deployment has deleted.

The page then breaks for exactly the returning visitors a cache was meant to serve fastest.

Keeping the previous build's assets available for a period is the usual remedy, and it needs to be a deliberate deployment step.

A short cache lifetime on the HTML document limits the window, which is the same reason the document and the assets want opposite caching policies.

Fix the reference or restore the file, depending on which moved.

Deploy assets before the HTML that references them, so there is never a window where the markup is ahead of the files.

Keep the previous build's fingerprinted assets for a period rather than deleting them on publish.

Add a check to the deployment that fetches the referenced assets from the live site, which is a few lines and catches the whole class.

Monitor for error responses on asset paths, which is where this appears before anyone reports it.

Open a page with the network panel filtered to failed requests — a clean page shows none.

Do it in a private window, since your own cache may hold the files the site no longer serves.

Check several templates, since the broken reference is usually in one shared component.

Watch the console for the messages a blocked or missing script produces, which name the URL.

Check third-party URLs separately, since those break without any deployment on your side.

`performance.resource_errors` reports referenced resources answering with an error status, which is this problem directly.

`performance.request_count` and `performance.page_weight` describe the inventory those resources were drawn from.

`images.broken` reports images that failed to load, which is the same failure in the family where it is most visible.

`availability.broken_links` covers broken anchor targets, which is a different list from broken resource references.

`performance.scan_limits` states how much of the inventory was measured, so a clean result is not read as more coverage than it had.

A 404 transfers a few hundred bytes, so a broken resource makes a page lighter rather than heavier.

A review sorted by weight will therefore never surface it, and a page with a broken stylesheet can look excellent by every size measurement.

It also distorts the other figures: a page missing its main script measures a far better blocking time than it really has.

Which is why the error list is read before the weight ranking rather than alongside it.