上周帮朋友看他的网站茶叶商城，首页加载了整整11秒。打开我盯着浏览器标签页上那个转圈的速度图标，差点以为断网了。网站打开开发者工具一看，打开服务器响应就花了3秒多，速度剩下的网站时间全耗在加载一张5MB的首页大图上——那张图还是直接从手机相册传上去的，连压缩都没做。打开

这种情况太常见了。速度很多人以为网站慢是网站“服务器不行”，其实问题往往出在几个具体的打开地方。我见过最离谱的速度一个案例，某企业官网首页嵌了七个不同的网站统计代码，每个都同步加载，打开用户打开页面时光是速度等这些脚本就跑掉了五六秒。老板还纳闷，说我们服务器配置挺高的啊。

服务器响应慢是第一道坎。有些虚拟主机超售严重，一台机器上挤了几百个网站，数据库查询稍微复杂一点就卡住。我测试过一个客户站点，光是建立数据库连接就花了1.8秒，这还没开始查数据呢。换成独立服务器或者云数据库之后，直接降到200毫秒以内。钱花在刀刃上，效果立竿见影。

图片是另一个重灾区。现在手机拍出来照片动辄四五兆，直接上传到网站，用户加载时就得完整下载。其实稍微处理一下——转成WebP格式，宽度限制在1200像素以内——体积能缩小到原来的十分之一。有个做民宿的客户，把首页轮播图从PNG换成WebP之后，页面加载时间从7秒降到了2.3秒。就这么简单一个动作。

前端代码臃肿的问题也很要命。很多建站工具生成的页面，光是CSS文件就几百KB，里面一大半样式根本用不上。JavaScript更是重灾区，各种插件、框架层层叠加。我见过一个用某开源CMS搭的博客，首页加载了23个JS文件，总共1.7MB。其实那个页面就展示几篇文章列表，根本不需要这么多交互逻辑。

浏览器渲染这块经常被忽略。有些网站把CSS放在页面底部加载，导致浏览器先渲染出无样式的HTML，然后突然闪一下变成正常样子。用户感觉就是“卡了一下”。正确做法是把关键CSS内联在head里，非关键的异步加载。这个改动不大，但体验提升很明显。

CDN不是万能药，但用对了确实管用。有个做外贸的客户，服务器在美国，国内用户访问慢得离谱。套上CDN之后，静态资源从国内节点分发，首屏时间从9秒降到3秒左右。不过他犯了个错误——把动态API也走了CDN，结果用户登录状态经常丢失。CDN要分清楚什么该缓存什么不该缓存。

HTTP/2和Gzip压缩属于基础设施层面的优化。开启Gzip之后，文本类资源体积能减少70%以上。HTTP/2的多路复用则解决了HTTP/1.1队头阻塞的问题。这两项在主流服务器上都是一行配置的事，但很多站点就是没开。我随手查过几个本地企业的官网，至少一半还在用HTTP/1.1且没开压缩。

说回那个茶叶商城。我让他做了三件事：图片压缩转WebP、开启Gzip、把统计代码改成异步加载。总共花了不到两个小时。再测的时候，首页加载时间降到了2.1秒。他挺高兴，说原来以为要花大钱换服务器，没想到都是些小改动。

网站速度这事，八成的问题都出在图片、脚本和服务器配置上。不用急着升级硬件，先打开开发者工具看看时间线，哪个环节最耗时，就从哪里下手。多数时候，几个具体的小修正就能带来明显改善。