首屏渲染优化提案反馈（原：Re: 答复: 中文兴趣小组5月5日电话会议）

(2014/05/05 10:36), Min,Yue wrote:
> 我是百度的闵月。近期百度准备向web performance 工作组提交首屏渲染优化规范
> 的提案。该规范用于加快移动端用户实际感知到首屏内容展现的速度，避免搜索项
> 目中观察到的简单搜索结果页由于等待内核绘制的触发条件，反而比复杂结果页实
> 际展现慢的问题。  
> 
> ------------------------------------------------------------------------------------------------------------------------------------------------------
> 
> 以下是该提案的详细内容，为了方便晚上的电话会议讨论，供大家参考：
> 
>  
> 
> *1．首屏渲染优化规范介绍*
> 
> 首屏渲染优化规范用于加速移动设备上首屏内容的绘制可见速度。
> 
> 在web页面代码解析（parse）后，还需要经过布局（layout）与绘制（paint）阶
> 段，才能在屏幕上展示给用户。移动设备屏幕很小，通常很短的代码就能够充满这
> 个屏幕，而这部分内容就是用户首先实际感知到的内容区域。
> 
> 当一个页面代码由A、B两段组成，代码A能够表示首屏的所有内容，当A完成web内
> 容解析（parse）后，并不能立刻完成布局（layout）与绘制上屏操作（paint）。
> 内核从parse状态转化成layout状态，存在若干触发条件，它们包括了解析的token
> 数目，解析的时间以及延迟（delay）时间。内核从layout状态转化成paint状态，
> 同样存在若干必要条件，这些条件使得内核无法提早退出layout流程，进入实际上
> 屏绘制阶段。所有这些限制条件并没有充分考虑到手机首屏内容的大小，以及实际
> 用户感知内容展现的重要优先级。在复杂的移动网络环境下这种限制对浏览速度的
> 影响更大。
> 
> 通过定义首屏渲染优化规范，web开发者可以指定浏览器进行合适的首屏内容提前
> 绘制（内核可自行判断首屏位置或是由开发者指定首屏位置），从而加快首屏展现
> 速度，显著缩短用户首次看见非白屏页面时间。

跟技术点无关，不过我觉得《使用案例》小节可以提前到这里，这里也可以提醒一下
下面的语法仅供参考，因为确实争议还挺多的，会有人很关注语法的好看程度什么
的，不过使用情景比这些重要多了。

其他部分是语法反馈：

> *2. 首屏渲染优化规范以及相关firstpaint属性的详细描述*
> 
> 首屏渲染优化规范由head部分的meta描述和body部分的firstpaint属性描述共同组成。
> 
> 在head部分，meta 信息描述为以下三种：
> 
> l  *<meta name="layout-optimize" content="First Screen
> Paint[;browser-defined-strategy]">*
> 
> 该描述指示浏览器自行决定首屏判断机制，进行首屏内容提前绘制优化。 
> 
> l  *<meta name="layout-optimize" content="First Screen
> Paint;user-defined-position">*

@name 一般是名词吧？ "layout-optimization" 之类的。

"First Screen Paint" 用空格分开这个不太常规，"paint-first-screen-
early=auto|til-inline-mark" 之类的比较好？即：

  <meta name="layout-optimization"
content="paint-first-screen-early=auto|til-inline-mark" />

> 该描述指示浏览器在开发者指定的首屏位置进行首屏内容提前绘制优化。  
> 
> 和meta描述对应的，在网页的body部分中会存在开发者定义的首屏位置元素，其描
> 述为*<tagName firstpaint>，firstpaint = “firstpaint”or “”(empty
> string)or empty  *其中tagName元素应为block排版元素

HTML 没有 block 排版元素这个概念（那是 CSS 的概念），可以从元素分类[1]选
一个组合出来（感觉是 heading content + sectioning content + <div>）。

不过我觉得另一个比较语义的要求是规定这个属性只能用在 <hr> 上。这样

  <hr firstpaint>

也有点像是锦江提的

  <!--firstpaint-->

了。

[1]
http://www.whatwg.org/specs/web-apps/current-work/multipage/elements.html#kinds-of-content

> ，firstpaint为
> firstpaint或空值均表示解析到此元素可以立即触发首屏排版绘制。firstpaint属
> 性为JS只读属性，写入该属性抛出JS异常，未知属性。创建新元素时，默认值为
> 空字符串。该属性只在parse阶段对浏览器起作用，当JS执行时，读写该属性不
> 会对浏览器行为造成任何影响；

DOM 里设置未知属性不会抛异常一样的。这里 @firstpaint 只要说成是如 <html>
上 @manifest[2]一样是没有 DOM 对应的属性就行了。真的想读取这个值可以用

  element.hasAttribute("firstPaint");

[2]
http://www.whatwg.org/specs/web-apps/current-work/multipage/semantics.html#attr-html-manifest

> 该属性也并不对于样式和绘制效果存在任何影响，比如
> 对style为display：none的隐藏元素也没有影响。**

我看不懂这句话是想说什么。这是想说一个

  <div style="display:none" firpaint>

会触发首屏排版绘制还是刚好相反？

> * *
> 
> 如果head部分存在meta描述且是由开发者指定首屏绘制位置， 而body部分缺失对
> 应的firstpaint属性元素，浏览器会回退到自身默认的绘制策略。**

其他冲突状况虽然很无聊，不过描述清楚可能比较好：

  * 如果 <body> 里有有 @firstpaint 的元素但是 <head> 没有
    <meta name="layout-optimize" content="First Screen Paint"> 该是什么
    情形？应该是想成有 "user-defined-position"。

  * 如果 <body> 里有有 @firstpaint 的元素但是 <head> 里是
    <meta name="layout-optimize" content="First Screen Paint;
    browser-defined-strategy"> 该是什么情形？

  * ...

> l  *<meta name="layout-optimize" content="First Screen
> Paint;user-defined-tokens={number}">*
> 
> 该描述指示浏览器在解析阶段达到开发者指定的tokens数目之后，可以立即触发
> layout过程，进行首屏内容提前绘制优化。
> 
> 这里的tokens为首屏内容token数目

这里首先 token 有很多种（照 HTML 规范的术语），会议中好像是说是开标签
token 吧，那这里命名应该直接说是 user-defined-open-tags= 就好了。

> ，number为大于0的整数。Token数目可由开发者指定或浏览内核云服务计算获
> 取。

这部分没能明白，所以开发者想用浏览内核云服务里有的 open-tags 数的时候到
底该写什么？不是

  First Screen Paint;cloud-provided

之类的么？又这个为什么不能跟

  First Screen Paint[;browser-defined-strategy]

并在一起？因为希望开发者能控制去不去云服务读这个数值？是不是给开发者太多
选项了？

> 这种描述既指定了首屏绘制位置又不用改变原有页面结构。
>  
> 
> *3.       **使用案例*
> 
> 几乎所有的网页都可以使用首屏渲染优化规范制导浏览器加快首屏展现速度，显著
> 缩短用户第一次看见非白屏页面时间。web开发者或是云端标记的firstpaint属性
> 以及内核自行采用的首屏判断机制存在各自的使用场景。

闵月的信不是提到

  # 避免搜索项目中观察到的简单搜索结果页由于等待内核绘制的触发条件，反而
  # 比复杂结果页实际展现慢的问题。

么？我觉得这里提事例比提什么 “几乎所有的网页都可以使用首屏渲染优化” 有说
服力多了。

话说 “云端标记的firstpaint属性” 是什么东西？前面没提过吧？

> 浏览器内核自行预测首屏内容位置的方式，相对比较灵活，在不同机型不同分辨率
> 的设备上，都能够精确计算绘制面积。但是由于依赖解析和布局过程预测，可能存
> 在预测不准，预测开销等问题，比如等待css资源决定绘制面积，重复排版绘制，
> 耗费cpu资源，以及影响完全加载时间。 
> 
> 开发者自行标记和云端标记首屏绘制位置减少了内核预测的开销，但不同机器分辨
> 率不同，一般情况下只会给出一个参考首屏位置，不会适配各种机型分辨率。

这边是不是可以提一下 @firstpaint 可以 “超出” 首屏一点一点？目前的实际使
用是什么情形？

> 对于希望首屏达到最优效果的开发者，可以对于主流设备，通过head和body中的属性标
> 记配合指定首屏位置， 保证首屏所有元素能被一次性的布局和绘制，从而避免内
> 核独立首屏优化绘制所带来的冗余的排版计算以及parse/layout/paint调度。

这一段我看两次才知道 “head和body中的属性标记” 是指 @firstpaint 跟 <meta
name="layout-optimize" content="First Screen Paint">……可以写清楚一点。


以上

Kenny

Received on Monday, 5 May 2014 15:45:40 UTC