CDN Caching Troubleshooting for Script Bundles in UltraCart StoreFronts
Script CDN Caching Troubleshooting
Last Updated: July 29, 2026
Table of Contents
Overview
UltraCart StoreFronts automatically consolidate qualifying external <script> tags into unified .js bundle files, then push those bundles to the CDN (with GZip and minification applied) to reduce request count and improve page load time. Inline scripts are also moved to the bottom of the page by default as part of this optimization.
Because the unified bundle is a generated artifact rather than a direct copy of the merchant's source file, changes to a script's contents or filename do not always propagate to the unified bundle immediately. This document covers how to diagnose and work around cases where a merchant continues to see an old script version after publishing a change.
Note: As of this writing, there is no documented, merchant-facing method to force immediate regeneration or invalidation of an existing unified CDN bundle. The workarounds below reduce the chance of hitting stale content, but do not guarantee immediate propagation. See Escalation.
Quick Diagnostics
Symptom | Likely Cause | Next Step |
|---|---|---|
Old script logic runs after editing script content in place (same filename) | Unified bundle not yet regenerated by UltraCart's change-detection | Republish the StoreFront page; if still stale, see Common Issues |
Old script logic runs after renaming/versioning the script file (e.g. | Unified bundle still references the prior file, or a browser/CDN edge cache is serving the old bundle | Confirm via Debugging Tools; consider |
New script works in incognito but not in the merchant's regular browser | Client-side browser cache | Hard refresh ( |
New script works in incognito but still stale for other visitors | CDN edge cache still serving prior bundle | Escalate — see Escalation |
Script tagged | Script is not actually being excluded from unification (attribute typo, tag structure issue) | Verify rendered page source shows the script untouched, no |
Common Issues
Edited Script Content Not Reflected After Publish
Symptoms: Merchant edits the contents of an existing script (same filename/URL) and republishes the StoreFront page, but the browser continues to execute the old logic. Root Cause: UltraCart unifies external scripts into combined bundle files pushed to the CDN. The system relies on internal change detection to know when to regenerate a bundle, which can lag behind a content-only edit. Diagnosis: View page source and locate the unified bundle URL (look for a _mg suffix). Fetch that bundle URL directly and check whether it contains the old or new script logic. Solution: Republish the page again to re-trigger propagation. If the bundle is still stale after a republish and a hard refresh, this is a known gap in available workarounds — proceed to Escalation.
Renamed/Versioned Script Still Shows Old Behavior
Symptoms: Merchant renames the script file (e.g. my-script.js → my-script-v2.js) expecting a clean cache break, but the storefront still runs old logic. Root Cause: The unified bundle is keyed off UltraCart's own optimization process, not the merchant's filename alone. A rename does not guarantee the unified bundle is rebuilt on the expected timeline. Diagnosis: Confirm the new filename actually appears in the rendered page source. Then check whether that reference is being served from a unified bundle (_mg suffix) or as a standalone script tag. Solution: Add data-uc-ignore to the new script tag so UltraCart leaves it untouched (no unification, no CDN offload):
<script src="https://example.com/my-script-v2.js" data-uc-ignore></script>
Republish the page after adding the attribute. Note the trade-off: the script no longer benefits from CDN edge caching or request consolidation.
data-uc-ignore Script Still Appears Stale
Symptoms: Merchant has added data-uc-ignore but still sees old behavior. Root Cause: Most commonly a client-side browser cache holding the previous file, not a UltraCart-side issue, since data-uc-ignore scripts are excluded from unification and CDN offload entirely. Diagnosis: Inspect the page source to confirm the script tag was left untouched (no unification). Test in an incognito window to rule out local browser cache. Solution: If incognito resolves it, direct the merchant to clear their browser cache or hard refresh. If it persists in incognito, escalate — this would indicate the attribute is not being honored as expected.
Debugging Tools
View page source on the live StoreFront page and compare the rendered
<script>tags against what was configured in the page editor. Unified bundles typically carry a distinct suffix (e.g._mg) that is not present on merchant-authored filenames.Fetch the unified bundle URL directly (outside the browser cache, e.g. via curl or a fresh incognito tab) to determine whether the CDN-served file itself is stale, independent of local browser caching.
Incognito / private window isolates client-side browser cache from CDN-level staleness — critical for narrowing down which layer is holding the old version.
Log Reference
No internal log format or diagnostic endpoint for unified script bundle generation is currently documented for support use. This is part of the identified documentation gap — see Escalation.
Escalation
Escalate to engineering when a merchant confirms staleness persists after: republishing, hard refresh/incognito test, and (if applicable) adding data-uc-ignore.
Collect before escalating:
Account ID / store ID
StoreFront page URL
Exact script filename(s) before and after the change
Timestamp of the publish action
The unified bundle URL observed in page source (if present)
Whether
data-uc-ignorewas tested and the resultBrowser/incognito test results
Related Documentation
None currently exists specific to script unification or CDN cache invalidation. This document is the first coverage of the topic.