企业官网建设流程全解析

1. 原理拆解：先搞清楚浏览器是怎么加载页面的

做性能优化这么多年，我最大的感受是：很多人一上来就抄工具、上插件、加各种配置，却连“一个script标签放在哪里最合适”背后的原理都说不清楚。异步加载这个词在面试题里几乎被说烂了，但真正理解它为什么能提速、什么时候会失效、有哪些坑的人，其实不多。

先说个最基本的背景：浏览器加载一个页面，不是把HTML拿回来就完事了，而是一条流水线。网络进程先下载HTML文档，解析器边下载边解析HTML，遇到CSS就构建CSSOM，遇到JavaScript就暂停解析、去下载并执行脚本。执行完了，解析器才能继续往下走，继续构建DOM树。DOM和CSSOM合成渲染树，最后经过Layout、Paint、Composite，用户才能看到画面。

这里面最关键的一个概念就是渲染阻塞（Render-blocking）。CSS会阻塞渲染，因为在CSSOM构建完之前，浏览器没法计算节点布局，画出来的页面是残缺的。而普通的外链JavaScript更严重，它不光阻塞解析，还阻塞渲染，因为浏览器不知道脚本里会不会用document.write去修改DOM。阻塞期间，渲染进程的主线程是被占着的，页面一片空白，用户面前只有白屏。

这就解释了为什么传统做法把CSS放<head>、把JS放<body>底部——是为了让HTML先解析完，最后再执行脚本。但“放底部”只是最原始的方案，它依然是一条同步链：脚本必须一个个按顺序下载、按顺序执行，中间任何一个脚本慢，都会拖慢整个页面从加载到可交互的时间。

异步加载要解决的，就是这整条同步链的问题。它不是简单地把标签挪个位置，而是从加载时机、执行时机、资源优先级三个维度去重构资源的加载策略。核心目标很清楚：首屏关键路径上的东西优先且尽快完成，非关键路径上的东西往后靠、并发拉、不阻塞。

在聊具体方案前，先估一下页面的性能基线。通常我会先用Lighthouse或者Performance面板跑一遍原始数据，记录这么几个值：

如果TBT偏高，主线程上往往挂着一堆同步脚本；如果LCP偏高，首屏关键资源可能没被提前加载；如果FCP和LCP差值过大，说明CSS或者首屏图片成了瓶颈。后面所有优化动作，都是围绕这些指标展开的。下面就把异步加载的各种技术逐个拆开讲。

2. 三种异步加载脚本的正统姿势：async、defer与动态注入

2.1 defer与async：看似兄弟，行为天差地远

HTML里给script标签加defer或者async属性，都能让浏览器在后台异步下载脚本文件，不阻塞HTML解析。但两个属性在“何时执行”上有着本质区别。

defer的意思是“延迟执行”：脚本下载不阻塞解析，但执行必须等到整个文档解析完之后。更重要的是，所有defer脚本会按它们在文档里出现的顺序依次执行。这一点很关键，假如A脚本依赖B脚本，写成<script defer src="B.js">放在前面、<script defer src="A.js">放在后面，执行顺序就是B先、A后，依赖关系不会乱。

async的意思是“异步执行”：脚本一旦下载完，就立刻执行，执行时照样阻塞解析。多个async脚本的执行顺序完全由下载完成时间决定，谁先到谁先跑，跟标签书写顺序无关。所以async脚本之间不能有依赖关系。

从性能角度说，defer更适合那些需要在DOM就绪之后运行的业务逻辑，比如操作DOM的初始化代码；async则适合独立脚本，比如数据统计、广告SDK、埋点这类谁都不依赖、也不依赖谁的外部脚本。用错场景会出问题：把有依赖关系的脚本标成async，很容易出现“XX is not defined”的报错，排查起来非常恼火。

2.2 动态创建script标签：最灵活的异步注入方式

还有一种非常经典的方式，就是用JavaScript动态创建script标签再插入页面：

function loadScript(url, callback) { const script = document.createElement('script'); script.src = url; script.onload = () => callback && callback(url, 'loaded'); script.onerror = () => callback && callback(url, 'error'); document.head.appendChild(script); }

动态创建的script标签默认就是异步加载的，不会阻塞HTML解析。这种方式最大的价值在于**“按需注入”**：用户触发某个交互时才加载对应逻辑的脚本，比如点击“查看全部订单”时才去拉取订单列表组件代码。这比在HTML里写死一堆script标签要可控得多，因为它把“加载什么”和“什么时候加载”的决定权完全交给了运行时的代码逻辑。

不过动态注入有个隐藏问题：如果同一页面多个模块都在动态加载同一份脚本，可能出现重复请求。所以实操中一般要维护一个加载状态表，已经存在或者正在加载的脚本不要重复注入：

const scriptCache = new Map(); function loadScript(url) { return new Promise((resolve, reject) => { if (scriptCache.has(url)) { scriptCache.get(url).then(resolve, reject); return; } const promise = new Promise((res, rej) => { const script = document.createElement('script'); script.src = url; script.onload = () => res(url); script.onerror = err => rej(err); document.head.appendChild(script); }); scriptCache.set(url, promise); return promise; }); }

2.3 模块化时代的主角：动态import()

ES Module的出现让异步加载有了更高级的形态。import()函数可以在运行时动态加载一个模块，返回值是一个Promise，天然支持按需加载和代码分割。

async function openEditor() { const { default: Editor } = await import('./components/Editor.js'); const app = new Editor(document.getElementById('editor-root')); app.mount(); }

import()和前面几种方式的根本区别在于，它是ES语法层面的标准能力，而不仅仅是DOM操作。它配合打包器（Webpack、Vite、Rollup）使用时，打包器会自动把动态import的模块单独拆成一个chunk文件，浏览器在运行时才去请求这个chunk。这样首屏入口文件体积可以大幅缩小，加载完主框架代码即可渲染页面主体，编辑器、图表库、大屏组件这些重模块全部按需拉取。

从性能角度看，动态import()是单页应用路由懒加载的核心实现方案。Vue Router和React Router的懒加载路由，底层都是借助动态import把路由组件拆成独立chunk。

3. 渲染层面绕不开的异步优化手段

3.1 图片懒加载的三种姿势

图片是页面里最普遍也最容易拖垮性能的资源。一张全屏banner如果是2MB的PNG，首屏加载时间直接被拉高几秒。图片懒加载的核心逻辑是：视口内的图片立即加载，视口外的图片等到即将滚入视口时再加载。

最原始的方案是监听scroll事件，用getBoundingClientRect()判断图片是否进入视口再替换src。这种方案性能不稳定，scroll事件触发频率极高，即使做了节流也容易产生主线程压力。后来出现了Interp Observer，可以在浏览器空闲期间异步观察元素可见性，性能好很多：

const observer = new IntersectionObserver((entries) => { for (const entry of entries) { if (entry.isIntersecting) { const img = entry.target; img.src = img.dataset.src; observer.unobserve(img); } } }, { rootMargin: '100px 0px', // 提前100px开始加载 }); document.querySelectorAll('img[data-src]').forEach(img => observer.observe(img));

不过现在浏览器层面已经提供了原生方案：loading="lazy"属性。直接加在img标签上，浏览器原生处理懒加载逻辑，零JavaScript开销：

<img src="real-image.jpg" loading="lazy" alt="描述" />

需要说明的是，原生懒加载有自己的判定策略，不同浏览器阈值略有差异，在复杂场景下不一定精准。比如轮播图里隐藏的非当前帧图片，用原生懒加载有时会出现预加载不足的问题。我自己常用的做法是：静态图片优先用原生loading="lazy"，动态插入的、行为复杂的图片用IntersectionObserver方案，两者结合。

3.2 资源预加载：preload、prefetch与preconnect

异步加载不只是“把加载延后”，也包括“把加载提前”。很多人忽略了这四个link标签的差异：

preload是当前页面关键资源的优先通道。举个例子，如果你用自定义字体，而字体文件加载太慢，文字可能一直显示为系统默认字体或者干脆隐形，导致CLS抖动。在head里加上：

<link rel="preload" href="/fonts/inter-var.woff2" as="font" type="font/woff2" crossorigin>

这样字体文件的下载就能提前启动。但preload有个要注意的点：一旦指定了preload，浏览器会强制下载对应资源，即使页面没用到。下载完的资源如果没在关键路径上被消费，反而浪费带宽。所以preload只适合当前页面确定会用的资源。

prefetch则是为了“前瞻”加载。用户有可能点击的下一个页面的JS chunk、图片组，都可以在浏览器空闲时提前下载。真正的风险在于：如果prefetch的资源在服务器上更新频繁，被预取的可能是过期缓存。另外，移动端网络环境差时，大量prefetch会白烧用户流量，必须收敛使用场景。

3.3 异步执行长任务：把主线程让出来

还有一个经常被忽略的思路：就算某个脚本要执行，能否不一次性占用主线程太久？

浏览器有一个API叫requestIdleCallback，可以在浏览器空闲期执行低优先级的回调。场景很典型：埋点数据的批量上报、日志聚合、页面无关紧要的DOM增强逻辑。这些任务如果挤在主线程忙时执行，会阻塞用户交互。

if ('requestIdleCallback' in window) { requestIdleCallback(() => { // 批量上报埋点数据 flushAnalytics(); }, { timeout: 2000 }); }

另一种更精细的做法是把同步长任务拆成多个小任务，用scheduler.postTask（目前Chrome已支持）或scheduler.yield让出主线程。页面里有重型图表库渲染、大列表渲染时，一帧时间（约16.7ms）如果被一个超过50ms的任务塞满，用户滑动页面就会感到卡顿。拆任务的标准做法是优先用requestIdleCallback拿空闲时间，再退化回requestAnimationFrame的分帧处理。

4. 性能优化落地实战：一次完整的首屏优化记录

4.1 搭建性能基线：从Lighthouse到Performance

前面讲了这么多原理，现在以一个新的H5活动页为例，完整跑一遍优化流程。这个页面的结构：顶部banner图、一个首屏产品渲染列表、底部有地图组件和用户评论模块，依赖主包里的三个业务chunk，HTML引用了全量的业务JS和公共库JS，图片全部直接给真实地址。

拿到手先跑Lighthouse，移动端模拟场景。最终分数是39分，其中Performance 39，LCP 6.7s，TBT 520ms，CLS 0.23。从Network面板能直观看到问题：首页一次性加载了主包2.4MB，三个业务chunk一共1.56MB，一张2.3MB的全屏banner图，还有字体文件没设preload导致字体在3.2秒后才到达。

很明显这是一个典型的“全量加载、无分级、无异步”页面。下面按优先级逐项拆解。

4.2 打包层优化：从2.4MB压到首屏只加载800KB

第一步操作不是改HTML标签，而是改打包配置。项目用的是Webpack 5，把单个入口文件拆开。

首先是路由级代码分割。页面有“首页商品、地图详情、用户评论”三个模块，但用户进入页面时只需要看见首页商品。改成Vue Router的懒加载写法：

const routes = [ { path: '/', component: () => import('./views/Home.vue') }, { path: '/map', component: () => import('./views/Map.vue') }, { path: '/comments', component: () => import('./views/Comments.vue') }, ];

这一步让Map和Comments两个视图从首屏bundle里剥离出去，打包产物出现三个独立chunk：Home约800KB，Map约560KB，Comments约430KB。

接着处理公共依赖。项目里用了ECharts绘制地图，体积很大，不是首屏必要资源。用SplitChunksPlugin把ECharts单独拆出来，并且在Map组件内部用动态import加载：

async function loadMapModule() { const echarts = await import('echarts'); const { createMap } = await import('./map.js'); createMap(echarts); }

公共依赖被拆出去之后，首屏bundle进一步压缩到520KB。再加上gzip之后，首屏加载体积从原来的2.4MB降到285KB左右。

4.3 HTML层优化：script放置、async标记与preload

打包拆完之后，接着改页面HTML的资源加载策略。这一步是针对运行时加载链的微操。

先看原来HTML的结构：所有script标签都放在<body>底部，但存在两个问题：一是公共库脚本（比如Vue运行时、axios）没有加async或defer，属于同步加载，阻塞解析；二是业务脚本之间有耦合关系，不能随便标async。

仔细分析后确认：Vue运行时、ElementPlus这类UI库和基础工具库之间没有依赖关系，可以标async。业务代码内部的主逻辑放到一个入口脚本里，保留同步特性在DOM解析完后再执行，用defer保证顺序。

优化后的头部结构是这样：

<link rel="preload" href="/js/vendor.dll.js" as="script"> <link rel="preload" href="/fonts/iconfont.woff2" as="font" type="font/woff2" crossorigin> <link rel="preconnect" href="https://api.example.com">

body底部的脚本则拆成了：

<script src="/js/vendor.dll.js" async></script> <script src="/js/main-entry.js" defer></script> <script> // 内联的三段式关键脚本：预加载数据请求提前到脚本执行前 </script>

这里有个很关键的细节：如果把内联脚本的请求时机提前到HTML解析阶段，用fetch直接请求接口数据，再在defer脚本执行时复用这份数据，首屏数据的TTFB到渲染时间能省下大几百毫秒。我在页面里写了一个内联的关键请求模块：

<script> window.__PRELOAD_DATA__ = null; fetch('/api/main/products') .then(res => res.json()) .then(data => { window.__PRELOAD_DATA__ = data; }) .catch(() => {}); </script>

主入口脚本执行时检查window.__PRELOAD_DATA__，有数据就直接渲染，没有数据再走正常的fetch流程。这种方式把数据请求和脚本执行并行起来，整体首屏时间减少非常明显。

4.4 图片与字体专项：懒加载能省一半请求

H5页面的banner图是2.3MB的原始位图。处理方式分两步：第一步在CDN侧生成多尺寸裁剪版本，按设备宽度输出对应的WebP格式；第二步在图片标签上增加懒加载策略。面向当前用户的机制效果，落地到HTML时不是简单全部加loading="lazy"，因为首屏banner属于LCP候选元素，加懒加载反而会拖延首屏绘制。

正确的做法是：首屏banner用fetchpriority="high"，配合preload提前拉取；首屏以下的图片加loading="lazy"，并统一加上CSS占位尺寸防抖。这块的优化下来，首屏图片总体请求数从14个降到6个，全部视口外图片都延迟加载，过了首屏区域才按需请求。

字体方面，页面用的是iconfont字体文件，因为不是关键路径，原本3.2秒才到达导致图标闪烁。加入preload之后，字体文件被提到CSS加载阶段并行拉取，图标闪烁问题直接消失了。

4.5 第二轮验证：核心指标对照

所有改造完成后，重新跑Lighthouse，同时用Performance面板录了一段真实滚动过程。结果：

从Network时间线看，关键路径上的资源基本都在1.5秒以内到达并解析完，主线程空闲时间明显增长，页面滚动流畅很多。可能有人问为什么没有直接到100分，因为页面里还保留了第三方统计脚本的同步加载——这是一个刻意保留的取舍，统计脚本可靠性高于性能收益，标注async容易导致上报丢失。这种有选择的折中在真实项目里比追求满分更重要。

5. 性能排查实战：七类高频问题与解决实录

5.1 async脚本依赖关系的连锁报错

最常见也最恶心的就是“Uncaught ReferenceError: xxx is not defined”。这类问题的根源十有八九是给有依赖关系的脚本加上了async。排查方法很简单：在控制台Sources面板找到抛错脚本的加载时间点，看它是否依赖另一个脚本的全局变量。如果是，把多个脚本整体合并成一个入口，或者改用defer保证顺序。

5.2 preload字体但没有crossorigin，导致字体加载两次

preload第三方字体时，如果请求是跨域的，必须在link标签上加crossorigin属性，否则preload发起的请求和CSS中请求字体的请求模式不一致，会被看作两个不同请求，浏览器会下载两次字体文件。这也是字体要命的CLS恶化的原因。

5.3 动态import的chunk优先级太低，被晚加载了

打包器默认给动态import的chunk不高优先级，页面切到地图选项卡时，地图chunk可能要300ms才能下载完，感官上很卡。解决办法是在页面空闲时预加载这个chunk：

const preloadMap = requestIdleCallback(() => { import('./views/Map.vue'); }, { timeout: 3000 });

这样用户真正点击地图时chunk往往已经缓存在本地了，切换几乎是瞬时的。这个技巧在单页应用里非常实用。

5.4 图片懒加载导致滚动时大量图片同时请求

如果rootMargin设得太大，或者图片离视口很近才触发，瞬间会发出大量请求，造成网络拥塞。软纤优化方案是配合loading="eager"的少量图片与其余用lazy，或者在IntersectionObserver回调里按优先级分组处理，不要一次性把所有接近视口的图片都换成真实地址。

5.5 requestIdleCallback的回调长期不执行

在用户一直在交互、主线程一直忙碌的运行场景里，requestIdleCallback给出的空闲时间非常有限，甚至长时间不触发回调。解决方法是设置timeout参数强制超时执行，或者用setTimeout模拟兜底。如果是页面加载初期的非关键任务，可以直接交给requestAnimationFrame先做，避免无限等待。

5.6 预加载资源下载了没用，浪费用户流量

preload误配置会让移动端用户多下载不必要的资源。排查方式：打开Network面板，过滤请求类型为preload，逐一确认这些资源是否被实际选中。有些时候是因为as字段写错了，preload解析器把它当成另一类资源下载，页面却按另一类来请求，导致双份流量。

5.7 数据请求慢拖累首屏

接口慢造成的性能问题不是靠前端异步标签能解决的，但可以通过“提前请求”和“数据缓存”两条路绕过去。上面提过的内联脚本提前请求就是其一。另一个是给数据接口加HTTP缓存，比如活动页的静态商品列表可以短缓存10分钟，这样二次进入页面可以直接用本地缓存渲染。

6. 一套可以直接上手的异步加载策略模板

6.1 通用决策流程

做任何页面的异步加载优化之前，先按这套流程过一遍：

1. 列出页面首屏真正需要渲染出的核心块，对应的资源叫做关键资源。
2. 把关键资源的script和style放在head中，使用preload优先加载。
3. 非关键的业务脚本一律延迟加载，用defer或放到body底部。
4. 独立无依赖的第三方SDK，能标async就标async。
5. 首屏以下图片全部懒加载，首屏LCP图片用fetchpriority=high。
6. 路由级组件全部动态import，再配合requestIdleCallback预取下一个路由的chunk。
7. 字体文件必须preload且加crossorigin，防止双重下载和FOUT。
8. 接口请求提前到HTML解析阶段并行发起。

6.2 不同场景下的参数调节

异步加载不是一套配置走天下。我整理了几个主要场景的推荐参数，供参考：

6.3 快速验证清单

优化提交之前，过一遍这份清单：

• Performance面板没有红色长任务，主线程长任务少于5个
• Network面板首屏关键资源请求时间线在LCP前完成
• 所有script标签要么有defer，要么有async，要么在body最底部
• 图片全部有宽高或aspect-ratio占位，CLS为0
• 动态import的chunk在gzip后小于200KB
• 字体preload且带crossorigin
• 无重复下载的资源

这套模板我在多种业务线验证过，通常能把首屏时间削减40%到60%。不过要记住，任何指标都只是参考，最终级的判断标准是用户在产品里的真实体验——减少卡顿、等待和白屏，才是性能优化始终要回归的本源。