How to Use HubSpot Without Slowing Your Site to a Crawl

HubSpot speed is a real problem, not a myth. The platform’s default setup — tracking scripts, drag-and-drop modules, and bundled CSS — can push your Largest Contentful Paint past three seconds before you’ve added a single piece of content. The good news is that every major cause is fixable without abandoning HubSpot or your marketing stack.

Why HubSpot speed suffers by default

HubSpot is a marketing platform first and a CMS second. That ordering shows up in the default page output. Every page loads the HubSpot tracking script (hs-scripts.com), the forms library, the cookie consent banner, and often a chat widget — before your hero image has even started downloading. On a clean install with the default COS theme, a homepage can easily carry 400–600 KB of JavaScript that has nothing to do with rendering the page.

The drag-and-drop editor compounds this. Each module ships with its own CSS and JS, and HubSpot bundles them per-page rather than globally. A page built with eight modules can load eight separate style blocks. None of this is a bug — it is the cost of the flexibility HubSpot sells. But flexibility and HubSpot speed are in direct tension unless you actively manage the tradeoff.

The real cost of a slow HubSpot site

A slow site is not a developer problem. It is a revenue problem. As we argued in Why Site Speed Is Now a Revenue Metric, Not a Dev Metric, every 100ms of additional load time correlates with measurable drops in conversion rate. For a B2B site generating 500 demo requests a month, a 10% conversion drop from sluggish load times is 50 lost opportunities — before you’ve spent a dollar more on ads. Poor HubSpot speed compounds this: the platform’s default scripts fire before the browser paints anything visible.

Search rankings are the second casualty. Google’s ranking systems use Core Web Vitals as a page experience signal. A HubSpot site that fails LCP or INP thresholds is competing at a structural disadvantage against leaner competitors, regardless of how good the content is.

What the numbers look like

A typical unoptimised HubSpot site scores between 35 and 55 on Google PageSpeed Insights for mobile. An optimised version of the same site — same content, same tracking, same forms — routinely scores 75–90. That gap is not about content quality. It is entirely about how the page is assembled and what loads in which order. HubSpot speed, in other words, is an engineering choice, not a platform ceiling.

The tracking script problem

The HubSpot tracking script is the single largest contributor to poor HubSpot speed on most sites. It is render-blocking by default, it initialises the chat widget even on pages that don’t use it, and it fires before the browser has painted anything visible to the user.

The fix is not to remove it — you need it for contact attribution, form submissions, and lifecycle tracking. The fix is to load it correctly:

• Defer the script. Add the defer attribute to the HubSpot tracking snippet. This tells the browser to download it in parallel but not execute it until the DOM is ready. Attribution still works; render is no longer blocked.
• Disable the chat widget on pages that don’t need it. HubSpot lets you suppress the widget per-page or per-template. A pricing page needs it. A blog post probably doesn’t. Suppressing it on non-conversion pages is one of the fastest HubSpot speed wins available.
• Use a tag manager with a performance budget. If you’re loading HubSpot tracking alongside Google Analytics, LinkedIn Insight Tag, and a heatmap tool, you have four scripts competing for the main thread. Audit what fires on each page type and cut anything that isn’t earning its keep.

Fixing HubSpot speed at the theme level

Most HubSpot speed problems are baked into the theme. The default themes — Growth, Sprocket, and the newer CMS Hub starters — are built for flexibility, not performance. They load global CSS that covers every possible module combination, most of which your site will never use.

Build a lean custom theme

The highest-leverage intervention for HubSpot speed is a custom theme built from scratch with only the modules your site actually uses. This is not a small project — expect two to four weeks of development — but the performance dividend is permanent. A custom theme can cut CSS payload by 60–80% compared to a default starter.

If a full rebuild is not on the table, the next best option is to audit your existing theme’s global.css and remove unused module styles manually. HubSpot’s design manager shows which modules are in use across your templates. Anything not in that list can be stripped.

Use HubSpot’s lazy loading and CDN correctly

HubSpot serves assets through its own CDN, which is genuinely fast. The problem is that many sites override CDN caching with short TTLs set in the theme or upload images that bypass the CDN entirely. Check that your theme is not setting Cache-Control: no-cache on static assets, and always upload images through the HubSpot file manager rather than embedding external URLs. Getting this right is a low-effort HubSpot speed gain that many teams overlook.

Images, fonts, and third-party embeds

After scripts, images are the next biggest drag on HubSpot speed. HubSpot’s file manager does not automatically convert uploads to WebP or AVIF — you have to do that before uploading, or use a third-party image optimisation step in your publishing workflow. A 2 MB hero image uploaded as a PNG will stay a 2 MB PNG.

• Convert to WebP before uploading. WebP is typically 25–35% smaller than an equivalent JPEG at the same visual quality. AVIF is smaller still but has slightly lower browser support.
• Set explicit width and height attributes. This prevents layout shift (CLS) as images load and is one of the easiest Core Web Vitals wins available.
• Self-host your fonts or use system fonts. Google Fonts loaded from an external CDN add a DNS lookup and a render-blocking request. Either self-host the font files in HubSpot’s file manager or use a system font stack for body copy.
• Facade third-party embeds. YouTube videos, Wistia players, and Calendly widgets all load significant third-party JavaScript. Use a facade — a static thumbnail that loads the real embed only on click — to keep them off the critical path and protect HubSpot speed on content-heavy pages.

For B2B sites in particular, this matters more than most marketing teams realise. As we covered in The Mobile-First Website That B2B Buyers Actually Use, B2B buyers increasingly research on mobile, often on patchy 4G connections. A 4-second load on mobile is not a minor inconvenience — it is a lost deal.

Core Web Vitals and HubSpot speed

The three metrics that matter most for HubSpot speed are LCP, INP, and CLS. Each has a specific cause and fix in the HubSpot context.

LCP (Largest Contentful Paint) is almost always the hero image or the above-the-fold heading. Preload the LCP image using a <link rel="preload"> tag in your HubSpot template’s <head>. This tells the browser to fetch it immediately rather than waiting for the CSS to parse.

INP (Interaction to Next Paint) measures how quickly the page responds to clicks and taps. On HubSpot sites, the main culprit is the tracking script executing long tasks on the main thread. Deferring it and splitting any custom JavaScript into smaller chunks both help HubSpot speed on interaction-heavy pages.

CLS (Cumulative Layout Shift) is caused by elements that move after the page loads — typically images without dimensions, web fonts swapping in, or cookie banners that push content down. HubSpot’s cookie consent banner is a notorious CLS offender. Reserve space for it in your layout rather than letting it inject dynamically.

Before and after: a HubSpot speed audit

These numbers are from real audits, not benchmarks. The fixes that move the needle most for HubSpot speed are: deferring the tracking script, replacing the default theme with a lean custom build, and converting images to WebP before upload. Everything else is incremental.

When HubSpot CMS is the wrong tool

HubSpot speed can be improved significantly, but there is a ceiling. If your site is a high-traffic SaaS product page where every millisecond of LCP directly affects trial sign-ups, HubSpot CMS may not be the right foundation. A headless architecture — where HubSpot handles CRM, forms, and tracking but the front end is served by a static site generator — gives you the best of both worlds: HubSpot’s marketing tooling with near-perfect performance scores.

This is the architecture we described in the context of How to Build a SaaS Website That Sells Without a Demo Call: a fast, conversion-optimised front end that doesn’t sacrifice the CRM layer underneath. It is more complex to build and maintain, but for sites where conversion rate is the primary lever, the economics justify it.

For most marketing-led B2B sites under 50 pages, though, a well-optimised HubSpot CMS build is entirely sufficient. The problem is almost never the platform — it is the defaults. HubSpot speed is a configuration problem, and configuration problems have solutions.

If you want a second set of eyes on your HubSpot setup or are considering a headless rebuild, Studio Máté is happy to take a look.

Frequently asked questions

Does HubSpot’s CDN fix speed problems automatically?

HubSpot’s CDN handles asset delivery efficiently, but it does not fix the underlying causes of poor HubSpot speed. Script bloat, oversized images, and render-blocking CSS are problems in the page structure itself — the CDN delivers them fast, but it cannot make them smaller or change the order in which they load.

Can I use HubSpot tracking and still pass Core Web Vitals?

Yes. The key is loading the HubSpot tracking script with the defer attribute and suppressing the chat widget on pages that don’t need it. Sites that do both routinely pass all three Core Web Vitals thresholds while keeping full attribution and form tracking intact.

How much does a custom HubSpot theme improve speed?

A purpose-built custom theme typically reduces CSS payload by 60–80% and can improve mobile PageSpeed scores by 20–35 points compared to a default starter theme. The exact gain depends on how many modules the default theme was loading that your site doesn’t actually use.

Is a headless HubSpot setup worth the complexity?

For most B2B marketing sites, no. A well-optimised HubSpot CMS build delivers sufficient HubSpot speed to pass Core Web Vitals and convert well. Headless architecture makes sense when you need sub-second LCP at scale, have a development team to maintain the front end, and the conversion rate improvement justifies the ongoing complexity cost.

What is the single highest-impact HubSpot speed fix?

Deferring the HubSpot tracking script. It is the most common cause of a poor LCP score, it takes under five minutes to implement, and it has zero impact on marketing attribution or form tracking. Everything else — theme optimisation, image compression, font loading — builds on top of that baseline.