web前端（32）
浏览器在加载网页的过程中，先下载HTML并开始解析。如果发现外部CSS资源链接，就发送下载请求。浏览器在下载CSS资源的同时，解析HTML文件。
在应用样式的时候，不会更改DOM树，因此解析样式表的时候也不会停止文档解析。
解析器遇到&script&标记时，立即解析并执行脚本。一旦发现有脚本文件的引用，就必须等待脚本文件下载完。这时，文档的解析会暂停，并且等到脚本执行完再继续。所以，脚本文件的下载和执行，会阻断其他资源文件的下载。
3 预加载器
当浏览器被脚本文件阻塞时，预加载器（一个轻量级的解析器）会继续浏览剩下的标记，寻找需要下载的资源。如果发现有需要下载的资源，预加载器在开始接收这些资源。预加载器只能检索HTML标签中的URL，无法检测到使用脚本代码添加的URL，这些资源要等脚本代码执行时才会获取。
【参考资料】
1 浏览器的工作原理：现代网络浏览器幕后揭秘
2 如何通过预加载器提升网页加载速度
* 以上用户言论只代表其个人观点，不代表CSDN网站的观点或立场
访问：173794次
积分：2283
积分：2283
排名：第9465名
原创：70篇
转载：29篇
评论：62条
(2)(1)(3)(10)(1)(1)(2)(8)(1)(1)(2)(7)(1)(1)(2)(1)(7)(1)(1)(4)(10)(2)(1)(5)(2)(1)(1)(2)(1)(5)(3)(5)(1)(1)(1)(1)(1)[转载]浏览器加载和渲染html的顺序-中国学网-中国IT综合门户网站
[转载]浏览器加载和渲染html的顺序
来源：互联网 发表时间： 22:55:44 责任编辑：李志喜字体：
这两天在维护修改传真发送程序时，为预防重复提交想让发送按钮变灰以提示用户已点击，但完成后发现：提示传真正在发送的消息（在页面上部且为父窗体中的元素）出现后按钮才变灰，然而按钮的disabled属性变化在消息显示之前，甚是奇怪。试过多种方法后，发现单纯用js还是无法实现。无意中记起层看过HTML渲染顺序的文章，后查证并做记录，方便以后查找。
1. IE下载的顺序是从上到下，渲染的顺序也是从上到下，下载和渲染是同时进行的。&2. 在渲染到页面的某一部分时，其上面的所有部分都已经下载完成（并不是说所有相关联的元素都已经下载完）。&3. 如果遇到语义解释性的标签嵌入文件（JS脚本，CSS样式），那么此时IE的下载过程会启用单独连接进行下载。&4. 样式表在下载完成后，将和以前下载的所有样式表一起进行解析，解析完成后，将对此前所有元素（含以前已经渲染的）重新进行渲染。&5. JS、CSS中如有重定义，后定义函数将覆盖前定义函数。&JS的加载&1. 不能并行下载和解析（阻塞下载）。&2. 当引用了JS的时候，浏览器发送1个js request就会一直等待该request的返回。因为浏览器需要1个稳定的DOM树结构，而JS中很有可能有&代码直接改变了DOM树结构，比如使用 document.write 或 appendChild,甚至是直接使用的location.href进行跳转，浏览器为了防止出现JS修&改DOM树，需要重新构建DOM树的情况，所以 就会阻塞其他的下载和呈现.&如何加快HTML页面加载速度&1. 页面减肥：&a. 页面的肥瘦是影响加载速度最重要的因素。&b. 删除不必要的空格、注释。&c. 将inline的script和css移到外部文件。&d. 可以使用HTML Tidy来给HTML减肥，还可以使用一些压缩工具来给JavaScript减肥。&2. 减少文件数量：&a. 减少页面上引用的文件数量可以减少HTTP连接数。&b. 许多JavaScript、CSS文件可以合并最好合并，人家财帮子都把自己的JavaScript. functions和Prototype.js合并到一个base.js文件里去了。&3. 减少域名查询：&a. DNS查询和解析域名也是消耗时间的，所以要减少对外部JavaScript、CSS、图片等资源的引用，不同域名的使用越少越好。&4. 缓存重用数据：&a. 对重复使用的数据进行缓存。&5. 优化页面元素加载顺序：&a. 首先加载页面最初显示的内容和与之相关的JavaScript和CSS，然后加载HTML相关的东西，像什么不是最初显示相关的图片、flash、视频等很肥的资源就最后加载。&6. 减少inline JavaScript的数量：&a. 浏览器parser会假设inline JavaScript会改变页面结构，所以使用inline JavaScript开销较大。&b. 不要使用document.write()这种输出内容的方法，使用现代W3C DOM方法来为现代浏览器处理页面内容。&7. 使用现代CSS和合法的标签：&a. 使用现代CSS来减少标签和图像，例如使用现代CSS+文字完全可以替代一些只有文字的图片。&b. 使用合法的标签避免浏览器解析HTML时做&error correction&等操作，还可以被HTML Tidy来给HTML减肥。&8. Chunk your content：&a. 不要使用嵌套table，而使用非嵌套table或者div。将基于大块嵌套的table的layout分解成多个小table，这样就不需要等到整个页面（或大table）内容全部加载完才显示。&9. 指定图像和table的大小：&a. 如果浏览器可以立即决定图像或table的大小，那么它就可以马上显示页面而不要重新做一些布局安排的工作。&b. 这不仅加快了页面的显示，也预防了页面完成加载后布局的一些不当的改变。&c. image使用height和width。&HTML页面加载和解析流程&1. 用户输入网址（假设是个html页面，并且是第一次访问），浏览器向服务器发出请求，服务器返回html文件。&2. 浏览器开始载入html代码，发现&head&标签内有一个&link&标签引用外部CSS文件。&3. 浏览器又发出CSS文件的请求，服务器返回这个CSS文件。&4. 浏览器继续载入html中&body&部分的代码，并且CSS文件已经拿到手了，可以开始渲染页面了。&5. 浏览器在代码中发现一个&img&标签引用了一张图片，向服务器发出请求。此时浏览器不会等到图片下载完，而是继续渲染后面的代码。&6. 服务器返回图片文件，由于图片占用了一定面积，影响了后面段落的排布，因此浏览器需要回过头来重新渲染这部分代码。&7. 浏览器发现了一个包含一行Javascript代码的&script&标签，赶快运行它。&8. Javascript脚本执行了这条语句，它命令浏览器隐藏掉代码中的某个&style&（style.display=&none&）。杯具啊，突然就少了这么一个元素，浏览器不得不重新渲染这部分代码。&9. 终于等到了&/html&的到来，浏览器泪流满面&&&10. 等等，还没完，用户点了一下界面中的&换肤&按钮，Javascript让浏览器换了一下＜link＞标签的CSS路径。&11. 浏览器召集了在座的各位&div&&span&&ul&&li&们，&大伙儿收拾收拾行李，咱得重新来过&&&，浏览器向服务器请求了新的CSS文件，重新渲染页面。
Yahoo对网页设计性能的建议：&&英文版：/performance/rules.html&&中文翻译：/smjack/archive//1396895.html
相关文章：
上一篇文章：下一篇文章：
最新添加资讯
24小时热门资讯
Copyright © 2004- All Rights Reserved. 中国学网 版权所有
京ICP备号-1 京公网安备02号浏览器加载渲染网页过程解析_百度文库
两大类热门资源免费畅读
续费一年阅读会员，立省24元！
浏览器加载渲染网页过程解析
上传于||文档简介
&&浏​览​器​加​载​渲​染​网​页​过​程​解​析
阅读已结束，如果下载本文需要使用
想免费下载本文？
下载文档到电脑，查找使用更方便
还剩4页未读，继续阅读
你可能喜欢浏览器渲染文本过程分析
浏览器是我们最常用的软件之一，文本又是网页中最主要的元素，在浏览器显示文本的过程中有许多有趣的细节，值得展开来讲讲，或许能减少一些误,本文将详细介绍，需要了解的朋友可以参考下
浏览器是我们最常用的软件之一，文本又是网页中最主要的元素，在浏览器显示文本的过程中有许多有趣的细节，值得展开来讲讲，或许能减少一些误解。这是一个比较粗略的，概括性的介绍，尽可能不涉及过多的技术细节和具体实现，而立足于给 Web 开发者和设计师提供一些正确的概念。 下面的介绍主要根据我对 WebKit 和 Gecko (Firefox) 的印象来谈，其他的浏览器也大致相同，如有阙漏之处欢迎指出。 当浏览器收到来自 Web 服务器的网页数据之后，第一步是要把它解码成可以阅读的文本，因为历史原因，不同区域和语言的网页可能会使用不同的编码方式，而浏览器判断编码主要是依据以下方法： 1.Web 服务器返回的 HTTP 头中的 Content-Type: text/ charset= 信息，这一般有最高的优先级； 2.网页本身 meta header 中的 Content-Type 信息的 charset 部分，对于 HTTP 头未指定编码或者本地文件，一般是这么判断； 3.假如前两条都没有找到，浏览器菜单里一般允许用户强制指定编码； 4.部分浏览器 (比如 Firefox) 可以选择编码自动检测功能，使用基于统计的方法判断未定编码。 编码确定后，网页就被解码成了 Unicode 字符流，可以进行进一步的处理，比如 HTML 解析了，不过我们这里跳过 HTML/XML 解析的细节，单讲得到了解析后的文本元素之后该怎么处理。 因为我们得到的文本可能是很多种语言混杂的，里面可能有中文、有英文，它们可能要用不同的字体显示；也可能有阿拉伯文、希伯来文这种从右到左书写的文字；也有可能涉及印度系文字这样涉及复杂布局规则的文字；另外，还可能有网页内自己指定的文本语言，比如 &span lang=&jp&&日本语&/span& 这样的标记，使得日文汉字可以使用日文字体显示 (因为 Han Unification 导致这些汉字和中文里的汉字使用同样的代码点，尽管很多写法不同)，&lang& 属性也可以在 HTTP 头、&meta& 或者 &html& 出现，用于标记整个文档的全局语言，通常这是一种好的习惯，方便浏览器进行字体匹配。 为了统一处理所有这些复杂的情况，我们要将文本分为由不同语言组成的小段，在有的文本布局引擎里，这个步骤称为&itemize&，分解后的文本段常被称作&text run&，但是具体划分的规则可能根据不同的引擎有所区别，比如 HarfBuzz 和 ICU 一般是根据要使用的不同排版类来划分 (常称作&shaper&)，比如英语和法语可能使用同一个 shaper 排版，那么相邻的英语和法语文本就会划分到同一个 run 里，而希伯来文需要另一个 shaper，就划分到它自己的 run 里，以 HarfBuzz 为例，它有这样一些 shaper： 通用的 (适用于中文、英文等等大多数布局规则简单的语言) 阿拉伯文 希伯来文 印度系文字 高棉文 缅文 谚文 不少浏览器还会在这个划分下面，在确定具体使用的字体之后，根据使用字体的不同划分更细的 run，这种 run 可能称作&SimpleTextRun&，每个都会使用和相邻不同的字体，最后把它们逐一交给 shaper 进行排版得到要绘制的字形，这样一来，shaper 的工作就被简化为在确定的语言、确定的字体下排版确定的文本，生成对应的字形和它们应该放置的位置、占用的空间。下面先详细说说确定字体的步骤。 说到字体，首先必须提到的就是 CSS 里的 font 和 font-family 等规则。比如这样的规则： 代码如下: p { font-family: Helvetica, Arial, sans- } strong { font-weight: } 如果对于这样一段文本： 代码如下: &p&A quick brown fox &strong&jumps&/strong& over the lazy dog.&/p& 表示这个段落里优先使用 Helvetica 这个 family 的字体，如果找不到，就找 Arial，如果还是找不到，就用浏览器设置的默认非衬线字体 (有的浏览器，比如 Safari 只给你一个设置，有的像 Firefox 则允许根据不同语言设置，这时可以根据前面分析得到的文本 run 语言信息来判断该用哪个)，这个过程非常简单，大家都很好理解。稍微复杂一点的是&jumps&，它应该继承父元素的 font-family，也用 Helvetica，但不用默认的 Regular，而用 Bold 版本，假如找不到 Helvetica Bold，就找 Arial Bold，否则就找浏览器设置的那个字体的 Bold 版本，假如都没有呢？就要考虑用人工伪造的方式来显示粗体了，这个且按下不谈，先看对于中文常见的情况：CSS 指定的字体没有覆盖我们需要的文本时，该怎么做。比如还是上面的 CSS 规则，但对这样的文本： 代码如下: &p&一只敏捷的狐狸...&/p& 这里的&一只敏捷的狐狸&该用什么字体呢？假设 CSS 里具体指定了中文字体，比如 Helvetica, STHeiti, sans-serif，那很简单，按照英文字体一样的规则来判断：逐个字符尝试当前的字体是否提供了针对该字符的字形，如果没有则尝试下一个，要是到了最后都没找到匹配的字体呢？CSS 规范里只简单的说执行&system font fallback&，但这个过程在不同的浏览器下可能很不一样，比如 WebKit 会使用 font-family 列表里的第一个字体和这段文本所属的语言来寻找 fallback 字体，像 Times 这样的 serif 字体对应的中文 fallback 字体，在 Mac OS X 下是华文宋体 (STSong)；而 Firefox 则会根据 sans-serif 这样的通用 font family 和对应的语言匹配到设置中针对对应语言的默认字体，比如在 Mac OS X 默认的中文非衬线字体是华文黑体 (STHeiti)。Linux 下一般通过 fontconfig 去根据语言、风格等参数来选择 fallback，但不同浏览器的实现还可能有区别；Windows 下则一般会使用系统的 Font Linking 机制，根据注册表内的 FontSubstitutes 信息来寻找。因为在这里不同的浏览器可能有不同的行为，所以建议在 CSS 中写明对应平台该用的字体。 具体的字体选择还有一些不太容易注意的细节，也是各个浏览器差异比较大的一点，可能会出现这样一些问题： 是否支持用字体的 PostScript name 选择：如 STHeiti 的 Light 版本又称作 STXihei，或者是否能用 full name 选择：有的浏览器不能正确地将 CSS 里对字体的 font-weight 或者 font-style 等要求映射到特定的字体上，尤其是在字体使用了非标准的 style 命名的情况下，考虑到很多厂商有自己的字体命名规则，这其实很容易出现，像 Helvetica Neue 的 UltraLight, Light, Regular, Medium, Bold 这些不同的 weight，是怎么对应到 CSS font-weight 的 100 到 900 数值上的？这就是特别容易出现 bug 的地方。 是否支持按 localized name 选择：比如能不能用 &宋体& 来代表 &SimSun&。以 Mac OS X 下的浏览器为例，Firefox 支持这样的写法，但基于 WebKit 的浏览器一般不支持，这样的问题 CSS 规范没有限定，所以无论哪种情况都是允许的。 总的说来，如果要保证最大限度的兼容性，在 CSS 书写的时候应该尽可能选择明确、不容易出错的写法，尽量少隐式地让浏览器自己确定 (be explict instead of implict)，虽然隐式写法通常比较简洁，但除非你 100% 确定想支持的浏览器在你想支持的平台下都能支持这个写法，否则还是不应该轻易用。 CSS3 新增的 @font-face 规则则是对于现有规则的扩展，提供了 web fonts 功能，但字体匹配算法的逻辑并没有改变，详细的算法可以看 CSS 规范里的说明。 当确定了字体以后，就可以将文本、字体等等参数一起交给具体的排版引擎，生成字形和位置，然后根据不同的平台调用不同的字体 rasterizer 将字形转换成最后显示在屏幕上的图案，一般浏览器都会选择平台原生的 rasterizer，比如 Mac OS X 下用 Core Graphics，Linux/X11 下用 FreeType，Windows 下用 GDI/DirectWrite 等等。关于这个步骤，typekit 的这篇 blog 可以作为参考。各个浏览器的差异主要来自使用的排版引擎可能对不同的语言支持有差异，调用 rasterizer 使用的参数可能有差异 (比如是否启用 subpixel rendering、使用的 hinting 级别等等)，但在同一个操作系统下的效果差别不会很大。 基于以上的介绍，可以尝试提出一个在现有浏览器下，针对中文用户的，书写 CSS 字体选择规则的建议，如下： 1.首先确定要选择字体的元素应该使用的字体风格，比如是衬线字体、非衬线字体还是 cursive、fantasy 之类的； 2.确定了风格之后，先选择西文字体，优先把平台独特的、在该平台下效果更好的字体写上，比如 Mac OS X 下有 Helvetica 也有 Arial，但 Helvetica (可能) 效果更好，Windows 下则一般只有 Arial，那么写 Helvetica, Arial 就比 Arial, Helvetica 或者只有 Arial 更好； 3.然后列出中文字体，原则相同，多个平台共有的字体应该尽量放在后边，独有的字体放在前面，还需要照顾到 Mac OS X/Linux 下一般用户习惯用(细)黑体作为默认字体，Windows 下习惯以宋体作为默认字体的情况，比如 STXihei, SimSun 这样的写法比较常见，如果写作 SimSun, STXihei，但 Mac OS X 上装了 SimSun 效果就不会太好看。 4.最后还是应该放上对应的 generic family，比如 sans-serif 或者 serif。 5.尽量用字体的基本名称 (比如 English locale 下显示的)，而不要用本地化过的名称。除非特殊情况 (Windows 下&某些&浏览器在特定编码下只能支持本地化的字体名称)。Mac OS X 下字体名称可以用 Font Book 查到 (菜单 Preview -& Show Font Info)，Windows 下字体信息在微软的网站可以得到，Linux/X11 下可以使用 fc-list 命令查到。 6.字体名称中包含空格时记住用引号扩起，比如 &American Typewritter& 和 &Myriad Pro&。 7.文档开头最好指明语言，比如 &html lang=&zh-CN&&，可以使用的语言标记参见 W3C 的说明。