Reducing Performance Friction with Microsoft Clarity's DOM-Based Recording

The Performance Paradox of Session Recording

Adding a session recording tool often feels like a trade-off: you gain visibility into how users struggle with your UI, but you risk slowing down the page load or bloating the browser's memory. The core problem is the data volume. Recording a raw video stream of a user's screen would be bandwidth-prohibitive for both the client and the server.

Microsoft Clarity solves this by using DOM mutation recording. Instead of capturing pixels, it records the changes to the Document Object Model (DOM)—the structural representation of the page. When a user clicks a button or a modal opens, Clarity records the specific change to the HTML and CSS, then reconstructs that sequence in the dashboard. This approach significantly reduces the payload sent over the network.

How Asynchronous Loading Protects the Critical Rendering Path

The Critical Rendering Path (CRP) is the sequence of steps the browser takes to convert HTML, CSS, and JavaScript into actual pixels on the screen. If a tracking script blocks this path, the user sees a blank screen longer than necessary.

Clarity's snippet is designed to load asynchronously. This means the browser continues parsing the HTML and rendering the page without waiting for the Clarity script to download and execute. Because the recording logic is decoupled from the initial page paint, the impact on First Contentful Paint (FCP) is minimized.

Handling Sensitive Data via Masking

Since DOM recording captures the actual text and structure of your page, Personally Identifiable Information (PII) can inadvertently end up in your recordings. To prevent this, Clarity uses masking. Masking replaces sensitive text with placeholders (like asterisks) before the data ever leaves the user's browser.

While Clarity provides global masking settings in the dashboard, engineering teams often need granular control over specific fields, such as credit card inputs or private profile details.

Example: Implementing Manual Masking

To ensure a specific element is never recorded, you can use the data-clarity-mask attribute. This is a declarative way to tell the Clarity engine to redact the content of that specific DOM node.

<!-- This field will be captured normally -->
<div class="user-welcome">Hello, User!</div>

<!-- This field will be redacted in the session recording -->
<div class="user-email" data-clarity-mask>user@example.com</div>

<input type="text" class="credit-card" data-clarity-mask />

Verification: To verify this is working, deploy the change to a staging environment, perform a session, and then check the playback in the Clarity dashboard. The elements with the attribute should appear as solid blocks or redacted text.

Technical Limitations and Trade-offs

DOM-based recording is efficient, but it is not a perfect mirror of the user's screen. There are three primary limitations to keep in mind:

• Shadow DOM and Iframes: Because the recorder tracks mutations to the main document, content inside <iframe> tags or encapsulated Shadow DOMs may not be captured unless specifically configured or supported by the current version.
• High-Frequency Mutations: If your application uses heavy canvas-based animations or constant DOM updates (e.g., a real-time stock ticker), the volume of mutation events can increase the payload size, potentially impacting the client's upload bandwidth.
• CSS-Only Changes: Some purely visual changes triggered by CSS transitions or animations may not always be captured with 100% fidelity if they don't trigger a DOM mutation event.

Practical Verification Workflow

Before moving Clarity to production, run these three checks in a staging environment:

1. Network Inspection: Open the Browser DevTools Network tab. Filter for collect requests. Ensure these requests are happening asynchronously and not blocking the DOMContentLoaded event.
2. PII Audit: Navigate to your most sensitive forms. Verify that data-clarity-mask is applied and that no plain-text PII is visible in the session playback.
3. Performance Baseline: Run a PageSpeed Insights report. Compare the "Total Blocking Time" (TBT) with the script enabled versus disabled to quantify the overhead.