HubSpot CMS ships with a global CDN, HTTP/2, automatic minification and image optimization. Out of the box it is fast. So when a HubSpot site scores badly on Core Web Vitals, the platform is almost never the reason — the page is.
Slowness accumulates. A hero image exported at full resolution, a second font family added for one heading, three analytics scripts from campaigns that ended last year, a module that renders after hydration. Each one is small; together they push Largest Contentful Paint past the point where visitors leave.
Here's the diagnostic order we use on HubSpot technical SEO engagements, starting with the changes that move the numbers most.
Measure the right thing first
Lab tools like Lighthouse give you a repeatable score; field data in Search Console's Core Web Vitals report tells you what real visitors experienced. Optimise against the field data and use lab runs to verify each change.
Test the templates, not just the homepage. In HubSpot, performance problems are usually template-level or module-level, so one slow blog post almost always means every post is slow.
Record a baseline for LCP, CLS and INP per template before touching anything. Without it you can't tell which fix worked.
1. Oversized hero images (the usual LCP culprit)
On most HubSpot pages the Largest Contentful Paint element is the hero image or hero background. If that file is a 2MB PNG exported at 3000px wide, nothing else you do will rescue the score.
Export at the widest size the layout actually uses, serve WebP, and let HubSpot's image resizing produce responsive variants rather than shipping one giant file to phones. Photographs belong in WebP or JPEG; PNG is for flat graphics with transparency.
Set explicit width and height on the image so the browser reserves space — that single attribute pair fixes a surprising share of layout-shift problems too.
2. Lazy loading applied to the wrong images
Lazy loading below-the-fold images is free performance. Lazy loading the hero image actively delays your LCP, because the browser waits before requesting the one image the score depends on.
Check your hero module: many HubSpot themes apply lazy loading globally. Exclude the above-the-fold image and keep it on everything else.
The same logic applies to embedded video. Load a poster image and fetch the player on click rather than on page load.
3. Font loading that blocks text
Two font families with four weights each is eight files on the critical path. Most sites use three of those weights.
Trim to the weights the design genuinely uses, self-host or preload the primary font file, and set font-display: swap so text paints in a fallback instead of staying invisible.
Also check for icon fonts. A whole icon font loaded to render four glyphs should be inline SVG instead.
4. Script accumulation from old campaigns
Every HubSpot portal we audit has tracking scripts nobody can account for — a retired chat widget, an A/B testing tool from two years ago, three overlapping analytics pixels. They run on every page view and cost real interaction time.
Audit the site-wide footer and header HTML in your portal settings, list every third-party script, and confirm someone still uses the data. Remove what nobody claims.
Whatever survives should load deferred or async wherever it isn't needed for first render.
5. Module bloat and duplicated CSS
Themes carry CSS for every module they offer, including the ones your site never uses. Sites built by several hands over time also accumulate near-duplicate modules with overlapping styles.
Consolidate modules that do the same job, remove unused theme CSS, and keep global stylesheet size honest. This is also where CSS specificity wars come from, which cost developer hours later.
Custom modules should scope their own CSS instead of appending to the global sheet.
6. Client-side rendered content
Tabs, accordions, filtered listings and sliders that build their content after hydration hurt twice: they delay meaningful paint, and AI crawlers that don't execute JavaScript may never see the content at all.
Render the default state server-side and enhance from there. The reasoning is covered in why your HubSpot site may be invisible to AI search.
If a module is the LCP element and renders client-side, that is the first thing to change.
7. Layout shift from late-arriving elements
Cumulative Layout Shift on HubSpot pages usually traces to three things: images without dimensions, embedded forms that resize once loaded, and cookie or promo banners injected at the top of the document.
Reserve space for embedded forms with a min-height container, and overlay banners rather than pushing content down.
Web fonts also shift layout when the fallback's metrics differ sharply from the loaded font — choose a fallback with similar proportions.
8. Fix the template, then hold the budget
Fixing performance once is easy; keeping it is the discipline. Set a page weight budget per template and check it whenever a new module or script is added.
Re-test after every campaign period, since campaign pages are where new pixels and heavy images enter a portal.
That ongoing check is part of HubSpot support and maintenance — cheaper than repeating this audit annually.
The order we work in
Hero image, then lazy-loading configuration, then fonts, then third-party scripts, then CSS and module consolidation, then rendering and layout stability. That sequence front-loads the biggest LCP gains before the fiddly work.
In practice, the first three items resolve most failing Core Web Vitals assessments on HubSpot sites we review.
If your templates are too tangled to fix incrementally, a rebuild on clean templates is often faster than untangling — see HubSpot website design and development.
Improve HubSpot loading speed without breaking forms or tracking
A faster page is not an improvement if visitors can no longer submit a form. Before changing script loading, record which tools power forms, consent, analytics, chat and booking widgets. Test changes on a staging or test page that uses the affected template, then check the published version: editor previews do not reproduce every live-site condition.
Test with consent both accepted and rejected, on mobile and desktop, and with a fresh browser session. Confirm that navigation works, forms show validation and success states, test submissions reach the intended CRM records, and analytics events fire only as intended. Defer nonessential scripts selectively rather than applying one loading rule to every integration.
After release, compare repeat performance tests under the same conditions and monitor real-user Core Web Vitals as new data arrives. Keep a rollback copy of the changed code and document which templates were affected. HubSpot Support & Maintenance can help manage these checks; the HubSpot performance optimization playbook covers the wider optimization process.
HubSpot website load capacity: will more traffic make it slow?
HubSpot website load capacity and page loading speed are different questions. Capacity concerns serving concurrent visitors; loading speed concerns how quickly each visitor can see and use the page. HubSpot manages its hosting infrastructure, so a slow mobile page alone is not evidence that you need a higher subscription tier or more server capacity.
Before a campaign launch, separate the hosted page from its dependencies. Embedded tools, external API calls and custom dynamic features may have their own limits or failure modes. Check document response times and failed requests alongside browser rendering, and verify that forms and booking flows still work. Check applicable provider policies and coordinate with providers before running load tests.
There is no defensible universal visitor limit to quote for every HubSpot website. Assess the actual templates, integrations and expected traffic pattern instead. If campaign readiness also involves redirects, indexability or canonical URLs, include those in a HubSpot technical SEO review; faster rendering will not fix a page that search engines cannot index.