The next HubSpot Community Developer Podcast! Site speed and optimization with John Fuller

Community Manager

Just wrapped our SEO podcast with @rikkilear which was a hoot and now it is time to get ready for the next show!  This time we will be talking with @John  of Ascend about all things site optimization and speed.  If you have any questions or thoughts on optimizing your site (and oh, I know you do) join the conversation below!


I will also be joined by two HubSpotters who know their way around:

Nhori Lopchan Tamang (she/ her) is Tech Lead for the Marketing Web Team.  She is a fan of bullet point lists and provided this bio to me 😀
- Tech Lead - Marketing WebTeam
- At HubSpot for about 4 years
- What I do:
- Web Strategy CMS projects architecture design & planning
- Maintaining best practices in the code mines
- Leading Squad from planning to the delivery of multiple project(s)
- Process improvement(s) for Web Strategy Project(s)
- Fun fact
-  Flexed with Michelle Obama during INBOUND meet and greet 


Michele Herzog (they/ them) is a developer in HubSpot's marketing department, focused on building and maintaining Previously, they were a Product Expert for the CMS product team, where they triaged your bugs and wrote developer documentation. They have a corgi named Banjo, who you might recognize from "Secret Corgi Mode". Tell your dog they say hi.



We have a late entry to our panel, @jmclaren could not handle not being on this show.

Jon McLaren (he/him) is a Senior Developer Advocate at HubSpot.  You may know him from past shows such as Episode 1: Accessibility with Jon Sasala or Episode 2: Email with Alyssa Wilie


Excited for this show!  Hope you are, too!





Check out our Community Developer Blog
where we feature our Community driven developer podcast and how to content
11 Replies 11
Top Contributor | Elite Partner

Hey Dennis,

Looking forward to this.


Image optimisation is a big one for this topic. What's the best process / way to handle this with HubSpot CMS?


Did my post help answer your query? Help the Community by marking it as a solution.

Full HubSpot agency:

One off HubSpot tasks:

Community Manager

@rikkilear !

Great question and one we will definitely explore in detail. 



Check out our Community Developer Blog
where we feature our Community driven developer podcast and how to content
Participant | Platinum Partner

Hey Dennis and John,


I am really curious to know abut following topics which is most facing issue by all developers I guess.

  1. How to deal with initial server response time. this is the mmost common thing I see in google page speed for hubspot sites.
  2. Resize image funciton is great solution to avoid big images uploaded by content editors, but it will cause quality loss any good alternative here ?
  3. How to deal with tracking/analitics codes which is necessory to put into header.
  4. What is the best practice for writting css and js ? inside css and js block of custom module or in common Style and Js file. wirritng in custom module cause extra http call

I also would like to know that as well: 

  1. What is the best practice for writting css and js ? inside css and js block of custom module or in common Style and Js file. wirritng in custom module cause extra http call

Another question - is it better to download and add the google font files to the file manager on HS and link to them in the CSS that way or use the google fonts CDN?

Community Manager

Brilliant questions!



Check out our Community Developer Blog
where we feature our Community driven developer podcast and how to content
Community Manager

Great questions and consider them added to the list 😛



Check out our Community Developer Blog
where we feature our Community driven developer podcast and how to content
Guide | Diamond Partner

Looking forward to this @dennisedson @John 

@jmclaren had a good answer in the recent CMS AMA regarding the Google core web vitals update and what HubSpot is doing to improve performance. He had stated that the CMS boilerplate template consistenly scores 90+ on Google Page Speed. Whats a good way to optimze legacy themes like Vast without having to change out to the boilerplate template?


Jon Chim
Design Director
Morey Creative Studios

check Did my post help answer your query? Help the Community by marking it as a solution

@jonchim  It was unclear what boilerplate was being mentioned in that response... Assume it was this boilerplate or thematic ones. If true... I wouldn't consider that a good representation.


It scores "90+ consistently" because it's a barebones page with placeholder images that are <= 2KB and nothing representative of an actual web page, stylistically or content, not to mention they're also the same image... across the boilerplate and inherently freeing the waterfall / fetching process. It gets close to 100 most of the time. That looks fancy... But, the moment you throw anything even remotely representative of a normal website on the boilerplate your scores will drop as the request chaining, waterfall, node depth, processing, etc will all grow exponentially. The node depth / DOM, below the fold processing etc are trivial and easily solved. The others go back to classic HubSpot performance problems the entire question / response you mentioned was about. Don't get me wrong you can still get "good" scores.... It's just a PITA with some caveats.


The waterfall is actually a good representation of the problems present. Response glossed over the server response time / TTFB + other HubSpot issues author's have no control over. CDNs typically improve this extensively hence it being at the edge closer to the user - the entire point of a CDN, but whenever you run all that through the wire aggregating IP data, hinting, country and other origin via cloudflares optional features you start dragging that idea through the mud....


It has virtually every issue hubspot authors complain about - me in particular. Chaining, clogged waterfall, etc. Look for yourself. TTFB isn't bad there... but, purely for completeness CDN's ironically will actually increase your TTFB if resources aren't cached yet due to round tripping and not having it at the edge yet. Even if you fixed those problems you're getting perceived performance. That doesn't mean it's actually performant / usable for users. There's nothing performant about loading a 500KB file to load a form, because it has poor i18n, style, and other code splitting. Love to see someone have their forms work in an i18n setting with data restrictions or throttled. Sure when GZipped / compressed it's not as bad... But, for a boilerplate to be pushing close to a half megabyte in page size with absolute 0 content.... That's a yikes from me dawg.


For example on a throttled 3g connection.... (lighthouse only)


For "optimizations", the answer is effectively "use our CMS, but don't use anything we provide and patch the rest to make something usable" under the assumption you want real performance rather then "marketer acceptable" performance. It's true most people are on 4G or better now, but that's not really an excuse to have page size and assets grow in size exponentially as things become "modernized". It's regression. Asynchronous nature inherently causes CLS shifts via forms, ctas, ... So, you also have to "patch" those if you want no CLS. That's fine anything asynchronous does that, but the issue being that the generic response that's touted here for years of "well just do X, Y, and Z or don't use it / roll your own" is an incredibly poor response as it's your own architecture causing the problem and that's not author responsibility. If you really wanted all of these things could be fixed at prior to pages being cached were it a priority.


Taglines like "we serve webp" sound great and very "optimized".... It's not actually this is just basic serving of assets at the CDN level via the browser supplied hints of what it can and cannot serve effectively at the edge. If your CDN is really good... Maybe it even accepts DPR, (Viewport)Width, and other hints to serve responsive images dynamically. But, to my knowledge that only works in Chromium as of now and the fingerprinting / privacy concerns are still being discussed by other engines. You can polyfill it... but that's actually a net negative affect as browsers don't require full parsing to start optimizing image fetching especially when you consider the ablity of browsers to fetch in parallel. This gets a bit hairy with background images obviously - especially with large heros.


When people rely on lazy loading like this - espcially above the fold - you then have to wait for all that parsing to take place before the connection is even warmed. You can do some perceived performance tricks with images if you really want like blurred placeholders etc. Such as, other lqip, svg traces, etc. But, none of that's easily dynamic via HubSpot nor do you have the ability to interface and generate anything in an easy way. That's in essence the real problem with HubSpot's performance. Lack of interoperability as this, asset optimizations, head configs, etc could all be generated and requires absolutely 0 overhead or content editing in most environments..... that aren't HubSpot.


To clarify, you obviously want to lazy load - it was merely pointing out the abstract lower level items of when you really want to push performance. It's true you have a reduction in file size, generically speaking with webp, but in some cases you actually don't want webp especially with chroma subsampling. Newer formats such as AVIF etc are ready to "ship" but aren't feasible at the edge yet due to their processing time so it's fair those aren't served. I wouldn't `ding` the boilerplate Other items listed in said response follow similarly. They're good "suggestions" that may inspire authors to attempt to fix minor issues, but do little for architectural / the big problems you can't fix where the "real" performance ops lie. Everything else is... quite trivial and re-hashed taglines.


Then beyond this... You have decoding of the images via the browser and optimizations you can do there. Either via attributes, progressive formats, etc.


The next obvious one is fonts.... Typically the slowest thing right after images. You can preload from google fonts, do web font loaders, etc and that's all nice, but the real solution would be self-hosting and doing per page shaving of the font in automated processes if you really wanted to push initial load. Browsers are supposed to be coming out with this built-in in the future if the details ever get worked out (half decade from now for acceptable support) but I wouldn't hold my breath. Until then it's still an ardous process.


Whenever you don't self-host, your files get included from Hubspot's user content domains, resources are etched from app.hubspot, (portal).js, or whatever other domains.... You're also really dragging out all the round tripping required.... Dependent on just how far back you want to go in terms of legacy support the vast majority of the above and what's included as stereotypical "performance" ops don't even work. You have no preloading of assets, no preconnect, etc. Even JS gets really hairy. The solution for those would be dynamic serving via adaptable pages at the server level - which you can't do clearly..... For modern browsers... you're fine. Just ISO everything and do standard ops and most things will work out.


With newer modern formats... Variable fonts! That can be a massive reduction and signiicantly cleaner to maintain. Then... for CLS you have newly added CSS properties / descriptors that can tweak "fallback" fonts to better match the main font and hence prevent CLS. But, this can actually be quite complex so I'll skip it. The real difficulty are international fonts with representation such as logographs (CJK) etc where the character sets are massive and so are the files naturally. Resorting to system stacks tends to be the way to go here at least until progressive loading natively happens or there's an automated way to chunk these. 


The next one is request chaining from every modules asset files per the waterfall in the boilerplate and every other HubSpot website. Solution is single file, chunk it, critical. Nothing special there.


Miscellaneous ops:


CSS ops such as leveraging hardware accelerations on suitable properties. Mainly `jank` on mobile. Lazy loading other types of assets / scripts as needed. Lazy loading goes way beyond images. People tend to also really gloss over how much re-factoring your CSS to be DRY can save. These are marketing websites... There's absolutely no reason whatsoever to be doing a full framework, markting specific cascades, etc.... That's just asinine.


Anyways.... This was a really roundabout way of saying: There's nothing inherently special about the boilerplate. It has trivial "optimizations" that you can throw on any theme and those are just the same things you already know: Preload, async what's not needed, optimize above the fold, etc. All of that can be done in the base of any theme. The real problems you're not fixing - present in any theme the boilerplate included - is the request chanining, etc without full rewrites. It actually misses a few things, but nothing I'll "ding" the boilerplate for as it's reasonable to not include assets specific optimizations in the head amongst other things that would clearly change. But, were there interoperability.... You could automate most of the performance problems away.


Going beyond the boilerplate would be vendor specific optimizations (as of the time of this writing) using content visibility, asset specific optimizations in the head, better splitting, critical, etc. All still pretty standard stuff.


Clarifications: Whenever I was talking about self-hosting, round tripping, etc and connections in general. Basically, as a visual... You don't want to be bouncing all over the place as all that has to come over the wire from somewhere and that somewhere is better as a single source of truth - preferrably on the edge. A map:


If that's still unclear....

Contributor | Partner

Hi Dennis, 


Now that @jmclaren is joining this is a can't miss.


Some questions: 

  • The CMS boilerplate is incredibly helpful! Do you have any plans to establish additional best practices that could be used for site optimization? For example, a ONLY-LOAD-NECESSARY-CSS-ABOVE-THE-FOLD boilerplate, a SCSS-EVERYWHERE boilerplate, a PRODUCTION-BUILD boilerplate, etc? A "perfect" boilerplate that works for everyone might me impossible but maybe there are ways to "extend" it with selected options?
  • How can we get content editors/marketors to contibute to site optimization? For example, almost nobody on my team knows that the hover "details" feature exists when selecting an image. Can we warn them that the page will load more slowly if they upload a 10mb png?
  • I noticed a new "tests" column was added to the website pages view. How cool would it be if you could include a "load time" column that periodically rechecks? Very would be very cool. I've found that I do "marathon" optimization sessions and then deprioritize it—seeing load times as content is added/updated would really be helpful.

Good luck with the podcast! 🎧




Key Advisor

Please let us know when it goes live. Thanks.

Aakar Anil
Marketing Technologist | @aakarpost | in/aakarpost
Community Manager

@Aakar , you should subscribe to the community developer blog!



Check out our Community Developer Blog
where we feature our Community driven developer podcast and how to content