Diagnose slow site search on a large product catalog

A WooCommerce store with roughly 15,000 products has a search box using WordPress's
native search, and search results take about 6 seconds to appear. Customers are
abandoning searches before results load, according to the analytics.

HOSTING: [shared/managed hosting plan through a mainstream host, no ability to install
or connect to a self-hosted Elasticsearch server, WP-CLI available but no root/server
access]
CURRENT SETUP: [no dedicated search plugin installed, relying on WordPress's default
search which runs a LIKE query across post_title and post_content, product attributes
stored in postmeta aren't searched at all]

Diagnose and recommend a fix like a consultant who knows native WP search doesn't
scale past a few thousand posts, not by suggesting generic query optimization:
1. Explain precisely why native search is slow at this catalog size: a LIKE '%term%'
   query can't use a database index efficiently, so it scans a meaningful portion of
   wp_posts and wp_postmeta on every search, and that scan only gets worse as the
   catalog grows.
2. Given the hosting constraint (no self-hosted Elasticsearch), rule out
   self-hosted-only options and evaluate the two realistic paths: a plugin that builds
   its own lightweight search index inside WordPress's own database (like FiboSearch),
   versus a hosted search-as-a-service option (like Algolia or ElasticPress's hosted
   tier) that indexes the catalog externally and returns results via API.
3. Recommend based on catalog size and budget trade-offs: a self-indexing plugin is
   the lower-cost, wp-admin-only path and likely enough at 15,000 products, while a
   hosted service is worth it if the client also wants faceted filtering, typo
   tolerance, or search analytics beyond what a plugin-level index provides.
4. Note that product attributes in postmeta currently aren't searched at all, so
   regardless of which path is chosen, confirm the new search solution actually
   indexes attributes and custom fields, not just title and content, or the "faster"
   search will still return worse results than customers expect.
5. Flag the edge case: switching search engines can break any existing custom code that
   hooks into WP_Query's search behavior, like a faceted filter plugin or a custom
   "search suggestions" dropdown built against the default query, so audit for that
   before cutting over, and plan to test search-dependent features in staging first.