For loading pages, plugins won't do the trick
If you want your page to be blocked until it's loaded, content blocker element should be part of your page and not generated by any plugin that always run after your page has loaded. At some point in time or another.
<body>
...
<!-- make it last -->
<div id="blocker">
<div>Loading...</div>
</div>
</body>
And have CSS do the rest
#blocker
{
position: fixed;
top: 0;
left: 0;
width: 100%;
height: 100%;
opacity: .5;
background-color: #000;
z-index: 1000;
}
#blocker div
{
position: absolute;
top: 50%;
left: 50%;
width: 5em;
height: 2em;
margin: -1em 0 0 -2.5em;
color: #fff;
font-weight: bold;
}
And Javascript that clears blocking:
$(function(){
$("#blocker").hide();
});
This is a working example using the code above. It removes blocker on timeout, because it's such a simple document.
Important notice
But maybe you're not understanding this the right way. Maybe you would like to block existing page when it posts back to server, because that's a different story. In this case your plugins should suffice and should run on unload window event and display blocker element. This would block existing page while it posts back its data and before browser starts receiving new content (which can be blocked with previously shown technique).
It seems the problem is browser waiting for server response
It's hard to tell since you can't pin point it yourself. But suppose the problem is that browser is waiting for server to respond. And as you mention session loading is slow. Two things:
- Optimise DB call to get those menu data quicker (if it really takes that long - have you checked with profiler?)
- Have a static default HTML page that displays the Loading content and executes a redirect:
- using a META refresh tag - safer for old browsers and those without javascript
- javascript - better for modern pages and especially because your page is using Javascript (
__doPostback anyone)
It seems that your best bet is the combination of both. But go one step at a time and see if it's better.
One more thing. I know that waiting for the first response (application start) takes some time. It does so on many pages. But people usually don't really bother since users can't do no harm with data because it's still not displayed. It's much worse when your response times are long when using the page, because users tend to click the same button several times (when creating/updating data for instance). That is much more harmful.
And maybe you're confusing the Asp.net application start-up with your session loading. When you application first starts it takes much longer for server to respond, because it has to compile your application and start it up. This can take considerable time. There are several workarounds for that that include changes to application recycling times and separate heartbeat services that make tiny requests to application just to keep it alive during longer time of inactivity.
You should also take into account that your in development page is running on a desktop machine. You should know whether your server is faster.
So maybe it's not the session creation but rather application start-up. You should tell the difference by opening a page in a browser and waiting for it to complete, then close the browser and opening it again (so new session will get created) and access your application. If it loads faster then it's not your session's fault but rather application start-up when .net framework has to compile your application.
Define the problem first then start mitigation.
