Closed Bug 985292 Opened 10 years ago Closed 9 years ago

Always use hash instead of build ID for cachebusting L10n JS files

Categories

(Marketplace Graveyard :: Consumer Pages, defect, P2)

defect

Tracking

(Not tracked)

RESOLVED WONTFIX

People

(Reporter: cvan, Unassigned)

References

()

Details

(Keywords: perf)

1. Load https://marketplace.firefox.com/?lang=fr
2. Load the network tab and watch the scripts that get loaded.
3. Notice https://marketplace.firefox.com/media/fireplace/locales/fr.js?b=1395207431756 gets loaded
4. Refresh the page
5. Notice now https://marketplace.firefox.com/media/fireplace/locales/fr.js?b=1395207440214 gets loaded

There are two bugs here:

1. https://github.com/mozilla/fireplace/blob/bfedac3/hearth/media/js/l10n.js#L47 looks up `document.body.getAttribute('data-buildIdJs')` but that should be ` document.body.getAttribute('data-build-id-js')` or `document.body.dataset.buildIdJs` (but use the former because IE), which means we're falling back to a unique numeric timestamp, so that URL never gets cached and you end up loading it every synchronous page load/fresh Marketplace app launch.
2. We should either rely entirely on ETags or cache fingerprint. I'd prefer the latter since the user won't have to wait on the network at all. So, let's keep a content hash for each locale's JS file, and reference that from `l10n.js`. This should programmatically be generated from probably commonplace and injected into some settings file or JS file whose module gets included and minified into our `main.js` bundle.
See Also: → 985290, 985291
See Also: → 985293
Keywords: perf
No longer blocks: tarako-marketplace
Blocks: 992365
Blocks: 998811
Not needed for tarako v0 as this should be included in the package.
No longer blocks: 998811
No longer blocks: 992365
See Also: → 1074474
Now that bug 1079894 is fixed, the locale files are served from the CDN with a far future expires and obey Last-Modified/If-Modified-Since. I also fixed the data-build-id-js error in that bug, so the cachebusting string doesn't change every refresh.

Now that they are cached properly and using the build ID correctly, I don't think we should bother changing the cachebusting mechanism for those files. We'll probably change at least one string every deploy anyway.
See comment 2.
Status: NEW → RESOLVED
Closed: 9 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.