Render-Blocking JS in HubSpot Themes: Agency Guide

Can you remove render-blocking JavaScript from HubSpot themes?

No. Two scripts that HubSpot loads on every CMS page, jQuery and the CTA script (current.js), are render-blocking by design, and there is no supported way to remove or defer them. jQuery has to load before the page content will render at all, and the CTA script has to initialize before content so calls-to-action don't visibly pop in a beat late. This is a platform-level constraint, not a theme bug you can code around.

For an agency, that matters the moment you run a client's HubSpot site through PageSpeed Insights and hand over the report. Google will always flag those two files as blocking scripts in above-the-fold content, on every HubSpot-hosted page you audit. If you don't know that going in, you can burn a day of billable dev time chasing a fix that doesn't exist, and worse, walk a client into a "why is our site slow" conversation you can't win on those specific files.

We learned this the hard way years ago: we opened a support ticket with HubSpot to confirm whether the scripts could be repositioned, and the answer was that they can't. In our audits since, that finding has held on every HubSpot CMS portal we've touched.

Why those two scripts can't be moved

The behavior is baked into how HubSpot's CMS renders pages, so it's the same across every theme. jQuery loads first because the theme's own rendering depends on it being available immediately; move it and content stops rendering as expected. The CTA script loads early for a related reason; it needs to know how to construct each CTA before the surrounding content paints, so the button appears in place instead of flashing in after the rest of the page.

This is HubSpot's CMS, now branded Content Hub, and historically CMS Hub and, further back, the COS ("content optimization system") that this behavior originally shipped with. The naming has changed; the render-blocking script order has not. Both files sit outside your theme, which is exactly why you can't reorder them from your own templates the way you can with custom JavaScript you author yourself.

The practical takeaway for a delivery team: treat these two flags as a fixed cost of the platform. Note them in the audit, explain them once, and move your optimization effort to the levers you actually control.

What this means when you're auditing a client's HubSpot site

Page speed still matters to the client's bottom line, so the audit isn't wasted; you just have to aim it correctly. A B2B site that loads in one second converts about three times higher than one that takes five seconds, per a Portent study cited in HubSpot's page-load-time research. That's the case for doing performance work at all; it is not a case for fighting HubSpot's core scripts.

So when the PageSpeed report lands on the two blocking files, don't let them become the headline. Reframe the audit around the metrics you can move (Largest Contentful Paint, total blocking time from avoidable scripts, image weight, font loading) and show the client where the real, recoverable seconds are. That reframing is a deliverable in itself: a clear "here's what's fixable, here's what's platform-locked, here's the projected impact" report reads as expertise, not excuse-making.

If you package portal audits as a productized service, bake the two locked scripts into the template so every analyst on your team explains them the same way. Consistent client-facing findings are part of why standardized reporting and KPI dashboards for agency clients pay off: the client sees a repeatable process, not a one-off scramble.

What agencies can actually optimize instead

Plenty. The two HubSpot scripts are locked, but most of a HubSpot page's real-world load time lives in choices your team makes in the theme, the modules, and the assets. These are the levers to put in front of the client:

Lever	Locked by HubSpot?	Agency play
jQuery + CTA script (current.js)	Yes	Document it, set expectations, move on
Web fonts	No	Swap slow third-party fonts for a leaner, faster-hosted stack
Images	No	Compress, resize, and lazy-load; kill oversized hero assets
Custom JavaScript you author	No	Defer or async anything not needed above the fold
Module and template bloat	No	Prune unused modules and heavy embeds from key templates

Fonts are a common quiet win. In one client audit, swapping a slow-loading Adobe Typekit font for a faster Google-hosted equivalent lifted the page-speed score on its own, and because Google factors load performance into rankings, aligning the font stack with faster infrastructure removed a technical-SEO penalty at the same time. None of that touches HubSpot's core scripts; all of it is fully in your control.

The point to carry into the client conversation: the render-blocking flags on jQuery and the CTA script are the floor of what a HubSpot page costs, and everything above that floor is optimizable. Your job is to get the site as close to that floor as the platform allows.

When to bring in a white-label dev partner

Some performance work crosses from configuration into engineering: custom module surgery, template refactors, deferring scripts safely without breaking CTA rendering, or reworking a theme that was built badly in the first place. That's the point where a lot of agencies either over-promise or eat unbillable hours. When a client asks whether HubSpot can be made to do something it doesn't natively support, our honest answer is that nine times out of ten we can find a way, but the way often involves real development, not a settings toggle.

If your team doesn't carry senior HubSpot CMS developers, this is a clean thing to hand to a white-label development partner: the engineering ships under your brand, the client never sees a second logo, and you keep the relationship and the margin. It's also how you scale delivery without hiring for every skill in-house, the model behind white-label HubSpot development for agencies. The theme-level troubleshooting that started this whole post, the kind where you're deep in HubSpot CMS (COS) development trying to figure out what's safe to move, is exactly the work a senior dev bench absorbs so your team doesn't have to.

Setting client expectations (the conversation)

Get ahead of the two locked scripts before the client finds them in a report. The clean version is short: "HubSpot ships two performance-critical scripts on every page that we can't remove without breaking the site; that's true for every HubSpot site, not just yours. Here's everything else we can and will optimize, and here's the impact we expect." Said once, up front, it turns a potential credibility problem into evidence that you actually know the platform.

That's the difference between an agency reacting to a PageSpeed screenshot and one that delivers HubSpot performance work with a plan: you know which flags are noise, which are recoverable, and when to escalate the genuinely hard fixes to a partner who does this every day.