博客提速实录：从首屏渲染到 CDN 回源的一次全链路性能优化

博客迁移到自研的 Go 版本、接入腾讯云 EdgeOne 之后，页面"看起来挺快"，但到底快不快、慢在哪里，一直没有认真量过。这次花了几天，从浏览器一路查到数据库，把整条访问链路完整过了一遍。过程中有被实验推翻的直觉，有优化本身引入的退步，还有一次线上故障，这篇文章都如实记录下来。

这次优化是和 AI 编程助手一起完成的：它负责测量、分析和给出方案，博客代码由我的博客智能体按方案修改，CDN 配置由我在控制台操作。

一、先把测量方法定下来

不测量就优化，等于在猜。这次一共用了三类工具。

1. curl：看响应头，拆分耗时

响应头里的 eo-cache-status 能看出是否命中 CDN 缓存（HIT 或 MISS），age 表示这份缓存已经存在了多少秒。再用 -w 把一次请求拆成 DNS、建连、TLS、首字节几段：

curl -s -o /dev/null -H "Accept-Encoding: br, gzip" \
  -w "dns=%{time_namelookup} tcp=%{time_connect} tls=%{time_appconnect} ttfb=%{time_starttransfer} size=%{size_download}\n" \
  https://www.lscx.org/

用首字节时间减去 TLS 完成时间，就是服务端等待时间。命中缓存时它约等于一次网络往返；没命中时会多出回源的时间，两者一比就清楚了。想强制测"没命中"的情况，给地址加一个随机参数（?cb=随机数）即可。

2. headless Chrome + CDP：测真实的渲染过程

光看首字节不够，用户感受到的是"多久看到内容"。我用 Python 通过 Chrome DevTools Protocol（CDP）驱动 headless Chrome，模拟 Lighthouse 的"慢速 4G"条件：150ms 往返延迟、1.6Mbps 下行、CPU 降速 4 倍。在页面加载前注入 PerformanceObserver，采集 FCP（首次内容绘制）、LCP（最大内容绘制）、CLS（布局偏移）和长任务：

send("Network.emulateNetworkConditions", {
    "offline": False, "latency": 150,
    "downloadThroughput": 1.6 * 1024 * 1024 / 8 * 0.9,
    "uploadThroughput": 750 * 1024 / 8 * 0.9,
})
send("Emulation.setCPUThrottlingRate", {"rate": 4})
send("Page.addScriptToEvaluateOnNewDocument", {"source": """
  window.__perf = {lcp: 0, cls: 0, longTasks: []};
  new PerformanceObserver(l => { __perf.lcp = l.getEntries().at(-1).startTime; })
    .observe({type: 'largest-contentful-paint', buffered: true});
  new PerformanceObserver(l => { for (const e of l.getEntries())
      if (!e.hadRecentInput) __perf.cls += e.value; })
    .observe({type: 'layout-shift', buffered: true});
  new PerformanceObserver(l => { for (const e of l.getEntries())
      __perf.longTasks.push([e.startTime, e.duration]); })
    .observe({type: 'longtask', buffered: true});
"""})

3. A/B 实验：不改线上代码，先验证值不值得改

CDP 的 Fetch 域可以拦截 HTML 响应，在浏览器拿到之前现场改写：删掉某些脚本、把 CSS 内联进去……这样同一个页面就能在"原版"和"优化版"之间反复对比，确认有效再动线上代码：

send("Fetch.enable", {"patterns": [{"urlPattern": URL, "resourceType": "Document",
                                    "requestStage": "Response"}]})
# 收到 Fetch.requestPaused 事件后：
body = base64.b64decode(send("Fetch.getResponseBody", {"requestId": rid})["body"]).decode()
body = rewrite(body)   # 删脚本、内联 CSS ……
send("Fetch.fulfillRequest", {"requestId": rid, "responseCode": 200,
                              "responseHeaders": headers,
                              "body": base64.b64encode(body.encode()).decode()})

说明一下：测量机在海外，经 EdgeOne 新加坡节点访问，所以文中的绝对数值和国内访客看到的不同，但优化前后的相对变化是成立的。

二、第一轮体检：问题清单

三、一个被实验推翻的直觉

看到页面底部那几个同步加载的大脚本，第一反应是"它们拖慢了首屏"，于是先做 A/B：去掉首页用不到的 KaTeX 和高亮库，其余脚本全部加上 defer。

结果 DOMContentLoaded 确实从 3.13 秒降到了 2.06 秒，但首次绘制完全没变（0.87 秒对 0.97 秒，在误差范围内）。原因是浏览器要等阻塞渲染的 CSS 下载完才开始画，那时脚本早已下载好了。真正卡住首屏的是 style.css 这一次网络往返。

接着测第二个变体：把 CSS 内联进 HTML。从收到 HTML 到首次绘制，直接从 0.87 秒降到了 0.33 秒。

所以两件事都要做，但目的不同：按需加载脚本是为了省流量、让交互更早可用；内联关键 CSS 才是让首屏变快的关键。

四、前端：按需加载 + 关键 CSS

1. 公式和代码高亮按需加载

渲染文章时，服务端先判断正文里有没有代码块、有没有公式，再决定是否输出对应的脚本和样式。列表页一律不输出。

这里踩过一个坑：有一篇文章正文里没有任何公式，代码块里却有几个 $，于是被误判为"含公式"，白白加载了 KaTeX。KaTeX 的自动渲染本来就会忽略 pre 和 code 里的内容，所以检测时先把这些标签剥掉就行（示意代码）：

var (
    skipTags   = regexp.MustCompile(`(?is)<(pre|code|script|style|textarea)\b.*?</(pre|code|script|style|textarea)>`)
    mathMarker = regexp.MustCompile(`\$\$|\\\[|\\\(|\$[^$\n]+\$`)
)

func hasMath(html string) bool {
    return mathMarker.MatchString(skipTags.ReplaceAllString(html, ""))
}

func hasCode(html string) bool {
    return strings.Contains(html, "<pre><code")
}

2. 关键 CSS 内联，完整样式异步加载

分别为"列表页"和"文章页"两类模板提取首屏需要的 CSS（包括深浅两套主题变量），内联进 <head>；完整的样式表改为预加载后再生效，不再阻塞渲染：

<style>/* 构建时生成的关键 CSS */</style>
<link rel="preload" href="/static/css/style.min.css?v=内容哈希" as="style"
      onload="this.onload=null;this.rel='stylesheet'">
<noscript><link rel="stylesheet" href="/static/css/style.min.css?v=内容哈希"></noscript>

代码高亮的样式只有 0.8KB，直接内联；KaTeX 的 CSS 改为同样的异步方式加载，因为公式本来就要等 JS 加载完才渲染，样式没必要阻塞首屏。

3. 其他几项

• 所有 JS 都加上 defer，并做了压缩混淆。
• 静态资源统一带上内容哈希做版本号，配合 Cache-Control: public, max-age=31536000, immutable，浏览器缓存一年。
• 亮暗两张 logo 改用 CSS 背景图，按当前主题切换，只下载需要的那一张。
• 给微信抓取用的隐藏分享图加了 fetchpriority="low"，PNG 从 42.7KB 压到 16.9KB。
• 正文图片在服务端输出真实的 width 和 height，加载时不再跳动，CLS 保持为 0。

4. 图片：一篇文章省下近 2MB

复查时发现一篇文章里放了 3 张原尺寸 PNG 架构图（最大 3240×2240）。正文显示宽度最多也就 800 像素，按高清屏 2 倍算，1600 像素足够。统一转成 1600 像素宽的 WebP（质量 82），并逐张确认图中的文字依然清晰：

三张合计从 2.3MB 降到 386KB。在慢速 4G 下，这篇文章的页面加载完成时间从 9.85 秒降到 4.1–4.8 秒。

五、压缩与缓存头

1. 换成 Brotli

原来是源站用低级别 gzip 压缩，CDN 拿到的已经是压缩过的文件，只能原样转发。改成源站不压缩静态文件，交给 EdgeOne 按访客浏览器的支持情况做 Brotli，文本资源普遍小了 23%–34%：

2. 一次自己挖的坑

关掉源站压缩之后复测，发现文章页反而变慢了。排查发现：HTML 在 CDN 没命中时完全没有压缩，文章页 130KB，而命中时只有 40KB。静态文件没命中时却是正常压缩的。

区别在于 HTML 是 Go 程序流式输出的，响应里没有 Content-Length，CDN 不会对这种响应做实时压缩。解决办法是只在反向代理 Go 的那个 location 里重新打开 gzip（示意配置）：

location / {
    proxy_pass http://127.0.0.1:<博客端口>;
    gzip on;
    gzip_comp_level 5;
    gzip_proxied any;   # 来自 CDN 的回源请求可能带 Via 头，没有这一行 nginx 可能不压缩
    gzip_vary on;
    gzip_types text/html application/xml application/rss+xml application/json;
}

3. 让后退缓存重新可用

HTML 从 no-store 改成 no-cache；页面里监听的 beforeunload 改成 pagehide（在 Firefox 里，前者会让页面进不了后退缓存）；统计接口的响应也不再返回 no-store，因为 JS 请求收到 no-store 的响应同样会让页面失去后退缓存。改完之后用 CDP 验证：

send("Page.navigate", {"url": "https://www.lscx.org/2741.html"})   # 打开 A，再打开 B
send("Page.navigate", {"url": "https://www.lscx.org/2740.html"})
send("Page.navigateToHistoryEntry", {"entryId": previous_entry})    # 后退
# 修复前收到 Page.backForwardCacheNotUsed，原因包括：
#   MainResourceHasCacheControlNoStore
#   JsNetworkRequestReceivedCacheControlNoStoreResource
# 修复后：没有这个事件，页面直接从后退缓存恢复

六、CDN：国内访客原来一直在跨境

DNS 解析的结果会因访客所在地区而不同，从海外测量看不出国内访客被分配到了哪里。好在可以用 EDNS Client Subnet（ECS）直接问 EdgeOne 的权威 DNS，模拟不同地区的访客：

CNAME=$(dig +short www.lscx.org CNAME)
ZONE=$(echo "$CNAME" | awk -F. '{print $(NF-2)"."$(NF-1)}')
NS=$(dig +short NS "$ZONE" | head -1)
dig +short "$CNAME" @"$NS" +subnet=114.114.114.0/24   # 模拟国内访客
dig +short "$CNAME" @"$NS" +subnet=8.8.8.0/24         # 模拟海外访客

结果吓了一跳：国内访客访问 www，被分配到的也是新加坡节点。原来 www 所在站点的加速区域不包含中国大陆。博客早有 ICP 备案，于是把加速区域切换为"全球（含中国大陆）"。再查一遍：

裸域也一起迁到 EdgeOne。 给 lscx.org 申请免费证书，用规则引擎做 301 跳转，路径和查询参数都保留：

{
  "RuleName": "裸域跳转到www",
  "Branches": [{
    "Condition": "${http.request.host} in ['lscx.org']",
    "Actions": [{
      "Name": "AccessURLRedirect",
      "AccessURLRedirectParameters": {
        "StatusCode": 301,
        "Protocol": "https",
        "HostName": {"Action": "custom", "Value": "www.lscx.org"},
        "URLPath": {"Action": "follow"},
        "QueryString": {"Action": "full"}
      }
    }]
  }]
}

同时开启强制 HTTPS（301），HSTS 先设 1 天观察，确认没问题再拉长。

缓存规则的骨架（已脱敏）：后台、API 和带有各类凭证 cookie 的请求不缓存；静态资源缓存 30 天；公共页面短缓存。

"Condition": "${http.request.uri.path} matches '^/(admin|api)(/|$)' or ${http.request.headers['Cookie']} matches '(^|.*;[ ]*)(<登录凭证>|<文章通行证>|<评论者标记>|<自动化程序标记>)=.*'",
"Actions": [{"Name": "Cache", "CacheParameters": {"NoCache": {"Switch": "on"}}}]

这里有一个和安全相关的教训：凡是会让页面内容因人而异的 cookie，都必须让请求绕过缓存。 比如加密文章：读者输入密码后会拿到一个通行 cookie。如果带这个 cookie 的请求也被缓存，CDN 就会把带正文的页面缓存下来，在缓存有效期内发给所有人，不知道密码的人也能看到。

七、一次线上故障：同一秒二十多个回源请求压垮了数据库

切换到国内节点的第二天，网站突然打不开：静态文件正常，HTML 全部超时，CDN 报 524，nginx 日志里全是 499。

原因是文章详情页在同一秒内收到了 20 多个回源请求，同时触发了两个问题：

1. 主查询的 rows 还没关闭，就在循环里发起次级查询，一个请求同时占用多条数据库连接；
2. 阅读量每次请求都直接写库，大量并发写操作争抢 SQLite 的写锁。

25 个连接瞬间被占满，彼此等待，形成了连接池死锁。

为什么偏偏是现在？ 以前所有流量都集中在新加坡一个节点；切到国内之后有几十个节点各自缓存，同一个页面在多个节点上几乎同时过期，就会在同一时刻集中回源。CDN 节点越多，越要考虑源站扛不扛得住这种同步回源。

修复：

// 错误示范：遍历 rows 的过程中又发起查询，一个请求同时占用两条连接
rows, _ := db.Query(`SELECT id FROM posts WHERE status = 'publish' LIMIT 10`)
for rows.Next() {
    var id int64
    rows.Scan(&id)
    db.QueryRow(`SELECT COUNT(*) FROM comments WHERE post_id = ?`, id).Scan(&n) // 第二条连接
}
rows.Close()

// 正确做法：先全部读完并关闭，再做后续查询
var ids []int64
for rows.Next() {
    var id int64
    rows.Scan(&id)
    ids = append(ids, id)
}
rows.Close()

阅读量改为先放进内存 Channel，每 3 秒合并成一条 SQL 写入；公共侧栏的数据加了 15 秒内存缓存；连接池也适当扩容。

var viewCh = make(chan int64, 4096)

func addView(postID int64) {
    select {
    case viewCh <- postID:
    default: // 缓冲满了宁可丢一次计数，也不能阻塞请求
        log.Println("view buffer full, dropped")
    }
}

func flushViews(db *sql.DB) {
    tick := time.NewTicker(3 * time.Second)
    pending := map[int64]int{}
    for {
        select {
        case id := <-viewCh:
            pending[id]++
        case <-tick.C:
            if len(pending) > 0 {
                batchUpdate(db, pending) // 一条 UPDATE ... CASE id WHEN ... 合并写入
                pending = map[int64]int{}
            }
        }
    }
}

修复后压测：绕过 CDN 直连源站，按 100、300、600 三档并发各压 30 秒，请求混合文章页、首页和列表页。三档全程没有一次超时或连接错误，延迟随并发增加而排队上升，但服务没有再假死。

顺便验证了批量写入的准确性：对同一篇文章发 300 个请求，等批量写入完成后再读取，阅读量正好增加了 301（另外 1 次是读取前那次请求本身），一次都没丢。

一个需要纠正的认识：EdgeOne 的"离线缓存"只在节点连不上源站时才会启用。这次故障里源站能连上，只是应用卡住不响应，所以离线缓存帮不上忙。要防这类故障，得靠源站自己的兜底，比如 nginx 的 proxy_cache_lock（同一页面的并发回源只放一个过去）和 proxy_cache_use_stale（应用出错时返回旧页面）。

八、把缓存时间拉长之前，先解决三件事

页面缓存时间越长，回源越少、命中率越高。但在把 120 秒改成 600 秒之前，有三个问题必须先解决。

1. 阅读量严重少计

原来阅读量是在服务端生成文章页时加 1。可页面一旦命中 CDN 缓存，请求根本到不了源站；反过来，爬虫和压测这类直接打到源站的请求，倒是全被计入了。

改为由浏览器上报：页面 load 之后，向 /api/views/:id 发一个 POST（/api 路径不走缓存）。同一浏览器 30 分钟内重复打开同一篇文章不再上报；服务端按 IP 去重 10 分钟，IPv6 地址按 /64 网段算一个访客；带爬虫特征的 User-Agent 不计数；计数仍然走内存缓冲加批量写入。

window.addEventListener('load', () => {
  const el = document.querySelector('[data-views-for]');
  if (!el || navigator.webdriver) return;
  const id = el.dataset.viewsFor, key = 'viewed_' + id;
  if (Date.now() - (+sessionStorage.getItem(key) || 0) < 30 * 60 * 1000) return;
  fetch('/api/views/' + id, { method: 'POST', keepalive: true })
    .then(r => (r.ok ? r.json() : null))
    .then(d => {
      if (!d) return;
      el.textContent = d.views + ' 浏览';
      sessionStorage.setItem(key, Date.now());
    });
});

去重时最棘手的是怎么拿到访客的真实 IP：

• EdgeOne 回源默认带的是 EO-Connecting-IP 和 X-Forwarded-For。后者会保留客户端自己带的值，第一个地址可以被伪造。
• 源站本身也能被直接访问，任何人都可以自己构造这些请求头。

最终的做法是：CDN 回源时加上一个只有 CDN 和源站知道的校验请求头；源站校验通过，才信任 EO-Connecting-IP；否则一律使用 nginx 记录的实际连接 IP。上线后从外部做了验证：伪造各种 IP 请求头直连源站，都按真实连接 IP 去重；经 CDN 访问时，也能按访客的真实 IP 正确去重。

2. 内容变了，缓存要马上失效

博客在内容变化时，主动调用 EdgeOne 的 CreatePurgeTask 接口清除对应页面的缓存：

刷新调用完全异步：业务代码只把地址放进队列，后台每 5 秒合并一次再调用接口，失败重试 3 次。调用接口用的是一个只有"清除缓存"这一项权限的子账号，密钥万一泄露，影响也非常有限。

req := teo.NewCreatePurgeTaskRequest()
req.ZoneId = common.StringPtr(cfg.ZoneID)
req.Type = common.StringPtr("purge_prefix")
req.Targets = common.StringPtrs([]string{
    "https://www.lscx.org/2741.html",
    "https://www.lscx.org/page/",
})
resp, err := client.CreatePurgeTask(req)

验证时还踩了个坑：第一次自测的结果是"保存文章后再请求，变成了 MISS"，看上去刷新生效了。但仔细一算，那份缓存恰好在测试窗口里自然过期了，所以这个 MISS 证明不了任何事。重新设计测试：等缓存刚生成，7 秒后保存文章，22 秒时再请求，结果是 MISS 且 age 为 0。缓存不可能在 22 秒内自然过期，这次才算真正证明了刷新生效。

3. 发评论的人要能马上看到自己的评论

评论提交成功后，服务端下发一个 10 分钟有效的标记 cookie，CDN 规则对带这个标记的请求绕过缓存。这样发评论的人刷新页面一定能看到自己的评论，不用等刷新任务生效；其他访客则在刷新任务生效后看到。会自动回复评论的程序也用同样的方式，始终拿到实时页面。

三件事都上线后，把页面缓存从 120 秒改成 600 秒。实测某个列表页的 age 涨到 172 秒仍然命中缓存，新规则生效。

九、顺手修的：分页地址

分页地址从 ?page=2 改成了 /page/2。原因有三个：

1. 这个博客从 WordPress 迁移而来，旧的 /page/N 链接此前全部 404，改完之后都能访问了；
2. 访问统计出于隐私考虑会丢弃 URL 参数，原来翻页的访问全被记成了首页；
3. 缓存键更干净，以后忽略 URL 参数时不会误伤分页。

旧地址统一 301 跳转到新地址，超出范围的页码返回 404，每个列表页都输出指向自身的 canonical。

十、结果

十一、几条经验

1. 先量再改，每改一步都复测。 这次有两次"越优化越慢"：关掉源站压缩导致 HTML 没命中缓存时不压缩；关键 CSS 的收益被文章页上两个阻塞渲染的样式表抵消。都是靠复测才发现的。
2. 用 A/B 实验检验直觉。 "底部同步脚本拖慢首屏"这个看似合理的判断，实验结果并不支持。
3. 验证要排除干扰。 缓存是不是恰好在测试窗口内自然过期？测试机走的是 IPv4 还是 IPv6？headless Chrome 默认带着自动化标记，页面上的上报逻辑会因此跳过不执行。这些都差点让我得出错误结论。
4. CDN 和源站是一个整体。 节点越多，同一页面同时回源的可能越大；缓存时间、自动刷新和源站的并发能力要一起考虑。
5. 安全不能为性能让路。 缓存规则要考虑带凭证的请求；不要信任客户端传来的 IP 请求头；接口密钥只给最小权限，而且不在页面、日志和聊天记录里明文出现。

网站的访问统计是公开的，感兴趣的话可以在页脚的"访问统计"入口里看到这次优化前后的访问情况。