WooCommerce’s built-in search uses WordPress’s default search functionality, which performs LIKE queries across post titles, content, and excerpts. For a store with 5,000+ products, this means scanning millions of characters in multiple database columns for every search request.
The performance degrades non-linearly. A search that takes 200ms with 500 products might take 3 seconds with 5,000 products and 15 seconds with 50,000. This is because LIKE ‘%search_term%’ queries can’t use database indexes effectively — they require full table scans.
The first improvement is implementing a proper search index. Elasticsearch or Algolia create pre-built indexes of your product data, turning every search into an index lookup instead of a database scan. Response times drop from seconds to single-digit milliseconds.
For stores that don’t need a dedicated search service, MySQL full-text indexes provide a significant improvement over LIKE queries. Combined with proper query caching, this can reduce search times by 80-90% without additional infrastructure costs.
WP Pro Host
Frequently Asked Questions
Why is WooCommerce product search slow on large stores?
WooCommerce’s default search uses WordPress’s built-in search functionality, which performs LIKE queries scanning post titles, content, and excerpts. LIKE ‘%search_term%’ queries cannot use database indexes effectively — they require full table scans. Performance degrades non-linearly: a search taking 200ms with 500 products may take 3 seconds with 5,000 and 15+ seconds with 50,000. This is a fundamental architectural limitation of the default search — it was designed for blog search, not ecommerce product search with thousands of SKUs and complex attribute matching.
What is the best WooCommerce search plugin for performance?
For stores under 10,000 products, SearchWP with WooCommerce integration provides meaningful improvement over default search through custom indexing. For larger stores or stores requiring real-time results, hosted search services (Algolia with WooCommerce plugin, or Elasticsearch via ElasticPress) provide the best performance — they maintain a search index outside the database that can be queried in under 50ms regardless of catalogue size. The tradeoff is added cost and complexity. FiboSearch (formerly Ajax Search for WooCommerce) is a popular middle-ground option that improves UX without requiring external infrastructure.
Does Redis help with WooCommerce search performance?
Redis helps indirectly by caching repeated search query results. If multiple customers search for “red dress” within a short window, subsequent searches after the first can be served from Redis rather than executing a full table scan. However, Redis caching does not fix the underlying query performance problem — it only reduces the frequency of executing the slow query. For stores with diverse search patterns (many unique search terms), cache hit rates will be low and Redis provides minimal benefit. The real fix for search performance on large catalogues is a dedicated search index (Algolia, Elasticsearch) or at minimum SearchWP with custom indexing.
How do I add full-text search to WooCommerce?
WordPress supports MySQL full-text search on FULLTEXT indexed columns, which is significantly faster than LIKE queries for text matching. Enable it by adding FULLTEXT indexes to wp_posts on post_title and post_content columns. Some search plugins use this automatically. However, full-text MySQL search still does not support product attribute matching (colour, size, material) without additional custom indexes on wp_postmeta. For attribute-aware search, a dedicated search engine (Algolia, Elasticsearch) that indexes both product content and attributes together is the most complete solution.
What AJAX search configuration improves WooCommerce performance?
Implement AJAX live search with debouncing (wait 300-400ms after the last keystroke before firing a search request) to reduce unnecessary API calls as customers type. Cache live search results on the server for common queries. Limit the number of results returned in live search previews (6-10 is sufficient) rather than fetching full product data for 20+ results. Ensure live search requests go to an optimised endpoint — not the default WordPress search URL — to take advantage of any custom search implementation or Redis caching. On mobile, consider a minimum character threshold (3-4 characters) before triggering live search.
Includes Elasticsearch on Scale and Custom plans, pre-configured for WooCommerce product data. For Growth plans, we implement optimised MySQL full-text indexes and search result caching that keeps product search under 200ms regardless of catalogue size.