跳到正文

浏览器渲染与性能 ​

  • 状态:未准备
  • 适用方向:前端 / Go 全栈
  • 最近复习:待填写
  • 下次复习:待安排

一句话回答 ​

浏览器将 HTML/CSS 解析成结构和样式,再进行布局、绘制与合成;优化应先确定瓶颈是网络、主线程、布局还是更新范围,再验证用户体验指标。

原理解释 ​

页面怎样显示出来? ​

导航后经历名称解析与连接、获取资源、增量解析 HTML;发现的 CSS、脚本和图片可以继续下载。DOM 和样式计算参与生成渲染结构,布局确定几何信息,绘制记录视觉内容,合成组织最终帧。实际流程有并行、增量和缓存,不是所有资源下载完才统一渲染。

重排、重绘、合成 ​

改变几何尺寸可能使布局失效,改变颜色通常只需重绘;某些 transform/opacity 动画可能利用合成,但不是无条件“GPU 加速且零成本”。在写入样式后立刻读取 offsetHeight 等布局数据,可能触发同步布局;循环交替读写会造成布局抖动。

js
// 先收集读取结果,再集中写入,避免每项都写后读。
const heights = cards.map(card => card.offsetHeight)
cards.forEach((card, i) => { card.style.height = `${heights[i] + 8}px` })

script 的 async 与 defer ​

经典外部脚本默认会阻塞解析;defer 并行下载,解析完成后按文档顺序执行,早于 DOMContentLoaded;async 下载完成即择机执行,不保证文档顺序。模块脚本默认有类似 defer 的解析时机,但依赖图和 async 等条件需另外考虑。

场景与边界 ​

优化方向:减少关键资源、代码分割、合理压缩缓存、给图片预留尺寸、拆分长任务、降低无意义更新。首屏关键图不应一概懒加载。rAF 与帧节奏对齐,但不会消除回调里的昂贵工作,后台页面还可能暂停它。

LCP 看主要内容显示时间,INP 看交互响应,CLS 看布局稳定性。实验室测量用于定位,真实用户数据反映实际分布;不要把单次 Lighthouse 分数当全部用户体验。

项目中的应用 ​

结合 Blog 目录与动画 和 SimulSpeak 字幕面板,在相同设备、生产构建和固定操作下记录 Performance/Profiler;收益数值仍待测。

常见追问 ​

  • CSS 阻塞 HTML 解析吗? 通常不直接阻塞解析,但阻塞相关渲染,并可能间接影响需要等待样式的脚本。
  • 内存泄漏怎么查? 重复进入退出同一页面,比较堆快照和保留路径,检查监听、定时器、脱离 DOM 的节点及媒体资源。
  • 防抖还是 rAF? 防抖等连续操作结束,rAF 聚合到帧节奏;根据交互目标选择。

参考资料 ​

理解机制,讲清取舍,用复盘检验掌握。