对于加载页面,插件无法解决问题
如果您希望页面在加载之前被阻止,内容阻止器元素应该是页面的一部分,而不是由始终在页面加载后运行的任何插件生成。在某个时间点或另一个。
<body>
...
<!-- make it last -->
<div id="blocker">
<div>Loading...</div>
</div>
</body>
让 CSS 完成剩下的工作
#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;
}
以及清除阻塞的Javascript:
$(function(){
$("#blocker").hide();
});
这是一个使用上面代码的工作示例。它会在超时时删除阻止程序,因为它是一个如此简单的文档。
重要通知
但也许你没有以正确的方式理解这一点。也许您想在现有页面回发到服务器时阻止它,因为那是另一回事。在这种情况下,您的插件应该足够了,并且应该在unload
窗口事件和显示拦截器元素上运行。这将在它回发其数据时以及在浏览器开始接收新内容之前阻止现有页面(可以使用先前显示的技术阻止)。
似乎问题是浏览器等待服务器响应
这很难说,因为你自己无法确定。但是假设问题是浏览器正在等待服务器响应。正如你提到的会话加载很慢。两件事情:
- 优化 DB 调用以更快地获取这些菜单数据(如果确实需要那么长时间 - 您是否使用探查器检查过?)
- 有一个显示加载内容并执行重定向的静态默认 HTML 页面:
- 使用 META 刷新标签 - 对旧浏览器和没有 javascript 的浏览器更安全
- javascript - 更适合现代页面,尤其是因为您的页面使用 Javascript(
__doPostback
任何人)
看来你最好的选择是两者的结合。但是一步一步走,看看是否更好。
还有一件事。我知道等待第一个响应(应用程序启动)需要一些时间。它在许多页面上都这样做。但是人们通常不会真正打扰,因为用户无法对数据造成任何伤害,因为它仍然没有显示。当您在使用页面时响应时间很长时,情况会更糟,因为用户倾向于多次单击同一个按钮(例如在创建/更新数据时)。那危害更大。
也许您将 Asp.net 应用程序启动与会话加载混淆了。当您的应用程序第一次启动时,服务器响应需要更长的时间,因为它必须编译您的应用程序并启动它。这可能需要相当长的时间。有几种解决方法,包括更改应用程序回收时间和单独的心跳服务,这些服务向应用程序发出微小的请求,只是为了在更长的不活动时间保持它的活力。
您还应该考虑到您的开发页面是在台式机上运行的。您应该知道您的服务器是否更快。
所以也许不是会话创建,而是应用程序启动。您应该通过在浏览器中打开一个页面并等待它完成来区分,然后关闭浏览器并再次打开它(这样将创建新会话)并访问您的应用程序。如果它加载得更快,那么这不是您的会话的错,而是当 .net 框架必须编译您的应用程序时应用程序启动。
先定义问题,然后开始缓解。