[Performance] Reduce Homepage Total Blocking Time from Unnecessary Search Indexing in IntegrationsGrid

[PARTH-TUSSLE]

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:

• Desktop Total Blocking Time (TBT): 4,260 ms
• Mobile Total Blocking Time (TBT): 1,630 ms
• Desktop Performance Score: 15/100
• Mobile Performance Score: 22/100

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 IntegrationsGrid component, which currently uses the site's search/data-list infrastructure.

Inside IntegrationsGrid.js, useDataList is initialized with the integrations catalog data:

const { queryResults, searchData } = useDataList(
  data.allMdx.nodes,
  setSearchQuery,
  searchQuery,
  ["frontmatter", "title"],
  ["frontmatter", "title"]
);

The underlying useDataList implementation builds a js-search TF-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

• The homepage does not perform unnecessary js-search indexing during its initial load.
• The homepage integrations continue to render correctly.
• Existing integrations navigation and functionality remain unchanged.
• The integrations catalog search/filter functionality continues to work without regression.
• Desktop Total Blocking Time is measurably reduced from the current 4,260 ms baseline.
• Mobile Total Blocking Time is measurably reduced from the current 1,630 ms baseline.
• Main-thread CPU usage during homepage load is measurably reduced.

Performance Evidence

Current Metrics

Metric	Desktop	Mobile
Performance Score	15/100	22/100
Total Blocking Time	4,260 ms	1,630 ms
Main-thread CPU workload	~2.1 s	—

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 master branch.

• 📚 See contributing instructions.
• 🎨 Wireframes and designs for Layer5 site in Figma (open invite)
• 🙋🏾🙋🏼 Questions: Discussion Forum and Community Slack.

Join the Layer5 Community by submitting your community member form.