Microsoft Clarity adds roughly 30-50 KB of compressed JavaScript and 100-300 ms of main-thread work to a typical WordPress page. On a fast server that is barely visible. On a slow one it is the thing you notice, because Clarity landed on top of a page that was already spending 900 ms waiting for the database.
Does Microsoft Clarity slow down your website?
Yes, measurably, but usually by less than people assume. Clarity loads asynchronously, fires after the page starts rendering, and does its heavy lifting (session recording, DOM mutation capture) while the user is already looking at content. The cost lands mostly in CPU time and interaction responsiveness, not in how fast the hero image appears.
Where it hurts is on pages that had no headroom to begin with. If your Largest Contentful Paint is 1.8 seconds, adding Clarity moves it to maybe 1.9. If your LCP is 3.4 seconds because the theme loads four font files and the shared host takes 1.1 seconds to return HTML, Clarity pushes you from "bad" to "bad and now I have a suspect." The tracker gets blamed because it was the last thing that changed.
That distinction matters commercially. Clarity gives you heatmaps, session recordings and rage-click data for free. Ripping it out to save 150 ms on a page that is already losing 1.5 seconds to the server is a bad trade. You just gave up your only view of why people abandon the form.
What third-party scripts cost in Core Web Vitals terms
Third-party JavaScript affects three of the metrics Google uses, and it affects each one differently. Understanding which metric each script touches tells you whether to defer it, move it, or leave it alone.
| Script | Approx. compressed size | Main-thread work | Metric most affected |
|---|---|---|---|
| Microsoft Clarity | 30-50 KB | 100-300 ms | INP, some TBT |
| Google Tag Manager (container only) | 35-45 KB | 50-150 ms | TBT |
| GTM with 6-8 tags firing | 150-400 KB total | 400-900 ms | INP, LCP if tags block |
| Intercom / Drift / HubSpot chat | 250-600 KB | 600-1,200 ms | LCP, INP, CLS |
| Hotjar | 80-120 KB | 200-500 ms | INP |
| Meta Pixel | 70-90 KB | 150-350 ms | TBT |
| Google Analytics 4 (gtag.js) | 60-80 KB | 100-250 ms | TBT |
Numbers vary by page and by what you configure, so treat these as ranges to check against your own field data, not gospel.
The pattern in that table is consistent: analytics and session-replay tools are small. Chat widgets are enormous. A live chat bubble routinely ships more JavaScript than your entire theme, and it frequently injects DOM after paint, which is how you end up with layout shift on mobile.
According to the HTTP Archive Web Almanac, the median mobile page loads 22 third-party requests, and third-party JavaScript accounts for a substantial majority of all script bytes on the median page (2022). Most site owners cannot name half of what is loading.
And according to Google's Core Web Vitals thresholds, a page needs Interaction to Next Paint at 200 ms or under to pass, with 500 ms as the failure boundary. INP is where script bloat shows up most brutally, because every tracker that listens for clicks, scrolls and mutations adds work to the exact moment the user does something.
How to test Clarity's real cost on your own page
Stop reading benchmarks and measure your page. This takes about 20 minutes and produces a number you can act on.
Run a baseline first. Use WebPageTest with a mobile profile and 4G throttling, three runs, and record LCP, Total Blocking Time and total JavaScript bytes. Do it at the same time of day, because shared hosting response times swing with neighbor load.
Then block the script and rerun. WebPageTest has a "Block" field in advanced settings; add clarity.ms to it. That gives you an identical test with Clarity absent. The delta between the two runs is your actual cost, on your actual page, on your actual host.
Do the same thing one script at a time for GTM, your chat widget and any pixel you can identify in the network panel. You will almost certainly find that one script accounts for more than all the others combined, and it usually is not Clarity.
For field data rather than lab data, check the Chrome User Experience Report through PageSpeed Insights. Lab tests tell you what a script costs on a simulated device. CrUX tells you what real visitors on real phones experienced over the last 28 days. If lab says 2.1 seconds and field says 4.3 seconds, your visitors are on worse hardware and worse connections than your test profile, and every millisecond of third-party work is costing you more than the lab suggests.
One more check worth doing: look at TTFB in isolation. If your server takes more than 800 ms to return the first byte of HTML, no amount of script management will save the page. That number is set before a single tracker loads. We wrote about the server-side bottlenecks that keep WordPress slow after caching because this is the most common misdiagnosis we see: someone spends a week auditing scripts when the fix was a database query taking 700 ms on every page load.
Which scripts to defer, delay, or drop
Sort every third-party script into one of four buckets based on what it does for the business, then act on the bucket.
Keep as-is. Anything that must run before consent decisions or that affects what renders. Your consent management platform, for example. Deferring it defeats the purpose and creates compliance exposure.
Delay until interaction. Session replay, heatmaps, most pixels. These do not need to fire in the first two seconds. Loading Clarity on first scroll or first click costs you a fraction of a percent of recordings and removes it from the critical path entirely. WP Rocket, Perfmatters and FlyingScripts all do this with a keyword match. The one caveat: delayed Clarity will miss the very first interaction on bouncing sessions, so if rage-click detection on landing is your reason for using it, keep it eager.
Move server-side. GA4 and Meta conversion tracking can run through server-side GTM or the Conversions API instead of browser JavaScript. That removes hundreds of kilobytes from the client. It costs more to set up and requires an endpoint, so it earns its keep on stores doing real volume, not on brochure sites.
Drop. The pixel from the agency you fired in 2023. The A/B testing tool nobody logs into. The chat widget that routes to an inbox no one reads. Every one of these is pure cost. Auditing them takes an hour and is the highest-return performance work available on most sites.
The math on dropping dead scripts is easy to justify. If you have four abandoned trackers averaging 90 KB each, you are shipping 360 KB and roughly 800 ms of main-thread work to every visitor for zero business value. According to Google's research with Deloitte, a 0.1 second improvement in mobile site speed increased retail conversion rates by 8.4% and average order value by 9.2% (2020). That is the framing to use when someone asks why script cleanup is worth billable time.
Why the server is usually the bigger problem
Here's the sequence that matters: the browser requests HTML, the server thinks, the server responds, the browser parses, then third-party scripts load. Everything a tracker does happens after the server has already spent its time. Which means a script audit can only ever recover the portion of load time that comes after TTFB.
On a slow shared host, TTFB of 900 ms to 1.4 seconds is normal. You have burned over a third of your 2.5 second LCP budget before a single byte of your theme has rendered. In that situation, trimming 200 ms of Clarity gets you from 3.6 seconds to 3.4. Still failing. Fixing the server gets you from 3.6 to 2.3, and then Clarity's 200 ms is comfortably inside budget.
We see the same order of operations problem in other places. It shows up in the Full Site Editing versus page builder decision, where people blame the builder for slowness that is actually PHP workers and object caching. It shows up in AI-built sites around month three, where the generated front end looks fine and the hosting underneath it was never configured. The front end gets the blame because it is the part you can see.
Our hosting stack is built around this: NVMe storage, tuned PHP-FPM pools, object caching and a CDN in front, so the HTML arrives before the browser has to make decisions. When TTFB sits in the 150-300 ms range, you can run Clarity and GTM and a chat widget and still pass Core Web Vitals. You are not choosing between measurement and speed.
That is the actual business argument for paying for managed hosting instead of $8/mo shared. Not that the marketing pages load faster. That your marketing team can install the tools they need without asking permission from the performance budget. If you want the specifics of what we tune and what the limits are, the spec sheet lists it.
What this looks like as a decision
Run the four-step version and stop.
Check TTFB first. If it is over 800 ms, fix hosting before touching scripts, because script work cannot recover server time. Then list every third-party domain in your network panel and identify the business owner of each one. Delete anything nobody claims. Delay session replay and pixels until first interaction. Leave Clarity running, because free qualitative data on why people abandon your checkout is worth 150 ms and nothing else in your stack gives you that.
Agencies running this across a portfolio should do it as a documented pass and put the before and after numbers in the monthly report. We covered the format in our piece on sending the monthly WordPress report before the client asks, and script cleanup is one of the few line items where you can show a chart that moves.
If your TTFB test came back ugly and you would rather someone else fix the server than spend a Saturday on PHP-FPM tuning, TopSyde managed WordPress hosting starts at $89/mo per site, includes migration, and comes with a 30-day money-back guarantee. Support answers in under 2 hours during business hours, and monitoring runs 24/7. See pricing or send us the URL and we will tell you what your first byte is costing you.
Frequently Asked Questions
Does Microsoft Clarity affect SEO rankings?
Not directly, and not enough to matter on a well-hosted site. Clarity's 100-300 ms of main-thread work can nudge Interaction to Next Paint, which is a Core Web Vitals metric Google uses as a ranking signal. But Core Web Vitals are a tiebreaker, not a primary factor, and if Clarity is what pushes you over the INP threshold, you had almost no headroom to begin with.
Is Microsoft Clarity slower than Hotjar?
Clarity is generally lighter. Clarity's script runs around 30-50 KB compressed versus roughly 80-120 KB for Hotjar, and Clarity tends to do less synchronous work. Clarity is also free with no session limits, while Hotjar caps sessions on lower tiers. Measure both on your own page with WebPageTest's block feature before switching on someone else's numbers.
Should I delay Clarity until user interaction?
Usually yes, with one exception. Delaying until first scroll or click removes Clarity from the critical rendering path entirely and costs you very little data. The exception is if you are specifically studying immediate bounces or rage clicks on landing, since a delayed script will not capture the first interaction on a session that ends in three seconds.
How do I know if my slowness is scripts or my server?
Look at Time to First Byte. It measures how long your server takes to return the first byte of HTML, and it happens before any third-party script loads. Over 800 ms points at hosting, PHP, or database queries. Under 300 ms with a slow overall load points at front-end weight, which includes third-party scripts, images and render-blocking CSS.
Topics
DevOps & Security Lead
12+ years DevOps, Linux & cloud infrastructure certified
Marcus leads infrastructure and security at TopSyde, managing the server fleet and AI monitoring systems that keep client sites fast and protected. Former sysadmin turned WordPress hosting specialist.
