Does HubSpot slow down your landing page? It can. Load the parts you need, when you need them.

What the data shows for HubSpot

The numbers come from third-party-web, an open dataset by Patrick Hulce built from HTTP Archive's Lighthouse runs across millions of pages on mobile settings. How that dataset is made, and the full list of scripts, is in third-party scripts and landing page speed.

We used third-party-web version 0.30.0, published in September 2026, with the HTTP Archive crawl from March 1, 2026. For HubSpot it reports:

• Average script execution time: 1,226 ms per page.
• Usage: 313,527 pages in the crawl.

One thing to know: the dataset counts every HubSpot domain as one row. That includes the tracking code, embedded forms, the chat widget, CTAs, and the cookie banner. A page with just the tracking code will usually run lighter than a page with all of it. The data does not split them apart, so we can't give you a number for each part.

For context, the same crawl shows Google Analytics at 108 ms, Hotjar at 732 ms, and Intercom at 1,433 ms.

What script execution time means for a phone visitor

A phone browser does most of its work in one lane, called the main thread. That lane builds the page, runs scripts, and answers taps. Only one job runs there at a time.

Google's Lighthouse docs say that when the main thread is busy, the page can't respond to user input. Google's Interaction to Next Paint (INP), a Core Web Vital, measures how long a tap waits for an answer. Google rates INP good at 200 ms or less and poor above 500 ms. Every millisecond a script spends on the main thread is a millisecond a tap on your call button can wait.

So an average of 1,226 ms from one vendor is a real share of the budget. On a cheap phone on a slow signal, that is time a homeowner spends looking at a page that won't scroll or won't let them tap "Get a quote."

How to load HubSpot the smart way

HubSpot does real work. It can carry your form leads into your CRM and show you which ad brought them. The goal is not to rip it out. The goal is to load each part only when it earns its keep.

1. Load chat after the visitor interacts

HubSpot's chat widget SDK has a setting called loadImmediately. HubSpot says it controls whether the widget loads on its own or waits until the widget.load method is called. The default is true. Set it to false in hsConversationsSettings, then call window.HubSpotConversations.widget.load() on the first scroll or tap. HubSpot notes that the HubSpotConversations object is created by the HubSpot tracking code, so the tracking code still loads first.

2. Ask if chat belongs on the ad page

Chat helps when someone answers it fast. If nobody watches the inbox at night or on weekends, a chat bubble is a script that costs time and may leave a lead hanging. On a phone-first contractor page, a big call button may do the job better.

3. Keep what you actually use

• Using HubSpot forms for leads? Keep the form script. It is your lead path.
• Tracking code there but nobody opens HubSpot reports? Ask whether the ad page needs it.
• HubSpot chat plus a second chat tool? Pick one.
• Cookie banner from HubSpot plus one from your site builder? Pick one.

If your stack is GoHighLevel plus HubSpot, also read the Google Ads and GoHighLevel gap. Two CRMs on one page often means two sets of scripts.

Check the page before and after

Change one thing, then test again. That is the only way to know what a change did on your page, since the dataset shows averages, not your page.

Paid plans show the fixes and add weekly monitoring with alerts when a page gets worse. For more on testing, see landing page speed test.

Related guides

Frequently asked questions