How Hubspot handles and order dependencies (CSS & JS)

I wanted to optimize and speed up Hubspot as much as possible, so I have dug pretty deep into how Hubspot CMS handles all the dependencies and in which order it places all the CSS and JS that are attached to a page from different scopes. We will leave the reverse engineering of{{ standard_header_includes }} for a later post .

TL;DR:

I have used different snippets to test the different locations where CSS or JS can be called, what are the default files that Hubspot includes, and how they are ordered. The {% require_* %} generate a enqueue list that follows this order:

CSS

• Hardcoded tags in the template before the standard_header_includes (without wrapper).

• {% require_css %} from the template head.

• Global settings with {% require_css %}

• {% require_css %} from page head HTML (in the content editor → advanced settings).

• {% require_css %} from the template after the standard_header_includes.

• {% require_css %} from the modules in cascading.

• HTML from the global settings without the wrapper {% require_css %}.

• HTML from the page head without the wrapper.

JS

We can see the same pattern for JS:

• Wrapped JS from the global settings.

• Wrapped JS from page head.

• Wrapped JS from page head.

• Wrapped JS from the template.

How I did it

Global settings:

Template:

3 modules in total, although I am using 2 instances of the same one.

Modules:

Inside the modules I have filled the CSS and JS tab and also added the following snippet to the HTML:

Page settings:

I attached a CSS file to the page and used the following snippet on the head (this is the setting you can find on the page content behind the advanced settings):

The result

First, we find the description <meta>followed by our hardcoded <link>. After that is where we really see what comes from the {{ standard_header_includes }}.

There are some <meta>t

tags for social networks and an injected <style>tag with some default HS CSS, related to cta_button (even if our test page had NO CTA in place) and default components such as hs-breadcrumb-menu, etc.

Then we see a couple of require_css being processed. Those are the two first require_css that we placed before the {{ standard_header_includes }}, one with the {{ require_css() }}function format and the other as the {% require_css %}tag.

Then we find that the next CSS is the one you place in the global head settings. I think this makes sense because with the new coded templates and themes you have much more control over the HTML markup and therefore you can place your "general" styles right before the standard_header_includes. Now you have the potential use of fragmented global settings based on the domains to overwrite styles, which in combination with CSS variables can do some wonderful easy peasy brand customizations within your themes.

What surprised me is that the {% require_css %}from the page head (when you are editing the page content in advance settings) came before the one from the template (after standard_header_includes). While I understand why this happens, I think it's not a good approach as a template require_csswill be more general than one contained in the page head. However, it shouldn't be a big deal as {% require_css %}on templates can be placed at your own discretion (before or after the standard_header_includes) and it is unlikely to mess up anything because you have full control over the HTML markup. Despite this, it definitely is something to keep in mind (although now I am curious about old dnd templates 😁).

After that, we find the CSS file that comes from the CSS tab module followed by the {% require_css %}inside its HTML tab. You can imagine that any other module added to the page will follow using the same pattern. It makes sense, as the HTML tab will be processed before the next module and therefore added to the queue right before the next module goes in place. It is worth mentioning that the CSS tab file is injected just once even if you have more than one instance, but you probably already knew that.

Also, you may have noticed how the first module test.cssis not minified while the second module test2.min.cssis. This is because on the first one there is one empty CSS selector (without properties). While in the second module has a selector with a font-size property. There are several things that break the CSS minifier (and the combinator). I will go in-depth about this in a different post. #TODO#

Then we find some meta tags of the page. Whatever you placed inside the global settings (without any {% require_* %}wrapper, like the <!-- global settings -->) is located in-between.

Here we can see that the attached CSS from the Page stylesheets setting (in the page editor, do not confuse with the page head) is placed right before what you place in your page head setting (without wrappers). So those would be the latest to load (unless you have in your template or modules not wrapped tags).

We finish the </head>tag with some Hubspot-related javascript. It is worth mentioning that just one of the 4 <script>tags are actually async, leaving the others to render block your content without even defer 🙄.

I didn't place any style or script without the wrappers in the HTML module tab because it is very easy to imagine that those will appear within the HTML module on the page.

Basically, the require_css will be enqueued when it gets processed, therefore a require_css in a module is processed earlier than one near the footer.

Conclusion

You may think that you basically want to wrap all your <style>and <script>tags with the wrapper {% require_* %}so it's placed correctly by Hubspot. And while you are correct that most of the time that would do, you will find a better approach to achieve the most performant website hosted on Hubspot CMS later in this post series.

Subscribe so you don't miss out!