Last modified: August 22, 2025
To improve page load speed and security, HubSpot automatically creates static versions of pages, blog posts, and knowledge base articles when possible. In other words, rather than assembling the page’s data and layout at the time of loading the page, HubSpot will render the page ahead of time so that it’s ready to be served. Copies of these pre-built pages are stored in HubSpot’s CDN around the world so that visitors can access pages faster based on their location. However, not all pages are eligible for prerendering. When a page contains certain HubL functions or variables, or uses certain page features, it will prevent the page from being prerendered. Similarly, in some cases, a page can be partially prerendered, which provides many of the same performance and security benefits as full prerendering. Below, learn more about the prerendering process, how to troubleshoot prerendering, and which features will impact prerendering.

​
Prerendering process

The prerendering process is triggered automatically when taking the following actions:
  • Publishing an edit to a page’s template
  • Updating shared data, such as some website settings
  • Updating a module that’s included in a template or page
During the prerendering process, HubSpot creates a static version of the page so that it’s ready to be served when its URL is requested. This improves the page load speed as there’s less server-side processing during each request. In terms of security, static pages reduce exposure to potential vulnerabilities associated with dynamic code and database queries. Generally, the prerendering process takes seconds to complete. Larger changes, such as updating a module that’s included in many templates and pages, may take several minutes to complete the page renders. CSS, JavaScript, and images files are always statically generated on HubSpot, so they are effectively always prerendered.
HubL in CSS and JavaScript files is evaluated only once when the asset is published.

​
Check if a page is prerendered

There are two ways to check if a page is prerendered:
  • ?hsDebugOnly=true: load the page with a ?hsDebugOnly=true query parameter. This will include an indication if the page can be prerendered. If it can’t be prerendered, a list of issues that prevent prerendering will appear, along with specific files and template line numbers. If the formatting of the debug information is hard to read, you can use the parameter ?hsDebug=true instead. When you inspect the page with that query parameter, the same debug information will appear in a formatted HTML comment near the bottom of your page.
Screenshot of HTML comment showing that page can be prerendered
  • X-HS-Prerendered: look for the X-HS-Prerendered header in the HTTP response headers of the page request. This header will only be present if the page is prerendered, and it will include the value of the last time the page was prerendered. You can find this information by inspecting the page, clicking the network tab, and looking at the response headers for the page request.
chrome network tab showing prerendered header
When possible, handle dynamic content rendering client-side using JavaScript. You may also use serverless functions to pull in dynamic data.

​
Incompatible features

The following HubL variables, HubL functions, and content features will prevent a page from being prerendered. These features prevents the same response from being served to every user, so they prevent the serving of a static prerendered page. Pages using some of these features may be served using partial prerendering.

​
Incompatible HubL variables

  • account
  • company
  • contact
  • local_dt
  • owner
  • request_contact
  • request.cookies
  • request.full_url
  • request.headers
  • request.path_and_query
  • request.query
  • request.query_dict
  • request.referrer
  • request.remote_ip
Note that, while the request variables aren’t compatible with prerendering, they generally have JavaScript alternatives you can use to access similar information.

​
Incompatible HubL functions

  • personalization_token()
  • today()

​
Incompatible functionalities

​
Partial prerendering

Partial prerendering allows HubSpot to serve partially prerendered pages. For example, a page may be entirely static except for a contact’s name displayed on the page. The page can be prerendered except for that contact name. Just before returning the page to the user, HubSpot will perform a render of just those dynamic values. Pages that use partial prerendering can’t be cached at the CDN or the browser. However, partially prerendered pages are faster to deliver than pages that can’t be partially prerendered. Partially prerendered pages also have the ability to fall back to an unpersonalized state in case of an outage or an attack. While partial prerendering may help the speed and reliability of your site, removing the HubL features that make pages non-prerenderable will have a much greater positive effect on your overall page performance.

​
Check for partial prerendering

To check if a page can be partially prerendered, load the page with a ?hsPrcDebug=true query parameter, and there will be additional output about the prerendered content for that page. If the page is prerendered, the X-HS-Prerendered header will be present and contain partial before the time the page was partially prerendered. Below is a list of HubL variables and filters that are currently supported with partial prerendering. Pages that include these variables and filters will be partially prerendered, and any expressions that include them will be evaluated at serve-time.

​
HubL variables

  • account
  • company
  • contact
  • local_dt
  • owner
  • query
  • request
  • request_contact
  • year

​
HubL filters

  • |random
  • |shuffle

​
JavaScript alternatives to incompatible HubL

While the various request HubL variables aren’t compatible with prerendering, these variables generally have JavaScript alternatives you can use to access similar information. For example, instead of the request.cookies variable, you could use the cookie property. Below is an example of using HubL vs. JavaScript to dynamically display content based on whether the user has visited the site before (based on their cookies). 
{% set hubspot_utk = request.cookies.hubspotutk %} {% if hubspot_utk %}
<div class="returning-visitor">
<h2>Welcome back!</h2>
<p>Thanks for returning. Here's what's new since your last visit:</p>
<ul class="updates-list">
<li>New product features launched</li>
<li>Updated pricing plans</li>
</ul>
</div>
{% else %}
<div class="new-visitor">
<h2>Welcome to our site!</h2>
<p>New here? Check out our Get Started guide:</p>
<a href="" class="btn btn-primary">Get Started</a>
</div>
{% endif %}