11个技术提高网站打开速度

其实有12个，最后一个暂时没实现。

零、背景

维护 chatGPT 网站的朋友问我：网站打开速度很慢，该怎么办？

我说：可以去分析一下为啥慢，然后去优化下。

朋友问：怎么分析呢？没有思路。

我说：先画出网站的架构图，然后从客户端开始分析全链路的耗时情况，并看每一阶段是否可以优化即可。

网站的架构图不复杂，分为四个模块：接入层、逻辑层、鉴权层、第三方。

一、浏览器缓存加速

通过浏览器的 network 查看耗时，首页打开耗时 10.34s。

其中主要耗时消耗在 script 和 stylesheet 文件上，因为这些文件太大了。

所以第一个是开启静态文件的浏览器缓存。

add_header Cache-Control "public, max-age=31536000, immutable";

开启后，可以发现首页打开耗时降为了 2.76s。

二、服务器304加速

有些资源很重要，可能随时会变更，所以不能放在浏览器缓存上。

但是这些资源变更的又不频繁，每次重新下载又比较消耗时间，该怎么办呢？

没错，可以使用 http 自带的一个特性 304 数据未变更。

etag on;

开启后，有些文件缓存之前需要好几秒，现在速度降低到几百毫秒，http 状态码是 304。

三、代理缓存

因为架构有一个 nginx 代理，客户端访问 nginx 代理， nginx 代理访问网站后端，这就有2次网络了。

浏览器上的缓存是针对一个用户的，服务端加上缓存，所有用户就都可以加速了。

所以针对 Nginx 代理，我们可以加上代理缓存。

proxy_cache_path /var/cache/nginx levels=1:2 keys_zone=my_cache:720m inactive=30d;proxy_cache_key "$scheme$request_method$host$request_uri";proxy_cache_valid 200 304 10m;proxy_cache_valid 404 1m;proxy_cache_methods GET HEAD;proxy_cache_bypass $http_pragma;proxy_cache_revalidate on;

四、CDN缓存

部分 304 的资源耗时几百毫秒，能不能进一步降低呢？

这就需要回到原始问题：为啥这些文件不能走浏览器缓存？

原因是那些静态资源，next.js网站服务器不确定什么时候会变化。

我们作为世界的创造者，自然知道这些是否会变化的。

所以我们就可以主动干预这些文件，强制走浏览器缓存。

怎么主动干预呢？

CDN 缓存，即预先把文件拉到 nginx 代理服务器上，没有时才去网站试试拉取。

location ~ ^(/_next/static/.*|.*svg|.*png|.*css|.*js)$ {    root /home/ubuntu/www/proxy.com/;    if ( !-e $request_filename){        proxy_pass  https://web.com;    }    proxy_cache my_cache;    proxy_ssl_server_name on;    add_header Cache-Control "public, max-age=31536000, immutable";}

可以发现，好几个 304 的文件都变成浏览器缓存了。

还有个 /_next/image 带有参数，比较特殊，我们特殊匹配一下，就也可以命中浏览器缓存了。

五、页面静态化

目前看，打开主页只有主页页面和一个接口的耗时比较高了。

类似于 304 的资源，主页其实也很少变化的。

所以主页也可以CDN 静态化，从而利用上缓存机制。

可以看到，主页也返回 304 了。

六、文件元数据缓存

由于我们使用了 !-e $request_filename 判断文件是否存在，所以文件的元数据如果缓存起来，就可以少一次磁盘IO操作，快速知道文件是否存在了。

open_file_cache max=1000 inactive=720h;open_file_cache_valid 720h;open_file_cache_min_uses 1;open_file_cache_errors on

七、服务同机部署

回顾架构图，网站分为三个模块，部署在三个服务器上。

如果同机部署，耗时就可以进一步降低。

当然，由于网站当初选型的是 next.js，页面和接口在一起的。

而next.js 编译速度是出了名的慢，所以 nginx 服务器跑不起来网站系统。

这里的方法是 Next.js 项目一分为二，接口项目把无关的网站资源全部删除，这样就可以在 nginx 上跑起来了，

location ~ ^(/api/account|/api/chat)$ {    proxy_pass  https://api.com;}

八、https 转 http

既然网站接口和鉴权服务同机部署了，也没必要使用 https 了，可以改成 http 本机通信了。

location ~ ^(/api/account|/api/chat)$ {    proxy_pass  http://127.0.0.1:3000;}

九、next.js 转原生 node

当初选择 next.js 是为了做前端。

接口部分拆分出来了，就没必要使用 next.js 实现了， 直接使用原生 Node 即可实现。

十、nginx 连接复用

nginx 代理与后台的TCP也保持着，那就可以降低三次握手的时间。

upstream ACCOUNT {    server 127.0.0.1:3000;    keepalive 100;}location ~ ^(/api/account)$ {     proxy_pass  http://ACCOUNT;     }

十一、node 连接复用

node 与后台通信有 http 也有 https，如果也能复用连接，还能节省进一步降低时间。

由于这里使用的 node 原生 fetch，官方查看资料可以知道自带连接池，但默认不适用。

所以打开keepAlive: true即可。

资料地址：https://fetch.spec.whatwg.org/

十二、最后

优化后架构图如下

最终，网站第二次打开速度为 707ms。

第一次打开时要下载一堆资源，再优化就需要去掉 next.js，换一个轻量级的框架了。

总结下优化列表如下：

1、浏览器缓存
2、304缓存
3、代理缓存
4、CDN缓存
5、页面静态化
6、文件元信息缓存
7、服务同机部署
8、https 转 http
9、接口重构，不使用 next.js
10、nginx 连接复用
11、node 连接复用

通过这些优化，网站打开速度从 10.34s 左右降低到 1s 以内，打开速度降为原来的 1/10。

其实，还可以做一个连接预热优化。

即用户准备输入内容时，提前向后台发一个预热请求，后台把全链路的连接都先创建好，这样用户点击发送按钮时，速度就是最快的了。

《完》

-EOF-

题图：来自朋友圈。

上篇文章：众所周知，狗会咬人，打狂犬疫苗小记

• 一个免费体验的 chatGPT 网站
• 分享国内直接使用 chatGPT 的方法
• 教你注册与使用 chatGPT

优网科技秉承"专业团队、品质服务" 的经营理念，诚信务实的服务了近万家客户，成为众多世界500强、集团和上市公司的长期合作伙伴！

优网科技成立于2001年，擅长网站建设、网站与各类业务系统深度整合，致力于提供完善的企业互联网解决方案。优网科技提供PC端网站建设（品牌展示型、官方门户型、营销商务型、电子商务型、信息门户型、微信小程序定制开发、移动端应用（手机站、APP开发）、微信定制开发（微信官网、微信商城、企业微信）等一系列互联网应用服务。