解决“通”或“不通”这类功能性问题，其实很好解决。解决网页打开“很慢”、“慢”、“正常”、“快”之类的性能问题，有时并不那么容易。
通过题主的描述可以获得以下事实：
- 网络的连通性没有问题，否则也无法Ping通服务器
- 域名解析也没有问题，否则也无法访问网页
- 服务器应该工作正常，否则也无法访问
- 网络是畅通的，否则Ping的延迟不可能正常
既然网络看起来是好的，为何访问网页慢呢？
根据多年的从业经验，我的推测是：
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个字节。
感谢观看
