This question is too broad to answer in detail, but here is how I would approach this:
- Given that WP’s native search is slow, we can rule out using this to get intermediate results while the visitor is typing. Unless we have a lightning fast dedicated server.
- So, this means we will have to build our own index for search purposes. In order to limit the size of this index we would have to choose which fields we want to use for the suggestions. I’d say: title, excerpt, category and tags, along with the link to the page. Let’s say these fields combined are a 400 byte chunk of information.
- Now, every time we save a post/page/attachment, we must store these chunks in a place that is readily accessible. The best way to do this probably depends on the eventual size of the site. With 1000 posts your index would be 400k bytes. That could be stored as an array of chunks in an option field in the database. If the site is much larger, one would probably save this array in a file.
- Now we have an index, the question is how to apply it to the site. There are two possible approaches: send searches to the server or download the whole index to the user end. If the index is 400k that’s the size of an image, so just sending it with the page and search it locally with javascript would be acceptable. This is probably the fastest way. If you cannot send the whole index every time, you’ll have to do the search on the server side by sending ajax-requests. The option table is always cached, so readily available. Keeping an index file cached requires some work, but is doable.
Bottom line: yes, this can be done, but expect it only to be really fast if there are not too many posts to index.