网页打开响应缓久才反应怎么办?
发布网友
发布时间：2022-04-24 04:43
共3个回答
热心网友
时间：2023-10-29 06:07
1
软件的兼容问题：
据网络调查发现，win7的IE浏览器跟迅雷软件存在不兼容的问题，卸掉迅雷就会变好。
因为我的IE是系统自带的，所以出现这种情况少。
1
重置浏览器：
右击浏览器——属性——再选择那个高级——点击下面的那个重置，即可。
1
重新设置主页：
我之前将百度设置为主页的，然后进入百度任何一个网页就会出现“无响应”的情况，后来将hao123设置成主页，再回到百度浏览其他的，再也没有出现无响应的情况。
具体方法：通过您的主页，进入如hao123类似的网站导航，将它设置成主页，再回去打开你出现无响应页面的，看是否好了。
希望我的方法能对您有用，谢谢了！
热心网友
时间：2023-10-29 06:08
优化一个加载顺序，看那个模块加载慢，懒加载用一下
热心网友
时间：2023-10-29 06:08
MTU问题
局域网出口网关，可能由于PPPoE拨号，在正常的用户IP报文头前又增添了8个字节的PPPoE头，使得用户1500字节的IP报文，变成了1508字节。
由于出口网关WAN接口的MTU = 1500。很显然1508字节的IP报文 > WAN接口的MTU，网关需要将1508字节的IP报文，分成2片，每片都要小于等于1500字节，才能通行。
分片（Fragment）会消耗网关的硬件资源、软件资源，如果网关是使用纯软件来进行分片，那效率是非常低下的，会造成延迟的增大。
当分片到达服务器时，服务器要组织硬件、软件来将分片进行重组（Reassemble），重组成最原始的1500字节（此时PPPoE头已经不存在了），这在一定程度上增加了处理延迟。
如果服务器没有采用网卡硬件加速重组，而是由TCP/IP协议栈（纯软件）进行重组，又是一个令人难以忍受的漫长。
还没有完，等服务器返程的IP报文（1500字节），到达局域网所在地接入网络时，又需要增添8字节的PPPoE头，IP报文又一次膨胀为1508字节，同样需要分片，这又一次增加了处理延迟。
当分片到达题主的主机时，同样需要进行重组，这又一次增加了处理延迟。
一来一回共增加了四次处理延迟，访问网页自然会慢。
还没有完，还没有考虑到有丢包的情况发生。如果2个分片有1个分片传输过程中丢了，源主机需要重传整个IP报文，而重传的IP报文一样需要分片。在这种情况下，不但有TCP 超时重传的延迟，还有分片的延迟。
这无疑是雪上加霜，让本来很糟的情况，变得更加糟糕。
这还没有完，分片到达服务器/主机时，由于其孪生兄弟还没有到达，需要暂时呆在缓存里等待孪生兄弟的到来，才能重组，对吗？
在网络丢包严重时，孪生兄弟可能永远都无法到达（丢了），呆在缓冲区的分片需要等待一段时间才能删除。要命了，会有茫茫多的分片不断到达缓冲区，并快速占满缓存空间。
有读者会问，为什么它们赖着不走啊？
因为孪生兄弟（分片）还没有到达！
再有分片到达时，没有缓存可以用了，怎么办？ 丢！
TCP如何修复这些丢包？
超时重传！
超时重传又增加了延迟！
说了那么多，其实就是一个意思，一旦分片了，就做好网络变慢的思想准备！
上文的观点，不是凭空的推测，而是多年实验室实验研究的结论。
如何证明是MTU造成的问题？
只要把主机的MTU从标准的1500修改成1492或更小，然后再次访问网页，和其它主机对比一下便知。
如何系统性地解决这个问题？
一般商用的路由器，为了避免分片，会部署一个Feature : “TCP Adjust-MSS”,用于动态修改用户TCP报文的MSS值，只要将将MSS值减小8个字节，以抵消PPPoE头带来的长度增加。
如果题主的网关路由器支持这个功能，打开这个功能。如果不支持，需要升级路由器。或将局域网的主机MTU都改小8个字节。
热心网友
时间：2023-10-29 06:07
1
软件的兼容问题：
据网络调查发现，win7的IE浏览器跟迅雷软件存在不兼容的问题，卸掉迅雷就会变好。
因为我的IE是系统自带的，所以出现这种情况少。
1
重置浏览器：
右击浏览器——属性——再选择那个高级——点击下面的那个重置，即可。
1
重新设置主页：
我之前将百度设置为主页的，然后进入百度任何一个网页就会出现“无响应”的情况，后来将hao123设置成主页，再回到百度浏览其他的，再也没有出现无响应的情况。
具体方法：通过您的主页，进入如hao123类似的网站导航，将它设置成主页，再回去打开你出现无响应页面的，看是否好了。
希望我的方法能对您有用，谢谢了！
热心网友
时间：2023-10-29 06:08
优化一个加载顺序，看那个模块加载慢，懒加载用一下
热心网友
时间：2023-10-29 06:08
MTU问题
局域网出口网关，可能由于PPPoE拨号，在正常的用户IP报文头前又增添了8个字节的PPPoE头，使得用户1500字节的IP报文，变成了1508字节。
由于出口网关WAN接口的MTU = 1500。很显然1508字节的IP报文 > WAN接口的MTU，网关需要将1508字节的IP报文，分成2片，每片都要小于等于1500字节，才能通行。
分片（Fragment）会消耗网关的硬件资源、软件资源，如果网关是使用纯软件来进行分片，那效率是非常低下的，会造成延迟的增大。
当分片到达服务器时，服务器要组织硬件、软件来将分片进行重组（Reassemble），重组成最原始的1500字节（此时PPPoE头已经不存在了），这在一定程度上增加了处理延迟。
如果服务器没有采用网卡硬件加速重组，而是由TCP/IP协议栈（纯软件）进行重组，又是一个令人难以忍受的漫长。
还没有完，等服务器返程的IP报文（1500字节），到达局域网所在地接入网络时，又需要增添8字节的PPPoE头，IP报文又一次膨胀为1508字节，同样需要分片，这又一次增加了处理延迟。
当分片到达题主的主机时，同样需要进行重组，这又一次增加了处理延迟。
一来一回共增加了四次处理延迟，访问网页自然会慢。
还没有完，还没有考虑到有丢包的情况发生。如果2个分片有1个分片传输过程中丢了，源主机需要重传整个IP报文，而重传的IP报文一样需要分片。在这种情况下，不但有TCP 超时重传的延迟，还有分片的延迟。
这无疑是雪上加霜，让本来很糟的情况，变得更加糟糕。
这还没有完，分片到达服务器/主机时，由于其孪生兄弟还没有到达，需要暂时呆在缓存里等待孪生兄弟的到来，才能重组，对吗？
在网络丢包严重时，孪生兄弟可能永远都无法到达（丢了），呆在缓冲区的分片需要等待一段时间才能删除。要命了，会有茫茫多的分片不断到达缓冲区，并快速占满缓存空间。
有读者会问，为什么它们赖着不走啊？
因为孪生兄弟（分片）还没有到达！
再有分片到达时，没有缓存可以用了，怎么办？ 丢！
TCP如何修复这些丢包？
超时重传！
超时重传又增加了延迟！
说了那么多，其实就是一个意思，一旦分片了，就做好网络变慢的思想准备！
上文的观点，不是凭空的推测，而是多年实验室实验研究的结论。
如何证明是MTU造成的问题？
只要把主机的MTU从标准的1500修改成1492或更小，然后再次访问网页，和其它主机对比一下便知。
如何系统性地解决这个问题？
一般商用的路由器，为了避免分片，会部署一个Feature : “TCP Adjust-MSS”,用于动态修改用户TCP报文的MSS值，只要将将MSS值减小8个字节，以抵消PPPoE头带来的长度增加。
如果题主的网关路由器支持这个功能，打开这个功能。如果不支持，需要升级路由器。或将局域网的主机MTU都改小8个字节。
