CSS Houdini:浏览器渲染引擎的「后门」如何让开发者突破CSS的边界

2018年,当CSS Paint API首次在Chrome 65中落地时,很多开发者可能没有意识到,这标志着Web开发进入了一个全新的阶段——浏览器终于向开发者敞开了渲染引擎的「后门」。 ...

9 min · 4348 words
Blog Cover

postMessage的性能真相:Web Workers通信为何总在关键时刻掉链子

2009年,Web Workers作为HTML5规范的一部分首次引入浏览器。十五年后,尽管多核CPU已成标配,但大多数Web应用依然在单线程的泥潭中挣扎。问题不在于开发者不知道Web Workers的存在——而在于当他们真正尝试使用时,发现数据传输的开销可能比计算本身更令人头疼。 ...

13 min · 6327 words

前端构建工具的四十年演进:从任务运行器到原生ESM开发服务器的技术博弈

2019年,一家电商公司的前端团队遇到了一个奇怪的问题:每次修改一行CSS代码,需要等待32秒才能在浏览器中看到效果。开发人员习惯了在代码编辑器和浏览器之间频繁切换,32秒的等待时间足以让他们忘记刚才想做什么改动。这不是个例——在那个时间点,一个中型React项目的Webpack冷启动时间动辄超过10秒,HMR(热模块替换)响应时间经常超过300毫秒。 ...

23 min · 11081 words

React Fiber架构如何让前端框架打破主线程阻塞困境

2017年,React团队做出了一个大胆的决定:重写React的核心算法。这个被称为Fiber的项目历时两年多,彻底改变了React处理更新的方式。为什么要花这么大力气重写一个已经广泛使用的库?答案藏在浏览器的单线程本质里。 ...

14 min · 6615 words
Blog Cover

为什么setTimeout不是最佳让出方案:从4ms最小延迟到优先级续行的技术突围

2023年9月,土耳其电商平台Trendyol的产品详情页INP指标高达963毫秒,处于"差"评级。用户点击商品后,页面近乎冻结。六个月后,这个数字降到了481毫秒——INP改善50%,点击率提升1%。转折点只改动了了几行代码:用scheduler.yield()替换了setTimeout。 ...

14 min · 6667 words

浏览器渲染为何需要"画地为牢"?从重排重绘到CSS Containment的性能革命

2024年,一家大型体育用品电商网站发现他们的商品分类页面在移动端存在严重的响应性问题——用户点击筛选按钮后,页面需要数百毫秒才能响应。Chrome DevTools的性能分析显示,问题根源在于浏览器渲染管道的过度工作:每当用户操作触发DOM变化,浏览器就需要重新计算整个页面的布局,即使变化的只是屏幕可见区域之外的几个商品卡片。 ...

15 min · 7313 words

CSS Flexbox布局入门:从弹性容器到项目对齐的完整指南

当你尝试让一个元素在页面中水平垂直居中,是否曾经写过这样的代码:设置绝对定位,然后手动计算top: 50%和left: 50%,最后还要加上负的margin来修正偏移?当你在做导航栏时,是否为如何让几个链接均匀分布而头疼?这些问题在CSS Flexbox出现之前,确实需要各种"黑魔法"才能解决。 ...

7 min · 3090 words