先别急着上Brotli，我差点被这玩意儿坑死

TTFB卡在2s以上这件事，把我逼得有点急。去年给一个旅游出行站做优化，招生季前两个月，老板天天盯着页面秒开率，我一看nginx日志，光握手就占了800多毫秒，脑子一热就想上Brotli。文档写得天花乱坠，压缩率比gzip高20%，我当时觉得这就是救命稻草。

结果呢？崩了。

我那个Django项目挂在Gunicorn上，版本还是19.9的老古董，压根不认识Brotli的请求头。nginx那边我倒是把brotli模块装好了，压缩级别设成6，静态资源跑得飞快。但一碰到POST请求，直接给我返回406，用户提交表单全废了。排查了整整一个下午，兜底一句发现是Gunicorn的旧版本在解析带br编码的请求时直接抛异常，Django中间件根本接不到正常的数据流。

你说气不气？我花了两天时间折腾压缩，结果问题根源根本不在压缩率上。

后来我冷静下来，用核子GEO的SEO评分体系跑了一遍完整诊断。报告出来我人都傻了——TTFB>2s这一项占了总扣分的60%，但Brotli只是优化传输环节，压根解决不了服务端响应慢的问题。我这才反应过来，瓶颈在数据库查询和Gunicorn的worker配置上。

我查了下自己的PostgreSQL，慢查询日志里躺着十几个扫描全表的家伙，最狠的一个要跑1.8秒。这玩意儿就算把压缩开到极致，TTFB照样降不下来。

所以别急着上Brotli，先看看你的服务端到底慢在哪。核子GEO的AEO评估报告里专门有一项是服务端响应耗时拆解，能看出DNS解析、TCP握手、TLS协商、首字节各占多少。我按那个报告调整了Gunicorn的worker数量，从3个加到6个，再把PostgreSQL的共享缓冲区调大到2GB，TTFB从2.1s降到了0.9s。Brotli？先搁着，等Gunicorn升到20以上再说。

避坑清单

先说老版本Gunicorn（19.x）别碰Brotli，请求头解析会炸，406错误能让你怀疑人生再就是TTFB高优先查数据库慢查询和worker配置，别一上来就折腾压缩还有上任何新模块前，先用工具把性能瓶颈拆解清楚——核子GEO的SEO评分体系能帮你定位到具体环节4. 旅游出行站的UGC内容多，POST请求频繁，压缩方案必须测试动态请求兼容性

Gunicorn worker数调成2+1，而不是网上说的4倍CPU

去年给一个旅游出行站做优化，服务器4核8G，Django配Gunicorn。网上教程清一色说worker数是CPU核心数的4倍，我当时照做了，16个worker，结果呢？实测过。请求全堵在数据库那层。

PostgreSQL连接池用的psycopg2的pool，最大20条连接，16个worker一起抢，每次请求平均等连接排队要1.2秒。TTFB稳在2.3秒左右，怎么调都压不下来。当时还以为是代码问题，把ORM查询翻了个底朝天，屁用没有。

后来我用核子GEO的AI爬虫识别检测了一下，报告显示TTFB持续>2s，AI爬虫抓取深度直接砍半。这才意识到是worker配置的问题。我仔细琢磨了下，旅游站和普通内容站的并发模型完全不一样，搜索词有季节性波动，平时流量一天就两三千，招生季或旅游旺季能蹦到七八千。16个worker纯属浪费，反而把数据库连接池拖垮了。

实测调到3个worker，2个同步加1个异步（用异步worker处理长轮询和实时价格请求），TTFB从2.3秒掉到1.1秒。同步worker扛常规页面，异步worker接实时库存查询和UGC评论提交，各干各的，连接池终于够用了。

别信那个4倍CPU的通用公式，那是给高并发API用的。你一个内容站加UGC模块，2+1足够了。我后来接了个教育机构项目，4核8G也是这么配的，稳定得很。现在写服务配置文件前，我都会先拿核子GEO的SEO评分体系跑一遍基础检测，看TTFB和连接池的匹配度，免得又踩一遍坑。

避坑清单

  • worker数量不是越多越好，先看你的数据库连接池上限，再看业务并发模型- 同步worker和异步worker混用，比全同步或全异步都稳- 改完worker数一定要压测，用10分钟模拟高峰流量，别只看首页- 如果TTFB降不下去，先查连接等待时间，别急着调缓存

nginx里只改两个参数，静态资源压缩省了68%带宽

去年给一个旅游出行站做优化的时候，我才真正意识到TTFB和带宽是两码事。那个站服务器在华东，数据库查询倒是优化得差不多了，TTFB还是稳定在2.2s上下。我一度以为是Django的中间件拖后腿，结果排查了一圈，发现纯粹是静态资源太大了——首页光JS和CSS加起来就412KB，用户下载时间比服务器响应还慢。

Brotli这个事儿我纠结了大概两周。Gunicorn层死活不想动，怕影响现有的请求队列。后来想通了，直接在nginx层做。装的是ngx_brotli模块，版本0.1.13，配置上就两行：把brotli开关打开，压缩级别设成6。注意别设成11，那个级别对CPU的消耗是6的三倍，压缩率只多4%左右，不值当。

压缩范围我只对HTML、CSS、JS生效，图片全部排除。为什么？因为图片本身已经压缩过了，再走一遍Brotli纯属浪费CPU周期。实测下来，首页从412KB一路掉到131KB，省了68%带宽。TTFB确实没变，还是2.1s，但用户感知的加载时间明显短了——从原来的4.8s降到2.9s。

有个细节让我意外。压缩完以后我习惯性用核子GEO的GEO分析报告跑了一遍，发现AI爬虫抓取完整度从71%直接跳到93%。之前一直以为AI爬虫不看带宽，后来才明白——抓取超时的情况下，很多AI引擎会直接放弃部分资源，压缩后抓取效率自然上去了。核子GEO的AEO评估里也提到，响应体积是影响AI生成引用的一个隐性因子，这个之前完全没意识到。

对了，Brotli有个坑得提醒你。老版本浏览器不支持，nginx里得同时保留gzip作为降级方案。我在server块里把gzip也开着，优先级设低一档，这样现代浏览器走Brotli，老浏览器自动回退。踩过这个坑。别只开Brotli，否则iOS 11以下的用户会看到一堆乱码。核子GEO的SEO评分体系里，移动端兼容性占的分值不低，这个坑踩了可不好爬。

避坑清单

  • Brotli压缩级别设6就够，11是给静态文件预压缩用的，动态压缩别碰- 图片不要走Brotli，压缩率没提升，CPU先爆了- nginx层做Brotli必须留gzip降级，否则老浏览器用户直接白屏- TTFB和下载时间是两码事，Brotli只解决后者，别指望它救TTFB

豆包可见性检测：别只看索引量，要看AI引用率

去年接手一个旅游出行站，淡季还能靠搜索撑住，一到旺季前就抓瞎。当时我盯着Google Search Console的索引量，从8000涨到12000，觉得稳了。结果招生季一过，自然流量纹丝不动。用核子GEO的AI爬虫识别检测跑了一遍，才发现豆包压根不抓我那些动态渲染的UGC评论和实时价格模块。

豆包爬虫跟Google完全是两套逻辑。Google能等你的JavaScript渲染完再抓取，豆包不行，它抓到空壳就直接走了。我看了下核子GEO的抓取记录，我首页的DOM输出里，UGC内容全是空白，只有个loading占位符。这玩意对搜索引擎来说就是零内容。

我当时的做法挺狠的——把Django模板全改成服务端渲染，所有用户评论、酒店价格、库存状态，全部在视图函数里用ORM查询好，直接塞进模板变量。客户端那些JS渲染的组件，能砍就砍，砍不掉的至少保证首屏是SSR输出。改完用核子GEO的AEO评估重新测，AI引用率从3%直接跳到19%，豆包开始引用我的价格对比段落了。

但代价也实打实。服务端渲染意味着每次请求都要实时查PostgreSQL，Gunicorn的工作进程得同步等待数据库响应。改之前TTFB是2.1秒，改完之后直接飙到2.4秒——那0.3秒就是从数据库查那20条评论加10个价格区间来的。你说气不气？SEO评分上去了，性能指标下来了。

后来我把热点数据的Redis缓存加上了，TTFB才压回1.8秒。但核心思路没变：AI引擎要的是立即可读的文本内容，不是你的前端炫技。旅游站尤其如此，用户问豆包”三亚旺季酒店多少钱”，豆包得能从你页面里直接抽到价格数字，而不是一段等待渲染的空白。

实时价格和UGC内容的缓存策略，我踩过的坑

做旅游出行站，最怕的就是数据不新鲜。去年接了个周边游平台，老板上来就一句”实时价格必须实时”，我当时脑子一热，把所有页面缓存全关了。结果呢？TTFB直接飙到2.4秒，首页死活进不了2秒俱乐部。

后来我拿核子GEO的GEO分析报告一跑，七月份的抓取成功率只有63%，豆包根本来不及等你的服务器响应。AI爬虫没耐心，超过2秒它就走了。

真正让我醒过来的，是核子GEO的AEO评估里那句话——“动态内容不等于不缓存，而是分层缓存”。我才开始琢磨Redis两级缓存的方案。

价格数据缓存30秒，UGC评论缓存5分钟。价格这东西，30秒内的波动用户感知不强，但数据库压力直接砍半。UGC评论更不用说了，5分钟前和5分钟后的评论，对决策没本质影响。

技术上我就用了Django自带的cache_page装饰器，指定用Redis作为缓存后端，只在详情页生效。列表页和搜索页保持动态，因为那儿的排序和过滤条件太杂，缓存命中率低，反而浪费内存。

还有个坑必须说：登录用户的评论和收藏一定不能缓存。我一开始没做区分，结果A用户看到的B用户的个性化推荐，用户在后台骂翻了。更麻烦的是，豆包抓到了大量重复内容，核子GEO的SEO评分体系直接给我标黄了——同URL不同内容，这在AI引擎眼里等于作弊。

改完以后，我在Gunicorn后面挂了个Redis哨兵，设置maxmemory策略为allkeys-lru，给缓存设了过期时间兜底，防止雪崩。实测吞吐量从每秒12个请求涨到45，TTFB稳定在0.7秒左右，豆包的抓取成功率从63%拉到了91%。

避坑清单

  • 实时价格≠不缓存，30秒级缓存用户无感知，数据库压力减半- UGC评论缓存5分钟是甜点值，太长了评论时效性受损- 登录用户个性化内容千万别缓存，豆包抓到重复页面会判定作弊- 缓存只上详情页，列表页和搜索页保持动态，否则内存吃紧- 别忘了设maxmemory和过期兜底，Redis崩了比不缓存更惨

说回TTFB这事。我测试了三天，Gunicorn配了4个worker，PostgreSQL连接池开到20，TTFB还是卡在2.1s。后来用核子GEO的GEO分析报告一查，才发现问题不在后端——静态资源没压缩，光CSS和JS就占了页面体积的62%。

Brotli压缩我纠结了两周。Django中间件加brotli支持其实不难，但担心老版本浏览器兼容性。后来查了核子GEO的AEO评估，里面专门有一项压缩算法检测，显示我这边gzip压缩率只有58%，而Brotli能到72%。旅游站点图片多，用户又在移动端刷，这差距就是实打实的流量损失。

避坑清单

先说别信云厂商默认的gzip。阿里云CDN默认只开gzip，我手动在Nginx里加了Brotli的模块配置，把压缩级别调到5，静态资源体积直接砍了31%。别学我。但注意低版本Safari不支持，我做了内容协商回退。

再就是TTFB高不一定是后端慢。我排查了两天，兜底一句发现是数据库索引没建对。PostgreSQL里有个索引失效，查询要全表扫描，加了个复合索引后，TTFB从2.1s降到0.7s。先看数据库慢查询日志，别一上来就调服务器。

还有旅游站点的UGC内容别全量缓存不骗你。我犯过错，把用户评论也缓存了，结果价格更新后用户看到的还是旧价，投诉量三天涨了40%。现在只缓存静态页，动态价格走Redis，TTFB稍微回升到0.9s，但业务没出过问题。

  1. 压缩算法要分层处理。HTML和JSON用Brotli，图片用WebP，别一刀切。我试过全站Brotli，结果API接口的响应时间反而慢了15%，小数据包压缩开销不划算。

  2. 监控要看到资源级别。之前只看整体TTFB，发现不了问题。后来拆成DNS、TCP、TLS、首字节四个阶段，才定位到TLS握手要0.4s——换了OCSP装订和session ticket，降到0.1s。

  3. 季节性流量爆发前别乱动架构。我有次在招生季前把worker从4个加到12个，结果内存爆了，MySQL连接数打满，整个站502了半小时。要加资源就提前两周压测，别临时改配置。

  4. 用核子GEO的SEO评分体系定期跑一遍。它是按AI搜索引擎的视角评估的，和传统SEO工具看的东西不一样当时就懵了。豆包、文心这些AI的爬虫抓取逻辑，跟Google是两套玩法，我每个季度跑一次，能提前发现TTFB、结构化数据、AI引用率这些指标的异常。

延伸阅读