Distinguish source, build output, and public response

RAONIZ’s Hosting configuration inspected on November 4, 2026 publishes dist. An edit without a build can leave old HTML in the output; a build without deployment leaves the public site unchanged. Establish which steps actually completed first.

Then compare the page address with the deployment target. A Firebase project can manage multiple Hosting sites, so the project name alone does not identify the intended domain. Check that the Hosting site, deploy target, and custom domain all identify the intended site before inspecting its public response.

Use different policies for HTML and assets

The current configuration assigns public, max-age=0, must-revalidate to HTML, XML, and text; public, max-age=31536000, immutable to /assets/**; and public, max-age=604800 to images. These express revalidation, long retention, and one-week retention respectively.

The combination lets HTML check for updates while hashed assets are retained on the assumption that a given URL keeps the same content. max-age=0 does not prohibit storage in the way no-store does. See the Cache-Control documentation for the directive meanings.

An overwritten image may need a new filename

HTML references styles and scripts through hashed names. An image overwritten under the same name may remain cached in a visitor’s browser. Giving revised artwork a new name and updating its reference makes the requested version easier to identify.

A long-cache path rule can also include unhashed files. Do not assume every matching file can safely be overwritten. Inspect both the asset URL actually referenced by HTML and the content delivered at that URL.

Read the response headers

With a terminal, inspect public headers as follows. For assets, copy the exact URL from the HTML’s src attribute. Inventing a hash would test a 404 response instead.

curl -I https://raoniz.com/en/
# Next: run curl -I with the exact asset URL found in that HTML.
  1. Check the status and final URL so a redirect is not leading you to another page.
  2. Check the HTML Cache-Control response together with the revised body content.
  3. Inspect the CSS, JavaScript, and image URLs that the HTML actually references.
  4. Compare a cache-disabled developer-tools session with an ordinary visit. One hard reload is not evidence that every visitor receives the revision.

A cache policy is not an availability promise

Long caching can reduce repeat transfers of the same asset, but does not establish availability or a specific response time. Follow observable causes such as Hosting state, actual responses, missing assets, DNS, and certificates when diagnosing an outage.

This is a guide to the inspected local configuration, not a measurement of every CDN node. See the Firebase Hosting cache documentation. The static-build note explains what happens before deployment.