Skip to main content
As a HubSpot developer, many pages that you develop will be static HTML, such as blog posts, knowledge base articles, and landing pages. But other times, you’ll need to build interactive page elements, such as image carousels, forms with client validation, or live chat widgets. With traditional HubL modules, adding interactivity often requires rendering these interactive elements client-side using JavaScript. This can negatively impact page performance and SEO. By using islands, you can avoid this issue by taking advantage of both client-side and server-side rendering. An island is a subtree of your interactive module. When serving a page to a visitor, the page is fully rendered server-side, initially rendering the page HTML without interactivity. Then, when interaction is needed, the island’s JavaScript is loaded, run, and attached to the page. This process of hydration takes advantage of client-side rendering to optimize the addition of React components to the server-rendered HTML. Using islands comes with several benefits, including: Below, learn how to implement islands, along with available island props and hydration behavior.

Implementation

  • Import Island from @hubspot/cms-components.
  • Import the module you want to wrap, adding ?island to the end of the import URL.
  • Render the Island component, passing the module name into the module prop.
  • Any serializable props that you want to pass to the module, excluding functions, can be passed as props in the Island component.

Available props

Below are the available Island component props.

Hydration types

By default, the island initialization script will hydrate all islands as soon as possible (i.e., on load). But for more complex pages, you may want to defer hydration of non-critical page elements until the browser has finished all other work, or until the visitor scrolls down to the island. Using the hydrateOn prop, you can specify one of the following hydration behaviors:
  • load (default): hydrates the island on initial page load.
  • idle: defers hydration by using the requestIdleCallback method. This can be useful for lower priority components, allowing client resources to be used first on higher priority items.
  • visible: hydration won’t occur until the element is visible on screen by using the Intersection Observer API. This can be useful for components that aren’t immediately visible to the user on page load (i.e., elements farther down the page). For complex islands, this can provide a significant performance benefit: if the user never scrolls to see the island, it will never be loaded.
Last modified on February 10, 2026