Thursday, October 18, 2018

Improving Native WordPress Search

This article on WordPress search was originally published by Torque Magazine, and is reproduced here with permission.

If you have ever worked on a WordPress site with a massive amount of posts and pages, you might have noticed something about the WordPress search: it doesn’t perform well. In this article, we dive into why the default WordPress search doesn’t scale and some ways to make it better.

How WordPress Searches

By default, the native WordPress search performs a query on your database that looks something like this:

A native WordPress database search query

Let’s break down this query a little bit.

  • First, we are using SQL_CALC_FOUND_ROWS on the wp_posts table. This says, if there were no limit (coming later), how many results would the following query turn up?
  • Then we search through the post_title, post_excerpt, and post_content columns for the search term (in this example I searched “tech”).
  • And we ensure that the content returned is a post, page, or attachment (media).
  • We check to make sure the status is “public”–not deleted or private (if you are a logged-in user it will also search only your own private posts).
  • We order the results by matching title, descending, or post date, descending.
  • Last, we limit the results to 10, paginating the rest of the results.

That’s a whole lot of checks WordPress runs through just to return search results. And every time you iterate through wp_posts to perform each check, MySQL is processing all rows in wp_posts. When you have hundreds of thousands of rows in the wp_posts table, this query can get ugly really quick. Here are some benchmarks from a few of my sites:

Bar graph showing query times per number of posts

On sites with a very large number of posts, the query took over 20 seconds! This is not a scalable search option for sites with high traffic.

Problem Identification

Knowing what we now know about the default search behavior, it’s important to call out why this might not be ideal for some websites.

  • WordPress only searches the “post_title,” “post_content,” and “post_excerpt” fields for your search terms. It also only presents “post,” “page,” and “attachment” post types. For users with custom post types, custom fields, or plugins like WooCommerce that add different page/post types, this can be problematic: these items will not appear in search results.
  • The query used by WordPress search performs very poorly at over 100,000 posts. For news sites or media sites with more than 100,000 posts, a search could take several seconds to perform.
  • The poor performance on the search query could cause server performance issues if your site receives a fair amount of search traffic.

Improving on WordPress Native Search

So now that we know WordPress native search isn’t an option for many sites, we can explore search solutions. Based on our problem identification above, our qualifications for a search solution include:

  • Search tools that will search all content or customized sets of content, not limited to the post types or post fields defined by default.
  • Search tools that perform well when presented with large data sets.
  • Search tools that will not cause poor server performance when presented with high traffic.

Below we will explore several solutions, including enterprise-grade external services and WordPress plugins.

Algolia Search

Algolia is an enterprise-grade search solution in which your posts and content are indexed offsite and returns results to your users. Its feature set includes fuzzy search, geolocation search, multi-language support, and search with synonyms.

Comparing search performance on a site with thousands of posts, there are some clear benefits with Algolia. Below is the performance of the default WordPress search:

DevTool view of the default WordPress search performance

Notice the search took 7.43 seconds using the default WordPress search. However, after implementing Algolia search the results were nearly instant:

DevTool view of Algolia search performance

The Algolia results were about 15x faster than standard WordPress search! That is a massive improvement in performance. Not to mention, if the site supports a large amount of traffic with concurrent searches, it will not cause strain on the server. Offloading searches to an external service that is specifically optimized for searching is a big win.

The post Improving Native WordPress Search appeared first on SitePoint.


by Janna Hilferty via SitePoint

No comments:

Post a Comment