Used properly the ASP.NET Master Page can be a useful and time saving mechanism, but there are some pitfalls which developers should be aware of and some common architectural mistakes which can render them more trouble than they are worth. Hopefully by reading this you can avoid some of the common (cough?*$ mistakes I already made) problems.
The n Commandments
The second mistake I made was trying to access Master Page properties from my user controls, while this can be done, it involves referencing the virtual path in the .ascx file then casting Page.Master to the referenced MasterPage.
<%@ Reference VirtualPath="~/MyMasterPage.master" %>
MyMasterPage m = (MyMasterMaster) Page.Master;
Another easy mistake is in architectures which involve using multiple user controls on the page, which are shown or hidden depending on the function of that page. While this one is not necessarily isolated to master pages it is important in the context of web 2.0 desktop like web applications which magically have elements appear and disappear. Just because an element is not visible it does not at all mean that the code will not run, I worked on an application recently in which I managed to literally quadruple the speed in a matter of minutes by making sure the code in invisible user controls wasn’t running until actually required. The previous developer had presumed that code only runs if the control is visible (logical), the choice of logically breaking up functions into specific user controls was spot on however, this oversight caused the app to run like a snail on ketamine.
Hopefully these pointers will help you have a painless Master Page experience!