1.3 一次页面加载的完整流水线
1.3 一次页面加载的完整流水线
本节摘要：页面加载是一条多道工序的流水线——取文档、解析建树、取样式、算样式、排布局、分层合成、绘制上屏，脚本还可能在中间改写结构。本节跟车走完全程，标出每道工序对应哪个班组，并解释"白屏多久、卡顿在哪"这类体验问题的流水线根源，为后续所有章节提供一张总参照图。
跟车走一遍：从回车到上屏
上一节认识了班组，这一节看流水线。把页面加载想象成工厂接收一张订单：浏览器向服务器要文档，就像采购部去提货；文档到手后进入解析车间，读出结构；样式文件随后进厂，两棵树合并计算出每个元素的最终外观；接着排版车间定下每个盒子的位置与大小，合成车间把页面分层，绘制车间把像素刷上屏幕。整条线上任何一道工序堵住，你看到的就是白屏、错位或卡顿。
图 1：页面加载流水线泳道图
泳道图上有一条容易被忽略的回环虚线：脚本执行后如果改了结构或样式，流水线要折回去重算样式、重排布局。这解释了一个日常现象——页面加载完又跳了一下，多半是脚本进场改了尺寸。记住"回去重算要花钱"这个直觉，第 5 章性能优化会逐段砍掉不必要的返工。
每道工序在决定你的体验
流水线不只是背景知识，它直接对应你能感知的体验指标。白屏时间，取决于网络往返加文档解析加首次绘制，样式表放在文档头部能让浏览器尽早拿齐装修材料，避免画一遍再推翻；内容跳动，多半是图片没预留尺寸，排版车间排完版图片才到货，只好挤开周围元素重排；交互卡顿，常见原因是行为班把重活儿压在主线程上，绘制工序排不上队。
用生产看板当例子走一遍。浏览器取回看板文档，从上到下解析：先遇到标题和统计卡片，再遇到一张样式表，解析暂停、等样式到货；样式到手继续解析表格与表单；快结束时遇到一段脚本，如果没有特殊标记，解析再次暂停、先执行脚本——脚本要找表单元素接线，此刻表单已在树中，顺利接上；最后布局、合成、绘制，看板亮相。任何一环慢半拍，车间主任盯着的就是白屏。
<!-- 看板文档的加载顺序示意：各工位的进场时机 --> <head> <link rel="stylesheet" href="board.css"> <!-- 样式表在头部：解析身体前先备好装修材料，避免先画毛坯再翻新 --> <script src="board.js" defer></script> <!-- defer 标记：先别打断解析，等文档读完整再执行脚本 --> </head> <body> <header>今日生产看板</header> <table><!-- 工单表：解析到此时已可见骨架 --></table> <form><!-- 新增工单表单 --></form> </body>
对照实验（可在开发者工具网络面板观察）： - 样式表放头部：内容出现略晚，但出现即是成品样式，无闪烁 - 样式表放尾部：骨架先裸奔上屏，样式到货后页面突然变脸 - 脚本无 defer：解析中途暂停执行，白屏时间被拉长 - 脚本加 defer：解析一气呵成，文档读完后脚本一次性执行
第二个代码块是一张"对照实验清单"，建议学完 1.4 后亲手做一遍：把样式表挪到文档尾、把 defer 去掉，各刷新一次看差异。流水线的知识一旦配合肉眼观察，就再也忘不掉。
症状速查：把流水线当排错地图
流水线学完，最实际的用法是当排错地图。页面出了状况，先对症状定位工序，再去对应班组的地盘找原因，别上来就乱改：
症状 → 工序 → 地盘（速查表）： 白屏时间长：网络段或解析段被堵 → 查样式表与脚本的位置、查请求体积 内容跳动：布局工序返工 → 查图片是否预留了尺寸 点击没反应：脚本没接线或执行出错 → 控制台看红字 样式改了没生效：层叠裁决输了 → 元素面板看最终生效的规则 字体忽大忽小：字体文件晚到，回退字体顶班 → 预加载或统一回退设定
这张表此刻只需混个脸熟，它的每一行都会在后续章节展开成完整技能：样式没生效归 3.1 节的选择器与层叠，点击没反应归第 4 章的事件与调试，白屏与体积归 5.3 节的性能优化。这里要带走的是排错的第一习惯——先分诊，后动手。定位错了地盘，改得再勤快也是白忙；定位对了，往往一行代码就够。往后每章开头我们都会回到流水线上标注位置，这张速查表也会随之越读越厚。
💡 关键直觉：浏览器的目标不是"最快显示所有内容"，而是"尽快显示已就绪的内容"。理解这条流水线后，你写的每一行代码都能对号入座：它让哪道工序提前了，还是让哪道工序返工了。
三个常被问到的流水线问题
问题一：为什么改个字号页面会跳，改个背景色不会？ 字号属于几何信息，改动后布局工序要重算位置与大小，周围元素跟着挪动；背景色只影响绘制，位置不动、只是重新上色。这条"几何与外观的代价差异"是样式班内部最重要的一条性能直觉，3.5 节讲动画时会专门利用它——让动画只动外观属性，不动几何属性。
问题二：为什么脚本默认要打断解析？ 因为脚本可能改写后面的结构——比如就地生成一段内容，浏览器无法预知，只能停下来等它执行完，保证后续解析建立在脚本生效后的树上。defer 的本质是程序员向浏览器承诺"我不改后面的结构"，浏览器才敢放行。承诺要兑现：加 defer 的脚本里不该再依赖"此刻后面的元素还没解析"这类时序假设。
问题三：渲染引擎段的合成是什么？为何动画偏爱它？ 页面被切成若干图层，像一叠透明胶片。合成工序只负责把胶片按位置叠加，不动胶片上的内容。改变某个元素位置时若只影响它所在胶片，就跳过布局与绘制、直接重新叠加——这是开销最小的刷新路径。3.5 节的位移动画会落到这条快车道上，此处先埋个伏笔。
顺带留一个观察作业：在开发者工具里开一次性能录制，刷新页面，把录得的时间轴与上面的泳道图对照——每道工序都能在录制里找到对应的时间段。此刻看不懂细节完全没关系，第 5 章性能优化会教你怎么读它，这里先混个眼熟，知道"流水线可以被录像"这件事本身就值回票价。
本节要点回顾
- 全程工序：取文档、建树、配样式、执行脚本、布局、合成、绘制，脚本改树会触发回环重算；
- 白屏根源：网络往返、样式表晚到、脚本打断解析，是延迟亮相的常见原因；
- 放置策略：样式表进文档头部、脚本加 defer 标记，是最容易学到手的加载优化；
- 代价分级：几何改动引发重排、外观改动只重绘、图层改动仅重合成，代价依次递减；
- 观察手段：开发者工具的网络面板能亲眼看对照实验的结果，1.4 节即将上手；
- 总参照图：此后每章开头都会在这条流水线上标注本章工位，值得回来重看。
流水线认得差不多了，下一节领取工位装备，把开发环境搭起来。