拆分初始化负载

第3章拆分初始化负载 Splitting the Initial Payload Ajax 和 DHTML（动态 HTML）的日益普及使如今网页上的 JavaScript 和 CSS 比以往任何时候都多。Web 应用程序变得越来越像桌面应用程序，很大一部分的应用代码不会在启动时被使用。高级的桌面应用程序采用的是插件式架构，允许动态加载模块，许多 Web 2.0 的应用程序也都采用了这种方式，并从中受益。本章将展示一些在启动时过度加载代码的流行的 Web2.0 应用程序，并讨论更加动态地加载页面的方法。 3.1 全部加载（译注 1） Kitchen Sink Facebook（http://www.facebook.com/）有 14 个共 786KB 未压缩的外部脚本（注 1）。即便是 Facebook 的核心前端工程师，想要弄清楚在初始化页面时有多少 JavaScript 是必须加载的也是非常困难的。在这 14 个外部脚本中有一些对页面初始化至关重要，而其他的也包括在内是因为它们对 Ajax 和 DHTML 功能的支持，例如下拉菜单和评论，以及如图 3-1 中所示的一些类似功能。尽可能快速渲染出网页很关键，这样做不仅可吸引用户，而且可以为他们创建良好的响应体验。试想一下，如果把 Facebook 的 JavaScript 分为两个部分：一部分是渲染初始页面必需的，剩下的作为另一部分。与其给用户带来响应停顿的第一印象，倒不如在初始化时只加载必要的 JavaScript，其余的 JavaScript 稍后再加载。译注 1：此处的原文是 Kitchen sink，是俗写 Everything but the kitdner sink 的简写，意思是几乎所有的一切。根据上下文，此处是指页面初始化时全部加载所有的脚本。注 1：当用户登录访问此页面时有 14 个脚本被加载。如果用户没有登录，则只有少数的脚本被使用。 21

图 3-1：Facebook 中 Ajax 和 DHTML 的特性这其中有一些问题：能节省多少时间？如何找到需要拆分的代码？怎样处理竞争状态？如何延迟加载“其余部分”的代码？前 3 个问题在这一章中解决。如何延迟加载“其余部份”的代码是第 4 章的主题。 3.2 通过拆分来节省下载量 Savings from Splitting 事实上，一直到触发 onload 事件时， Facebook 执行的 JavaScript 函数只占全部下载量的 9%。使用 Firebug 的 JavaScript 性能分析器就能统计出直到触发 onload 事件时有多少函数被执行。（注 2）以 onload 事件为统计截止点是因为在此之后所需的功能可以也应该在初始页面渲染完成时开始加载。我称之为在 onload 后加载（post-onload download）（各种不同的延迟。加载技术详见第 4 章。）表 3-1 列举了 10 个美国顶级网站在 onload 事件前下载但并未执行的函数的百分比。平均而注 2：Firebug 是一个优秀的网站开发工具，可见 http://getfirebug.com/。 22 │ 第 3 章：拆分初始化负载

言，在初始化页面期间 75%的函数下载了但并未执行，因此，如果延迟下载这些未执行的函数，初始化时 JavaScript 的下载量将大大减少。诚然，75％的估计值可能有些被夸大，那些未执行的函数可能用于错误处理或某种特殊情况，但足以说明大部分的 JavaScript 是可以延迟下载的。未压缩的 JavaScript 大小平均为 252KB。这个百分比是指函数数量，而不是大小。如果我们假设函数大小一致，那么 75% （平均为 189KB）在 onload 事件之后才被加载，这将使页面的初始化速度大大提高。表 3-1：在 onload 事件触发之前 JavaScript 函数执行情况百分比网站未执行函数的未压缩的 javscript 代百分比码大小 http://www.ao.com 71% 115KB http://www.ebay.com 56% 183KB http://www.facebook.com 91% 786KB http://www.google.com/search?q=flowers 56% 15KB http://search.live.com/results.aspx?q=flowers 75% 17KB http://www.msn.com 69% 131KB http://www.myspace.com 87% 297KB http://en.wikipedia.org/wiki/Flowers 79% 114KB http://www.yahoo.com 88% 321KB http://www.youtube.com 84% 240KB 3.3 寻找拆分 Finding the Split Firebug 的 JavaScript 性能分析器能显示出在触发 onload 事件之前所有已执行的函数名。这个列表可以帮助我们把要下载的 JavaScript 代码拆分成两个文件，一个用于页面初始化，另一个则可以延后加载。然而，一些函数虽然未被使用，但仍然是必需的，比如错误处理和一些条件判断代码。所以完全准确地将需要初始化的代码剥离出来，并避免未定义标识符错误是一个巨大的挑战。JavaScript 的一些高级特性，包括函数的作用域和 eval 使这个挑战变得更加复杂。 Doloto（http://research.microsoft.com/apps/pubs/default.aspx?id=70518）是由微软研究院开发的自动拆分 JavaScript 代码的系统，它可以把代码拆分到不同的组。第一组包含初始化网页所必需的函数，剩下的则在这些代码需要执行时按需加载它们，或者等到初始化的那些 JavaScript 代码加载完毕时再加载。当应用到 Gmail、 Live Maps、 Redfin、MySpace 和 Netflix 3.3 寻找拆分 │ 23

时，Doloto 减少了多达 50%的初始 JavaScript 代码下载量，应用程序的加载时间缩短了 20%~40%。 Doloto 决定在什么位置拆分代码是基于训练阶段（training phase）的，它会把 JavaScript 拆分成多个文件下载。对于大多数 Web 应用程序来说，最好把在 onload 事件之前执行的 JavaScript 代码拆分成一个单独的文件，下载完成之后剩下的 JavaScript 采用无阻塞下载技术立即下载，我们将在第 4 章讲述这种技术。直到用户拖动菜单或点击页面上的某个元素之后才开始下载额外文件的话，会导致用户必须等待 JavaScript 加载完毕。假如所有额外的 JavaScript 在页面初始化渲染之后下载，我们就可以避免这种等待。在 Doloto 或其他系统完全公开之前，开发人员还是需要手动拆分代码。下面一节将讨论拆分时需注意的一些事项。 3.4 未定义标识符和竞争状态 Undefined Symbols and Race Conditions 拆分 JavaScript 代码的一个难点是要避免出现未定义标识符错误。如果在 JavaScript 执行时引用到一个被降级到延迟加载的标志符时，就会出现这种问题。比如在 Facebook 中，我建议对下拉菜单的 JavaScript 延后加载。但是，如果下拉菜单在它所需要的 JavaScript 下载完成之前显示出来，而且用户可以点击，那么 JavaScript 就不会生效。我的建议是建立一个下载 JavaScript 和用户点击菜单之间的竞争状态。在大多数情况下，JavaScript 会赢得这个竞争状态，但也确实会发生用户先点击的情况，此时调用下拉菜单函数（尚未被下载），就会出现未定义标识符的错误。在延迟加载的代码与用户界面元素相关联的情况下，可以通过改变元素的展现来解决此问题。在这种情况下菜单可以包含一个“加载中…”的图标，提醒用户该功能还没加载完成。另一个选择是在延迟加载的代码里绑定界面元素的事件处理程序。在这个例子中，菜单会被初始化成一个静态文本，点击它不会执行任何 JavaScript。延迟加载的代码包括菜单的功能和事件的绑定，在 Internet Explorer 中通过 attachEvent 实现，其他浏览器则需要采用 addEventListener（注 3）。在延迟加载的代码不与界面元素相关联的情况下，可以使用桩(stub)函数解决这个问题。桩函数是一个与原函数名称相同但是函数体为空，或者是用一些临时代码代替原有内容的函数。前一节介绍过的 Doloto 具有按需加载额外 JavaScript 模块的能力。Doloto 实现这个按注 3：更多信息请看 http://www.quirksmode.org/js/events_advanced.html。 24 │ 第 3 章：拆分初始化负载

需下载的功能就是在初始化下载的代码中插入桩函数，当调用它们时，动态加载其他的 JavaScript 代码。当新增的 JavaScript 代码下载完成，原函数会覆盖桩函数。更简单的方法是给每一个被引用但又被降级为延迟下载的函数创建一个桩函数。如有需要，桩函数可以返回一个桩值，例如一个空字符串。如果用户在完整的函数下载完成之前尝试使用这个 DHTML 的功能，将没有任何反应。稍微高级一点的解决方案是，用桩函数记录用户的请求，并在 JavaScript 完成加载时调用相应的代码。 3.5 个案研究：Google 日历 Case Study: Google Calendar Google 日历是一个很好的拆分出初始加载的例子。图 3-2 显示的是当 Google 日历被访问时的 HTTP 请求状况，我把这些图表叫做 HTTP 瀑布图。每个横杠代表一个请求，资源类型显示在左边，横轴代表时间，横杠的位置说明了在加载页面时每个资源开始和结束的点。图 3-2：Google 日历 HTTP 瀑布图 Google 日历请求了 5 个脚本，压缩前共 330KB。整个负载中拆分出了一个 152KB 的初始化脚本，被优先请求（从顶部数第 3 条横杠）。由于这个脚本仅不到 JavaScript 总量的一半大小，因此阻塞现象大大减轻。其余的 JavaScript 负载在页面开始渲染后加载。 Google 日历团队通过拆分 JavaScript，使页面渲染速度比所有 JavaScript 在同一个文件中加载的做法快很多。拆分 Web 应用程序的 JavaScript 并不是一个简单的任务。它需要明确初始化时所需的函数，找到所有必需代码的依赖关系，设置桩函数，并延迟加载其余的 JavaScript。这些任务需要进一步自动化。微软的 Doloto 项目就是这样的一个系统，但在撰写本文时，它还没有发布。在这个工具正式推出之前，开发者只能先自力更生了。 3.5 个案研究：Google 日历 │ 25

本章的重点是拆分 JavaScript，但拆分 CSS 样式表也是有益的。相对于拆分 JavaScript，后者节省的资源要少一些，因为样式表的整体大小通常比 JavaScript 小，而且下载 CSS 并不会像 JavaScript 那样具有阻塞特性（注 4）。不过这也是一个值得深入研究，并为其开发工具的机会。注 4：Firefox 2 是一个例外。 26 │ 第 3 章：拆分初始化负载

拆分初始化负载

by kaven yan on Apr 21, 2010

Accessibility

Categories

Tags

Upload Details

Usage Rights

Statistics

拆分初始化负载 — Document Transcript