海外客户点击网站后大约要花上7到8秒的时间才能打开它，询盘表单也因此失效了。首字节时间每多一秒，跳出率就越高一些，在跨境电商、外贸独立站和SaaS出海面板中表现更为明显。等到企业建起自己的网站之后，真正拉开差距的是不是页面设计而是来自几千公里外的用户是否可以瞬间打开呢？🚀
速度限制的原因是什么
很多公司一开始就买加速服务，但是花了钱以后发现速度并没有提高多少，大部分原因都是因为对瓶颈判断有误——并非网络问题，而是源站本身的问题。
上线前需要做三组数据：TTFB首字节时间大于800ms就要一层层排除，直到找到DNS解析、TLS握手或者后端程序生成；静态资源所占比例大约为70%；跨大陆链路的状况可以用多点ping和traceroute来测试跳数及丢包情况。
源站在国内，而用户大多位于欧美等地，仅因为地理上的距离就造成了大约150到250毫秒的延迟，再加上TCP三次握手、TLS两次握手所花费的时间加起来几乎占了整个建立连接过程的一半左右。这样的损失是不能用压缩图片来解决的，只能通过边缘节点把数据推送到用户身边去。
节点的选取要依据用户分布的情况画出一张地图
节点的数量并不是越多越好，只有覆盖到位置上才有用。把过去半年内的访问数据按国家、运营商、城市来排序，选取出占据总流量80%的部分，并且与服务商给出的节点列表一一对应起来。主攻东南亚地区的站点里，新加坡、马来西亚和印尼当地运营商之间的互联互通要比欧洲有多少个数据中心更重要一些。
选择时要考虑三个因素：是否支持Anycast就近接入、边缘节点与源站之间有没有专线或者优化的路径、能不能按区域来精细地调度。很多小公司的用户会被“全球2000+个节点”的说法所欺骗，其实命中率很低，因为没有本地POP。
缓存分层，能够保留的就全部放到边缘
缓存规则对效果的影响占到80%，按照资源类型分别设定：
- 用图片、字体以及经过版本控制后的JavaScript和CSS文件，并给它们设置一个比较长的缓存时间（TTL大于30天），然后用文件名哈希来实现版本更新
- HTML 页面可以设置短期缓存或者不缓存，并且用
stale-while-revalidate来确保在刷新时不会出现中断 - 用URL参数和Cookie等数据来创建不同的缓存键，并且不依赖用户会话信息作为缓存的标识符
目的是要使静态资源的命中率达到大约95%，而回源的比例要小于5%。如果命中率低于90%，那么就要先看看缓存键里有没有不应该有的参数，再检查一下TTL是否设置得过低。
回源优化和动态请求也要加快速度
只有少数站点是纯静态的，而订单、登录、搜索等操作都需要回源。这时就要打开动态加速功能，在边缘节点与源站之间开辟出一条更高效的传输通道以避开公网中存在的瓶颈，经过试验可以缩短30%-50%的回源时间。
并且把源站点也加入到HTTP/2或者多路复用连接中去，这样就能减少建立连接的次数了；同时对数据库连接池、OPcache和页面级别的缓存做了优化，避免CDN把流量送到门口后又被源站点自己堵住了。
传输层也被更新了，并且与压缩以及协议一同发生了变化
如果把图片转换成WebP或者AVIF格式的话，在同样的视觉效果下可以节省出3到5倍的空间；用Brotli来压缩文字资料又可以再减少约15%的空间；而开启HTTP/3（QUIC）协议之后，在网络环境较差的时候就能有很好的表现，并且首屏加载速度也会有很大的提升。
同时启用TLS会话复用、OCSP stapling和0-RTT等特性来降低握手次数。
灰色版本上线以及效果验证
首先用二级域名或者10%的流量来做灰度测试，在运行了48个小时之后再进行全量发布。验收标准包括四个：TTFB、LCP、缓存命中率以及源站带宽下降幅度。应该使用真实用户的访问数据来进行监测，并且要分别查看各个区域中P75和P95的数据情况，平均值往往会掩盖掉某些地方的糟糕用户体验。
一些小的问题
HTTPS证书要正确地安装在边缘节点上，没有中间证书的话就会导致一些老版本的客户端不能访问；回源鉴权和IP白名单等设置要做好，否则就会让源站被绕过直接连接；日志投递、实时监控也不能忽略掉，出现问题时只能依靠它们来查找原因；在大促或者新业务上线之前做一次资源预热，避免冷启动造成首屏体验不佳的情况发生。
企业建立自己的网站不是一蹴而就的事情，在采用CDN进行加速之后还需要经常查看命中率、回源时间以及各地区的流量波动情况来确保全球各地的访问速度始终处于一个合适的状态。