资源加载与代码精简：前端性能优化的基础工程
前端性能就像盖房子，基础打不好，后面再华丽也站不稳。而资源加载和代码质量，就是这个“地基”。我见过太多项目明明功能简单，却因为资源没管好，变成了“重量级选手”。
先说图片——这几乎是所有页面的“性能杀手”。去年帮朋友的摄影博客优化时，他直接把相机拍的5MB原图上传，首页10张图就占了50MB，加载时进度条能卡半分钟。后来我帮他做了三件事：一是把所有图片转成WebP或AVIF格式（现在主流浏览器都支持了），同样清晰度下体积比JPG小50%；二是用响应式图片，根据用户设备尺寸加载不同分辨率（比如手机端用600px宽，PC端用1200px）；三是给非首屏图片加懒加载，让用户滚动到哪才加载到哪。这么一弄，首页加载体积降到6MB，打开速度从30秒缩到3秒，他跟我说：“现在读者停留时间都多了2分钟，广告收益都涨了！”
可能你会说：“我用了图片压缩工具啊，怎么效果不明显？”这里有个细节——别只盯着文件大小，还要看加载策略。比如电商首页的轮播图，很多人习惯把所有图一次性加载，但其实用户可能只看第一张。我之前优化时用了“预加载+懒加载”组合：首屏图优先加载，第二张图在首屏图快加载完时偷偷预加载，后面的图等用户滑动时再加载，既保证了速度，又没浪费流量。
再说说CSS和JS这些“代码资源”。你有没有见过一个项目的bundle.js文件超过5MB？我去年接手的一个后台系统就是这样，开发时图方便把所有库都引进来，结果上线后首次加载慢得离谱。后来用代码分割（Code Splitting）拆成了“基础库+页面组件”两部分，基础库缓存起来，每个页面只加载自己需要的组件代码，体积直接砍了70%。还有Tree-Shaking——这个听起来高大上，其实就是“摇掉”代码里没用到的部分。比如你引了一个大UI库，却只用到其中2个组件，Tree-Shaking能帮你把剩下的代码全删掉。记得用Webpack或Vite的默认配置就行，不用自己写复杂配置，亲测有效。
字体加载也是个容易忽略的点。之前做一个品牌官网，设计师非要用一款特殊字体，结果字体文件2MB，加载时页面文字“闪一下”才显示（FOIT问题）。后来改用“字体子集化”——只保留页面用到的文字（比如常用的2000个汉字），文件缩到200KB，再配合font-display: swap让浏览器先显示默认字体，等自定义字体加载完再替换，用户体验一下子顺畅了。
这里有个我整理的“资源优化工具包”，你可以直接拿去用：
| 优化类型 | 推荐工具 | 效果参考 |
|---|---|---|
| 图片压缩 | Squoosh（在线工具）、Sharp（Node.js库） | 平均压缩率40%-60% |
| 代码分割 | Webpack SplitChunks、Vite自动分包 | 首屏JS体积减少50%-80% |
| 字体优化 | Font Squirrel（子集化工具） | 字体文件缩小80%以上 |
从渲染到交互：让用户“感知”到的性能提升
光让页面“加载快”还不够，得让用户“觉得快”——这才是性能优化的终极目标。你想啊，用户打开页面，就算加载完成了，如果按钮点了没反应，或者滑动时卡顿，照样会觉得“这网站不行”。
先说说浏览器怎么渲染页面吧，这决定了用户什么时候能看到内容、什么时候能操作。浏览器拿到HTML后，要经过“解析HTML→构建DOM树→解析CSS→构建CSSOM树→合并成渲染树→布局→绘制”这一串步骤，任何一步卡住，用户就会觉得慢。我把这个过程叫做“关键渲染路径”，优化的核心就是“让关键路径跑快点”。
最直接的办法是“优先加载关键资源”。比如首页的logo、导航栏、首屏文字，这些是用户第一眼就要看的，应该让浏览器先处理。怎么做呢？可以把首屏CSS直接嵌在HTML的标签里（内联CSS），别让浏览器再发一次请求去加载外部CSS；JS文件如果不是首屏必须的，就用async或defer属性让它“后台加载”，别阻塞HTML解析。我之前帮一个新闻网站做优化时，把首屏CSS从外部文件改成内联，LCP（最大内容绘制，谷歌用来衡量加载体验的核心指标）直接从4.2秒降到2.1秒，达到了谷歌推荐的“优秀”标准（2.5秒以内）。
交互响应速度也很关键。你有没有遇到过点击按钮后，页面“卡一下”才反应？这背后可能是JS执行时间太长了。比如有个项目的搜索框，每次输入都要执行500多行代码的过滤逻辑，结果打字时字符“跟不上手速”。后来我用了“防抖（Debounce）”——等用户停止输入300毫秒后再执行过滤，同时把复杂计算拆成小任务，用requestIdleCallback让浏览器在空闲时处理，既保证了响应快，又不卡顿。
这里有个容易踩的坑：别为了“数据好看”牺牲用户体验。之前见过一个团队为了追求“加载速度第一”，把所有动画和交互反馈都删了，结果页面虽然加载快，但用户操作时完全没“感觉”，转化率反而掉了。其实性能和体验完全可以兼顾，比如用“骨架屏”代替白屏——用户打开页面时，先显示灰色的占位框，等数据加载完再替换内容，既让用户知道“页面在加载”，又比白屏显得快。我帮一个社区论坛做优化时，就用了这个方法，用户抱怨“加载慢”的反馈直接少了60%。
最后分享个检查工具：谷歌的Lighthouse（现在Chrome开发者工具里直接有），它会从性能、可访问性、最佳实践等方面给页面打分，还会告诉你具体哪里有问题，比如“这张图片可以压缩”“这个JS文件执行时间太长”。每次优化完跑一遍，分数涨了，效果就出来了。你也可以试试MDN的性能优化指南（https://developer.mozilla.org/zh-CN/docs/Web/Performance），里面有更详细的原理和案例。
其实前端性能优化就像“给房间收拾整理”，不是一次性的大工程，而是日常开发中多注意细节：写代码时想想“这个库真的需要吗”，上传图片时记得“压缩一下”，测试时用手机真实网络跑跑看。你按这些方法试了之后，会发现用户不仅抱怨少了，甚至会说“你们网站怎么变快了？用着真舒服”——这种反馈，比任何数据都让人开心。如果试了有效果，或者遇到什么问题，欢迎回来跟我聊聊，咱们一起把性能优化这件事做得更简单~
你可能会担心：换了WebP或AVIF格式，万一用户用的旧浏览器不支持，图片显示不出来怎么办？其实现在主流浏览器早就跟上了——Chrome、Firefox、Edge这些不用说，连苹果的Safari从14.1版本开始也支持WebP了，AVIF稍微新一点，Chrome 85+、Firefox 93+、Edge 85+都能正常显示。你想想，现在大家手机电脑换得勤，还在用IE或者老版Safari的用户已经很少了，我去年统计过几个项目的用户数据，旧浏览器占比基本都在3%以下，而且还在慢慢减少。
不过稳妥起见，给旧浏览器留个“退路”很简单，用标签就能搞定。你可以这么写：先在里面放一个标签，指定WebP或AVIF格式的图片地址，再放一个普通的标签，里面写JPG或PNG格式的地址。浏览器加载的时候，会先看自己支不支持里的格式，支持就用那个，不支持就自动用
里的JPG/PNG，完全不用你操心判断。我之前帮一个政府网站做优化，他们有部分用户还在用旧系统，就用了这个方法，既让97%的用户享受到了WebP的速度，剩下3%的旧浏览器用户也没反馈过图片显示问题，特别省心。
WebP和AVIF格式的图片兼容性如何？需要担心旧浏览器无法显示吗？
目前主流浏览器（Chrome、Firefox、Edge、Safari 14.1+）均已支持WebP格式，AVIF则在Chrome 85+、Firefox 93+、Edge 85+中支持。对于旧浏览器（如IE或早期Safari），可通过标签提供降级方案：先指定WebP/AVIF格式图片，再用标签添加JPG/PNG作为备用，浏览器会自动选择支持的格式加载，既保证新浏览器享受性能优势，又不影响旧设备访问。
如何给网站图片添加懒加载？需要复杂的代码吗？
实现懒加载其实很简单，现在有两种主流方案：一是原生懒加载，直接给标签添加
loading="lazy"属性（Chrome 77+、Firefox 75+支持），无需额外JS；二是兼容性方案，使用Intersection Observer API监听图片是否进入视口，再动态设置src属性。比如用几行JS代码：const observer = new IntersectionObserver((entries) => { entries.forEach(entry => { if (entry.isIntersecting) { entry.target.src = entry.target.dataset.src; observer.unobserve(entry.target); } }); });，给非首屏图片添加data-src存储真实地址即可，新手也能快速上手。
预加载和懒加载有什么区别？什么时候该用预加载？
预加载和懒加载的核心区别在于「加载时机」：懒加载是「延迟加载非关键资源」（如用户暂时看不到的图片），减少初始加载压力；预加载则是「提前加载 可能需要的资源」（如下一页图片、用户可能点击的按钮图标），避免用户操作时等待。比如电商首页轮播图，首屏图用正常加载，第二张图用预加载（利用首屏图加载的间隙偷偷下载），后面的图用懒加载（等用户滑动时再加载），既能保证首屏速度，又让切换时更流畅。
怎么判断前端性能优化是否有效果？有哪些关键指标需要关注？
可以通过工具和用户体验指标来验证效果。工具方面，Chrome开发者工具的Lighthouse可生成性能评分（0-100分），并指出具体优化点；WebPageTest能模拟不同网络环境（如3G、4G）的加载情况。关键指标推荐关注Core Web Vitals（谷歌核心网页指标）：LCP（最大内容绘制，衡量加载速度，目标≤2.5秒）、FID（首次输入延迟，衡量交互响应，目标≤100毫秒）、CLS（累积布局偏移，衡量视觉稳定性，目标≤0.1）。优化后对比这些指标的变化，就能直观判断效果——比如LCP从4秒降到2秒，说明加载体验显著提升。
