Repository navigation
[Performance] Reduce Homepage Total Blocking Time from Unnecessary Search Indexing in IntegrationsGrid #8019
Description
Activity
Hi! I’d like to work on this issue if it’s available. I’m interested in investigating the unnecessary search indexing on the homepage and implementing a focused performance improvement without affecting the integrations catalog’s search and filtering functionality.
Would it be possible to assign this issue to me? Thank you!
I'd like to work on this — the root cause is in the shared
useDataListhook (src/utils/usedataList.js), which eagerly builds the full js-search TF-IDF index on mount regardless of whether the consumer ever exposes search. Plan: make the index build lazy (only on the first actual search keystroke, cached until the dataset changes) instead of changingIntegrationsGriditself, sinceuseDataListis shared by 7 other components (blog, resources, news, Sistent) that have the exact same problem. Could you assign this to me?Hey @PARTH-TUSSLE @leecalcote , I'd like to take this one on!
I dug into the code and found what's driving the TBT hit: useDataList builds a full js-search TF-IDF index over the entire integrations catalog (titles + full MDX body) synchronously on mount — and there's actually a duplicate useEffect in there too, so rebuildIndex() fires twice on first render for good measure. IntegrationsGrid pulls this in even on the homepage, where it's only ever showing a static 13-item preview with a "See All" button — no search box, no filtering, so all that indexing work is pure waste on the critical path.
Here's how I'd fix it:
useDataList.js: Make the index lazy instead of eager. Build it on-demand the first time searchData actually runs a query, cache it (ref/memo) so it's not rebuilt on every keystroke, and only rebuild when dataList itself changes. Also delete the redundant empty-dependency useEffect — no reason to build the index twice. This helps every page that uses this hook, not just the homepage (Blog, Resources, News, Sistent, etc. all go through it too).
IntegrationsGrid.js: Add a hasSearch prop (default true, but false for the homepage's count={13} preview). When false, skip rendering the search box and filtering UI controls, rendering the static slice directly without unnecessary setup.
Verification: I'll re-run Lighthouse/DevTools profiling on both desktop and mobile against the 4,260ms / 1,630ms TBT baselines, and manually confirm the full integrations page still searches, filters by category, and handles empty states with zero regressions.
Happy to get started right away if you can assign it to me — I'll open a PR as soon as I have something working!
Hey @neo0007777 — heads up, this one's already in progress: I called dibs on 2026-09-05 and opened PR #8023 with essentially this exact fix (lazy TF-IDF index build in
useDataList, cached untildataListchanges, plus dropping the duplicate empty-depuseEffect). It's up for review now. @PARTH-TUSSLE @leecalcote might want to assign it over there to avoid duplicate work — happy to redirect you to another open issue if you're looking for something to pick up.@Bryandero98 we need to first ask for issue assignment (explaining your approach) first, and then once its assigned, then only start working on fixing it. Assigning it to you, assuming its your first time here, but please keep this in mind moving forward! Thanks for understanding!
Current Behavior
The Layer5 homepage performs significant client-side JavaScript work during its initial load that is not required for the homepage experience.
PageSpeed Insights reports:
Lighthouse profiling shows approximately 2.1 seconds of main-thread CPU time consumed by the homepage JavaScript workload on desktop.
Root Cause
The homepage renders the
IntegrationsGridcomponent, which currently uses the site's search/data-list infrastructure.Inside
IntegrationsGrid.js,useDataListis initialized with the integrations catalog data:The underlying
useDataListimplementation builds ajs-searchTF-IDF search index across the integrations catalog during client-side execution.The indexing work runs on the main thread during initial page load.
However, the homepage does not expose the search or category-filtering interface associated with this data. It only renders a limited set of integration entries as part of the homepage integrations section.
As a result, the homepage performs substantial search-indexing and catalog-processing work that is not required for the initial homepage experience.
Desired Situation
The homepage should avoid performing unnecessary search-indexing or heavy catalog-processing work during its initial load.
The integrations displayed on the homepage should continue to render and function normally, while the search functionality required by the integrations catalog remains unaffected.
Acceptance Criteria
js-searchindexing during its initial load.Performance Evidence
Current Metrics
The current TBT is a significant contributor to the poor homepage performance score, particularly on desktop.
The primary finding is that search-indexing and catalog-processing work is performed even though the homepage does not require the associated search functionality.
Scope
This issue focuses specifically on unnecessary search/indexing work associated with the homepage
IntegrationsGrid.Other homepage performance findings, including LCP, CLS, and bundle size, are tracked separately.
Related Screenshot
Contributor Resources and Handbook
The layer5.io website uses Gatsby, React, and GitHub Pages. Site content is found under the
masterbranch.