你去看看gmail的页面源码……

CSS和HTML混一起不是很常见的一种性能优化手段吗，特别是有在强大的CDN和精良的缓存控制的情况下

没有人伤的话，正常人这种事不会提出保险赔付以外的赔偿的，如果要提请他们走法院诉讼就行，一切按照法律来

@lunacory 我就是干净重装的，连数据都没恢复- -

@cikelengfeng appstore的应该也不是handoff，比如我去陆家嘴的时候就会出现这图标，而当时我电脑根本在10公里以外的家里还没开机

如果显示器支持DP就mini DP -> DP吧

更新一下，最后我把Yosemite的毛玻璃半透明效果关了，用了2天未见卡顿

@ioth Early 2013 rMBP顶配

你觉得没有密码，怎么认证用户“同意你查询”呢？

如果是Windows平台，haozip有个批量转压缩格式的功能可以去掉密码，我平时就这么用，打开haozip后按ALT+Q就会出来

苹果只是想告诉你，OSX也应该进入关机/重启时代了，向Windows看齐

从摄影的角度来说，左边的图可调整空间要更大- -

@nina 我的用户名[at]gmail v2没有私信我也不大敢就这么公开留个Q……

Safari的卡顿和BUG让我非常受不了，又会拖慢系统，但是考虑到全平台的支持和iCloud tab、Handoff等功能，还是被绑在上面了……

@raincious Thanks，确实一边看着吐槽类动画一边看这贴子，当时就想着用一些戏谑的语气但显然过火了，在此道个歉 @huaxinjiayou

我的Numbers可以

@taoche 我们做网络层面的资源加载优化，重点考虑的是2个指标：

第一是单资源加载时间，这个主要由带宽和资源大小决定，所以我们会做压缩，会开gzip，会使用缓存
第二是网络延迟，这个和资源的大小几乎没有关系，哪怕就一个TCP包，要和服务器做一次Network Roundtrip的通信，也得经受2次的网络延迟，所以我们会有Connection: keep-alive来减少TCP链接打开的次数（因为三次握手是严重受网络延迟影响的），所以我们追求文件的合并

CDN能减少网络延迟但并不能消除，另一方面网络延迟也和客户端（比如开个迅雷试试）的网络状况有很大关系，网络是前端优化领域最不可控的部分，因此一个策略就是将不可控的内容尽可能减少，合并也是受这思想影响（当然我不是说全合并了就一定是最好的）

请求优化是一个很有意思的事，比如楼主站点在我的电脑（普通的10M带宽中国电信）下，是这样加载的：

http://img3.picbed.org/uploads/2014/10/QQ20141025_1_2x.png

从图里很容易能看到这些：

1. Chrome是一批次4个请求的，4个占满以后后面的请求会阻塞
2. base.js作为一个67KB的资源，同时是后面几个js的基础，所以这个67KB不加载完，其它js是不会加载的
3. 在base.js这个大家伙加载完以前，浏览器已经把其它的图片、CSS全下载完了，同时还有段时间空在那，也就是说这段时间有几ms可以用来加载其它js这个页面就能提前几ms可用
4. 因为其它资源较少都提前完成了，common.js和index.js可以并行下载，这2个不合并在网络延迟稳定的情况下不影响整站性能，但增加了一个SPOF

从图中也可以得出一些优化的结论：

1. base.js中包含seajs，但也包含了其它东西，导致它太大了，且作为了性能的瓶颈
2. 如果把seajs单独拆开来，它依旧能和base.js并行加载不会影响性能（浏览器优先下载脚本，会把图片资源滞后），同时可以让依赖seajs的common和index提前开始下载更早可用，这是一种优化策略
3. 让seajs独立出来，通过seajs的并行加载能力（其实不用也可以实现并行），再把base拆成若干个小包，比如20KB一个共3个，从图中看几乎可以和那些图片同时完成下载，浏览器不会有段时间空着没事干，这个恰恰是和“合并”相反的一种策略，但有优化的效果，所以我说了并不是全合并一定是好的
4. 图片其实能合并或用datauri，但是考虑到图片并不是SPOF型资源，在这个Network图上也不会形成瓶颈所在，所以不合并不会造成什么问题

至于你提到的“做个CDN并发远比合并JS文件来的好”我确实不明白是什么意思，在哪几方面，怎么样的数据能显示出CDN并发好于JS文件合并呢？

@airyland 百度联盟相关部门，广告管家、移动SSP等若干个产品，主攻单页应用方向

我们这边很简单，PM对功能开发用时没有话语权，工程师依照能把东西做得优秀为前提进行时间估算并以此推进项目，轮不到PM急着上功能。对于特殊情况如市场限制某些重大功能不出来产品就完了，工程师表示理解并快速上线，但会在此前要求上线后PM会留出足够的时间来给工程师尽快完成相关的改造和优化，比如每个敏捷迭代要有1/2的时间由工程师自主控制

另一方面，本身开发团队这边就不会投入所有工程师人力做业务项目，始终有1/5左右的人力（比如团队10个人，就有2个人）在业务之外去做一些技术的积累和对代码的审查，从代码中发现问题并及时改进。在之前这1/5的人力一般是交给高级别工程师，最近想尝试使用转盘式让每个工程师都有这样的机会

百度是非常技术导向的一个公司（相比A和T），技术人员的话语权可是很强的，这也是为啥我快5年了也不想离开，在这里可以非常愉快地和技术人员相处并得到足够的时间空间自我提高，可以认真细致对待每一行代码，去思考大量可能的优化并付诸实施

@huaxinjiayou 就像简历里大家都会拼命表达自己很不错很适合工作一样，我想前端使用一个自己做的小站代替简历是个很好的方向，但这个小站也应该和简历一样去拼命表达自己的前端能力和对前端技术的态度才是：）

虽然有4年多没去应聘了，不过面的人是不少，以上是感想- -