Web 加速器： Loder v1.0 发布 🎉

[yesvods]

Loder是一个轻量级加载器，通过合理地声明资源任务依赖关系，以最高效形式执行 Web 加载，提供强大的性能追踪，持续优化性能瓶颈。

目前线性粗放式的 Web 资源加载模式，尤其在条件有限的移动端，很大程度限制了页面加载体验。费很大劲把脚本体积降下来，却得到极其有限的性能收益。使用微核启动器 Loder，快速启动应用，利用在Bundle加载执行同时，展示 Loading 交互、发起鉴权、初始数据请求等，最大化利用设备能力提高页面渲染性能。

Loder 具备以下特性：

• Dead Simple API
• 声明式依赖，极简的资源任务管理
• 极致加载，所有资源任务都以最适合时刻加载
• 轻量体积(1.4kb Gziped), 极速启动应用
• 几乎无需修改逻辑，简单几步即可加速应用至极致！

应用示例

举个栗子，应用会在运行前先把所需脚本准备妥当，之后会顺序执行鉴权、授权、获取数据、渲染。大多数的 Web 都会通过类似的模式去加载渲染。流程大致如下：

看似一种很直观的方式却很粗放，性能优化非常考验我们对资源任务加载的业务逻辑、依赖、顺序的理解，精细化运营这些过程，Web 性能可以得到意想不到地提升。我们可以大致整理一下应用的资源任务加载过程：

• 应用启动

  • 依赖[ "首屏数据", "应用鉴权", "应用 Bundle 加载&执行"]
  • 启动应用

• 应用鉴权

  • 依赖[ "加载鉴权 SDK", "获得用户 ID" ]
  • 发起鉴权请求

• 首屏数据

  • 依赖[ "请求客户端 axios" ]
  • 发起多个请求

可以看到，有一部分资源任务是可以正交进行的，这就是我们充分利用浏览器特性提高性能的关键。但是，如此繁琐的加载，维护起来并不容易。Loder 提供极简的 API，通过声明式注册资源和任务，即能以最优形式进行 Web 加载，以上述应用启动流程来举例：

启动应用前鉴权

// 资源注册 —— 鉴权 SDK
loder.add('authSDK', loder.loadScript('//sample.com/sdk.js'))

// 任务注册 —— 获取用户 id
loder.add(
  'userId',
  () =>
    new Promise(resolve => {
      resolve('id')
    })
)

// 任务注册 —— 鉴权
loder.task(
  'auth', ['authSDK', 'userId'],
  () => new Promise(resolve => {
    // do auth
    resolve('success')
  })
)

加载首屏数据

// 资源注册 —— 请求客户端
loder.add('axios', () => import('axios'))

// 资源注册 —— 首屏数据
loder.task(
  'fpData', ['axios'],
  () => new Promise(resolve => {
    const axios = loder.get('axios')
    return axios('//sample.com/userData.json')
  })
)

启动应用

// 资源注册 —— JS Bundle
loder.add('createAppFn', () => import('./createAppFn'))

// 任务声明 —— 应用启动
loder.task('bootstrap', ['auth', 'fpData'])

// 一切就绪，执行加载
loder.run('bootstrap', async () => {
  const create = await loder.echo('createAppFn')
  create("Awesome Time")
})

通过非常的简单声明，Loder不仅仅将PageLoaded性能提升至极致，甚至可以利用首屏数据请求期间，去加载应用所需的资源脚本，以及花费大量时间执行的Bundle。

Loder vs SSR

除了高效加载、极简 API、无业务入侵性外，Loder作为一个客户端加载器，具备更多天然的优势：

| 特性\方案 | Loder | SSR | | ------------ | -------------------------- | --------------------------------- | | Server 支持 | 不需要 | 需要维护额外 SSR 服务器 | | Server 压力 | 低，正常使用 CDN 方案 | 高，每次请求需 Server 支持 | | Client | 无需改动业务逻辑 | client-ssr 两套版本 | | 通用性 | 任何支持 JS 浏览器 | 简单页面，如客户端鉴权情况不支持 | | 首屏渲染时间 | 快，无需浪费接口请求时间 | 极快，一次请求可获取首屏内容 | | 页面空白时间 | 快速启动，极大减少空白时间 | 大数据查询接口，空白时间较长 | | 可交互时长 | 短，脚本加载完成即可交互 | 中，ssr 后依旧需要完全加载 bundle |

最后

Loder 作为一个 Web 极致性能加载器，驱动 Web 高效加载渲染，通过性能跟踪辅助发现&优化性能瓶颈，也促使我们去思考如何组织 Web 的加载时序。

Links

Github: https://github.com/yesvods/loder

Landing page: http://loder-docs.scoii.com

[xomix]

😭………………前端都需要加载器了吗……………………

[azh7138m]

if 换行没有花括号，拒绝

[oott123]

唔，没看出来和 amd 有啥区别呢？

[Lxxyx]

用全家桶一般是因为 TCP 连接的开销，要比单独下某个小文件要大。

而且实际场景中，一般都会分成两部分来，一部分是首屏资源的加载，要求越快越好，一般放置在 head 标签里，另一部分则是全家桶的 bundle。

说实话没有看出楼主这个方案的具体优势在哪儿

[bertonzh]

我也没看出来和 amd 有什么区别。
BTW，既然都用了 Dynamic import, 还搞这么繁琐的东西不是闲的么？

```
const onlyone = fn => {
let promise
return () => {
promise = promise || fn()
return promise
}
}

const authSDK$ = onlyone(() => loadScript('sdk.js')) // loadScript need implement
const userId$ = onlyone(() => Promise.resolve(1))
const auth$ = onlyone(async () => {
await Promise.all([userId$(), authSDK$()])
return 'success'
})

const axios$ = onlyone(() => import('axios'))
const fpData$ = onlyone(async () => {
const [axios] = await Promise.all([auth$()])
return axios('//sample.com/userData.json')
})
```

[yesvods]

@bertonzh AMD 方式很明显需要手动管理流程的执行顺序，一旦流程复杂了声明的依赖关系也并非直观，看到还依赖了 asycn await 的语法来保证执行顺序，一来额外开销，二来依旧是以同步思维去管理流程。

另外一个点是数据获取，在加载过程中拿到的数据，需要在实际业务上使用，通过 Loder.echo('data')可以很方便拿到对应的数据。

Loder 让加载过程更加清晰可维护，使用阶段更加便利，而且能持续跟踪每一个流程的性能情况，这个用其他方式来实现亦可，只不过 Loder 目标是让加载更加高效简单，让优化变得不再困难。

[yesvods]

@Lxxyx 全家桶的确是有必要性，可以关注一下全家桶逐渐变大时候，更多影响前端性能的是 Invoke 的过程，Loder 会充分利用这个时间消耗过程，与此同时发起数据请求，使得页面缩短渲染时间。