GFPGAN本地部署实战：Python批量修复人脸图像与视频
2026/10/1 3:07:04
你在DevTools里打开Network面板，一条条请求像流水一样往下刷，但页面就是卡在白屏上好一会儿；脚本明明只有几十KB，却让首屏等了将近一秒。这种状态我太熟悉了——不是代码逻辑复杂，也不是后端接口慢，而是整个加载链路压根没有做异步加载的设计。异步加载这四个字听起来像是前端进阶课的入门概念，实际上它是性能优化里最容易被忽略、又收益最明显的一环。这篇文章基于一个原理篇的标题做深度拆解，我会从运行机制讲到可复现的实战改造，最后把我在线上踩过的几个坑一并说透，适合刚接触性能优化的开发者，也适合那些已经做了基础优化但感觉还差点意思的工程师。
1. 异步加载为什么是一道必答题，而不是可选项
很多人把异步加载理解为“把script标签加个defer”，这个理解不能说错，但它把问题看小了。异步加载的本质，是重新分配浏览器在页面生命周期里的“工作时间”——把那些不紧急、不需要同步阻塞的任务，挪到页面真正空闲的时间窗口去执行，让首屏渲染拿到最高的资源优先级。理解这个前提，你才能明白为什么纯堆机器、纯压缩代码解决不了加载慢的问题。
1.1 同步脚本最先犯错的地方
我们先做一个最简单的实验：一个HTML页面，head里放了一个普通script，代码只有三行计数的逻辑。浏览器解析HTML到script标签时，必须停下来，先去下载这个脚本，然后执行它，执行完了才能继续解析后面的DOM。如果这个脚本放在CDN上，它就是一个完整的网络往返。按RTT 80ms算，加上DNS、连接时间，一个几十毫秒就能执行完的脚本，硬生生把页面解析卡掉了100多毫秒。
这个时间看起来不多，但问题在于页面上不止一个脚本。业务代码、统计脚本、聊天组件、IM推送、灰度工具，各自都来一个同步script，累加出来的阻塞时间就是秒级的。更要命的是，这些阻塞发生在DOM解析阶段，浏览器还没开始渲染首帧，用户看到的就是一个白屏，连loading都没有。
我见过最典型的事故，就是运营在页面上临时加了一个大表格插件，直接在模板里用同步script引入，结果线上PV暴跌。后台一查，平均白屏时间从300ms涨到了1.8秒。这就是同步脚本的代价——它让你页面上所有原本很快的东西，全部等它一个。
1.2 从“阻塞”到“空闲窗口”：优化的大前提
要理解异步加载，就得先建立“浏览器空闲窗口”这个概念。浏览器不会像CPU满载的程序那样一刻不停，它在主线程上有大量的空闲间隙——比如当前帧渲染完了、下一帧还没开始，比如微任务队列清空了、事件还没来。这些间隙加起来其实非常可观。
异步加载的核心目标，就是把非关键任务塞进这些间隙，避免它们占用关键的渲染路径。所谓关键渲染路径，简单说就是从拿到HTML到画出一帧画面的最短链路。链路里的每一步都应该服务于首屏内容，任何无关资源的同步等待都是在拖后腿。
所以优化的大前提是：识别哪些资源是首屏必需的，哪些是可以延后的。首屏必需的资源，比如骨架屏样式、首屏数据请求，给最高优先级；非必需的，比如用户交互后才用的组件、页面底部的图片、第三方统计脚本，全部降权，用异步的方式加载。这个思路一旦建立，你再来理解defer、async、动态import、懒加载，就会发现它们只是同一种思想的不同实现工具。
2. 异步加载背后的运行机制，先看这三件套
理解了“为什么做”，再来看“怎么做”背后的原理。这一节我把异步加载相关的底层机制拆成三块：事件循环怎么调度任务、浏览器怎么排资源优先级、代码拆分在模块层面怎么生效。这三块弄明白，你就不需要背API了，任何异步加载方案在你眼里都是同一个逻辑推出来的。
2.1 事件循环与任务队列：为什么setTimeout能推迟但不阻塞
JavaScript是单线程的，这决定了它同一时刻只能做一件事。但浏览器不只有一个线程，它有主线程、网络线程、渲染线程、合成线程等等。异步加载的底层逻辑，本质上是“让网络线程去下载，让主线程先干别的活，等下载完成再把回调塞进任务队列”。
浏览器的事件循环就是一个持续运转的调度器：先从宏任务队列里取一个任务执行，执行完把微任务队列清空，然后判断是否需要渲染，最后回到宏任务队列。setTimeout就是往宏任务队列里塞一个定时任务；Promise.resolve的回调进的是微任务队列；渲染线程会主动请求主线程在合适的时间帧执行绘制。
理解了这一点，你就知道为什么async和defer会有区别。async脚本下载完成后立刻执行，不保证执行顺序，谁先下载完谁先执行；defer脚本会等整个文档解析完成后再按顺序执行。前者适合完全独立的第三方脚本，后者适合依赖DOM结构或者相互有顺序要求的脚本。
我在优化的时候经常会问自己一个问题：这个脚本能不能放宏任务的末尾执行？如果可以，它就是可延后的；如果需要等一个数据请求完成后再处理，那它就是异步回调驱动的。这个判断比背API有效得多。
2.2 网络优先级体系：浏览器自己怎么排兵布阵
浏览器下载资源不是一碗水端平的，它有自己的优先级规则。HTML请求是Highest，同步脚本、首屏CSS一般是High，异步脚本、图片通常是Low或者Idle。但优先级并不是你显式指定的，它由浏览器根据资源类型和依赖关系自动推断。
手动干预优先级的手段主要是preload和prefetch。preload是告诉浏览器“这个资源很重要，提前下载”，它会把资源标记为High优先级，并且提前发起请求，但它不阻断解析；prefetch是告诉浏览器“这个资源以后可能用得到，趁空闲下载”，优先级通常是Idle，而且可能被浏览器取消。
我用preload最多的场景是首屏字体。字体文件如果等CSS解析到@font-face才去下载，首屏文字会先显示fallback字体，然后字体加载完再闪一下，体验很差。用preload提前拉取字体，可以把这段等待时间从渲染路径里去掉。但preload要节制，每个页面控制在3个以内，否则所有资源都在抢带宽，反而拖慢真正的关键资源，这个我后面会在坑位里专门展开。
关键的排序逻辑可以简单记成：关键资源优先下载、非关键资源延后下载、以后可能会用的资源空闲时下载。浏览器这么做，本质上也是一种“异步加载”——它在并行度有限的前提下，把下载任务按时间轴重新配置了。
2.3 代码拆分的微观基础：模块与依赖树的关联
浏览器端异步加载在代码层面的实现主要靠动态import()。它的原理和defer完全不同：defer只是延迟一个已经下载的脚本的执行，动态import则把下载和执行都推迟到运行时。
一个使用ES Module的项目，在构建时会生成一张依赖图，打包器（Vite用的Rollup、Webpack）会根据静态import关系把模块打包进多个chunk。当代码里写了await import('./xxx')，这个模块就成了一个独立的chunk，入口代码运行时才会拉取它。这就是代码拆分的微观基础：你可以按路径拆分、按组件拆分、按业务模块拆分，但本质上都是“把依赖树中的一个子树摘出来，延迟它的加载时机”。
开发者工具里看DevTools的Network，你会发现加载一个路由页面时，只有首屏的chunk被下载了，其他路由对应的chunk要等用户点击跳转才发起请求。这种即用即拉的策略，直接把“全量下载所有代码”的负担消解成了“按需下载”。原理并不复杂，但足够解决大部分中后台应用“初始包太大”的问题。
3. 可复现的实战：一步步改造一个“卡顿”页面
前面讲原理，这一节直接上案例。我造了一个典型的“性能任性”页面，功能很简单：一个首屏标题、一张大图、一个按钮，点击按钮渲染一个图表。页面初始加载却要2.1秒才能看到标题，交互后还要等1秒才能看到图表。我们按三轮优化一步步把它改到首屏800毫秒以内、点击图表即刻渲染。
3.1 先造一个性能任性的Demo
我用一段伪代码描述这个页面的原始结构：
<!doctype html> <html> <head> <link rel="stylesheet" href="//cdn.example.com/lib-chartjs.css" /> <link rel="stylesheet" href="/styles/main.css" /> <script src="//cdn.example.com/lib-chartjs.js"></script> <script src="//cdn.example.com/lib-moment.js"></script> <script> // 统计脚本 var track = window.track || function(){}; </script> <script src="/js/main.js"></script> </head> <body> <h1 class="hero-title">活动主会场</h1> <img src="/img/hero.png" width="1200" height="600" /> <button id="renderChart">查看数据</button> <div id="chartBox"></div> </body> </html>你可以看到问题所在：Chart.js、Moment.js这些和首屏毫无关系的组件库，全都同步放在head里。浏览器解析到第一个script就开始卡住，下载执行完再继续，等于首屏被迫等待所有组件库完成。而实际用户操作是，先看到标题和大图，点按钮才用图表。这就是典型的“没有按需加载意识”的写法。
3.2 按优先级出手的三轮优化
第一轮优化是给脚本加defer或者async，把非关键脚本全部移出解析路径。
<script defer src="//cdn.example.com/lib-chartjs.js"></script> <script defer src="//cdn.example.com/lib-moment.js"></script> <script defer src="/js/main.js"></script>这样浏览器恢复了解析HTML的速度，DOM很快构建完成，标题和图片可以立即渲染。但这里有个细节：defer脚本会按顺序执行，Chart.js比Moment.js先执行，而Chart.js的老版本依赖Moment.js，所以顺序不能乱。如果换成async，加载快的那边会先执行，极可能报错。我通常的规则是：同一条依赖链上的脚本用defer，完全独立的第三方脚本才用async。
第二轮优化是图片懒加载。首屏里的hero图片确实需要展示，但页面往下滚动时还有一长串活动商品图片，这些完全可以用loading="lazy"推后加载。不过首屏主视觉图千万不要加lazy，否则浏览器会等布局完成后才判断是否可见，反而把LCP时间拖长。正确写法是只给首屏以下的图片加：
<img src="/img/product-1.jpg" loading="lazy" decoding="async" alt="商品1" />第三轮优化是动态import图表库，这是收益最大的一步。把main.js里的Chart.js改为运行时动态加载：
const renderChartBtn = document.getElementById('renderChart'); renderChartBtn.addEventListener('click', async () => { const { renderChart } = await import('./chartRenderer.js'); renderChart(); });这样Chart.js和Moment.js根本不会出现在初始请求里。用户点击按钮，才发起chunk请求，加载完再渲染图表。体验上是“点击后瞬间出图”，而不是“页面加载时等一秒、点击后再等一秒”。
3.3 第二轮：用动态导入处理组件，绕过首屏接口
实际业务里的代码拆分不会像我造的Demo这么简单，我给你一个真实一点的场景：中后台的报表页面，顶部是筛选器，下面十几个图表卡片，每个卡片对应一个配置项，但用户可能只打开其中两三个。
这种情况下，全部图表组件一次性注册完就是浪费。我会把每个图表卡片封装成一个独立的ES模块，路由入口里只注册一个渲染器，卡片容器出现时再去动态import对应的渲染函数：
const card = document.querySelector(`[data-chart-id="${chartId}"]`); if (card) { const { mountCard } = await import(`./cards/${chartId}.js`); mountCard(card, data); }这里还有个容易被忽略的收益：每个独立模块被动态import之后，浏览器会单独缓存它。用户第二次打开同页面时，命中缓存的chunk几乎是秒出，不需要重新下载。配合构建时给chunk设置哈希文件名，缓存策略也能顺手做好。
4. 影响的大小你怎么量？性能指标与实际工具
优化做得再欢，没有量化手段都是自我感动。性能优化是一项必须“先测量、再优化、再回归测量”的工作。这一节说清楚指标怎么选、工具怎么用、数据怎么解读，否则你不知道自己的异步加载到底有没有生效。
4.1 关键指标：FP/FCP/LCP/TTI/TBT
我用表格把几个核心指标说清楚，方便你对号入座：
| 指标 | 全称 | 含义 | 优化的对应手段 |
|---|---|---|---|
| FP | First Paint | 页面第一次绘制像素点 | 减少同步阻塞，让浏览器尽快渲染 |
| FCP | First Contentful Paint | 第一次绘制出文本、图片等内容 | 首屏CSS尽快加载，非关键脚本延后 |
| LCP | Largest Contentful Paint | 最大内容绘制，衡量“主要内容有没有出来” | 首屏图片/标题尽快加载，降低资源抢占 |
| TTI | Time to Interactive | 页面可交互时间 | 减少主线程长任务，延迟加载非必要脚本 |
| TBT | Total Blocking Time | 从FCP到TTI之间所有长任务阻塞总和 | 拆分长任务、异步处理非关键计算 |
异步加载直接影响的其实是FCP和TTI。脚本不阻塞解析了，FCP会明显提前；长任务被拆分延后了，TTI也会改善。不少团队只看一个LCP，其实不够，因为异步加载过度也可能让LCP变差——比如首屏图片被错误地懒加载了，LCP就会恶化，这个坑我在后面详细说。
4.2 实践测量：用Performance面板和Lighthouse做回归对比
实际测量我分两个层级：本地研发用DevTools的Performance面板做细粒度分析，线上环境用Lighthouse或者WebPageTest做回归对比。
Performance面板的使用逻辑是“录一段、看一段”。打开页面，用Ctrl+Shift+E开始录制，页面加载过程会被完整记下来，包括每个任务的执行时间、每个网络请求的优先级和时间线。你要重点看两个地方：一是F12面板底部的Summary，看Scripting和Loading分别占了多少时间；二是Performance里的红色长任务，那是主线程长时间被占用的标记。
Lighthouse则适合做整体评分对比。我习惯在改造前后分别跑一次，记录FCP、LCP、TTI三个数值。注意跑lighthouse时用模拟网络状态，比如Fast 3G或者Slow 4G，这样结果更有参考价值。实测数据是最有说服力的，我常给团队定的一个最低验收线是：优化后FCP比优化前提升30%以上，TTI提升20%以上，同时LCP不得变差。
有一点容易踩坑：DevTools的Network面板里打开“Disable cache”会让懒加载和动态import的缓存命中判断失效，你看到的请求数量会比真实场景多很多。测优化效果时，尽量用无痕窗口，保留缓存，才接近真实用户体验。
5. 我踩过的坑，值得你再踩一遍再去想
异步加载不是不报错的，它在带来性能提升的同时，也会带来一批新的“烫手山芋”。下面三个坑都是我在线上实际踩过、并且反复在团队里讲过的，每个都代表了一类很典型的错误用法。
5.1 延迟加载与首屏内容冲突：LCP不升反降的典型负例
有一次我给一个活动页做了全图懒加载优化，信心满满地上线，结果监控里的LCP从1.2秒涨到了2.5秒。排查了半天，原因是首屏的主视觉图被我加了loading="lazy"。
浏览器处理懒加载图片时，不会立刻发起请求，而是等它自己判断图片进入视口才加载。但这个判断要依赖布局和滚动位置的确定，布局在CSS加载完成后才能稳定，于是图片的请求被推迟到了CSS解析之后，白白多了一段等待时间。
正确做法是：首屏LCP候选元素（大标题、首屏大图）一定不能懒加载，反而可以用fetchpriority="high"告诉浏览器这个资源要优先：
<img src="//cdn.example.com/hero.png" fetchpriority="high" width="1200" height="600" alt="主视觉" />从那次之后我总结了一个原则：懒加载只加给“确定不在首屏”的元素，不确定的宁可不加。判断方法很简单——页面首帧渲染时，这个元素的占位是否存在？如果它是你首屏布局不可分割的一部分，就不要懒加载。
5.2 预加载资源混乱：把钱撒给所有兄弟，结果全军覆没
preload是个好东西，但它的默认行为是“浏览器必须下载”，它会占用网络带宽和连接数。我见过一个页面在head里一口气preload了8个资源：两张首图、三份字体、两个组件chunk、一个接口预请求。结果CDN上这些资源确实都提前下载了，但真正的关键CSS反而排在后面，FCP变得更慢。
preload的正确用法是只加载“首屏渲染真正首先需要的”关键资源，而且最好配合async/fetchpriority使用，同时通过media属性避免在小屏设备上加载无关图片。prefetch则更适合用在“用户很可能下一步会访问”的场景，比如列表页预热详情页的接口，但它优先级很低，只寄希望于浏览器空闲时下载。
5.3 数据流被阻塞：异步JS与后端接口超时争议
前端异步加载有时候会被误用。有一次一个同事跟我抱怨，说用了动态import之后，接口首屏请求反而变慢了。我一看代码，他把首屏数据请求也放进了动态import的模块里，而这个模块要到某个交互事件后才被加载。这不叫异步加载，这叫延迟发请求——它把原本可以在后台进行的数据请求，硬生生拖到交互时才发起。
这里要分清两件事：静态首屏数据请求应该在页面加载第一时间发起，异步加载优化的是“代码执行和模块下载”，不是“数据获取时机”。如果数据和页面的首屏强相关，就用静态import或者在入口处立即发起fetch请求，等代码就绪时数据可能已经从服务器返回了；如果数据只在某个交互后需要，那就可以放进动态import的模块里，顺便把请求也带进去。
这条经验换个说法就是：异步加载不是万能药，它只解决拉取和运行的时序问题，不能替代合理的接口设计。后端接口慢，该做的是缓存、数据分片、接口聚合，而不是前端改两个字就指望性能翻倍。
6. 一次线上事故后的复盘：异步加载还改变了我的代码习惯
前年我们上线过一个大促页面，功能全部做完，性能优化也做了：脚本全defer了，组件按需加载了，图片懒加载了，页面首屏瞬间就出来了，数据也很漂亮。结果大促当天，用户疯狂反馈页面“点了没反应”。
排查发现是因为登录失效的弹窗组件被包装在了动态import里，而动态import需要加载一个新的chunk。用户在大促当天网络拥堵，这个chunk下载超时，导致点击按钮后弹窗一直出不来，整个页面看起来像死掉了一样。
这次事故给我敲了个大警钟：异步加载对网络有更强的依赖性。当一段逻辑被拆成独立的chunk后，它就多了一次网络往返的失败概率。如果这段逻辑是“用户明确操作的反馈”，你就得给它做降级处理：预加载热区chunk、设置超时提示、失败时给友好状态，或者干脆把关键交互所用到的模块预加载到缓存里。
从那以后我调整了自己的编码习惯：能用代码拆分的地方就拆，但凡是涉及用户直接操作的模块，我会额外在合适的时机（比如页面空闲时）把它的chunk提前预热拉到缓存，这样用户真正点击时其实是命中缓存的，不需要现场下载。这个预热动作看起来简单，却把“首屏快”和“交互稳”这两件事平衡得很舒服。
异步加载和性能优化走到这一步，回头看其实就是一套思路：把事情分成紧急和不紧急，把资源分成关键和非关键，把任务分成必须现在执行和可以稍后再做。原理不难，难的是每次都保持这种分配意识。你在下一个项目里，不妨就把这当作唯一的基准：首屏没出现的资源，先问一句“它真的需要现在加载吗”。