The problem here is going to be that, no matter what the "priorities" of the respective tasks might be, the (only!!) thing that's going to affect their impact on the system .. on the performance experienced by the web users .. is going to be: the scope of what the background task is doing [i]to the database.[/b] The number of records it affects, the size and frequency of the locks that it creates ... not the execution priority assigned to the background process by the operating system's scheduler!
(In fact, if the background task isn't given good priority it might simply wait longer, and delay things more.)
To be a "good citizen" alongside web-oriented activity, the background task must lock small areas of the database, hold them briefly. In other words, exhibit a performance footprint similar to that of the web-oriented activities.
(A slow, unobtrusive car that's in the fast-lane isn't unobtrusive... it's just holding up traffic.)