no more nor less than any other control added to the page. Remember, EVERY server control you add to the page has that same life cycle all of its own.
Of course that's assuming that you (or some other developer) do not do something to ACTIVELY make it degrade performance (i.e. making it count to a billion every page_load won't help performance).
Edit
Okay, here's the thing.
First, you're asking for a yes/no response to a question whose answer is "it depends." And the answer is "it depends" because I don't know how said user control is getting tortured in its related code.
Second, I'm going to add more text here. Basically I'm going to repeat what I said in a four sentences up above in about 1,000 words. So....
If you take a brand new user control. Don't add any code to it in the CodeBehind. Don't drop any server controls on the ASPX side of things.
Then there will be no difference in how it affects performance than adding an Asp:Button or an ASP:Label to the designer will affect performance.
TO BE CLEAR: Until you add stuff to a user control, it is no more, nor less, impactive on a website's performance than any server-side control is.
Will there be an "impact" on performance? Technically, yes, but effectively, no.
And that is a very important distinction. Remember, every server side control makes a minute impact on performance. They're instantiated objects, and instantiated objects consume memory and resources. Of course that impact is negligible, and I would only considered that minuscule impact as "degradation" when you're adding hundreds of controls (server or user) to a page.
The USE of user controls is not where you need to be concerned.
Your concern needs to be in the IMPLEMENTATION of the user control.
It's when a programmer gets into that CodeBehind and starts doing stupid things to eat up memory and processor cycles that things start degrading. Alternatively, how the programmer implements the user control can improve the performance of a web application (as David stated here).
Edit 2
The question "in general whether it is good to use usercontrols versus not to do the same work" is not the question you're asking up above. If the task you're doing degrades performance it's not going to matter if your task is in a user control or not. Additionally, if it's a good idea depends on the project, the team, the scope, and maybe even design paradigms.
- The answer to "in general, is there a performance degradation to using a user control" is "effectively no."
- The answer to "in general, is it a good idea" is "it depends."
- The answer to "in general, will a task be better in a UserControl or not" again, is "it depends."
Without details about your specific situation (code base, design, dev team, maintenance team, etc) there cannot be a better answer.
I've built applications where using a User Control was overkill and would have bloated the application unnecessarily. I've built applications where using a User Control was not precise enough and was actively hard on the back end [we were dynamically instantiating controls, so we used Custom and Composite Server Controls rather than user controls (all code, versus code + designer)]. And I've built applications where user controls were the perfect solution.
But all of those decisions were made due to design.