上周帮朋友排查他的网站个人博客，页面加载居然要六秒多。打开按了F12一看，速度好家伙，原因光是网站首页就请求了87个资源文件，光是打开那张轮播图就压缩前有4.2MB。这哪是速度网页，分明是原因座搬家公司都嫌重的仓库。

网站慢的网站第一个坑，往往就埋在图片里。打开很多站长懒得压缩，速度直接从相机或设计稿里拖出来就用。原因一张1920像素宽的网站高清图，不经过任何处理，打开体积轻松破2MB。速度移动端用户刷到这种页面，流量哗哗走，加载却像蜗牛爬。更别提那些轮播图、背景图，一套下来十几个大文件，服务器再快也架不住这么折腾。我的习惯是：装饰性图片一律用WebP格式，关键内容图控制在100KB以内，能CSS画的绝不用图。

另一个隐形杀手是外部请求。你页面里嵌了个统计代码，又调了个字体库，还挂了三个广告联盟的脚本。每个外部域名都得走一次DNS解析，建立TCP连接，再等对方服务器响应。哪怕每个只要200毫秒，五个外部服务叠加就是整整一秒。我见过最夸张的案例，一个电商活动页挂了11个第三方SDK，光握手就得三秒多。这年头，谁有耐心等你慢慢跟别人打招呼？

服务器响应慢也常被忽略。租个最便宜的虚拟主机，CPU配额低得可怜，碰上动态页面要查数据库、渲染模板，稍微有点并发就卡死。我自己的经验是，静态页面直接上CDN，动态接口做好缓存。Redis该用就用，页面片段缓存能省下80%的重复计算。别舍不得那点内存钱，用户流失的损失可比服务器贵多了。

还有个容易忽略的点——前端渲染顺序。有些框架喜欢把所有JS打包成一个巨无霸文件，首屏非得等脚本执行完才肯显示内容。结果就是白屏几秒钟，用户以为网站挂了。解决办法很简单：关键CSS内联，非关键脚本加defer或async，首屏只渲染必要组件，剩下的等空闲了再加载。有次我把一个Vue项目的路由改成按需加载，首屏时间直接从3.2秒降到1.1秒，效果立竿见影。

HTTP/2和HTTP/3的区别也值得说一嘴。老站点还在用HTTP/1.1，浏览器对同一域名的并发连接数限制在6个左右，资源一多就得排队。换成HTTP/2之后，多路复用能让所有请求同时跑，哪怕几十个文件也不怕。去年帮客户迁移到HTTP/3，配合QUIC协议，弱网环境下的加载速度提升尤其明显——地铁上刷页面，以前转圈十秒，现在三秒内出内容。

最后还得提一下缓存策略。静态资源没设Cache-Control头，用户每次刷新都得重新下载。明明logo图一百年不变，偏偏让浏览器反复拉取。设置好强缓存和协商缓存，回访用户的速度能快一大截。我见过不少团队，后端接口做了缓存，前端静态资源却裸奔，本末倒置。

说到底，网站提速不是单点优化，而是一条链路的事。从图片压缩到请求合并，从服务器配置到前端渲染，每一环都得抠。上次给朋友那博客做完体检，删掉多余插件、压缩全部图片、开启Gzip、套上CDN，最后加载时间稳定在1.2秒。他问我秘诀是什么？哪有什么秘诀，就是把每个环节的懒都治一遍而已。