I know this is probably out of your control, but 30 seconds is really long. There probably is no index on the fields in the database that is not a username. Tell the developer to add an index and things would go much faster.
Solution 1: Add an advanced search button
In terms of UI, you are talking about a search-as-you-type (type-ahead) kind of field, which assumes that users will see results while they are typing. Because that's not possible when searching for non-usernames, I would not offer that functionality on a non-username search. This means I would offer a search field with "Search for username" as label and an "advanced search" button opening a second field allowing to search for non-usernames. The second field would not be a type-ahead type of field, so you'll need to add a submit button.
This is a clunky solution, but better aligned with expectations of the user who expects instant results when using a type-ahead field.
Solution 2: Execute 2nd search when user stops typing
A more complex solution would be to perform the non-username search after the username search. This means that the list of results would first show matching usernames followed by an entry with a spinner with text: "searching in names, job titles,...". So, when you search "jo", the results list would show:
- (spinner) searching across first name, last name,...
When the 30 second non-username search is complete the spinner disappears and the results are added to the list. You will have to play with the delay times (times between typing and executing a search request) to get the experience right. I suggest executing the username search very quickly while typing, and execute the non-username search when the user stops typing. Otherwise your server will be hit with several request (for each character typed) that will take 30 seconds and your server will be under a lot of stress.
This suggestion assumes you can successfully hook into the type-ahead functionality often offered out-of-the-box by popular front-end libraries. This may be harder than my first suggestion to develop.
But let me repeat again, a 30 second search is extremely long. Unless you are dealing with searching within millions of records on a slow server, it would probably be easier to fix the database scheme than "solve" it on the UI level. The other thing is, usernames, first names etc. don't change that often, so things can be heavily cached. Adding an database index to these fields basically means you tell the database to create a cache against these fields.