The problem with pasting code into Webflow
Webflow's custom code fields are fine for a few lines. Past that, code pasted into a settings box has no history, no review and no way back. The next developer finds 30 KB of mystery JavaScript and no idea which part is safe to touch.
The setup
- A repo with
src/(readable modules) anddist/(built files). - A build step that bundles, minifies and writes a hash for each file.
- A tag per deploy:
git tag -a v1.4.0 && git push --tags. - Load it from jsDelivr, pinned to the tag:
<script src="https://cdn.jsdelivr.net/gh/you/site@v1.4.0/dist/site.prod.js"
integrity="sha384-..." crossorigin="anonymous"></script>Why pin a tag and not @main
@main is cached and changes under you. A tag never changes, so the URL is the version. Want the previous release back? Change v1.4.0 to v1.3.2. That's the whole rollback.
What the integrity hash buys you
The integrity attribute tells the browser what the file must hash to. If the CDN ever serves something different, it won't run. It also catches your own mistakes: if the hash doesn't match, you deployed a different file than you built.
Two gotchas from real deploys
- Don't name files
*.min.js. jsDelivr can serve its own minified copy of a.min.jspath, which won't match your hash. Name builds*.prod.js. - Verify before you switch. A brand-new tag can take a minute to appear on the CDN. Fetch the file, hash it, compare with your build's hash, and only then update Webflow. It's the same habit I describe in Descartes' method of doubt: a tool saying it worked isn't the same as seeing it.
The handoff payoff
The client's team sees a short, readable list of scripts with version numbers. A developer who inherits the site gets a repo with a changelog. Nobody has to be afraid of the custom code tab.