Those applications surely exist. SWI-Prolog still has a reputation of being slow. Over time it got a few times faster, placing it now amongst most of the “classical” systems (leaving the “modern” systems far behind 
) I assume that applications for which performance really matters mostly use YAP or SICStus.
SWI-Prolog has been reported to compete well with YAP and SICStus on many large applications though. It all depends what type of operations are critical. Do not forget that these old benchmark have a pretty poor coverage of what many large applications use.
If you mean with responsive, being capable to handle interrupts or, for the WASM version to yield back to the browser, the only long term blocking action is the (stack) garbage collector. Atom and clause garbage collections happen in a separate thread (as yet not for the WASM version) and thus run concurrently without blocking other threads. As we have seen, some foreign predicates may block handling interrupt for quite a long time, but this is fairly easily fixed. The interfaces for making them yield to keep the browser responsive when using the WASM version are there, but they are not easy to use. In particular if a lot of state is involved in the foreign code. With some effort, GC could be made to yield. Atom and clause GC are probably not even hard to keep responsive in the WASM version.
And, who knows what will happen in the WASM world. Emscrypten already allows C code to be compiled into asynchronous code. AFAIK at the cost of a large code blowup and a lot of performance for now. I see no real reason why the WASM VM cannot support asynchronous behavior though.