如何在3分钟内提高网站打开速度？-技术圈

对于一个用户来说，判断一个网站好坏的首要指标就是网站的打开速度。有研究表明：用户打开网站最满意的时间是3秒以下，网站打开时间超过10秒，就会有98%的用户选择直接关闭网站。如此严重的用户流失对于站长和企业来说，都是非常严重的问题：无论你的网站布局有多么合理，素材有多么精美，内容有多么无敌，都再无用武之地。这时候，我们该怎么办？

在开始分析解决问题前，先得对整个网站系统有个清晰的理解。网站是单机部署，还是多机部署？有没有用到负载均衡？当前网站的QPS多高，各机器负载情况如何？最好能用可视化图形画出清晰架构。

除此之外，我们也需要知道浏览器请求背后的原理：当用户在浏览器输入完一个网址，这背后经历了一系列复杂的流程才能最终将页面呈现出来：比如DNS解析、TCP建连、TLS握手、浏览器解析和渲染（详细流程可以参考：https://github.com/alex/what-happens-when）。这其中每一个环节出了问题，都可能导致最终网站打开速率降低。那么，我们应该怎么快速找到问题点？

01 分析定位问题

首先，要定位网站打开慢的原因，通常有以下几种方法：

· 客户端信息收集

我们一般需要用户配合，提供一些基础信息：

问题是否必现 /是首次打开慢，还是每次打开都很慢？

如果只是首次打开慢，说明是本地没缓存。如果每次打开都慢，说明服务端缓存配置可能不正确，或者站点包含了太多动态请求。

是否共性问题 /除了本站点打开慢，打开大流量网站（比如www.qq.com）也慢吗？

如果大流量站点打开也慢，极可能说明本地网络或者DNS存在问题。否则，可能是本站点的原因。

是否网络差异 /切换不同的WiFi，或者切换热点重试，是否有改善？

如果WiFi/热点访问体验不同，也可能说明是网络链路问题。比如服务器在电信网络，而客户端在移动，跨网互联会存在天然的延时。

其他用户是否有类似问题

如果只是个别客户端出问题，基本能确定是客户端自身原因。

我们可以保持和客户交流，通过提问的方式验证自己的猜想，不断地把不可能的因素排除掉，确定排查方向。

· 抓包

除了找用户收集信息之外，我们还可以引导用户借助浏览器抓包诊断。比如Chrome就有开发者工具，其中network面板可以分析资源加载时序，查看每个资源的加载时间，定位到加载慢的资源，详细操作：https://developer.chrome.com/docs/devtools/network/。

· 诊断工具

除了主动询问客户外，也可以利用自动化诊断工具来快速获取客户端的ip、localDNS、浏览器版本等基础信息，http://debug.ping.dnsv1.com/ping.x。

· 第三方探测

有时候，为了判断问题是个例行为还是共性行为，我们可以借助第三方探测工具来排查。比如一次性探测工具：https://www.17ce.com/，周期性探测系统可以用博睿、基调等公司提供的服务。

· 主动监控

为了更快、更主动的发现客户端的异常，一般情况下我们也需要在业务代码中做一些埋点上报逻辑，将页面加载的延时等基础信息上报服务端，用于分析访问情况，对页面优化有极大的参考作用。

不仅仅是页面内要做埋点上报逻辑，对于服务端，我们也需要做好监控，将服务器基础信息（CPU/内存/磁盘/tcp连接/文件描述符）以及业务维度指标（请求QPS、请求时延、线程池数量）上报至监控系统。当系统具备了全面的监控，碰到问题时我们才不会盲目，可以顺着监控曲线快速验证猜想，排除干扰，定位到根因。

以上粗略列举了分析定位问题的一些手段，实际操作过程中我们往往需要综合多种方式来找到问题。

02 问题解决方案

定位到根因后，我们便可以针对性提出解决方案。

· 客户端原因

如果是客户端网络/DNS解析异常，需要联系本地网络服务提供商解决。

· 服务端原因

1. 服务器CPU高负载

一般情况下，这意味着请求量超出了服务器承受能力，资源已耗尽，需要扩容新服务器。有以下方式：

1）LB服务端负载均衡

可以引入负载均衡服务，比如腾讯云CLB，能将来自客户端的请求以特定的均衡算法派发到后端服务器上，降低单台服务器压力。并且还可以探测后台服务器存活性，自动剔除掉不健康的节点。

2）DNS全局负载均衡

如果请求量超出了单台LB承受能力，这时LB也可能会挂掉，因此可以引入多个负载均衡服务，为了让客户端能发现多台负载均衡，我们可以修改DNS解析，添加多个LB ip作为A记录。

3）接入CDN

如果网站业务正处于一个上升期，流量预计会有不小的增长，为了跟上业务发展的节奏，我们会需要频繁扩容，这是一个繁琐的过程，费力不说，购买新LB和服务器都需要不小的服务器、网络带宽成本。这时，我们可以考虑将网站接入CDN。对于静态资源类网站，CDN可以将绝大部分资源缓存在边缘节点上，提升最后一公里用户的访问效率，为服务器抵挡住接近100%的流量，CDN加速产生的流量相比普通服务器产生的流量更廉价，因此可以大大减少网站服务器成本。腾讯云CDN就提供了这样的能力。

2. 网络带宽打满

此时可以选择带宽扩容，或者接入CDN，相对来说，CDN加速带宽相比服务器带宽更廉价，是更好的选择。

3. 服务器首包响应慢

这意味着服务器负责正常，但业务侧处理能力跟不上，可能有以下几类原因：

1) WEB服务器性能太差。比如Apache服务器，由于每个连接都需要创建新线程处理，在高并发量请求场景下线程创建销毁以及切换开销都不小，因此可以换用性能更好的服务器软件nginx。

2) 磁盘IO高负载。可以考虑服务器内存做缓存，内存读写效率相比磁盘有很大提升，可以显著提升性能。如果觉得改造成本比较高，又不差钱的话，可以选用SSD硬盘，也能有不错的提升效果。

4. 网络传输慢

客户端和服务端处在不同网络，或者客户端和服务端处于不同区域，都可能造成网络传输慢。此时，我们可以从协议栈上全栈做优化。

1) 物理上，就近部署服务。将服务器靠近目标用户，并且同网络部署，降低路由跳数，但如果目标用户广泛分布，此法解决不了问题。

2)传输层上，我们可以对tcp参数做调优，比如linux有net.ipv4.tcp_max_syn_backlog/net.ipv4.tcp_rmem/net.core.somaxconn等参数可以配置。也可以换用更好的拥塞控制算法，比如bbr。

3) 应用层协议上，可以启用传输效率更好的HTTP2、QUIC协议。

4) 应用开发上，有非常多优化方式。比如将多个css/js文件打包合并，减少分散加载引入的慢启动时延。可以将文本类文件压缩传输。可以可以在浏览器、内存、磁盘、中间件上做各级缓存，可以将外链本地存放，图片内容base64编码，为站点申请多个域名，解决浏览器同个域名最大6个tcp连接的限制。

5) 使用CDN。腾讯云CDN在全球广泛部署有非常多缓存节点，资源一旦在节点上缓存下来，后续客户端都能直接从最近的节点拿到内容，因此显著降低地理位置差异引入的延时。此外，腾讯云CDN支持智能压缩传输、支持HTTP2/QUIC协议，能帮助站点在不改造的情况下更进一步提升传输效率。

• 综合来看，将网站接入CDN是最省事、成本最低、并且加速效果最好的一种方式。

最后我们以一个静态网站样例来说明应用以上一些优化手段后的效果。

03 实战演练

这是一个AdminLTE3的示例页面，首页上加载资源很多，我们按加载时长从大往小排序，可以看到，在没优化前，页面总共加载耗时8.48s。其中adminlte.min.css文件加载就花了4.68s，耗时最多。

查看server回包，可以看到缺失Transfer-Encoding、Content-Encoding这样的头部，说明未启用压缩。

1. nginx开启压缩传输

我们配置服务器nginx，启用传输压缩，再看看效果。

可以看到adminlte.min.css加载时间降低为724ms，只有之前的15%。网站总体加载时间6.02s，比之前8.48s降低了一些。

server返回头部中确实携带了Content-Encoding、Transfer-Encoding。

2. 接入CDN

我们以腾讯云CDN接入来说明，只需要简单几步操作即可快速启用CDN加速。

1) 接入域名

在腾讯云CDN控制台上，最简单的操作，只需要将加速域名，源站ip填写进来，点击确认提交即可创建域名配置。

2) 调整解析

域名配置创建好后，会分配一个CNAME，该CNAME即是接入CDN的关键，可以将客户端DNS请求调度到最优CDN节点。我们只需要将原始域名添加一条CNAME类型记录指向该CNAME即可。

最终DNS解析关系应该如下：

3) 查看域名配置

腾讯云CDN默认为静态站点开启了智能压缩特性，还有其他功能，读者可以自行挖掘。

4) 验证加速效果

再一次访问站点，由于请求由就近CDN节点提供服务，这里加载延时进一步降低，并且总体加载时间也只有3.24s，比原始站点开启压缩之后的6.02s提速效果大大增加。

5) 启用QUIC加速

除了以上优化，我们还可以在腾讯云CDN控制台上为域名启用QUIC特性，提高传输效率。

6) 再一次验证

可以看到，css加载延时进一步降低，总体加载时间只有2.15s。

• 网站页面加载速度优化的方法有很多，有实力、爱折腾的开发者可以通过调整软件设计、架构以及服务器配置达到加速效果。除此之外，最简单、便捷的方法就是将网站接入CDN，快速启用压缩、QUIC特性，达到既节省成本，又灵活，还能大幅提速的目的。

关注腾讯云CDN👇获取更多信息

参考文献

[1] web性能权威指南

[2] https://www.nngroup.com/articles/

response-times-3-important-limits/

[3] https://github.com/alex/what-happens-when