It seems some scripts are injected into the <head> tag outside of {{ standard_header_includes }}
For instance /v2/<portalid>/banner.js which will be present in the Network panel eventhough we don’t have an active cookie banner under Settings.
Since the added scripts aren’t available in the page source (initial DOM) my guess is that they’re added dynamically by some require_js call somewhere that we can’t access.
Is there any way to |cut or loop through these scripts and remove specific ones? We are aware that some of them are necessarry, however banner.js in our case shouldn’t be there.
Thanks for tagging some good people @Jaycee_Lewis
However the suggested solution is not applicable for the scripts in question. These seem to come from some core code that we have no control over and as such are not a part of standard_header_includes.
I’ve raised the issue with support on mail too to which they have responded and I have then done the same as the response didn’t offer any solution
Hi @albertsg
I’m afraid that banner.js and v2/forms.js etc. are seemingly not included through {{ standard_header_includes }}
I stumbled upon your solution prior to writing up this post, but the mentioned scripts are added dynamically from somewhere else (not in DOM when inspecting source).
So while your solution is indeed clever, it won’t work for these specific couple of scripts (i tested it with footer_includes too to no avail).
The response from support seems to suggest that some files are indeed injected dynamically into the head section, but not as a part of the {{ standard_header_includes }} - More like a core thing working behind the curtains of our control.
Just removed {{ standard_header_includes }} from base.html and these scripts are still loading regardless:
index.js
project.js
v2.js
main.min.js
<portalid>.js (twice)
collectedforms.js
banner.js
has-permission?portalid-etc…
actions?portalid-etc…
However!
If I remove {{ standard_footer_includes }} they all disappear. But if I adjust your solution to standard_footer_includes and look for banner.js in a string, it won’t remove banner.js.
I guess I need to test it some more and see if I can work something out.
Digging around I found that {{ standard_footer_includes }} will call a javascript file with the portalid as its name.
This file will run through a trigger population of banner.js, collectedforms.js and analytics.js and add them dynamically to the <head> tag of the site.
I’m not sure there is a way to exclude the call for banner.js in such a mixed file, but I was thinking if there was a way with Hubl code to delay the execution of {{ standard_footer_includes }} for e.g. 3 seconds?
In case it might be informational for anyone, this is the reponse i got from support:
We am not seeing a Cookie Banner appearing on their page, but I can see that banner.js is loading.
The banner script is part of our main script loader to check if a Cookie Banner is enabled in their Cookie Banner settings and this is expected to be present even if the Cookie Banner is switched off.
This behavior is default and is not changeable, but they should be aware that no banner is actually loading because it is disabled in their HubSpot settings.
Basically a 64kb script is loaded regardless of the Cookie banner being activated in the account or not.
As I’ve also responded back to support, I’m not particularly fond of that approach. I hope they’ll review their approach and optimize it.
The reason to this debate is primarily that Lighthouse and Google Pagespeed Insights are punishing site scores for loading scripts that aren’t in use. Secondly to offer devs more control.
For instance we have no way to add “defer” or “async” load methods to these particular scripts and we can’t control the timing of them either.
For instance: Does it make sense to load v2/forms.js directly on page request, or perhaps postpone that file a few seconds so it won’t hurt performance scores? It’s not likely that anyone is going to fill in a form while a site is loading anyway so why not postpone it?
Generally I’ve seen quite a few complaints about HubSpot CMS performance during the last couple of years (here in the forums too) and I believe it’s time to start acting on it if HS CMS want to position itself as a top CMS contender.
64 kb might seem like an indifferent topic in the grand scheme of things. However, it’s the reasoning behind it that I think needs some rethinking.
This is going to be the solution until I find a way to delay execution of {{ standard_footer_includes }} through Hubl code.
What I did was:
1. Use @albertsg’ method mentioned here, adjusted to traverse through {{ standard_footer_includes }} and eliminate the call for <portalid>.js:
{% set custom_footer_includes = standard_footer_includes|split('\n') %}
{% for line in custom_footer_includes %}
{% unless line is string_containing 'portalid-here.js' %}
{{line}}
{% endunless %}
{% endfor %}
2. Insert the raw JS from <portalid>.js file in a script tag with a setTimeout function of e.g. 3 seconds
3. Money!
This is a visually heavy site with big background video, sliders etc. and please know that every other aspect has been optimized as well (resize_image_url), defer/async script, optimized webp images etc. etc.
Hi, Just to add weight to this. My site is getting butchered by PageSpeedInsights and Hubspot’s banner.js is top of the list. I don’t use it. Can you stop forcing us to use it please? It’s hurting my business.
Thanks for the question. Let’s see if we can get the conversation going — hey 
— Jaycee
