We have an ObjC-based Mac App utility. A fair fraction of the functionality is built in JavaScript and resides in a couple of WKWebViews so that we can more easily share code with other platforms. Because it is a utility, usually the application will be hidden or at least not the frontmost application. But if the user hits a hotkey or provides certain other inputs, the app should respond immediately with a series of actions. In the Obj-C part of the code, we can do this to alert the system that our non-visible, non-active, application is doing something in response to the user input: [[NSProcessInfo processInfo] beginActivityWithOptions: NSActivityUserInitiatedAllowingIdleSystemSleep reason: @"Do the Thing"] To get the JavaScript to do the work needed, we call evaluateJavaScript:completionHandler: on one of the WKWebViews. The JavaScript performs a series of computations, then uses window.webkit.messageHandlers.xxxx.postMessage to return results to the ObjectiveC code, which then takes action based on various SDKs, and the user sees the result. The problem we are encountering is relatively infrequent, but it appears that macOS puts the 'Web Content' process (which every WKWebView has) to sleep, and sometimes delays of many seconds (sometimes over 15 seconds) occur between the evaluateJavaScript:completionHandler: call and the postMessage response. These observed delays are not related to complexity of the JavaScript computations or the amount of data being processed. Using the Console, we can see that evaluateJavaScript:completionHandler: seems to result in this message: 0x104682280 - [PID=0, throttler=0x1046e8498] ProcessThrottler::Activity::Activity: Starting background activity / 'WebPageProxy::runJavaScriptInMainFrameScriptWorld' Then shortly afterward: 0x104682280 - [PID=0, throttler=0x1046e8498] ProcessThrottler::Activity::invalidate: Ending background activity / 'WebPageProxy::runJavaScriptInMainFrameScriptWorld' So it seems that evaluateJavaScript:completionHandler: "wakes up" the WKWebView similar to the beginActivityWithOptions:. But many parts of our computation do some work, then expect the next "tick" in JavaScript to continue using the partial result to produce more work. I suspect that the delays are related to the WKWebView being put "back to sleep" before all the "next tick" code executes. Because these actions are taken in response to user invocation, delays of more than a fraction of a second are instantly noticeable and result in user dismay. Are there any configuration settings that can prevent the 'Web Content' process from going to sleep? Or (better) techniques or mechanisms that would force the process to "stay awake longer"? (Keeping in mind that the WKWebView is likely not visible, and/or the containing window may be hidden.)