This document aims to assist Korean users who are learning Framer and are facing challenges due to a lack of Korean resources by translating official blog content into Korean and adding practical information. We hope it provides some help to those using Framer.

How does the Framer site become interactive?

A website is fundamentally built with HTML, and JavaScript must be added to enable interactions like button clicks or text input. For fast initial loading, Framer first delivers HTML via server-side rendering. This allows users and search engines to view the screen immediately.

Simultaneously, the necessary JavaScript for the process is loaded, which is known as the hydration process. This is the stage where React receives HTML and attaches event listeners, and from here, the site can respond to actions like clicks or scrolls. This is when the site can truly be called 'interactive'.

Some JavaScript-based elements need to fetch data from the server to become interactive. For example, the Framer homepage requires fetching the user's login status for areas marked in red from the server.

Other sites might need reviews, recent blog posts, or weather updates. Retrieving this data each time can take some time. Particularly when requests for one set of data lead to requests for another, it can create a chain effect, and all these operations are handled during hydration.

Moving forward, I will delve into more technical details to show what really happens. If you prefer to skip the technical intricacies, you may proceed to the final section.

React: The relationship between Suspense and Hydration

During hydration, React utilizes the Suspense feature when fetching data. Suspense is a mechanism to inform React that “this component is currently waiting for something”.

Previously, we used only one Suspense instance for this, as demonstrated in the following example.

<App>
  <Suspense>
    <Page>
      <Header />
      <DataFetching content="blog" /> {/* ⬅️ Suspense 발생 */}
      <DataFetching content="footer" /> {/* ⬅️ Suspense 발생 */}
    </Page>
  </Suspense>
</App>

Whenever 'blog' and 'footer' data are fetched, a single Suspense tag known as a “Suspense boundary” is activated, (this is referred to as ‘suspending’). React begins the data requests for these two components in parallel combination, but there is a nuanced behavior in this action.

If a component suspends and then receives data to unsuspend during hydration, React restarts hydration from the Suspense boundary holding the component.

This means that every time React requests data, it restarts rendering from a single Suspense tag under <App>. For instance, when fetching 'blog' data, React re-renders <Header> and the two <DataFetching> child components again. The same process happens when fetching 'footer' data.

Consequently, parts that need only one-time rendering get repeated multiple times. Components fetching data lead their parent components to re-render. In the example, assuming each data fetcher has child components, a total of 12 renderings occur: <Page> and <Header>, 3 times; blog data fetcher and its child components, 2 times; footer data fetcher and its child components, 1 time (= 6 + 4 + 2).

Faster Hydration: Granular Suspense

The above example might run quickly for small demos, but it would slow down significantly on websites with hundreds or thousands of components. Moreover, rendering speed varies according to the device (especially the CPU). It's crucial to ensure users with different device speeds experience equally fast interactions.

Initially, we attempted to resolve this with memoization (React.memo), wondering whether React would prevent re-rendering these components. Unfortunately, React schedules re-rendering for child components within Suspense boundaries, so this approach is not very effective.

To address this issue, you need to add granular Suspense boundaries around data-fetching components.

<App>
  <Suspense>
    <Page>
      <Header />
      <Suspense><DataFetching content="blog" /></Suspense> {/* 🎉 독립된 바운더리 */}
      <Suspense><DataFetching content="footer" /></Suspense> {/* 🎉 독립된 바운더리 */}
    </Page>
  </Suspense>
</App>

Now, each Suspense boundary can catch the components that suspend within its sub-tree structure. React resumes hydration right from the point where it caught the suspending component, eliminating the need for full re-rendering regurgitation. In practice, the Framer homepage expanded its boundaries from a single one to 151 granular boundaries.

This way, every component is rendered once during hydration, organizing the hydration process into a O(n) linear speed according to n, the number of nodes in the component tree. It's fast and linear, irrespective of how many data fetchers exist within the tree.

Implications for the Framer site

Beta testing results show a 50~80% increase in hydration speed across many devices, with speed improving up to 200% on slower devices depending on the amount of needed data during hydration. As a result, scroll animations activate faster, and the timeline for user interaction with the site significantly advances.

(Left: Before, Right: After; recorded on M2 Pro with 6x CPU throttling and 4G speed applied in the latest Chrome profile.)

In conclusion, scroll animations begin to respond faster, enabling users to interact with the Framer site sooner. Improvements have also been noted on pages with many SVGs. As SVG loading starts, hydration simultaneously kicks off. Measurements across all Framer sites visited on mobile devices have found elements like cookie banners appearing 42% faster on average.

Even on fast devices, this change is noticeable. Testing on an M2 Pro MacBook with a 100Mbit/s network revealed hydration completion times significantly advanced.

(Left: Before, Right: After; recorded on an M2 Pro Mac with 100MBit/s internet connection and the latest Chrome profile applied.)

Framer users will see these changes automatically applied without additional effort. Just republish your site to experience enhanced performance right away. Special thanks to performance engineer Ivan Akulov, who identified and addressed the root causes.

If you have any questions or concerns regarding performance, please contact the performance team on the community forum.

This article is a translated and adapted version of Framer's official blog post, ‘Sites now become interactive 50% faster’.