浏览器地址栏里敲下那串字符，回车。不到一秒，屏幕上铺开一张图文并茂的页面。多数人觉得这事天经地义。可拆开来看，这背后跑着一套相当精巧的协作机制。

HTML文件本身不过是一堆纯文本。服务器把它吐出来的时候，它没有任何颜色、没有字体、没有布局。真正让它“活”过来的是浏览器里的渲染引擎——Chrome用Blink，Firefox用Gecko，Safari用WebKit。引擎拿到HTML后做的第一件事是解析，把标签逐个拆开，构建出一棵DOM树。你写的<div>、<p>、<span>在这棵树里各占一个节点，层级关系跟你的嵌套写法完全对应。

光有DOM还不够。CSS文件或<style>块里的规则会被解析成另一套结构，引擎拿它跟DOM做匹配，算出每个节点最终该长什么样。这个过程叫样式计算。麻烦的地方在于优先级：行内样式压过ID选择器，ID压过类名，类名压过标签名。写页面的人多少都踩过这个坑——明明写了新样式，页面上纹丝不动，打开开发者工具一看，被另一条权重更高的规则盖掉了。

样式定了，位置还得算。布局阶段，引擎根据盒模型逐层计算每个元素的尺寸和坐标。块级元素独占一行，行内元素顺着文字流排。遇到float或者flex、grid这类布局方式，计算逻辑会更复杂。一个页面上几百个元素，每个都得算出精确的像素位置，这一切通常在十几毫秒内完成。

布局结束就进入绘制。引擎把每个节点转成屏幕上的实际像素——背景色、边框、阴影、文字，一层层画上去。如果页面里有合成层（比如用了transform或opacity动画的元素），这部分会交给GPU单独处理，不拖累主线程。最后所有层合并，你看到了完整的页面。

JavaScript在这条流水线里扮演的角色最微妙。它通过DOM API能随时修改结构、样式、内容，但每次修改都可能触发重排或重绘。改一个元素的width，浏览器得重新计算布局；改color，至少得重绘。频繁操作DOM的代码如果写得不够小心，页面就会卡顿。我见过一个列表页，每次滚动都动态计算元素高度并写回样式，结果帧率掉到个位数。后来改成CSS的position: sticky，问题直接消失。

网络层同样关键。一个页面往往要加载几十个资源：HTML、CSS、JS、图片、字体。浏览器用HTTP/2的多路复用并行拉取，但CSS会阻塞渲染——引擎必须等CSSOM构建完才能开始布局。JS更霸道，<script>标签默认会暂停HTML解析，直到脚本下载并执行完毕。所以现代做法是把非关键JS加上defer或async，让解析不被卡住。

移动端又添了一层变数。视口宽度、设备像素比、触摸事件，都得单独处理。<meta name="viewport">这行标签写错了，整个布局在手机上就崩了。响应式设计不是可选项，是默认要求。

回过头看，一个Web页面从请求到呈现，牵扯了解析、样式、布局、绘制、合成、网络、脚本执行好几个环节。每个环节都有优化空间，也都有坑。写页面容易，写好难。那些看起来“理所当然”的流畅体验，背后是浏览器引擎和开发者共同较劲的结果。