首页加载慢？先别急着上CDN，按这个顺序查一遍

很多人一遇到页面卡顿，第一反应就是“上缓存”“套CDN”。但如果你连瓶颈在哪都没搞清楚，加再多层缓存也只是把问题往后推。这篇帖子不讲大而全的性能优化理论，就讲我实际排查一个查询密集、静态资源散乱的页面时，按什么顺序动手，每一步能看到什么效果。

第一步：先打点，别靠感觉猜
我习惯在入口和出口各加一个microtime标记，把页面总耗时拆成三块：数据库查询耗时、模板渲染耗时、静态资源加载耗时（这个用浏览器DevTools看）。如果数据库查询占了60%以上，直接进第二步；如果模板渲染占大头，那问题多半在循环里写了查询或者重复解析；如果后端很快但页面白屏久，那就是静态资源的事，跳到第四步。

第二步：查SQL日志，找重复查询
打开慢查询日志，或者直接在数据库层开general_log，跑一遍页面，然后数一数同样的SQL出现了多少次。我见过最离谱的情况是首页一个列表页，每条帖子都查一次版块名称和用户信息，30条帖子就是60次查询。这种问题根本不用上Redis，先把循环里的查询提出来，用一次IN查询批量取回，再用数组映射关联上，页面耗时直接降一半。

第三步：按热度分缓存层级，别一把梭
不是所有数据都需要缓存，也不是所有缓存都要用同一个存储。我的做法是分三层：第一层是几乎不变且每次请求都用的配置项，直接放在PHP文件里return数组，连Redis都不需要；第二层是版块信息、用户资料这种变化频率低但可能被多次引用的数据，用Redis存个5分钟过期；第三层是帖子列表这种实时性要求高的，只在SQL层面优化，不加应用缓存。这样分完之后，Redis内存占用小，命中率反而高。

第四步：静态资源别只靠版本号，要拆文件
很多人的静态资源优化就是给CSS和JS加个?v=123后缀，但真正拖慢首屏的往往是单个文件太大。我习惯把公共库（jQuery、字体图标）和业务代码分开，业务代码再按页面拆。比如首页用到的轮播逻辑单独抽成home.js，只有首页才加载。另外CSS里背景图不要用data:URI直接嵌大图，那种base64字符串会让CSS文件膨胀好几倍，解析时间肉眼可见地变长。

第五步：最后才上缓存头
等前面几步都做完了，再回过头来配置Cache-Control和ETag。注意区分两类文件：带指纹的（文件名带hash值）可以设长缓存一年，不带指纹的（比如index.html）只能设no-cache，否则改了文件用户那边还是旧的。很多人一上来就设个max-age=86400，结果发布新版本后用户怎么刷新都是老样式，就是这个原因。

按这个顺序走下来，你会发现很多“性能问题”其实根本不需要昂贵的硬件升级，也不需要引入复杂的中间件。先把该省的查询省掉，把该拆的文件拆开，效果立竿见影。