為什麼有些網頁開啟特別慢（電腦網頁開啟很慢怎麼回事啊）
解決“通”或“不通”這類功能性問題，其實很好解決。解決網頁開啟“很慢”、“慢”、“正常”、“快”之類的效能問題，有時並不那麼容易。
通過題主的描述可以獲得以下事實：
- 網路的連通性沒有問題，否則也無法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個位元組。