RE: 首屏渲染优化提案反馈（原：Re: 答复: 中文兴趣小组5月5日电话会议） from Hu, Chunming on 2014-05-06 (public-html-ig-zh@w3.org from May 2014)

From: Hu, Chunming <hucm@act.buaa.edu.cn>
Date: Wed, 7 May 2014 00:45:55 +0800
To: 'Xidorn Quan' <quanxunzhen@gmail.com>, 'John Hax' <johnhax@gmail.com>
CC: 'W3C HTML5 中文興趣小組' <public-html-ig-zh@w3.org>
Message-ID: <009201cf694a$a9abf8f0$fd03ead0$@act.buaa.edu.cn>
这个hint让我想起前两天刚翻译的一个news，后来发现Xidorn在后面的邮件也提到了。

http://www.chinaw3c.org/archives/498/ 

 

2014年4月24日，W3C的CSS工作组发布了CSS Will Change Module Level 1的首份标准工作草案。

http://www.w3.org/TR/2014/WD-css-will-change-1-20140429/ 

 

浏览器在做CSS渲染时有一系列复杂的优化，这些优化可以让Web页面更快、更有效的加载，但使用这些优化都有一个启动开销，过大的启动开销会严重影响页面对用户响应。该文档定义了一个有趣的CSS新属性－－will-change，开发者可以通过这个属性提前通知用户代理（如浏览器）某个元素的内容未来将有何种变化。这样，用户代理就可以提前为优化渲染这些元素做好准备，如在动画真正开始前，提前进行一些准备工作。

 

From: Xidorn Quan [mailto:quanxunzhen@gmail.com] 
Sent: Tuesday, May 06, 2014 9:07 PM
To: John Hax
Cc: W3C HTML5 中文興趣小組
Subject: Re: 首屏渲染优化提案反馈（原：Re: 答复: 中文兴趣小组5月5日电话会议）

 

我觉得 John 说的非常好，现在这个提案过于限于具体实现，暴露浏览器实现细节。我也赞同放在 CSS 里面比较好。

既然是 CSS 的话，我有一个想法，我们不如给浏览器这么一个 hint：这个元素的 geometry 不会随其后续元素的载入而发生改变。如果浏览器能得到这么一个 hint，它就可以立即对这个元素进行排版及渲染，而不必顾忌后面的内容。

更进一步地，我联想到了现在刚好在 FPWD 阶段的 will-change，我们可以提议给 will-change 加一个 keyword 叫做 never 来给浏览器这么一个 hint，各位觉得如何？

不过我不是很确定这个方案对于现有的浏览器解析策略有没有可行性。（没有研究过相关流程）

 

2014-05-06 17:57 GMT+10:00 John Hax <johnhax@gmail.com>:

很抱歉未能参加昨天的电话会议。

 

这份提案粗看了一下，总体感觉还是需要很多改进的。

 

 

第一，完全赞同kenny所言，在初期最重要的是把user cases写清楚，有说服力。

第二，现有提案过于限于具体实现方法，特别是暴露太多浏览器内部实现细节，因而显得“dirty”。比如token之类的，对于大部分开发者来说都无法理解，罔论使用？

 

下面讲几个具体想法：

 

1. 这个东西既然与呈现有关，宜以CSS实现，而不是增加tag/attribute。正如viewport，虽然最初以meta形式出现（因为易于实现），但标准化后还是在CSS中。

 

2. 具体优化策略目前似乎只有token数（用户指定或云服务计算）？这过于狭隘了（完全来自于当前浏览器的算法细节）。实际上实践中对于首屏优化有许多相关问题。例如网络传输时是否使用chunk编码，是否可认为强制发送一个chunk表示要开始首屏rending？那么为什么不是在spec中规定这样的行为？（注意我只是提出一个反问，并不是建议要提供这样的特性。）

 

3. 总体上来说，具体优化算法应该是浏览器自己决定，而不是过多由开发者指定。给开发者提供细粒度的控制是需要谨慎的。我认为比较好的方式是允许开发者指定大略的策略。比如 layout-optimize: [policy] ，policy的取值可以是 auto（浏览器自行决定），fast（尽快展现），normal（传统方式），progressive（有一个元素就呈现一个元素）……

 

 

 

2014-05-06 12:10 GMT+08:00 Xidorn Quan <quanxunzhen@gmail.com>:

 

我猜这个邮件本意是要发到兴趣小组的，所以转发过来

---------- Forwarded message ----------
From: chaixiaoxing <public_00@hotmail.com>
Date: 2014-05-06 14:04 GMT+10:00
Subject: RE: 首屏渲染优化提案反馈（原：Re: 答复: 中文兴趣小组5月5日电话会议）
To: Xidorn Quan <quanxunzhen@gmail.com>



对于<body>A(设置首屏)
B</body>的需求，更期望有个技术是服务器只传A给浏览器，等A被渲染后再自动续传B。移动设备，尤其是手机，页面节点一般比较少，白屏时间开销感觉主要在浏览器和服务器通信上，如果A和B都parse后，目测B的layout的时间增加些ms，至于B的paint时间，浏览器应该都做了不在可视区不paint的优化了。

按现在提案，感觉用属性更好，如果能用css更好了，用新标签影响页面DOM，而且增加标签的相关实现。



> From: quanxunzhen@gmail.com
> Date: Tue, 6 May 2014 12:25:49 +1000
> To: kanghao.lkh@alibaba-inc.com
> CC: minyue@baidu.com; public-html-ig-zh@w3.org; wuping02@baidu.com
> Subject: Re: 首屏渲染优化提案反馈（原：Re: 答复: 中文兴趣小组5月5日电话会议）


>
> 2014-05-06 1:20 GMT+10:00 吕康豪(平寿) <kanghao.lkh@alibaba-inc.com>:
> > (2014/05/05 10:36), Min,Yue wrote:
> > HTML 没有 block 排版元素这个概念（那是 CSS 的概念），可以从元素分类[1]选
> > 一个组合出来（感觉是 heading content + sectioning content + <div>）。
> >
> > 不过我觉得另一个比较语义的要求是规定这个属性只能用在 <hr> 上。这样
> >
> > <hr firstpaint>
> >
> > 也有点像是锦江提的
> >
> > <!--firstpaint-->
> >
> > 了。
>
> 放在一个单独的自关闭标签里面这个方法我觉得比现有的提案要好，这样也不需要区分打开时还是关闭时，这个标签作为一个整体包括在首屏范围内。语义上可以解释为这个属性将这个标签变成了一个
> hint，会比将属性本身作为 hint 要稍微更容易接受一点。
>
> 另外，是否有相关的数据可以表现这种优化潜在的作用？比如说，到浏览器可以正确渲染出首屏内容的点为止，载入耗时多少，到浏览器以现有策略准备开始渲染首屏内容时，载入耗时为多少，这样的表格？
>
> - Xidorn
Received on Tuesday, 6 May 2014 16:47:50 UTC