边缘计算已经成为网站建设的标准做法，并非通过增加更多的服务器来实现，而是将原来需要发送到源站进行渲染、压缩、路由和认证的工作转移到距离用户最近的一个节点上去做。
边缘计算加速的真实意义：由静态存储转向动态运行
传统的CDN只能缓存图片、CSS、JS等静态资源，对于动态的内容仍然需要向源站发起请求来获取数据。而边缘计算CDN则可以在PoP节点上执行轻量级函数（比如Cloudflare Workers或者AWS Lambda@Edge），在请求到达的时候就可以进行路由判定、首屏部分渲染、AB测试分流以及内容压缩等操作。一次跨地域的访问所节省下来的几十毫秒到几百毫秒的时间，累积起来就会对LCP和跳出率产生影响。
可以执行的是简单的逻辑，比如根据地区更换语言和货币、根据设备种类判断是否要返回高清图片、根据登录状态组合首页内容、在节点上拦截恶意请求和异常爬虫。重计算、写入数据库以及复杂的权限验证等操作仍然应该放在源站上进行，否则边缘函数本身就会成为新的性能瓶颈或者故障点。
加速度来自于哪几个方面：五处可测量的地方
- 物理距离缩短：DNS和TLS握手就近进行，TTFB降低很多。
- 协议协商自动化：边缘节点会自动开启HTTP/3和TLS 1.3，并且减少了握手机制中的轮数。
- 动态内容的边缘化处理方式是将推荐位置、价格和库存等数据按照地区以及用户的等级进行缓存，从而减轻服务器的压力。
- 智能预取和预热：根据热力图，在访问量高峰到来之前就把重要的网页推送到节点上。
- 边缘精简：去掉HTML、CSS和JavaScript中的注释以及多余的空白字符，并且用Brotli来代替Gzip进行压缩的话，那么它的压缩效果会比Gzip好上20%左右。
边缘函数怎么写？不要直接把源站的逻辑全部复制过来
边缘节点和源站的环境不一样，冷启动时间更长，执行时间也较长，并且对内存的要求更高。适合放在边缘上的有路由判断、头部改写、地域分流、AB测试以及请求过滤等；而需要长时间运算或者稳定的连接池来支持数据库操作、大量使用第三方库的服务应该留在源站。上线之后要一直关注边缘函数的错误率和超时率，并且不能只关注CDN的缓存命中率。
速度优化要服从于搜索体验：四种常见的错误设置
| 误配置 | 造成的后果 | 建议改法 |
|---|---|---|
| 动态页面过度缓存 | 爬虫抓到过期内容，与线上实际版本不符 | 动态接口设 no-cache，按 Cookie 分层缓存 |
| 忽略移动端节点优先级 | 移动端 TTFB 偏高，影响移动友好度评分 | 启用运营商级移动节点与 LTE 优先路由 |
| 未启用边缘脚本 | 爬虫体验停留在中心服务器水平 | 首屏关键逻辑部署到边缘 Worker |
| 节点过度分散 | IP 频繁变动，稳定性评价受损 | 节点控制在 3—5 个主要地理区域，源站 IP 保持稳定 |
百度具体的做法是
第一步：用百度搜索资源平台中的抓取诊断功能来测试开启和关闭边缘计算的情况下抓取的耗时情况；第二步：把核心JS和CSS放到支持边缘函数的CDN上，并开启自动预热功能，在有新内容发布之后马上就能够在各个节点上使用；第三步：为百度蜘蛛设置一个单独的缓存时间和更靠近自己的节点组，不与普通用户争夺资源；第四步：定时清除过期的缓存数据、监测页面加载时间等指标，一旦发现有延迟的情况就马上检查节点配置。
容易被忽视的地方
如果某个免费或者低质量的边缘CDN节点曾经发送了大量的恶意请求的话，那么它就会被搜索引擎加入黑名单，并且还会影响到整个网站的评价。所以在挑选服务提供商的时候，“IP信誉度”和“节点稳定性”应该比“节点数量”更重要一些。
边缘计算的加速本质就是把速度作为基础设施来建设，并非上线之前的一种临时措施。按照“协议优化、静态缓存、动态边缘化、爬虫策略、持续监控”的顺序进行的话，首页和收录效果才有可能一起得到提升。