Super User is a question and answer site for computer enthusiasts and power users. It's 100% free, no registration required.

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

Does the chrome browser behave differently when the computer is locked, or the window is not in the foreground? I am noticing that page load slower in such use cases on windows.

If so can this be disabled through any of their flags?

share|improve this question
This depends on the settings of your OS (which you haven't specified, to start with), for non-server OSes by default foreground applications get precedence over background applications. This is expected behavior, and it might or might not be that the developers went after the same thing. – Tom Wijsman Mar 1 '12 at 17:26
I added the OS, it was for windows. So I do understand the OS does this - however I am noticing a difference from IE (on the same scenario). So it would seem the browser is doing something extra...or on top of what the OS does. – GeorgeU Mar 1 '12 at 17:30
BTW they do state this "Just as Windows can do this for desktop applications, a multi-process browser can do this for tabs. When you navigate away from a tab, Chrome uses this as a hint that the resource for that tab are less important than your foreground tab. Chrome will lower the priority of the now backgrounded tab and also give back a portion of the working set for that tab to the OS. " – GeorgeU Mar 1 '12 at 17:39
From your description it sounds like the system is simply paging Chrome’s memory. Do you have a lot of tabs open with pages with lots of images, JavaScript, and Flash? Is the hard-drive LED flickering a lot or the hard-drive thrashing. If so, then that is normal if you leave a program that uses a lot of memory unused for a while; Windows will eventually page it’s memory to disk, (even if it does not need the memory right away). – Synetech Mar 10 '12 at 17:19

The simple answer is no. Google Chrome does not behave differently when the computer is locked or the browser is not full screen.

The slightly longer answer is that when the screen is locked, the user is still logged in, and all user applications continue to run as normal but on the user-desktop rather than the secure desktop. All drawing events are shortcircuited to avoid wasting CPU drawing frames that aren't going to be shown, but nothing much else happens that Google Chrome will see.

One other feature of running in the background is that threads get smaller timeslices when they are not in the foreground - a deliberate feature in Windows because a 5% slowdown on a foreground thread can make the system appear slow, whereas a 5% slowdown on a background process is usually unnoticeable.

In Windows this same principle also carries over for network and disk latency. Foreground threads are given priority for queued network operations, so if thirty threads all want to do DNS lookups (as may very well be the case if you open loads of new tabs in Chrome), the ones that happen first are the ones for the tab you're looking at.

A combination of all of these factors means that when Google Chrome isn't in the foreground (e.g. because something else is, or the machine is locked) and other things are going on in the system, Google Chrome may perform less well than if it were in the foreground.

Ultimately though, this is Windows being clever and trying to make your user-experience less sluggish, not Google Chrome doing anything different.

share|improve this answer
Matt, I was aware of the windows logic and originally I thought it was windows. However, even after forcing the priority to Normal for the chrome instance - it still behaved differently - slower. – GeorgeU Mar 6 '12 at 16:20
The priority boost given to background threads is different to the task priority given in Task Manager. Changing this behaviour is a system wide change, and can be done by going to ControlPanel > System > Advanced System Settings > Advanced > Performance > Settings > Advanced > Adjust for best performance for Background threads. – SecurityMatt Mar 6 '12 at 16:55
matt i will give it a try. Still not convinced since I do not see the issue on IE, running in the same scenario. Also Chrome documentation hints that they are doing extra logic in addition to windows. – GeorgeU Mar 6 '12 at 17:13
That page seems to suggest that when a tab is in the background it is also marked "low" priority by Chrome, which means that the timeslices and priority for network and disk access will be lower for that process than all other running applications. When you said before that you were raising the priority for Chrome, are you sure you were raising it for the tab-process and not for the window-process? Each window has it's own process as well as each tab, but it's the tab that'll need its priority raising. – SecurityMatt Mar 6 '12 at 17:19
well I achieve it on my own build of Chrome, by ensuring that SetPriorityClass is not lowered below normal (in the chrome code). – GeorgeU Mar 6 '12 at 18:01

Yes, Chrome does set a much lower priority to background tabs.

If an entire window is in background, then all the tabs will also be in background. The JavaScript on the tabs is processed only once every 1 or 2 seconds (I can't remember which). This delay is hard-coded in a constant in the Chromium source code. You'd need to recompile Chromium to give more priority to background tabs.

I know because I looked into it. I wanted a JavaScript to run in background and trigger every few hundred milliseconds, but after the tab was in the background for a bit, the timers triggered only once every 1 or 2 seconds.

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.