app解析不会执行js代码
At Velocity NY, Daniel Espeset of Etsy gave a great talk about how Etsy profiles their JavaScript parse and execution time. Even better, after the talk, they released the tool on GitHub.
在纽约Velocity，Etsy的Daniel Espeset进行了精彩的演讲，讨论了Etsy如何配置其JavaScript解析和执行时间。 更好的是，在谈话之后，他们在GitHub上发布了该工具。
Daniel shared a few examples in his deck, but I couldn’t wait to take Daniel’s tool and fire it up on a bunch of random browsers and devices that I have sitting around.
Daniel 在他的平台上分享了一些示例，但是我迫不及待地想要使用Daniel的工具并在我周围坐着的一堆随机浏览器和设备上启动它。
For this test, I decided to profile just jQuery 2.1.1, which weighs in at 88kb when minimized. jQuery was selected for its popularity, not because it’s the worst offender. There are many libraries much worse (hey there Angular and your 120kb payload). The results above are based on the median times taken from 20 tests per browser/device combination.
对于此测试，我决定仅介绍jQuery 2.1.1，将其最小化时的大小为88kb。 选择jQuery是因为其受欢迎程度，并不是因为它是最糟糕的犯罪者。 有很多库要糟得多(嘿，Angular和您的120kb有效负载)。 上面的结果基于每种浏览器/设备组合进行20次测试所获得的中位数时间。
The list of tested devices isn’t exhaustive by any means—I just took some of the ones I have sitting around to try and get a picture of how much parse and execution time would vary.
无论如何，经过测试的设备列表都不是详尽无遗的-我只是坐着一些设备来尝试了解解析和执行时间会有多少变化。
| Device | Browser | Median Parse | Median Execution | Median Total |
|---|---|---|---|---|
| Blackberry 9650 | Default, BB6 | 171ms | 554ms | 725ms |
| UMX U670C | Android 2.3.6 Browser | 168ms | 484ms | 652ms |
| Galaxy S3 | Chrome 32 | 39ms | 297ms | 336ms |
| Galaxy S3 | UC 8.6 | 45ms | 215ms | 260ms |
| Galaxy S3 | Dolphin 10 | 2ms | 222ms | 224ms |
| Kindle Touch | Kindle 3.0+ | 63ms | 132ms | 195ms |
| Geeksphone Peak | Firefox 25 | 51ms | 109ms | 160ms |
| Kindle Fire | Silk 3.17 | 16ms | 139ms | 155ms |
| Lumia 520 | IE10 | 97ms | 56ms | 153ms |
| Nexus 4 | Chrome 36 | 13ms | 122ms | 135ms |
| Galaxy S3 | Android 4.1.1 Browser | 3ms | 125ms | 128ms |
| Kindle Paperwhite | Kindle 3.0+ | 43ms | 71ms | 114ms |
| Lumia 920 | IE10 | 70ms | 37ms | 107ms |
| Droid X | Android 2.3.4 Browser | 6ms | 96ms | 102ms |
| Nexus 5 | Chrome 37 | 11ms | 81ms | 92ms |
| iPod Touch | iOS 6 | 26ms | 37ms | 63ms |
| Nexus 5 | Firefox 32 | 20ms | 41ms | 61ms |
| Asus X202E | IE10 | 31ms | 14ms | 45ms |
| iPad Mini | iOS6 | 16ms | 30ms | 46ms |
| Macbook Air (2014) | Chrome 37 | 5ms | 29ms | 34ms |
| Macbook Air (2014) | Opera 9.8 | 14ms | 5ms | 19ms |
| iPhone 5s | iOS 7 | 2ms | 16ms | 18ms |
| Macbook Air (2014) | Firefox 31 | 4ms | 10ms | 14ms |
| iPad (4th Gen) | iOS 7 | 1ms | 13ms | 14ms |
| iPhone 5s | Chrome 37 | 2ms | 8ms | 10ms |
| Macbook Air (2014) | Safari 7 | 1ms | 4ms | 5ms |
| 设备 | 浏览器 | 中位解析 | 中位执行 | 中位数总计 |
|---|---|---|---|---|
| 黑莓9650 | 默认BB6 | 171毫秒 | 554毫秒 | 725毫秒 |
| 联电U670C | Android 2.3.6浏览器 | 168毫秒 | 484毫秒 | 652毫秒 |
| 银河S3 | 镀Chrome32 | 39毫秒 | 297毫秒 | 336毫秒 |
| 银河S3 | UC 8.6 | 45毫秒 | 215毫秒 | 260毫秒 |
| 银河S3 | 海豚10 | 2毫秒 | 222毫秒 | 224毫秒 |
| Kindle触控 | Kindle 3.0+ | 63毫秒 | 132毫秒 | 195毫秒 |
| 极客峰 | 火狐25 | 51毫秒 | 109毫秒 | 160毫秒 |
| Kindle火 | 丝绸3.17 | 16毫秒 | 139毫秒 | 155毫秒 |
| Lumia 520 | IE10 | 97毫秒 | 56毫秒 | 153毫秒 |
| Nexus 4 | 镀Chrome36 | 13毫秒 | 122毫秒 | 135毫秒 |
| 银河S3 | Android 4.1.1浏览器 | 3毫秒 | 125毫秒 | 128毫秒 |
| Kindle Paperwhite | Kindle 3.0+ | 43毫秒 | 71毫秒 | 114毫秒 |
| Lumia 920 | IE10 | 70毫秒 | 37毫秒 | 107毫秒 |
| 机器人X | Android 2.3.4浏览器 | 6毫秒 | 96毫秒 | 102毫秒 |
| Nexus 5 | Chrome37 | 11毫秒 | 81毫秒 | 92毫秒 |
| iPod Touch | iOS 6 | 26毫秒 | 37毫秒 | 63毫秒 |
| Nexus 5 | 火狐32 | 20毫秒 | 41毫秒 | 61毫秒 |
| 华硕X202E | IE10 | 31毫秒 | 14毫秒 | 45毫秒 |
| 小型平板电脑 | iOS6 | 16毫秒 | 30毫秒 | 46毫秒 |
| Macbook Air(2014) | Chrome37 | 5毫秒 | 29毫秒 | 34毫秒 |
| Macbook Air(2014) | 歌剧9.8 | 14毫秒 | 5毫秒 | 19毫秒 |
| iPhone 5S | IOS 7 | 2毫秒 | 16毫秒 | 18毫秒 |
| Macbook Air(2014) | Firefox 31 | 4毫秒 | 10毫秒 | 14毫秒 |
| iPad(第4代) | IOS 7 | 1毫秒 | 13毫秒 | 14毫秒 |
| iPhone 5S | Chrome37 | 2毫秒 | 8毫秒 | 10毫秒 |
| Macbook Air(2014) | Safari 7 | 1毫秒 | 4毫秒 | 5毫秒 |
As you can see from the table above, even in this small sample size the parsing and execution times varied dramatically from device to device and browser to browser. On powerful devices, like my Macbook Air (2014), parse and execution time was negligible. Powerful mobile devices like the iPhone 5s also fared very well.
从上表中可以看到，即使在这样小的样本量下，每个设备和浏览器之间的解析和执行时间也大不相同。 在功能强大的设备上，例如Macbook Air(2014)，解析和执行时间可以忽略不计。 功能强大的移动设备(如iPhone 5s)也表现出色。
But as soon as you moved away from the latest and greatest top-end devices, the ugly truth of JS parse and execution time started to rear its head.
但是，一旦您离开了最新，最好的高端设备，JS解析和执行时间的丑陋事实就开始浮出水面。
On a Blackberry 9650 (running BB6), the combined time to parse and execute jQuery was a whopping 725ms. My UMX running Android 2.3.6 took 652ms. Before you laugh off this little device running the 2.3.6 browser, it’s worth mentioning I bought this a month ago, brand new. It’s a device actively being sold by a few prepaid networks.
在Blackberry 9650(运行BB6)上，解析和执行jQuery的总时间高达725ms。 我的运行Android 2.3.6的UMX花了652毫秒。 在嘲笑这个运行2.3.6浏览器的小设备之前，值得一提的是我一个月前购买的全新设备。 这是一种由一些预付费网络积极销售的设备。
Another interesting note was how significant the impact of hardware has on the timing. The Lumia 520, despite running the same browser as the 920, had a median parse and execution time that was 46% slower than the 920. The Kindle Touch, despite running the same browser as the Paperwhite, was 71% slower than it’s more powerful replacement. How powerful the device was, not just the browser, had a large impact.
另一个有趣的注意事项是硬件对时序的影响有多大。 Lumia 520尽管运行与920相同的浏览器，但解析和执行时间的中值比920慢46％。Kindle Touch尽管与Paperwhite运行相同的浏览器，但比其更强大的功能慢71％。替代。 该设备的功能强大，而不仅仅是浏览器，影响很大。
This is notable because we’re seeing companies such as Mozilla and Google targeting emerging markets with affordable, low-powered devices that otherwise run modern browsers. Those markets are going to dominate internet growth over the next few years, and affordability is a more necessary feature than a souped up device.
值得注意的是，因为我们看到Mozilla和Google等公司针对新兴市场推出了价格低廉的低功耗设备，而这些设备否则会运行现代浏览器。 这些市场将在未来几年内主导互联网的增长，而可负担性是比功能强大的设备更为必要的功能。
In addition, as the cost of technology cheapens, we’re going to continue seeing an incredibly diverse set of connected devices. With endless new form factors being released (even the Android Wear watches quickly got a Chromium based browser), the adage about not knowing where our sites will end up has never been more true.
此外，随着技术成本的降低，我们将继续看到连接设备的多样化集合。 随着无休止的新形式发布(甚至Android Wear手表也很快有了基于Chromium的浏览器 )，关于不知道网站最终位置的说法从未如此真实。
The truly frightening thing about these parse and execution times is that this is for the latest version of jQuery, and only the latest version of jQuery. No older versions. No additional plugins or frameworks. According to the latest run of HTTP Archive, the median JS transfer size is 230kb and this test includes just a fraction of that size. I’m not even asking jQuery to actually do anything. Basically, I’m lobbing the browsers a softball here—these are best case results.
这些解析和执行时间真正令人恐惧的是，这是针对最新版本的jQuery的，并且仅适用于最新版本的jQuery。 没有较旧的版本。 没有其他插件或框架。 根据HTTP Archive的最新运行，中值JS传输大小为230kb，此测试仅包括该大小的一小部分。 我什至不要求jQuery实际上执行任何操作。 基本上，我在这里向浏览器打了个垒球，这是最好的结果。
This re-affirms what many have been arguing for some time: reducing your dependency on JS is not healthy merely for the minor percentage of people who have JS disabled—it improves the experience for everyone. When anything over 100ms stops feeling instantaneous and anything over 1000ms breaks the users flow, taking 700ms to parse your JavaScript cripples the user experience before it really has a chance to get started.
这再次证实了许多 人一段时间以来一直在 争论的问题：减少对JS的依赖并不仅仅对一小部分禁用JS的人来说是不健康的-它可以改善每个人的体验。 当超过100毫秒的任何事物停止瞬时感觉，而超过1000毫秒的任何事物都中断了用户流时，花费700毫秒来解析您JavaScript会使用户体验真正无法开始。
So what’s a web developer to do?
那么，Web开发人员该做什么呢？
Use less JavaScript. This is the simple one. Anything you can offload onto HTML or CSS, do it. JavaScript is fun and awesome but it’s also the most brittle layer of the web stack and, as we’ve seen, can seriously impact performance.
使用更少JavaScript。 这很简单。 您可以将任何内容卸载到HTML或CSS上。 JavaScript既有趣又很棒，但是它也是Web堆栈中最脆弱的一层，而且正如我们所看到的，它会严重影响性能。
Render on the server If you’re using a client-side MVC framework, make sure you pre-render on the server. If you build a client-side MVC framework and you’re not ensuring those templates can easily be rendered on the server as well, you’re being irresponsible. That’s a bug. A bug that impacts performance, stability and reach.
在服务器上渲染如果使用的是客户端MVC框架，请确保在服务器上进行预渲染。 如果您构建了客户端MVC框架，但又不能确保也可以轻松地在服务器上呈现这些模板，那么您将是不负责任的。 那是个错误。 影响性能，稳定性和覆盖范围的错误。
Defer all the scripts. Defer every bit of JavaScript that you can. Get it out of the critical path. When it makes sense, take steps to defer the parsing as well. Google had a great post a few years back about how they reduced startup latency for Gmail. One of the things they did was initially comment out blocks of JavaScript so that it wouldn’t be parsed during page load. The result was a 10x reduction in startup latency. That number is probably different on today’s devices, but the approach still stands.
延迟所有脚本。 尽可能多地利用JavaScript。 使其脱离关键路径。 在有意义的情况下，也应采取步骤来推迟解析。 几年前，Google就如何减少Gmail的启动延迟发表了精彩的文章。 他们做的一件事是最初注释掉JavaScript块，以便在页面加载期间不会对其进行解析。 结果是启动延迟减少了10倍。 在当今的设备上，该数字可能有所不同，但是这种方法仍然有效。
Cut the mustard. I’m a big fan of “cutting the mustard”, an approach made popular by the BBC. This doesn’t solve the problem of low-end devices with modern browsers, but it will make a better experience for people using less capable browsers. Better yet, by consciously deciding not to overwhelm less capable browsers with excess scripts you not only provide a better experience for those users, but you reduce the need for extra polyfills and frameworks for modern browsers as well. On one recent project where we did this, the entire JavaScript for the site was about 43% of the size of jQuery alone!
切芥末。 我是“切芥末”的忠实拥护者 ，这是英国广播公司流行的一种方法。 这不能解决带有现代浏览器的低端设备的问题，但对于使用功能较弱的浏览器的人来说，它将提供更好的体验。 更好的是，通过有意识地决定不使用过多的脚本淹没功能较弱的浏览器，不仅为这些用户提供了更好的体验，而且还减少了现代浏览器对额外的polyfill和框架的需求。 在我们最近进行的一个项目中，该网站的整个JavaScript大约只有jQuery大小的43％！
There are certainly cases to be made for JS libraries, client-side MVC frameworks, and the like, but providing a quality, performant experience across a variety of devices and browsers requires that we take special care to ensure that the initial rendering is not reliant on them. Frameworks and libraries should be carefully considered additions, not the default.
JS库，客户端MVC框架等当然会出现情况，但是要在各种设备和浏览器上提供高质量，高性能的体验，我们需要格外小心，以确保初始渲染不会依赖在他们。 应该仔细考虑框架和库的添加， 而不是默认值 。
When you consider the combination of weight, parse time and execution time, it becomes pretty clear that optimizing your JS and reducing your site’s reliance on it is one of the most impactful optimizations you can make.
当您考虑权重，解析时间和执行时间的组合时，很明显，优化JS并减少对站点的依赖是您可以做出的最具影响力的优化之一。
翻译自: https://timkadlec.com/2014/09/js-parse-and-execution-time/
app解析不会执行js代码
