fix: load minified regenerator runtime in production

[MarlonPassos-git]

What problem is this solving?

Production storefronts load regenerator-runtime@0.11.1/runtime.js through the VTEX npm asset proxy. Lighthouse flags the 6.6 KiB transferred script as unminified JavaScript and estimates about 3.8 KiB savings.

The same asset and audit were reproduced across five Store Framework storefronts.

Lighthouse evidence

How does this work?

This changes only the production external path to runtime.min.js. Development keeps the readable runtime.js.

Although regenerator-runtime@0.11.1 does not publish that file, jsDelivr officially generates missing .min.js variants on demand. The VTEX npm asset proxy already serves this exact URL successfully through its jsDelivr fallback.

Measured through the VTEX asset proxy with async=2:

• current: 24,200 raw / about 6,833 gzip bytes
• proposed: 6,674 raw / about 2,617 gzip bytes
• reduction: about 4.2 KiB transferred (Lighthouse reports a conservative 3.8 KiB)

Both responses expose the same eight regenerator APIs and pass the same generator behavior probe.

Validation

• Development external remains runtime.js
• Production external resolves to HTTP 200 through *.vtexassets.com
• Original and minified runtime public APIs match

[vtex-io-ci-cd]

Hi! I'm VTEX IO CI/CD Bot and I'll be helping you to publish your app! 🤖

Please select which version do you want to release:

• Patch (backwards-compatible bug fixes)

• Minor (backwards-compatible functionality)

• Major (incompatible API changes)

And then you just need to merge your PR when you are ready! There is no need to create a release commit/tag.

• No thanks, I would rather do it manually 😞

[MarlonPassos-git]

vtexio/version-select failed because Patch is not selected in the VTEX IO CI/CD bot comment. As an external contributor, I cannot mark that option or access the CI details, so a VTEX maintainer needs to select Patch and rerun the CI.

[iago1501]

Hi @MarlonPassos-git ... Thanks for digging into this and for measuring it across storefronts. The diagnosis is spot on: production loads unminified regenerator-runtime@0.11.1/runtime.js, and Lighthouse is right to flag it.

We looked at this with the team and our suggestion is to take a slightly different path, if you are up for it.

runtime.min.js is not published on npm (unpkg 404s; later versions do not ship it either), so the asset proxy has to lean on jsDelivr’s on-demand minify as the only working origin. That file is a critical runtime for both the browser and SSR, so we would rather not make a third-party fallback the source of truth for it.

The savings you measured (~4 KiB gzip) are real and appreciated. A path that should keep that win without the extra dependency:

Add a react/ entrypoint (e.g. regenerator-runtime) pinned to 0.11.1, same idea as runtime:AMP / runtime:intl-polyfill.
Point prod externals.json at runtime:regenerator-runtime, and keep dev on runtime.js.

The react builder already minifies prod output, the script stays a separate external (load order before React/apps stays the same), and origin/cache stay on VTEX published assets.

Two things worth checking if you go that way: the webpack bundle still has to expose the regeneratorRuntime global on client and SSR, and the gzip size should still beat today’s ~6.8 KiB. If the chunk wrapper eats the savings, it is probably not worth the extra moving parts.

Happy to help review that follow-up if you want to try it. Thanks again for the PR, this was a useful catch.