Adding Sitecore Search to your site? Watch out for this performance tradeoff!

If you’re going to be adding Sitecore Search to your React / Next.js app, you may have come across this documentation page showing how you can get started.

First, it says to install @sitecore-search/react. This is a package with a few minor dependencies that brings in some essentials that will make your life easier when using Sitecore Search. No problems with that.

Then, it has an innocent looking step:

Aditionally [sic], you can install @sitecore-search/ui a headless components package for building Sitecore Search widgets like recommendation, preview search and search results with Sitecore Search SDK.

npm install — save @sitecore-search/ui

This is an optional step where you can make use of the Sitecore Search team’s React component library / UI kit to really speed up the implementation effort.

They include a lot of components in this UI kit, about 15 components at time of writing.

The kicker and tradeoff though is what happens when you bring in this library:

"dependencies": {
        "@radix-ui/primitive": "^1.0.1",
        "@radix-ui/react-accordion": "^1.1.2",
        "@radix-ui/react-checkbox": "^1.0.4",
        "@radix-ui/react-collapsible": "^1.0.3",
        "@radix-ui/react-collection": "^1.0.3",
        "@radix-ui/react-compose-refs": "^1.0.1",
        "@radix-ui/react-context": "^1.0.1",
        "@radix-ui/react-direction": "^1.0.1",
        "@radix-ui/react-dismissable-layer": "^1.0.4",
        "@radix-ui/react-icons": "^1.3.0",
        "@radix-ui/react-id": "^1.0.1",
        "@radix-ui/react-label": "^2.0.2",
        "@radix-ui/react-popover": "^1.0.6",
        "@radix-ui/react-presence": "^1.0.1",
        "@radix-ui/react-primitive": "^1.0.3",
        "@radix-ui/react-select": "^1.2.2",
        "@radix-ui/react-slider": "^1.1.2",
        "@radix-ui/react-toggle": "^1.0.3",
        "@radix-ui/react-toggle-group": "^1.0.4",
        "@radix-ui/react-tooltip": "^1.0.1",
        "@radix-ui/react-use-callback-ref": "^1.0.1",
        "@radix-ui/react-use-controllable-state": "^1.0.1",
        "@radix-ui/react-use-previous": "^1.0.1",
        "@sitecore-search/common": "2.2.3",
        "@sitecore-search/react": "2.2.3",
        "@sitecore-search/react-templates": "2.2.3",
        "smoothscroll-polyfill": "^0.4.4"
      }

It brings in a lot of @radix-ui which is a whole other beast. It is a UI kit / atomic component library. Other popular options out there include Chakra UI, Mantine, Shadcn.

If you were going to be using Radix UI in your app anyway, no worries, you’ve got lucky, you can stop reading now and go on your day. If you weren’t going to use Radix UI, then unfortunately you’re going to be bloating your site to the tune of about 120kb. On the site I’m working on, this is about 10% of the total site js payload.

This can affect your Lighthouse score which in turn will affect your core metrics that in turn Google uses as part of its page ranking algorithm.

With @sitecore-search/ui I get a score of 68, and the “Reduce unused Javascript” line item shows up in red:

Without @sitecore-search/ui I get a score of 88, and the “Reduce unused Javascript” line item disappears totally from the audit.

Without @sitecore-search/ui

A couple of tools I recommend using if you’re interested in getting better performance scores:

• Webpack Bundle Analyzer — visualize your js after tree-shaking.
• Chrome DevTools Coverage — see exactly what code is or isn’t running.

In summary, I’m hoping that you’re more aware of what dependencies you’re bringing in and have considered their tradeoffs. I do recommend that you use a React component library that fits your team’s goals and requirements. I’m personally a big fan of Mantine. Thanks for reading.