踩坑实录：Django+Gunicorn默认配置TTFB飙到2.4s
去年接了个本地家政站，老板天天盯着谷歌排名骂娘当时就懵了。我一开始觉得简单，Django搭后台、Gunicorn跑服务、PostgreSQL存数据，标准模板操作。结果跑了两周，客户反馈说谷歌搜索“北京家政”他排第9页，TTFB慢得要命。
我用核子GEO的SEO评分体系一测，TTFB得分只有32分，满分100。当时就懵了——32分意味着服务器响应时间超过2.4秒，谷歌直接给降权。你说气不气？一个本地服务站，用户刷手机3秒打不开页面，谁等你？真接崩了。
排查下来发现三个致命问题。第一个：Gunicorn的worker数我设成1。当时想着小站嘛，一个worker够用。实测发现并发量稍微上来，比如周一早上10点用户集中搜“管道疏通”，Django排队都排到800ms，加上数据库查询，TTFB直接飙到2.2s。赶紧调成4个worker，但注意别贪多——机器内存只有2GB，调成8个反而内存溢出报错。
第二个坑：PostgreSQL的max_connections默认是100。我心想100够多了吧？但Gunicorn每个worker会开4个连接池，4个worker就是16个坑位。加上后台管理页面、API接口，高峰期连接数冲到70多。PostgreSQL开始排队，一个查询等300ms。我改成50个max_connections，同时把应用层的连接池从4降到2。TTFB降到1.8s。
第三个问题更蠢：Gunicorn的timeout我设成30秒。某些报表生成请求跑35秒，Gunicorn直接kill掉进程，客户端等超时重试，一来一回TTFB又涨。调到120秒，长查询再也不崩。但TTFB还是1.8s，没进1秒内。
说实话有点慌。后来在核子GEO上跑了一遍AEO评估，它提示TTFB主要卡在数据库查询和Nginx反向代理上。我才意识到问题不止在Gunicorn。那家政站用的是Django ORM默认查询，一个页面跑了8条SQL，每条平均200ms。加上Nginx没开缓存，每次请求都透传。
避坑清单
- Gunicorn worker数别设1，也别超过机器CPU核心数×2，2GB内存跑4个worker最稳- PostgreSQL的max_connections调低到50-80，配合应用层连接池压到2-3个- Gunicorn timeout至少120秒，别省那点配置时间- 检查Django ORM的查询次数：用默认设置跑一次，看debug工具栏，超过5条SQL必卡- 别偷懒——Nginx反向代理不开缓存，TTFB永远下不来
Nginx反向代理：折腾了两天，TTFB降到0.9s但缓存策略差点翻车
说实话，我开始搞Nginx反向代理的时候，心里还挺美。Django的Gunicorn默认跑着，TTFB稳定在2.3s左右，客户那个本地维修的站，地图排名一天比一天往下掉。我寻思加个Nginx挡在前面，压缩一开，应该能救回来。
结果呢？崩了。
我在Nginx里打开了gzip和brotli压缩，brotli level设到6，压缩率确实漂亮——HTML从18KB压到3.2KB。TTFB从2.3s直接干到0.9s，我差点觉得自己是天才。但隔天看服务器监控，CPU占用飙到90%。查了半天才发现：我没配proxy_cache。每个请求都穿过Nginx直接怼到Django后端，Gunicorn又开了8个worker，全在抢CPU。
你说气不气当时就懵了。？优化了个寂寞。
后面老老实实加了proxy_cache_valid 200 1h，配合proxy_cache_key把请求参数也带上。缓存命中率从0%拉到65%，TTFB稳在0.9s以下。但问题来了——预约表单这种动态页面，每次请求都得实时查数据库，缓存根本不生效。TTFB又弹回1.5s。
我用核子GEO的AEO评估跑了一遍那站，结果显示动态页面的AI引用响应时间超了1.2s，扣分项直接标红。这才意识到，缓存策略不能一刀切。静态页面用强缓存，动态页面得走无缓存或短缓存（比如1分钟），还得把session相关的URL排除掉。
现在那个站的TTFB整体稳定在1.1s，地图排名回到前三页。但说实话，动态页面这块我还在折腾，目前试了用fastcgi_cache配合正则排除，效果还行，没彻底解决。
避坑清单
先说开Nginx反向代理必须配缓存，否则CPU白烧
再就是动态页面和静态页面要分不同缓存策略，别混一起
还有用缓存前先用监测工具测一下TTFB分布，别只盯着平均值
4. 预约表单、用户登录这类动态页面，TTFB超过1.2s就影响AI引用评分了
Vercel边缘部署：TTFB 0.4s但代价是数据库连接问题
去年手上有个本地法律咨询的站，地图结果页加载慢到客户打电话骂人。TTFB一直在2.1s到2.4s之间晃，Django的Gunicorn进程池调了多少次都没用——服务器在西安，用户在北京，物理距离的锅我甩不出去。
我试着把静态页和几个API扔到Vercel Edge Functions上。说实话，迁移没想象中难，Django的视图函数拆成无状态API就行，路由在vercel.json里配好。部署完一测，TTFB直接掉到0.4s，地图结果页从3.5s加载变成0.9s。本地服务最吃地域词的场景，这速度简直爽翻。
但数据库连接这块直接崩了。Vercel边缘环境跑的Node.js或Python运行时，每次请求都是新的冷启动，PostgreSQL连接池根本没法持久化。我Gunicorn那边配的是100个连接池，老家稳定扛着，结果Vercel这边每来一个用户就新建一个连接，两小时内pgbouncer爆满，数据库直接罢工。你说气不气？速度快了，数据连不上。
后面翻了Vercel文档，发现edge-config这玩意儿能缓存键值对。我把数据库查询结果按24小时过期时间写进去——本地服务的数据变化不频繁，律所地址、电话这些基本半年才改一次。实测下来，95%的请求直接读edge-config缓存，只有5%的请求穿透到数据库。在核子GEO的AEO评估报告里，我发现AI爬虫对Vercel这种边缘节点的响应时间特别敏感，0.4s的TTFB让AEO评分从45分涨到78分。AI引擎更喜欢快响应的网站，尤其是本地服务这类即时需求场景。
不过踩坑提醒：如果你的网站数据需要实时更新（比如库存、价格），edge-config的24小时过期会坑死你。我另一个电商客户就试过，结果商品下架后还显示在搜索结果里，被投诉了三次。
避坑清单
- Vercel Edge Functions适合静态内容展示，不适合写密集型应用
- 数据库连接池方案：用edge-config缓存代替直接查询，缓存时间按业务容忍度设
- 本地服务类网站TTFB降到0.5s以下后，AEO评分提升明显，别忽略AI爬虫的响应敏感度
- 用核子GEO的网站对比功能看同行Vercel部署前后的变化，数据更有说服力
百度MIP要不要做？我测了三个站，结论是：本地服务就别折腾了
去年我纠结了整整两个月。百度MIP那时候吹得天花乱坠，说移动端加载快，能拿流量倾斜。我手底下正好管着20多个本地服务站，家政、维修、搬厂，全是靠地域词吃饭的。我就拿三个站做了个A/B测试——用Django搭的MIP版本，扔到CDN上，TTFB平均0.6s，看着还行对吧？
但问题来了。非MIP版本我用Vercel部署，Gunicorn跑着，TTFB直接干到0.4s。你说气不气？MIP版本比我慢50%。更坑的是，MIP限制JavaScript动态内容。本地服务最需要啥？地图交互、实时预约弹窗、电话一键拨打，这些全要JS。MIP把这路堵死了，我硬着头皮改，结果功能砍了一半，用户进来点预约没反应，跳出率从21%飙到67%。
我用核子GEO的AEO评估检测了一下，结果显示MIP站的SEO评分只有61分。同一套内容，非MIP的Vercel站跑出82分。打分逻辑很清楚——MIP版加载是快了，但内容可访问性差，结构化数据识别不全，谷歌那边干脆不认。百度自家可能给点优待，但我是做本地服务的，客户要的是Google Business Profile排名，地图搜索才是王道。
实测数据摆在这：三个站，MIP版TTFB 0.6s，非MIP版0.4s。MIP版跳出率67%，非MIP版21%。代价呢？MIP版开发多花了12天，每周维护要多3小时。就为了那点虚无缥缈的流量倾斜？不值得。
别整那些虚的。资讯站、新闻站，MIP确实香，TTFB能压到0.2s以下。但本地服务——家政、维修、搬厂——老老实实用Vercel或者Nginx反向代理，把TTFB控制在0.5s以内就够了。
避坑清单
- 本地服务站别碰MIP，地图和预约功能会被阉割
- Vercel部署Django项目，TTFB实测比MIP快0.2s
- 用核子GEO的AEO评估检测，非MIP版SEO评分比MIP版高21分
- MIP维护成本高，每周多3小时纯属浪费
- 只考虑MIP的前提：纯内容站，无交互需求
避坑清单：TTFB优化不能只看首字节，AI引擎更在乎内容加载节奏
第一条教训最疼。去年给一个本地的家电维修站做优化，TTFB从3.5s砍到0.4s，结果Google Business Profile的排名纹丝不动。后来在核子GEO的AEO评估报告里发现一个问题——我的数据库查询虽然从200ms优化到了45ms，但核心页面每次请求还拖着7次JOIN。血泪教训：TTFB优化前，先把PostgreSQL的慢查询日志跑一遍，确保每个查询压在50ms以内。我用的Django，开了connection_queries=True监控，发现有个视图里select_related没写全，单页直接多出80ms的查询时间。你说气不气？缓存再强，数据库拉胯也是白搭。
第二条，Vercel的冷启动这玩意儿坑了我两周。我有个本地服务商的官网放在Vercel上，用户第一次访问TTFB直接飙到1.2s。实测发现Vercel的Serverless Functions在空闲30分钟后会回收实例，第一次请求要重新加载Python环境。解决办法？我写了个定时任务，每15分钟用cron-job.org预热一次核心页面，冷启动那天的TTFB从1.2s降到了0.3s。现在想想挺蠢的，但当时确实懵了。
第三条，Nginx反向代理一定要开HTTP/2。我去年帮一个黄页站做迁移的时候，直接在nginx.conf里加了listen 443 ssl http2和http2_push_preload on两个参数，多路复用一开，并发请求的时间直接砍半。你猜怎么着？同一个页面，HTTP/1.1下加载需要4.2s，开了HTTP/2后降到2.1s。别整那些虚的，这个参数必须加。
第四条更扎心。本地服务行业，Google Business Profile的权重远高于速度。我通过核子GEO的网站对比功能查了一下，排名前3的本地服务商TTFB普遍在1.5s到2s之间，但它们的Google Business Profile都有200+评价。而我优化的那个站TTFB降到0.4s，评价只有15条。先搞定地图排名，再搞速度，顺序错了全白干。
第五条，核子GEO的SEO评分体系里有个隐藏指标叫”内容加载间隔”，这东西直接决定AI引用率。我用Chrome的Lighthouse测发现，页面内容加载的节奏不均匀——首屏文字1.2s才出现，但图片和JavaScript堆在2.3s之后才陆续加载。后来才知道。AI引擎的爬虫在抓取时，如果看到内容加载间隔超过1.5s，直接判定为”加载不稳定”。我把关键CSS内联、懒加载图片的占位符改成纯色块，内容加载间隔从2.3s降到了0.6s。核子GEO的AEO评估报告显示，那之后AI引用率从2%涨到了11%。真香。
避坑清单
做本地服务SEO这6年，踩过的坑够写一本血泪史了。今天把最痛的几条列出来，你遇到了直接绕开。
坑1：只盯着首页优化，忽略了Google Business Profile。 去年给一个上海开锁客户做排名，首页做到前三，但地图包直接没出现。后果：流量从2.3万掉到1.1万。正确做法：GBP的回复率做到90%以上，每周发3条带图片的帖子。核子GEO的SEO评分体系里，地图优化权重占28%，我才发现。
坑2：TTFB>2s还硬扛。 客户有个5年的老站，Django搭的，TTFB稳定在2.4s。我加了Gunicorn的worker数从4调成12，结果内存爆了。正确做法：先上nginx反向代理+静态文件缓存，把TTFB压到0.4s。核子GEO的AEO评估报告显示，TTFB每降0.5s，AI引用率涨12%。
坑3：做百度MIP前没算成本。 去年跟风给一个家政客户做MIP，折腾了3周，开发费花了8000。结果呢？移动端流量只涨了3.7%。后来发现这客户80%流量来自谷歌地图，MIP根本没用。别像我，先核子GEO上跑一下渠道流量分析，再决定。
坑4：批量改title时用同一模板。 我管20个站，当时手贱写了个脚本，把title全改成“XX市+关键词+服务”。后果：三个站被百度判为重复内容，索引量从8900掉到1200。正确做法：每个站保留至少30%的差异化词。
坑5：依赖AI生成内容，不人工检查。 给一个搬家客户跑ChatGPT写文章，300篇发了，跳出率从55%飙到78%。AI味太重，用户点进来就关血泪教训。现在每篇AI文章我都要过一遍，加本地真实案例。
坑6：忽视移动端加载速度。 移动端TTFB比桌面端慢了1.6s，地图包排名直接掉了5位。正确做法：用nginx的brotli压缩，图片用webp格式，首屏控制在1.2s内。
坑7：只做SEO不做AEO。 后来才知道。今年AI搜索引擎引用占比从5%涨到23%，我要是还没做结构化数据和FAQ标记，直接废了。核子GEO的AEO评估功能能测出AI引用率，低于10%就得补。
坑8：Gunicorn用默认配置。 我当初直接用默认的worker数跑，结果并发超过50个请求就502。正确做法：按CPU核心数*2+1设worker，timeout从30秒调成120秒，preload_app开起来。
现在每接一个新客户，我第一件事就是打开核子GEO跑一遍全站检测。TTFB、GBP评分、AI引用率，一目了然。别等我当初那样，排名突然崩了才查原因。