re 懒惰
#7 This post is part of the Velocity countdown series. Stay tuned for the articles to come.
＃7这篇文章是Velocity倒数系列的一部分。 请继续关注未来的文章。
Some time ago Google talked about using a sort of lazy JavaScript evaluation which especially helps mobile devices. The idea was to comment out a chunk of JavaScript you don't need right away and serve it this way. Later, when you need it, you get the content of the commented code and eval() it. More here and here.
前段时间，Google谈论使用某种懒惰JavaScript评估，该评估特别有助于移动设备。 这个想法是注释掉不需要JavaScript片段并以这种方式提供它。 稍后，在需要时，您将获得注释代码的内容并对其进行eval()。 在这里和这里更多。
At the last Fronteers conference I had the pleasure of chatting with Sergey Chikuyonok, who is so great and (among other things) is responsible for coming up with zen coding and writing a bunch of deep articles on image optimization for Smashing Magazine. So he told me he experimented with similar lazy HTML evaluation and it proved to be incredibly helpful for mobile devices. Not only the overall experience is faster but the initial rendering happens sooner and we all know how important that is.
在上一届Fronteers会议上，我很高兴与Sergey Chikuyonok聊天，他非常出色，并负责提出zen编码，并为Smashing Magazine撰写了许多有关图像优化的深入文章。 因此，他告诉我他尝试了类似的惰性HTML评估，事实证明它对移动设备非常有用。 不仅整体体验更快，而且初始渲染更快，而且我们都知道这很重要。
Sergey is a busy person and chances of him writing about his experiment in English seemed pretty low at the time, so I decided to do an experiment on my own and see what happens. Meanwhile he did write about it so I forgot all about my findings, but here they are now.
谢尔盖是个忙碌的人，当时他用英语写实验的机会似乎很少，所以我决定自己做一个实验，看看会发生什么。 同时，他确实写了这篇文章，所以我忘记了所有发现，但现在就在这里。
长文件 (Long document)
I took one big HTML document - The adventures of Sherlock Holmes, which is half a megabyte or about 200K gzipped. Page A is the document as-is, plus some JS for measurements.
我拿了一个大HTML文档-Sherlock Holmes的冒险，这是一个半兆字节或大约200K的压缩文件。 A页是文档原样，外加一些用于测量的JS。
Page B (lazy) is the same page but with about 95% of its content commented out. The remaining 5% is a whole chapter so there's plenty of time to deal with the rest while the user is reading. After onload and a 0-timeout I take the commented markup (conveniently placed in <div id="lazy-daze">) and strip the comments. Then take the "unwrapped" time after another 0-timeout to let the browser repaint the DOM and regain control.
B页(惰性)是同一页，但其中约95％的内容已被注释掉。 剩下的5％是一整章，因此在用户阅读时有足够的时间处理其余内容。 在onload和0超时之后，我使用注释的标记(方便地放在<div id="lazy-daze"> )并删除注释。 然后在另一个0超时之后花费“解包”时间，以使浏览器重新绘制DOM并重新获得控件。
The overall skeleton of the lazy page is like so:
惰性页面的总体框架如下：
<!doctype html>
<html>
<body>
<h1>THE ADVENTURES OF<br/>
SHERLOCK HOLMES</h1>
...
... to chat this little matter over with you.</p>
<div id="lazy-daze">
<!--
<p>II.</p>
<p>
At three o’clock precisely ...
... she has met with considerable success.</p>
-->
</div>
<script>
window.onload = function () {
setTimeout(function(){
var daze = document.getElementById('lazy-daze'),
inner = daze.innerHTML;
daze.innerHTML = inner.substring(4, inner.length - 4);
setTimeout(function(){
// take end time...
}, 0);
}, 0);
};
</script>
</body></html>
实验 (Experiment)
All the files are here: http://www.phpied.com/files/lazyhtml/
所有文件都在这里： http : //www.phpied.com/files/lazyhtml/
We have the plain normal document - http://www.phpied.com/files/lazyhtml/sherlock-plain.html And the lazy one - http://www.phpied.com/files/lazyhtml/sherlock-lazy.html
我们有普通的普通文档-http: //www.phpied.com/files/lazyhtml/sherlock-plain.html和懒惰的文档-http: //www.phpied.com/files/lazyhtml/sherlock-lazy.html
In order to run the experiment you just go to http://www.phpied.com/files/lazyhtml/start.html And click "Go nuts". This will load each of the two documents 20 times and take a few time measurements. "Go nuts" again and you'll get 20 more data points.
为了进行实验，您只需转到http://www.phpied.com/files/lazyhtml/start.html并单击“发疯”。 这将两个文档中的每一个加载20次并进行几次测量。 再次“疯狂”，您将获得20多个数据点。
The time measurements I take are:
我进行的时间测量是：
- "plain" - unload to onload of the base version “普通”-卸载到基本版本的onload
- "lazy" - unload to onload of the lazy version NOT including unwrapping it. This should be quicker than the plain version “ lazy”-卸载到惰性版本的加载，不包括解包。 这应该比普通版本更快
- "unwrapped" - unload to onload plus time to unwrap and rerender - this is expected to be bigger than "plain" because the browser has to render twice and is therefore doing more work“展开”-卸载到加载以及展开和重新渲染的时间-预计这比“纯文本”要大，因为浏览器必须渲染两次，因此需要做更多的工作
- DOM loaded "plain" - unload to DOMContentLoaded instead of onloadDOM加载为“纯文本”-卸载为DOMContentLoaded而不是onload
- DOM loaded "lazy" DOM加载“惰性”
Then I take the same 5 measurements but instead of starting at unload of the previous page, it starts at the top of the documents, as soon as a timestamp can be taken with JavaScript. This will exclude DNS, establishing connection, time to first byte...
然后，我进行了同样的5次测量，但不是从上一页的卸载开始，而是从文档的顶部开始，一旦可以使用JavaScript进行时间戳记，它就从文档的顶部开始。 这将排除DNS，建立连接，到第一个字节的时间...
结果 (Results)
Here are the results from back when I did the experiment originally last year, using iPhone 2 (with iOS 3.2 or thereabouts)
这是去年我最初使用iPhone 2(装有iOS 3.2或更高版本)进行实验时返回的结果
I ran this experiment over Wifi and again over 3G.
我在Wifi上进行了此实验，然后在3G上进行了此实验。
First striking thing - it takes the about the same time to load the plain old page over Wifi and over 3G. For the smaller, "lazy" document, there is a difference, but there's virtually none for the plain base page. The guess here is that the rendering and its cost in terms of memory and CPU is far greater than the actual download time. In other words it takes longer to render than it does to download an HTML. At least in this class of phones. This guess is confirmed when you look at the time from the top of the documents, when the request overhead is removed:
首先要注意的是-通过Wifi和3G加载原始的旧页面大约需要花费相同的时间。 对于较小的“惰性”文档，有区别，但是对于普通基础页面几乎没有任何区别。 这里的猜测是，渲染及其在内存和CPU方面的成本远远大于实际下载时间。 换句话说，渲染所需的时间比下载HTML需要的时间更长。 至少在这类手机中。 当您从文档顶部查看时间，并消除了请求开销时，可以确认此猜测：
With or without the request time - it's all pretty much the same.
有或没有请求时间-几乎都是一样的。
The next striking thing - and how about that lazy document! It renders 3-4 times faster than the whole plain document. Not bad.
下一件引人注目的事情-那个懒惰的文档呢！ 它的渲染速度是整个普通文档的3-4倍。 不错。
And one more surprise - lazy+unwrap time is less than the plain old document. Now that's interesting. It appears faster to split the task into two and do the whole double-rendering, which should've been slower because it's extra work. I guess that poor phone really chokes on the long document.
还有一个惊喜-延迟+解包时间比普通的旧文档要少。 现在很有趣。 将任务一分为二并进行整个双重渲染似乎更快，这应该慢一些，因为这是额外的工作。 我猜那可怜的电话在长文件上确实令人窒息。
The same I found is true in Firefox, but almost the difference is negligible.
我发现在Firefox中也是如此，但是几乎可以忽略不计。
iPhone 4 (iPhone 4)
I repeated the experiment tonight on iPhone 4 and wifi. And boy, is there a difference. What used to take 13 seconds is now under 3s.
我今晚在iPhone 4和wifi上重复了该实验。 和男孩，有区别。 过去需要13秒的时间现在不到3秒。
The lazy + unwrap time is more than the plain time, which was to be expected.
延迟+解包时间比预期的普通时间更长。
Rendering that initial lazy document is still 2-3 times faster that waiting for the whole document.
渲染最初的惰性文档仍然比等待整个文档快2-3倍。
The numbers:
数字：
2765 plain (2014 DOM)
2765平原(2014 DOM)
1268 lazy
1268懒
2995 lazy+unwrap
2995懒+解包
Ignoring the request overhead:
忽略请求开销：
2200 plain (1421 DOM)
2200纯色(1421 DOM)
715 lazy
715懒
2423 lazy+unwrap
2423懒+解包
And one last run/observation - on the 3G and iPhone 4 there isn't much benefit of lazy-evaluation and empty cache. The request seems much more expensive. unload to onload 4.9s where document top to onload is 2.5. When the request overhead is out of the picture than lazy eval wins again - 1.7s compared to 2.5s
最后一次运行/观察-在3G和iPhone 4上，延迟评估和空缓存没有太多好处。 该请求似乎更加昂贵。 卸载到onload 4.9s，其中文档top to onload是2.5。 当请求开销超出画面时，懒惰的eval再次获胜-1.7s对比2.5s
分词 (Parting words)
- Lazy HTML FTW?懒惰HTML FTW？
- Who the heck loads an entire book in a page?! Well it may happen. It may not be a whole book, but just a lot of markup. The entire book gzipped was 219K. A hefty document, but have you seen some of those news sites? 到底是谁在页面上加载整本书？ 好吧，这可能会发生。 它可能不是一本书，而是很多标记。 压缩后的整本书为219K。 一份沉重的文件，但是您看过其中一些新闻网站吗？
- Possible use case - blog comments. Lots and lots of blog comments. Or posts. 可能的用例-博客评论。 很多博客评论。 或帖子。
- If you're going to lazy-load something and get it with an ajax request, why not save yourself the request and ship with another chunk of html 如果您要延迟加载某些内容并通过ajax请求获取它，为什么不保存自己的请求并随另一HTML一起发货
- This was a simple layout task. Just a bunch of text. I'm guessing there could be much more complicated pages and layouts to render. And rendering is what takes the time it seems. 这是一个简单的布局任务。 只是一堆文字。 我猜可能要渲染的页面和布局要复杂得多。 渲染需要花费很多时间。
- Drawbacks a plenty because of the hidden content - accessibility, SEO. 由于隐藏的内容(可访问性，SEO)的缺点很多。
Thoughts? Anyone want to run the test on Android or any other phone/device/tab/pad/whathaveyou? The guess is that the newer/powerful the device the smaller the difference. But it will be nice to know.
有什么想法吗？ 任何人都想在Android或任何其他手机/设备/标签/平板电脑/上运行测试吗？ 猜测是设备越新/功能越强，差异就越小。 但是很高兴知道。
Tell your friends about this post on Facebook and Twitter
在Facebook和Twitter上告诉您的朋友有关此帖子的信息
re 懒惰
扫一扫
259
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
