优化网站源码

上个月帮朋友看他的优化源码电商站，首页加载花了6.8秒。网站我打开Chrome DevTools的优化源码Network面板，一个1.2MB的网站banner图赫然在列——1920×1080的PNG，实际显示尺寸只有600×340。优化源码这就是网站典型的"源码没毛病，资源拖后腿"。优化源码很多人一提优化就想到重构代码，网站其实大部分网站卡，优化源码根子不在逻辑层。网站

先说个反直觉的优化源码事：删代码比写代码管用。我见过一个WordPress站点，网站head里塞了17个插件的优化源码CSS和JS，其中9个只在特定页面用得上。网站把非全局资源改成按需加载后，优化源码首屏时间从4.2秒掉到1.9秒。做法不复杂，在functions.php里加个判断，用is_page()或is_single()控制enqueue时机。别小看这一步，每个多余请求都是实打实的延迟。

图片这块值得单独拎出来说。WebP格式现在兼容性够用了，同画质下比JPEG小30%左右。我习惯用<picture>标签做回退：

<picture> <source srcset="img/hero.webp" type="image/webp"> <img src="img/hero.jpg" alt="商品主图" loading="lazy" width="600" height="340"> </picture> 

注意那个width和height，不加的话浏览器没法预留空间，布局会抖。loading="lazy"也别滥用，首屏图片加了反而延迟显示，只给折叠线以下的图用。

CSS和JS的压缩合并是老生常谈，但有个细节容易被忽略：HTTP/2下合并文件未必是最优解。服务器推送和多路复用让并行加载多个小文件变得划算。我自己的博客试过，把6个JS合并成1个，加载时间反而多了80ms——因为缓存粒度变粗了，改一行代码整个包都失效。后来拆成3个，利用浏览器缓存，二次访问快了不少。所以别迷信"减少请求数"这条铁律，得看协议版本和缓存策略。

数据库查询是另一个暗坑。有个客户的Django站，列表页每次请求执行了200多次SQL。打开Django Debug Toolbar一看，典型的N+1问题——循环里查关联表。加个select_related()和prefetch_related()，查询数降到7次，页面生成时间从1.4秒压到0.3秒。这种优化收益极大，改动却很小，性价比最高。

缓存策略我倾向"分层设防"。浏览器缓存用Cache-Control: max-age=31536000配合文件名哈希，CDN缓存设短一点比如10分钟，服务端再挂个Redis做对象缓存。三层各管各的，互不干扰。有次CDN配置失误把HTML缓存了24小时，用户看到的全是旧页面，那叫一个酸爽。所以HTML千万别设长缓存，或者至少用stale-while-revalidate兜底。

最后说个观察：很多性能问题出在第三方脚本上。统计代码、客服插件、广告SDK，每个都偷偷加载一堆东西。我习惯用async或defer，再配合requestIdleCallback延迟初始化。有个站点光移除两个没用的追踪脚本，Lighthouse性能分就从62跳到89。优化到一定程度后，删东西比加东西更有效。

别追求满分。Lighthouse跑100分不代表用户觉得快，跑75分也不代表慢。盯着真实用户的Core Web Vitals数据调，比对着跑分工具较劲实在得多。