用 Fiddler 监控，在 IE6 下，资源下载顺序为：
很明显，下载顺序从上到下，文档流中先出现的资源先下载。在 IE8, Safari, Chrome 等浏览器下也类似。
Firefox 对下载顺序做了优化：
Firefox 会将 js, css 提前下载，而将图片等资源延迟到后面下载。
对于渲染，利用 Fiddler 将网速调慢，可以看到 css 下载后会马上渲染到页面，渲染和下载同步进行。js 的解析和运行，也类似。
对于 js 运行，以及页面加载相关事件的触发，特别做了测试。在 Firefox 下，打开测试页面：
[22:13:32.947] HTML Start[22:13:32.947] normal inline script run time[22:13:34.904] normal external script run time[22:13:35.775] [body] normal external script run time[22:13:35.789] [body end] normal external script run time[22:13:35.789] HTML End[22:13:35.791] deferred inline script run time[22:13:35.791] deferred external script run time[22:13:35.793] DOMContentLoaded[22:13:38.144] images[0] onload[22:13:38.328] images[1] onload[22:13:39.105] images[2] onload[22:13:39.105] images[3] onload[22:13:39.106] window.onload
很明显，JS 的运行严格按照文档流中的顺序进行。其中 deferred 的脚本会在最后运行（注：Firefox 3.5 开始支持 defer，而且支持得很完美）。
再来看下 IE8，结果如下：
[22:33:56.806] HTML Start[22:33:56.826] normal inline script run time[22:33:57.786] normal external script run time[22:33:57.812] deferred inline script run time[22:33:57.816] document.readyState = interactive[22:33:57.934] [body] normal external script run time[22:33:58.310] [body end] normal external script run time[22:33:58.310] HTML End[22:33:58.346] deferred external script run time[22:33:58.346] images[0].readyState = loading[22:33:58.346] images[0].readyState = complete[22:33:58.346] images[0] onload[22:33:58.361] doScroll[22:33:58.451] images[1].readyState = loading[22:33:58.479] images[1].readyState = complete[22:33:58.479] images[1] onload[22:33:58.794] images[2].readyState = loading[22:33:58.854] images[2].readyState = complete[22:33:58.854] images[2] onload[22:33:58.876] images[3].readyState = loading[22:33:58.876] images[3].readyState = complete[22:33:58.876] images[3] onload[22:33:58.887] document.readyState = complete[22:33:58.888] window.onload
可以看出，IE8 下，defer 只对 external 脚本有效，对 inline 脚本无效。另，与 DOMContentLoaded 最接近的是 doScroll. 这是 doScroll 被广泛用来模拟 DOMContentLoaded 的原因。小心：仅仅是模拟，细节上并不等价。
还可以得到一个有点意外的结果：放在 body 结束前的脚本，执行时，依旧最好放在 domready 事件中。无论在 Firefox 还是 IE 下，解析到 HTML End 时，并不代表 DOM 可以安全操作，特别是页面比较复杂时。
从上面数据中，也可以看出 YSlow 性能优化法则里，建议将样式置顶和脚本置底的根据。
有兴趣的可以进一步测试动态添加样式和脚本的情形，会稍有不同，但没有特别 surprise.
最后总结下：
页面资源的下载顺序是从上到下的，文档流中先出现的资源先下载（注：存在并发，具体请参考 UA Profiler）。当某一样式下载完成时，会立刻渲染到页面（体现了层叠样式表中层叠在渲染时的含义）。当某一脚本下载完成时，也会立刻解析和运行。脚本的运行严格按照文档流中的顺序进行，deferred 的脚本会在正常脚本运行之后运行（Firefox 和 IE 下）。
特别需要留意：脚本运行时，会暂停该脚本之下所有资源的下载（因为脚本可能改变文档流，甚至跳转页面，浏览器的暂停策略是合理的）。要小心内联脚本，经常会阻塞后续下载。
好了，废话不多说。以上结果，建议各位亲自测试，反复测试，疯狂测试，一直到眼花缭乱稀里糊涂恍然大悟继续糊涂为止……
浏览器加载,渲染
3月27日消息，苹果宣布2024年全球开发者大会（WWDC）将于6月10日至6月14日举行，巧合的是，这次大会与端午假期重合。
苹果官方表示：
在线参加 Apple 每年规模最大的开发者盛会。亲眼见证 Apple 最新平台、技术和工具的发布。了解如何创建和改进你的 App 和游戏。与 Apple 设计师和工程师互动交流，与全球开发者社区建立联系。以上活动均免费在线举行。
探索各种新的工具、框架和功能，助力你打造出理想的 App 和游戏。通过视频讲座学习新技能，与 Apple 专家进行一对一会面，以推进你的项目，完善你的构思。
Swift Student Challenge 旨在支持和鼓舞下一代开发者、创作者和企业家。太平洋时间 3 月 28 日，我们将公布今年的获奖者名单。获奖者将有资格参加在 Apple Park 举办的特别活动。我们还会选出 50 名杰出获胜者，他们将受邀前往库比提诺，获得为期三天的非凡体验，包括参加 Apple Park 的特别活动。
RTX 5090要首发 性能要翻倍！三星展示GDDR7显存
三星在GTC上展示了专为下一代游戏GPU设计的GDDR7内存。
首次推出的GDDR7内存模块密度为16GB，每个模块容量为2GB。其速度预设为32 Gbps（PAM3），但也可以降至28 Gbps，以提高产量和初始阶段的整体性能和成本效益。
据三星表示，GDDR7内存的能效将提高20%，同时工作电压仅为1.1V，低于标准的1.2V。通过采用更新的封装材料和优化的电路设计，使得在高速运行时的发热量降低，GDDR7的热阻比GDDR6降低了70%。