Recommended Free Tools
iTechGuides is reader-supported. When you buy through links on our site, we may earn an affiliate commission. As an Amazon Associate I earn from qualifying purchases. Learn more
If your React hotfix is deployed but users still see the old app, first find out which response is stale: the HTML entry page, a JavaScript or CSS file, a shared cache, or a service worker’s cached response. Then fix that layer. A reliable default is to make HTML revalidate before reuse and cache content-fingerprinted assets for a long time—but only while each asset URL always serves the same bytes.
Why isn’t my React update showing up?
A successful deployment and a visible update in a user’s browser are separate events. The browser may reuse a stored response, an intermediary cache may return an older response, or a service worker may serve cached resources without making a network request. The symptom alone does not prove NGINX is responsible.
Start by distinguishing three possibilities: the HTML is old; the HTML is current but points to old JavaScript or CSS URLs; or the network delivers the current app but the browser still renders an older cached experience. React’s documentation explains that hashed asset filenames let distinct builds use distinct filenames, which supports long-term caching when URLs are immutable: React production build documentation.
Trace the stale response before changing cache settings
- Compare the received HTML with the current build. Inspect the asset URLs referenced by the HTML and compare them with the current build output or asset manifest. If the HTML references an older filename, focus on the HTML response or a cache serving it.
- Request the HTML and a fingerprinted asset separately. Record each response’s status, body or build marker,
Cache-Control, and anyETagorLast-Modifiedheader. Use the public hostname, and compare against the origin directly when possible. If the responses differ, a proxy or CDN between the origin and users may be involved. - Check which NGINX server and location handle each request. Review the active configuration for the HTML path and asset paths, including
add_header,expires, and any more specific locations. Then inspect the actual responses rather than assuming a header configured at the server level reaches every location. - Verify the deployed files and route fallback. Confirm NGINX serves the newly published build from the intended document root and that the requested asset files exist. Review the order of
try_fileschecks: an SPA route may fall back to the entry HTML, but a missing JavaScript or CSS file should return a real not-found response instead of the HTML shell. - If the network response is current, inspect the browser’s service worker. Check whether the app registers a service worker and how its fetch handler selects cached responses. MDN notes that service workers can provide cached resources without a network request and recommends cleaning up old cache versions in the
activateevent: MDN guide to caching in progressive web apps.
Set different cache policies for HTML and fingerprinted assets
HTML is mutable: it needs to point users to the current build’s asset URLs. A suitable policy is Cache-Control: no-cache, which allows a response to be stored but requires it to be validated before reuse. By contrast, no-store tells caches not to store a response; it does not delete an older response already stored for that URL. MDN explains these directives and the role of versioned asset URLs in its HTTP caching guide.
For content-fingerprinted JavaScript, CSS, images, or fonts, a long lifetime can avoid repeated validation when each content change produces a new URL. MDN gives Cache-Control: public, max-age=31536000, immutable as an example for cache-busted resources. The value is an example policy—not a requirement for every app—and should be used only if the deployment guarantees that a URL’s contents never change.
| Resource | Practical policy | Why it fits |
|---|---|---|
| HTML entry document | Cache-Control: no-cache |
Allows storage but requires validation before reuse, so the document can discover current asset URLs. |
| Content-fingerprinted assets | Cache-Control: public, max-age=31536000, immutable |
Suitable as an example long-lived policy when changed content always gets a new URL. |
| Missing static asset | Return a not-found response | Prevents a missing script or stylesheet from receiving the SPA HTML entry page. |
Apply the policy in NGINX without hiding missing assets
This illustrative configuration separates the HTML entry from fingerprinted assets and checks for files before using an SPA fallback. Adapt the paths and locations to the build output and the rest of your server configuration:
server {
root /srv/www/my-react-app;
location = /index.html {
add_header Cache-Control "no-cache";
}
location /assets/ {
# Only use for assets whose filenames are content-fingerprinted.
add_header Cache-Control "public, max-age=31536000, immutable";
try_files $uri =404;
}
location / {
try_files $uri $uri/ /index.html;
}
}NGINX’s try_files directive checks paths in order and internally redirects to the final URI when none match. Its behavior is documented in the NGINX core module reference. In the example, the asset location checks for a file and returns 404 if it is missing; the general location checks files and directories before falling back to /index.html.
Check header behavior in the actual configuration. NGINX’s add_header normally applies only to specified response status codes; the always parameter extends it to other codes. Under the standard inheritance model, a child configuration level inherits parent add_header directives only when it defines none of its own. A location that adds a cache header can therefore stop inheriting headers set at a higher level. See the NGINX headers module reference.
Rank #3
- Upgraded Two Zipper Pockets: Forvencer server books feature two secure zipper pockets for better organization of coins, cash, and receipts, ensuring that everything you collect has a safe and secure place
- Smart Storage & Quick Access: Designed with 8 multi-functional compartments, the right side includes a guest receipt pad, while the left has a money pocket, ticket pocket, and credit card slot. Two small clear pockets store bills, receipts, and other visible items. A stitched pen loop ensures you always have your favorite pen ready
- High-quality & Easy to Clean: Crafted from high-quality PU leather with heavy-duty stitching, this server book is built to last. It resists tears, scratches, and its waterproof surface makes cleaning easy with just a damp cloth or a non-chlorine sanitizer
- Perfect Fit for Your Apron: Measuring 5” x 8”, this compact organizer is slightly smaller than other models, making it ideal for bending or sitting while carrying in your server apron. It holds everything a waitress needs—a place for everything
- What's Included: This server organizer comes with multiple open and zippered pockets to store money, receipts, tips, etc. Clear sleeves are perfect for keeping menus or special lists while serving. Available in a variety of colors, allowing you to express yourself even when in uniform
The example is not a universal drop-in. Confirm that /assets/ matches the build’s actual asset path, that no other location takes precedence, and that API, dotfile, and base-path routing are handled appropriately. Verify the resulting headers and status codes on real responses.
Roll out hotfixes without breaking open sessions or rollback
- Publish the complete new set of fingerprinted assets before switching the HTML to reference them.
- Keep old fingerprinted files available long enough for already-open clients and rolling deployments to request them; align retention with the release and rollback process.
- After deployment, check the public HTML and a referenced asset, then verify the site in both a fresh browser session and a session that previously showed the old app.
Keeping old files is an operational safeguard for versioned URLs: clients may still hold HTML from an earlier release and request the asset names it references. React’s documentation describes why hashed filenames distinguish builds; it does not prescribe a retention period for a particular deployment.
Quick Recap
Rank #4
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
