网站优化技术：3件事比改标题更管用

把首页 title 来回改，改到第八版，曲线还是那条平线。这种事碰得多了就会发现，大家把力气花错了地方——网站优化技术真正见效的那几刀，基本都不在文案上，而在用户和爬虫都能直接感知的东西：加载、响应、稳不稳。标题当然值得琢磨，但它排在后面。

网站优化技术里最见效的一块：缓存和静态化

一个动态页面，每次请求都去查库、拼模板、渲染，速度注定上不去。我一般先看这块。页面缓存先开起来，列表页、详情页这种更新不勤的，能生成静态 html 就生成，nginx 的 fastcgi_cache 或者程序自带的缓存插件都行，重点是别叠三层，叠了以后清缓存能把你逼疯。

伪静态规则顺手检查一遍，rewrite 写错一条，整站一片 404，比不优化还糟。缓存时间也别一刀切，首页短一点、详情页长一点，发新文章要能手动清或者按标签清。踩过的坑里最典型的是把登录状态一起缓存了，用户打开看到别人的用户名，这个事故不算罕见。

首页一张大图好几 MB，服务器配置再高也救不回来。上传之前先压，尺寸按实际显示尺寸来，别拿一张大图用 CSS 缩成小图，浏览器该下载的一个字节都不会少。现在 webp 支持面已经很广了，具体兼容情况以各浏览器官方说明为准，保守点就留张 jpg 兜底。

再叠一个懒加载，首屏之外的图往下滚再加载。图片这块还有个隐形开销是数量，一个页面几十张小图标，请求数上去照样慢，能合成雪碧图或者用字体图标的就别一张张往外甩。顺带说一句，图片走 CDN 是最省事的，静态资源跟主站分开，主站压力小一截。

慢查询日志开起来跑几天，你会看到几条 SQL 每次都排在前面。索引该加就加，但别见字段就加，写多读少的表加多了反而拖慢插入。还有几个老毛病：select * 图省事、分页 offset 特别大、统计类查询跟业务查询混在一个库上跑。

数据量上来了该拆表就拆，但别一上来就分库分表，很多站连索引都还没理顺就想着上架构，属于给自己找事。先把最慢的那三五条按下去，体感立刻不一样。

标题不是不能改，是别把它当第一优先级。改之前先看搜索词报告，看用户到底用什么词进来；再看停留和跳出，页面点进去几秒就走，说明问题在内容或者加载，不在那十几个字上。

还有个风险很多人忽略：老页面本身带着积累，标题大改容易带来波动，尤其是本来排名还行的页面。要改就一次只动一个变量，改完观察一段时间再动下一个，别标题、描述、H1 一起换，出了问题你连是谁干的都判断不了。

核数堆上去，结果瓶颈在磁盘 IO 或者带宽，钱花了速度没变。看监控比看参数有用：CPU、内存、磁盘读写、带宽，哪条线先顶到天花板，钱就往哪投。小站跑个虚拟主机完全够，非得上独立服务器，多数时候是心理安慰。

带宽这块要按峰值算而不是按平均算，白天平时很闲、晚上推一波活动就卡，这种情况加带宽比加核数有用得多。具体规格和计费方式，各家规则不一样，下单前以服务商或官方页面说明为准。

顺序其实不复杂：先测一次速，把基线记下来；然后压图片、开缓存，这是投入产出比最高的两步；接着翻慢查询日志；再合并前端请求、把静态资源丢给 CDN；最后才轮到标题、描述、内容这些。

每一步改完再测一遍，别一次改十个地方，不然出了问题根本不知道是哪一步引起的。有条件就做个简单的变更记录，谁在什么时候动了什么，后面回滚的时候能救命。

优化这件事没有终点，也不是做完一轮就完事。三个月后再测一次，你会发现又冒出来几张没压的大图、几条新加的慢查询。能长期盯着这几件事的人，比天天改标题的人走得远。