延迟15分钟 资讯由
延迟15分钟 资讯由
延迟15分钟 资讯由
&&---中化集团下属企业---中化石油/中化实业中化泉州石化中化化肥沈阳化工研究院中化国际中国种子集团有限公司中化蓝天中化河北中化青岛中化江苏中化招标中化塑料中国金茂怡生园远东宏信外贸信托中化财务公司
&&&&---政府机构---中央政府门户网站外交部国防部发展改革委教育部科技部工业和信息化部国家民委公安部监察部民政部司法部财政部人力资源社会保障部国土资源部环境保护部住房城乡建设部交通运输部水利部农业部商务部文化部国家卫生和计划生育委员会人民银行审计署国资委海关总署税务总局工商总局质检总局广电总局新闻出版总署(版权局)体育总局安全监管总局统计局林业局知识产权局旅游局宗教局参事室国管局预防腐败局侨办港澳办法制办新华社中科院社科院工程院发展研究中心行政学院地震局气象局银监会证监会保监会电监会社保基金会自然科学基金会台办新闻办档案局信访局粮食局能源局烟草局外专局公务员局海洋局测绘地信局民航局邮政局文物局食品药品监管局中医药局外汇局煤矿安监局密码局航天局原子能机构国家语委国务院扶贫办国务院三峡办南水北调办
&&&&---新闻媒体---新华网人民网光明网央视网中国新闻网中国经济网中国网中国广播网国际在线中国日报网中国青年网
&&&&---中央企业---中国核工业集团公司中国核工业建设集团公司中国航天科技集团公司中国航天科工集团公司中国航空工业集团公司中国船舶工业集团公司中国船舶重工集团公司中国兵器工业集团公司中国兵器装备集团公司中国电子科技集团公司中国石油天然气集团公司中国石油化工集团公司中国海洋石油总公司国家电网公司中国南方电网有限责任公司中国华能集团公司中国大唐集团公司中国华电集团公司中国国电集团公司中国电力投资集团公司中国长江三峡集团公司神华集团有限责任公司中国电信集团公司中国联合网络通信集团有限公司中国移动通信集团公司中国电子信息产业集团有限公司中国第一汽车集团公司东风汽车公司中国第一重型机械集团公司哈尔滨电气集团公司中国东方电气集团有限公司鞍钢集团公司宝钢集团有限公司武汉钢铁（集团）公司中国铝业公司中国远洋运输（集团）总公司中国海运（集团）总公司中国航空集团公司中国东方航空集团公司中国南方航空集团公司中国中化集团公司中粮集团有限公司中国五矿集团公司中国通用技术（集团）控股有限责任公司中国建筑工程总公司中国储备粮管理总公司国家开发投资公司招商局集团有限公司华润（集团）有限公司中国港中旅集团公司[香港中旅（集团）有限公司]国家核电技术有限公司中国商用飞机有限责任公司中国节能环保集团公司中国国际工程咨询公司中国华孚贸易发展集团公司中国诚通控股集团有限公司中国中煤能源集团公司中国煤炭科工集团有限公司中国机械工业集团有限公司机械科学研究总院中国中钢集团公司中国冶金科工集团有限公司中国钢研科技集团公司中国化工集团公司中国化学工程集团公司中国轻工集团公司中国工艺（集团）公司中国盐业总公司华诚投资管理有限公司中国恒天集团公司中国中材集团公司中国建筑材料集团有限公司中国有色矿业集团有限公司北京有色金属研究总院北京矿冶研究总院中国国际技术智力合作公司中国建筑科学研究院中国北方机车车辆工业集团公司中国南车集团公司中国铁路通信信号集团公司中国铁路工程总公司中国铁道建筑总公司中国交通建设集团有限公司中国普天信息产业集团公司电信科学技术研究院中国农业发展集团总公司中国中纺集团公司中国外运长航集团有限公司中国丝绸进出口总公司中国林业集团公司中国医药集团总公司中国国旅集团有限公司中国保利集团公司珠海振戎公司中国建筑设计研究院中国冶金地质总局中国煤炭地质总局新兴际华集团有限公司中国民航信息集团公司中国航空油料集团公司中国航空器材集团公司中国电力建设集团有限公司中国能源建设集团有限公司中国黄金集团公司中国储备棉管理总公司中国广核集团中国华录集团有限公司上海贝尔股份有限公司彩虹集团公司武汉邮电科学研究院华侨城集团公司南光（集团）有限公司中国西电集团公司中国铁路物资总公司中国国新控股有限责任公司安全检查中...
请打开浏览器的javascript，然后刷新浏览器
<.cn 正在遭受攻击，请稍等片刻.
还剩 5 秒&QQ空间的前端技术水平如何？
感觉挺复杂，挺卡的一个东西，或者说加载比较缓慢？&br&只是打开Qzone首页（我的动态，这里指&a href=&///?target=http%3A//user./XXXXXXXXX& class=& external& target=&_blank& rel=&nofollow noreferrer&&&span class=&invisible&&http://&/span&&span class=&visible&&user./XXXXX&/span&&span class=&invisible&&XXXX&/span&&span class=&ellipsis&&&/span&&i class=&icon-external&&&/i&&/a&），鼠标没有移动到屏幕的任何元素上，也没有进行任何点击，就有295个请求，图片就不说，很合理，但是却加载了114个JavaScript文件。前端性能优化原则难道不是尽量合并请求吗？ &br&看得出用了异步加载，但是从网页背景出现颜色，到真正各个控件渲染完成能用能流畅滚动，还是过了很久。&br&感觉有些不可思议。(这是我小号我刚开通的QQ空间，没有装扮，也没加上任何奇奇怪怪的挂件。)&br&&img src=&/043fd3e5d552fb46a4eb3aa_b.jpg& data-rawwidth=&357& data-rawheight=&347& class=&content_image& width=&357&&&img src=&/881b23f02c45c6248954b_b.jpg& data-rawwidth=&508& data-rawheight=&286& class=&origin_image zh-lightbox-thumb& width=&508& data-original=&/881b23f02c45c6248954b_r.jpg&&
感觉挺复杂，挺卡的一个东西，或者说加载比较缓慢？只是打开Qzone首页（我的动态，这里指），鼠标没有移动到屏幕的任何元素上，也没有进行任何点击，就有295个请求，图片就不说，很合理，但是却加载了114个JavaScript文件。前端性能优化原则难道不是尽量合并请求吗？ 看得出用了异步加载，但是从网页背景出现颜色，到真正各个控件渲染完成能用能流畅滚动，还是过了很久。感觉有些不可思议。(这是我小号我刚开通的QQ空间，没有装扮，也没加上任何奇奇怪怪的挂件。)…
按投票排序
利益相关：QQ空间 web前端开发，你吐槽的页面，就是我做的。知乎从来都是只看不答，这次为了答题，总算注册一个知乎大号。这个回答仅对题主提出的做的不好的地方做下反思和一些解释，至于技术牛不牛，不在这里探讨，反正我是不牛的那个。妈妈说做错了就得承认，黄老师说不能鸭子死了嘴壳子硬。感谢题主指出了问题，让我可以再回过头来看做得不好的地方（老大总算要安排时间给我优化啦，哈哈哈）。一开始，关于文件数加载，先提出我的看法：1.最重要的时间是什么，是用户首次可交互时间，那么为了尽可能的优化这个时间，我们要保证在这之前请求尽可能的少，这是必须做到极致的。2.有些功能，用户一进来并不会立刻使用，那么这些功能的文件，只需要在用户准备用它之前加载好即可。什么时候加载，多少个请求，其实影响不大。好啦，下边一个一个的说吧。1.加载了114个js文件我进自己空间，清掉缓存，无缓存状态，js 122个，吓尿了。再次进空间，带缓存访问，还好，文件数虽多，大多数都是从from cache，还好还好。回过来继续看哪些文件可合并，哪些文件不可合并。逐个说下吧。1）基础库文件 3个这几个是基础库，可不可以合呢？当然可以合，为什么不合呢？基础库文件基本是不会改动的，我们又设置了长缓存。对大部分用户来说，这个文件是会使用缓存的，如果我们把这3个文件突然改成合并加载，所有用户都会重新下载这部分文件，浪费流量啊，浪费流量就是浪费钱。这几个是基础库，可不可以合呢？当然可以合，为什么不合呢？基础库文件基本是不会改动的，我们又设置了长缓存。对大部分用户来说，这个文件是会使用缓存的，如果我们把这3个文件突然改成合并加载，所有用户都会重新下载这部分文件，浪费流量啊，浪费流量就是浪费钱。2）说说发表框的文件 3个这些文件可不可以合呢，从抓包可以看出，其实我是合了的。为什么是3个而不是1个呢？因为合成1个url就太长了，超出老ie的限制，就要报错。没办法，拆成3个。那为什么不低版本ie 3个请求，新版本浏览器1个请求呢？有些其他原因，这里不好说这些文件可不可以合呢，从抓包可以看出，其实我是合了的。为什么是3个而不是1个呢？因为合成1个url就太长了，超出老ie的限制，就要报错。没办法，拆成3个。那为什么不低版本ie 3个请求，新版本浏览器1个请求呢？有些其他原因，这里不好说3）个人中心的各种模块 8个文件这里的合并没做好，从长度上来说，可以减少到3到4个请求，这里有优化空间4）音乐播放器文件 3个这里也有优化空间，不多说啦这里也有优化空间，不多说啦5）评论框的文件 20个这个可以合并一下，为什么之前不合并呢？要讲好长一个故事，题主估计也不想听，不废话啦这个可以合并一下，为什么之前不合并呢？要讲好长一个故事，题主估计也不想听，不废话啦6）其他接入的团队的文件 11个合不合呢？我也想合，待我去问问7）/qzone/mall/目录文件 6个有个基础库重复加载啦，惭愧惭愧。其他的代码都是一些功能模块，可以合并么？也可以，不过这些模块进某些页面时用，有些页面时不用，而且不是首屏的功能，多几个请求对体验的影响不大。总的来说，合也可，不合也可。有个基础库重复加载啦，惭愧惭愧。其他的代码都是一些功能模块，可以合并么？也可以，不过这些模块进某些页面时用，有些页面时不用，而且不是首屏的功能，多几个请求对体验的影响不大。总的来说，合也可，不合也可。8）/qzone/photo/目录文件 8个这个目录的文件倒是可以把请求合并一下，预计可以减少到3 到4个请求。这个目录的文件倒是可以把请求合并一下，预计可以减少到3 到4个请求。9）又是一堆功能模块 37个这里也可以优化，预计可以减少到8个以内这里也可以优化，预计可以减少到8个以内10）3个配置文件可以合，不过合并后，1个文件变更会导致其他文件也重新下载，性价比不高。而且这些文件并不会在第一屏加载。合不合对体验的影响不大。可以合，不过合并后，1个文件变更会导致其他文件也重新下载，性价比不高。而且这些文件并不会在第一屏加载。合不合对体验的影响不大。综上，预计优化后总请求数在40个以内。还有优化空间的，我们也可以再探讨2.对最高赞的匿名用户（请原谅，你匿名了，我只能这样称呼你了）提出的问题稍微解释下：1）有些文件没混淆，有些文件混淆了。为什么呢？我们是在发布系统上做的压缩混淆。最开始是指做压缩，不做混淆的。在某个时间点才开启了混淆。只要在那个时间点之后发布的文件，就是做过混淆的。我的看法是，如果经常改的文件，下次修改发布后，自然就混淆了。如果不是经常改的文件，有没有必要去混淆呢？得看收益了那旧文件要不要去混淆呢？我们找个文件分析一下吧。以这个文件为例：原始文件大小：136K只去注释换行空格，开启gzip，大小：21k去注释换行混淆，开启gzip，大小：19k以上的结果可以看出，做不做混淆，对一个136k的文件来说，影响在2k。我们当时的策略是：对cdn上流量较大的文件，重新发布一遍，做混淆。流量小的，就等到下个版本发布时就混淆。一直等不到下个版本的，流量又小的，就不管了。你又可能会问：把所有旧代码发布一遍，很麻烦么？发布不麻烦，麻烦的是，有些旧代码过不了gcc simple级别的压缩，重新发布一遍（上万个文件），意味着发布的时候得花很多时间去改旧代码。时间就耗进去，需求不做了么？不做需求，那么还要不要领工资呢？不领工资，回家老婆要买驴牌，孩子要学跳舞，这些都要钱啊！面对现实，还是忍了2）中英文混搭中英文混搭的地方确实很多，没办法，读了这么多年书，最对不起就是英文老师。不过你这个例子举得不好，因为这里的dianping指的就是大众点评，如果我去改成英文什么的，反而更影响了理解。中英文混搭的地方确实很多，没办法，读了这么多年书，最对不起就是英文老师。不过你这个例子举得不好，因为这里的dianping指的就是大众点评，如果我去改成英文什么的，反而更影响了理解。3）空if这里实在是惭愧，不解释，接受打脸。4）代码审查的力度这也是我想吐槽的，如果借这个机会能换的大家的重视，这脸打得值得。感谢你能看到这里。最后的最后，题主和那位匿名的兄弟，如果有兴趣，可以私信我，如果我们彼此能看上眼，可以来我们这里试试。
利益相关：作为一个刚离开空间前端团队，现在已经不在腾讯的程序猿，我也来说两句吧。单从文件没有合并，个别代码没有压缩混淆就说这个团队技术不行是有失偏薄的。虽然说肯定有不对的地方，但很多是历史原因，目前没有改进也不是一件天地不容的事。具体一些原因@雕兄 有提到。我这里也想补充几点:1.我们是以用户首屏可交互时间为考核标准，对这个指标的优化也简直到了变态的程度.而文件合不合并不管对于用户体验还是考核标准来说多没有多大的影响，所以之前一直是忽略了2.文件数过多另外一个原因是预加载，在用户空闲的时候就提前加载接下来可能要用到的模块，这样用户在使用的时候就能快速打开了。（这个预加载逻辑也会分高峰和闲时决定执不执行，另外对于高峰时段，还有很多优雅降级的方案，比如图片换小一个规格，大图模式变小图模式，部分模型改变加载策略等。额，好像扯远了。其实在这里我更想说的是：QQ空间的前端技术绝对能算上国内领先水平！！我们做个很多东西，但都没有对外说，以至于大家觉得我们啥也没干，然后通过一些不好的地方，就说我们技术不行。实在令人寒心。结合在空间这三年，我再说我们做的一些事情吧：从12年7月入职腾讯实习，当时还在做朋友网，那时候已经在用seajs做模块化，还内部做了一个构建工具，当时的构建工具已经具有这些功能：1.自动把html模板编译成Function写到文件作为一个js模块来使用2.把多个js模块合并到一个文件，还自动按文件路径给模块补id，实现跨项目公用文件（这个功能spm一直没有提供，可能他们也没这个需求吧）3.监听文件变化实时编译这个工具到现在也是用的很爽，最近webpack，fis3这些构建工具开始流行，而我们在12年就自己开发了一个啊。另外也提一下，在13年的时候大家都在说前端模板，比如artTemplate这些，都在说自己编译性能好，其实早在12年我们就把模板在构建工具里预编译了，要比么？构建工具说完再说一下一些新技术的使用吧.Webp图片压缩技术到现在不知道有多少人了解,简单说一下,就是通过Webp格式压缩图片,在同等质量的情况下体积比jgp图片还小约30%.体积能减少这么多无论从节省存储空间,减低流量,减少用户加载时间.这么好的技术肯定希望能尽快用起来.然后当时只有chrome浏览器支持,IE完全不支持,怎么办呢? IE的用户比例还是大头啊,当时google给的解决方案是把图片通过Flash来显示,一个页面只有一张图片还有,像空间动态一屏都是图片如果要同时加载上十个flash肯定卡死,后来怎么解决呢,我们还是通过flash去加载webp图片,不过在flash里面再把图片转成jpg格式,然后再转成base64传到页面,不过IE8 base64编码不能超过32k,怎么破?直接在flash把图片分割,传回页面后再用多个Img标签把图片合起来.至此,已经实现webp对IE8+的支持.哦,对了,做这个事情还是在13年初.Webp说完再重点说一下Nodejs这边应用吧:12年的时候如果有听说哪个公司把Node用在生产环境应该是一件不可思议的事吧。当时朋友网就用了两台服务器搭Node Server做了在线聊天和页面直出的功能。要知道，那时Node还没有cluster模块，怎么利用好服务器多核环境呢？当时的做法是一个父进程监听80,和cup数-1个子进程处理请求,父进程做任务分发实现负载均衡.(为什么不用Nginx做分发?因为当时发现子进程突然无缘无故就挂掉了,所以又引入了心跳包机制,子进程没10s发消息给父进程我还活在,如果过了10秒父进程没收到心跳包就kill掉子进程重启).那时候还有一个比较严重的问题是内存泄露,不过当时没有很好的内存分析工具,这个问题没有得到很好的解决,不过这也没有影响我们在生产环境中使用,有内存泄露,每天定时重启一下就好.(内存泄露问题后面heapdump,memwatch工具出来之后得以彻底解决,并且把很多内存使用不合理的地方优化下来,比如长文本String改用buffer等)有了Node做Sever之后,我们做了更多事情,就不细说了,点一下:1.请求后台Sever要实现负载均衡,公司有一个L5的组件解决这个问题但没有Node版的,怎么办?写Node扩展2.在虚拟机上内核数识别不对,最后定位到是Node的bug,读的变量不对,改源码解决3.用Node在转发请求,实现全站域名统一,快速解决跨域问题.实现HTTP 2.0 / SPDY4.模块错误在线实时监控5.Node直接调用后台二进制接口,跟手机接口统一,大大减少后台工作量.6.Node性能优化,通过v8性能分析工具发现require中用到正则,性能堪忧,通过优化后整体性能提升了5%,开始以为require有缓存就随便写,发现这个坑后,以后ruquire还是写在最外层吧说了这么多也不是说空间的技术最牛,但国内领先肯定是说得上的.当然,因为产品形态的原因也不能所有技术都用上,比如现在一些流行的mvvm框架,对于空间这种频繁交互的场景不太合适,不过facebook开源的react native之后,我们也开始去用React来开发Hybrid App在这个团队学到了很多东西.对这个团队也是无限的感激.也非常推荐刚毕业,对技术有追求的同学加入这个团队.很久没写过这么长的文字了,就作为离职的一个总结吧.
作为空间前端老司机，看到大家讨论那么激烈。也想分享一下自己的经验，作为空间06年到11年的前端开发，或许可以给大家分享一些当时的技术选型让大家看到空间的技术演进（至于现在为什么变成这样，我不去做评价对错）。1. 06年，还是一个前端技术萌芽的年代，虽然04年google把ajax概念让更多人看到了前端的重要性，但是前端技术还是非常没有标准化的年头。刚接手空间的前端代码，前辈们为了极致的体验，十几号开发（前端，后台，甚至运营开发都有）都在同时改一个文件G4.js，文件数量可达200k（自己脑补有多少行）。当时没有像现在那么多框架，那么多解决方案，更加没有node.js，你从何下手？ 如果你们都觉得文件请求合并为基本原则，那么这个做法是不是就是对的？2. 对于那么大的文件，代码本身的问题就非常多。所以接下来的事情，我想的方式是拆开，模块化。做这个事情，后来就到了07年，为了让模块化开发方式简单，自己写了压缩合并工具，自己定义模块加载的方式。然而当时能想到最简单的优化就是，把首页用户不需要的内容尽量异步加载。如果回想起来，当时最遗憾的是，并没有把模块化的工作方式，抽象成设计模式。后来做DO分离的时候，我们把前端的工具也慢慢推动形成了公司级的工具，包括发布和压缩，其实也是最早期的前端工程化雏形。当然工程化还包括了最早的公司web端性能的测速平台3. 抓包中你们还能看到qzfl，这个是最早期为了解决开发规范，解决浏览器兼容的产物。这个框架为空间做了非常多的深度定制，同时也从整个团队来说，让前端开发在生产环节获得效率的提升（当然始终没有提升效率到，我们有时间去做开源，这个深表遗憾）。当然到现在同时看到多个基础库，其实是让我觉得非常痛心的一点，在现在提倡去框架的时代，在空间依旧看到了很多基础库。这个确实需要后辈们想办法，qzfl已经发挥了它最大的价值，是否还能带来更大的价值？4. 前端优化，这个很古老又很赞新的问题。怎么做都没有对错，虽然前端优化也能有一些常规的设计模式去驱动，但是设计模式不见得都是全对的。空间的优化原则是基于数据分析的基础去做的，所以我们会去关注真实用户端的使用情况。空间多首屏加载做了非常多调整，以及对10%的用户，在网络接入，运营商，使用习惯上做更多的分析。所以我们并不会说直接套用xxx优化原则就认为我们做了优化，优化随着时间推移，随着用户硬件的升级，也在不断调整着策略。当然以上这些优化其实只解决了用户访问的速度问题，并没有解决卡顿的问题。所以我在12年的velocity china上提出了前端的渲染性能优化的分析方法(有兴趣可以百度搜索16毫秒的优化)，希望前端开发通过渲染问题的分析，去优化空间的卡顿。因为空间长期都在和网络较量，对于复杂前端性能，确实看得不够多，特别是运行时的性能。空间的前端技术，也许在现在很多人看起来技术很古老。但是它已经是一个大象级别的项目。另外在业务面前，一个理性的程序员会考虑，我的重构是否对现在的优化还有价值？ 空间当年从10万到百万，到千万访问量的提升的时间段内，各种优化都是值得的。然而到了现在顶峰阶段，去做天翻地覆的改动价值是否得以放大？所以，也建议大家不要以新技术的运用作为判断前端技术是否NB的唯一标准。回想04年ajax诞生，算是新技术？其实只是一个新的设计模式。最后空间前端团队，虽然在开源上没有太多的贡献，但是在腾讯内，给大家创造了非常大的成长空间，创建了腾讯的web前端通道，让前端技术真正在公司内受到重视，做到这点已经足够。心存感激。
线上代码如何并不直接反应团队技术水准，这个在大公司干过的应该都懂，不信你们去看看新浪博客的前端js，那代码是04年的时候做的架构，就不说有多nb了，放到现在一些公司也是做不到的，但是博客现在基本已经毁了，这并不是技术能控制的，产品不ok，技术没办法发力，很多事情没有契机去做，比如优化，大改版，技术升级等。因为产品过于复杂，很多新人不敢动老代码，历史问题等，铁打的营盘流水的前端，谁care呢。所以看了很多qq空间的技术说了一些问题，我体会也很深，有时候有些项目，真的身不由己，技术选型一开始很重要，但是10年前的产品的选型必然和今天主流不一致，但这并不能说明技术团队技术不行.缓存利用根据流量峰值做不同策略的尝试，我在10年就知道腾讯在做，这个也是qq空间团队主导的，10年啊，不吹不黑，当时淘宝和现在的淘宝应该都没有做起来。
现在才来写点啥是不是晚了。。。看到stone，子舜都被引出来还是勾起很多回忆。。。雕兄和lv的回答也很赞，友昆作为现任掌门人请继续加油吧，支持你单纯先说下题主的问题，首先说的都是对的，必须认同其实这些道理都知道，为啥没有执行，我想通过后面的讲故事的方式来解释，说找借口也可以，确实作为空间前端老年人代表要来讲讲，不说不痛快Qzone开始有大量前端逻辑始于2006年4月左右，作为到现在为止还在大量使用C/C++基于自建web server框架进行CGI bin实现web开发的公司，在中国乃至全世界都是独树一帜，2006年4月，Qzone刚刚因为要解决CGI过重导致的web接入层性能瓶颈（当然不止这个瓶颈，用户增长速度当时达到日增80万且100％留存活跃）做过一轮重构，那可能是国内业界第一次百万用户量以上的web业务做完全的动静分离架构，web接入层完全成为RESTful的data setter/getter，所有的表现逻辑都由web前端绘画出来，包括首次打开，整个页面也是用js DOM API一坨坨画出来的。虽然丑而极端，但确实第一次极大解放了后端集群的压力（大量的业务逻辑计算和展现模版计算开始去消耗用户设备的资源），对于一个月内用户量从50万暴增到300万的、工程师（重构前不分前后端）加运维（当时也没有D/O分离）一共才11人的team，已经是最快的方案，当时负责前端开发工作的人员只有两人，纯前端项目的规模应该在5万行的样子（虽然前端都不喜欢这么估，但考虑到和后端项目对标，姑且这样吧）自此之后，直到2011年前，Qzone的前后端架构分界没有重大变化，前端工程师几乎承担60％＋的业务逻辑维护工作，特别要提一下Qzone前端工程师的工作内容，除了和产品经理tradeoff需求外并实施外，所有用户投诉（当然包括老板投诉，5个大老板从早晨9点到凌晨2点的各种轮番问题反馈，不是怪罪老板，这样的老板真的能让团队成长很快）的受理和初步定位（遇到网络质量衍生的一系列问题要自己出方案规避，而不是丢给运维了事），公司级漏洞防御规约（公司最大的web ugc平台的责任），自己实现业务的前端监控（页面自测速、前后端公网调用成功率、用户机器负载等）以及持续优化，公司自建CDN的持续迭代优化建议，前后端接口统一规范的开发维护（CGI模版的维护哦，比神马php，python之类的麻烦多了），在后端整体做异地分布的时候，整体域名规划、同步延迟消脏方案全部洞穿到前端，由纯前端业务架构师规划，当然还有复杂flash项目（照片上传组建、农牧场整体前端构建等）。这一切都是在一个不到40人的前端team进行，对口产品和运营超过60人，业务规模3000万（半小时AU，不是DAU），2011年数据。2012年开始，其实Qzone的Desktop Web版本（也就是PC版啦）所有的重心开始偏向移动端开发，大量的web前端hc被缩减，现有团队成员很多响应公司号召转去mobile native开发。如果一定要看下web前端技术，可以模拟移动浏览环境开一下瞅瞅，顺便提一下，那后面都是nodejs，也是个接近千万日活的业务。2007年大概7月，qzfl这货有了，当时jQ不成器，prototype、dojo、ext之类的又实在不适合，所以才自己搞了个qzfl，确实作为开发框架，里面有些划分不合理，比如耦合了一部分为qzone体验高度定制的drag&drop引擎（虽然没有耦合业务逻辑，但其实不算变成框架的必要部分）。但qzfl里面还是有些亮点的，比如用documentFragment做根容器来get jsonp，不需要用前后端传参数的方式防止callback function name冲突（后来有个叫adv的家伙，通过控制毫秒级时序队列，更好的做到了同名隔离，纯粹从思想上来讲，算是js在客户端平台上的微线程实现吧）；还有个叫jsLoader的货，其实可以说是诞生很早的模块化加载器；2012年初在做news feeds前端模版引擎优化的时候，在后端开始尝试了虚拟DOM的概念（Qzone内部团队分成平台和UGC，平台news feeds帮助业务更方便的在首屏以各种花式曝光），现在看看也算是类React的东东吧，其实2012年大量web前端转app native开发的时候我们就说过："硅谷是人最贵的地方，不可能每个公司都搞平行的android／ios／win phone ／ web 几坨人马，养不起，一定会在硅谷诞生基于web开发native构建＋运行时的方案"，果然fb的react后来就出来了。。。 腾讯是一家非常业务导向的公司，在一个业务团队，绝对不可能给你充足的人力空间搞纯技术项目，大量的基础建设都是大家用很多OT堆起来的。如果当时可以有一个5～10人的泛前端（native前端＋web前端）team一起研究，做个基于jsc的类似react的engin并不是不可能。当然，马后炮没鸟用，不说也罢2011年开始，朋友网前端团队（朋友网和Qzone同属一个部门，社交平台部）已经开始较多尝试nodejs，朋友网相对Qzone来说用户群较为集中且相对高端，低端老旧客户端运行环境很少，因此是非常好的开源新技术组件实施田，朋友网的前端团队把很多不成熟的开源项目本地化并进行了很多有意义的优化。上文部分同学说的模版compile，可比jade的这个能力早了很多，到2013年的时候，nodejs已经在Qzone相册，触屏站等场景大量使用。。。全都是超大规模的web业务现在回头想想，其实很多事情没做好，最大的问题还是缺人；Qzone前端开发团队人数最多的时候不超过50人（产品经理和运营共100人的时候，大家都知道运营需求最费前端）鹅厂不同于阿里，对前端技术通道的误解更深，很多业务线其实都没有组织架构上正式的前端团队，也有大量业务的前端团队由后端开发leader领军，如今想来也是唏嘘一场
腾讯的Qzone前端团队和QQ前端团队可以说是代表着整个腾讯的最高水平了。就是产品弱了点。
话说我在三年前回复过一个类似的问题： 记得当时得票数最多的一个回答贴了好几张图来证明数据数据造假，当时貌似有上百个赞（当时还是蛮多的）。经过一番讨论后，回答者就把答案给删了。没想到过了几年又遇到类似的问题了……——————————————————————————————————首先回答下提问者的问题：“前端性能优化原则难道不是尽量合并请求吗？”。是的，确实是尽量合并就合并。但是这个是有一定历史原因的，因为以前ie 6有并发限制，再加上计算机硬件也不怎么地，而且以前也没AMD和CMD等模块加载规范（当时最牛的应该就是yui的模块加载了），所以合并起来确实是最好的解决方案。但是，随着游览器和硬件的升级，再加上网络越来越好，而且前端项目越来越复杂，这个确实不是太重要的点了（但是并非是不重要）。其次针对QQ空间的问题，QQ空间真的没有合并和混淆文件吗？那这是什么?CDN文件合并不会不知道吧那这是什么？有用过seaj的的同学应该很清楚这个是什么吧（这里补充说明下，空间这边在发布前就会有一套工具把零散的模块进行合并）那位至今不愿意露脸的匿名同学提到这里有问题，可能是不太清楚Seajs的模块打包方法，这句话的意思不是把jQuery打包进来了，而是把括号里面这些子模块打包进来了。只有空间没有混淆文件吗？再回到问题来，为什么还是有这么多请求？简单讲，空间不是一个简单的页面，里面有各种模块。除了核心体验的模块是“同步拉取”（其实也是异步拉取的，只是这些文件是强依赖）的，其他模块都是异步拉取的。这是什么意思呢？对于用户来讲，就是能让你在最快的时间内进行核心操作，但是一些非核心操作（如数据上报啊、还有其他非核心功能），都是在之后拉取的。其实这个也是空间这边技术的主要优化点，为的就是不仅仅依靠性能数据，而是根据用户的实际体验来衡量（就是让你在最快的时间内能够进行操作）。觉得我在胡扯？那看下下面这个facebook的请求截图，一共是79个。而且facebook可没有空间那么多增值的功能。这么多请求是不是真的让我使用起来比较卡？把flash先关下再试试？话说由于兼容性需要，空间很多功能都是用flash实现的，flash那些众所周知的问题就不提了。之前听老大说有逐步推进用HTML5替代的计划，但是由于我不是负责这方面业务的，所以具体的进度我也不太清楚。如果我还是觉得慢咋办？点右上角那个绿色的东东最后再说下关于压缩和混淆的问题，其实现在的存储和带宽成本和几年前相比真的很低了，压缩确实可以减少文件大小，但是想想真的有那么重要吗？很多时候大家都把做其他一些东西的思维移植到前端，像我刚刚工作时，一个完全不懂前端的领导让我把代码压缩混淆，并且很郑重的说不这样做会导致代码泄漏问题。但是说个实话，只要你代码在游览器端跑，我肯定是有办法读出你的逻辑的。当然，我并不是说压缩和混淆不重要，只是觉得没有必要过于钻牛角尖。或许以后真的会有一套规范来定义JS文件的压缩和加密，但是肯定不是现在简单的压缩混淆就可以做到的。就像如果你是程序类面试官，你会因为一个人不剪指甲就不给他offer吗？很多人，为了彰显自己的能力，总是喜欢挑战权威，但是技术这东西是很严谨的，你看了一篇文章说XX好，可是不根据实际情况就把这点套用到任何地方，真心不是一名合格的技术人员应有的表现。对了，前面那位匿名同学说要向淘宝学习，其实技术本来就是相互学习的。
QQ空间的前端技术水平如何？QQ空间曾经是腾讯最大的前端团队（大的还有AlloyTeam、广研的邮箱团队等等等），在前端这个词还没出现的时候就已经开始了细致的浏览器端分工，设立了公司的前端技术通道，必须是挺牛的，只是个人认为公司对外分享的氛围太低调了，不够开放，感觉对业界的贡献不够多。只是打开Qzone首页（我的动态），鼠标没有移动到屏幕的任何元素上，也没有进行任何点击，就有295个请求，图片就不说，很合理，但是却加载了114个JavaScript文件。前端性能优化原则难道不是尽量合并请求吗？ 架构的水平，初级是看是否符合规则，到了出神入化的境界，就要考虑怎么灵活组合，甚至是打破规则。有句话怎么说来的，“规则就是用来打破的，前提是你了解他”。# 就这里的例子来说，按指导原则，合并请求绝逼是没有错的呀，可再这么巨大的产品面前（减少资源请求是另外一个重要的原则，只是堆砌的内容确实太多了），首屏的东西谁都不少，考虑过把114个JavaScript合并成一个是什么后果么？？打开页面后看着一个空白的页面，等待一个几M的js下载完成会是什么心情。这种情景下怎么做合理一些呢，首页的框架html直出，你可以看到第一页的内容，然后各种模块的js组件在后台lazyload，等待下次要用的时候不用临时再去下载。（PS：吐槽流量的同学，你们在用4G上PC么，哈哈哈。移动端对流量的优化也蛮极致的，强网络tcp链接确保速度，若网络html链接确保可用，不同场景屏幕大小加载的图片size也分好几个规格）# 说到打破规则，还有个例子。有一条规则是将CDN、CGI请求等分给适量的不同域名，这样子可以是浏览器开启更多的并发下载。PC版的空间也是这么搞的，后来到移动端解析域名的DNS消耗之巨大，以及下载网速之缓慢，多域名反而成了劣势。# 说到lazyload，想起黄老师（这里说的是stone老师）讲的农场的一个优化案例。那时候大家网速都比较慢啦，下个flash资源也要不少时间，大家偷菜种菜的时间晚上8-9点是高峰，不光大家家里慢，高峰期的时候服务器压力也很大，而且公司跟运营商买的带宽是按峰值算的，平常大家睡觉的时候白白的浪费银子啊，后来根据用户是否是农场用户的属性，在网络空闲阶段提前把农场的资源下载下来缓存，大家玩的也爽，服务器也爽，老板也爽，反正就是各种爽。-----------------------------------# 上边匿名同学从代码看出来的问题也是实际存在的，但更多的是技术管理方面或者产品形态方面，不能片面的否认团队的技术能力（同学们也要加油啊）。空间的技术团队遵循”互联网产品“的”速度是一切，勇于试错“的指导思想，一天跟着产品需求可以发很多个大版本，难免会有些浮躁，没有很好的环境沉下心来写框架级别的东西，当然要想写也没人拦得住的，requirejs刚流行那会儿也有同学搞出来轻量的类似框架，只是没用起来。这点和淘宝的同学比起来，商品展示支付相关的页面更看重模块的稳定和复用性，可以一周发一次版本，有更多精力打磨框架。产品本身问题很多，有同学打比方，QZone的代码就像一个陈年的破车，打满了各种补丁，可居然还没事儿一样跑着……
# 至于混淆什么的，他的好处是增加代码阅读的困难，如果不是敏感代码，当真无所谓，感兴趣可以看一下登录模块的代码，这里是混淆了的。如果考虑到流量什么的话，同时开启gzip压缩的情况，两种方式基本上没有区别。---------------------------PS ，11年加入空间团队，和当时前辈们学了很多，很感激。现在虽已离开，很怀念……
谢kelen邀。看到有一些同学已经回答的的内容就不重复了，现在我也不负责QQ空间的前端，说一点点个人的观点吧。1 前端技术好不好，应该是有相对客观的标准的：用户体验说了算。当然也不是说平均测速数据压倒一切，很多时候“最差的10%的用户感受有多差”是一个更重要的指标，因为对产品的抱怨几乎都来自于体验最差的用户，所以需要对他们做更多的关注。这有的时候也会导致技术实现者不一定选择对于平均用户体验最佳的方案，比如说不一定要把文件合并做到极致，所有的脚本都合并成一个。2 当然js文件数过多还是要反对的，虽然我并没有看到题主说的100多个js请求（估计跳转了几个页面后抓的包在一起统计，或者有一些域名下的json被混进去了？或者装扮不同带来的差异？）但是确实有一些小js应该考虑合并请求。特别指出，合并脚本请求并不是合并脚本文件，我们使用的cdn有合并多个文件到一个请求中的功能。比如
这样的。因此以前我们常常会在一些特性发布的初期把代码放在独立的小文件里面，等成熟后改为合并请求方式。3 前端js不压缩不混淆是我比较坚持的原则，虽然现在前端团队不见得还坚持这一点。这并不只是“为了线上测试方便”，当然我也很乐于看到这个方便。不建议压缩的原因是，实际上在网络下发的时候我们是统一做gzip压缩的，大部分的数据冗余在这个时候去掉了，对代码做压缩后再gzip跟直接gzip的差异并不大。不建议做混淆的原因是，对信息加密史略有了解的人都知道，公开的加密算法比秘密的加密算法更安全。代码也类似，容易读的代码对于开发者和白帽子更容易发现问题，而只要找到代码漏洞是有利可图的，黑客并不太在乎你的代码是否做过混淆。此外一些加密和混淆方式还需要在客户端做额外的还原计算，这样就不是优化而是劣化了。因此我继续呼吁大家不要在没有监控数据支持的情况下做这类“看起来似乎有效果”的优化。3 回应一下上面某匿名兄提出的拼音是什么鬼的问题。 从贴出的代码山观看“dianping”其实是一个字符串常量赋给了wihtelist白名单变量，应该是指的一个大家够知道的域名。多数情况下我们还是要求代码采用英文和英文缩写方式的，当然不排除有一些地方有历史痕迹或者有新人带入，还好大部分代码并没有做混淆（混淆的代码我希望换成不混淆的版本），所以欢迎大家review和指出。
作为空间web前端的现任司机，我也来说几句，立场中立。我是来回答标题的，但因刚发出来就回答得太快，问题更新几波后，我的答案并没有什么鸟用，变成了现在这样子：大家对着个PC页面展开各种立场的讨论。首先，技术具有时效性。去年大热的离线包技术，放在今年讲就没有时效性，再过十年手机网速超过pc再提离线包我跟你急。11年大热的模块化，今天也没有时效性。同理，08年大热的js压缩混效放在当下也没有时效性。技术点失去时效性，并不是说他就不重要了，只是代表着没啥好讨论的了。标准已经确立，是否遵循这个标准是各自的事，有的为了让流程更规范落地了，有的因为价值不明显没的强制执行。同样PC web时效性也没有了，现在很少看到大家在分享PC时代的成果。但这并不代表PC可以不管了，做得不好的承认并让期变好。但团队的关注点不会改变，移动端的web才是当下的王道。时效性这一森林法则在产品上同样适用，甚至放大到整个互联网。在公司内部也到处可见，如果在通道评审中，你拿一个过时的技术点讲给评委，会被PK的很惨。公司内部某个框架或架构很好用，过几年没时效性可能就要被吐槽了。那如何保持时效性呢，那就是迭代，快速的迭代。大家所说的水平，大多来自这样的评架：A用了个有时效的技术方案，B用了个过时效的技术方案。大家就会得出A比B水平高的结论。那么我们来看下空间web前端那些年在时效上的历史，我是11年入职的，前面的不了解也就不说了。11年，完成模块化（铺地板），同年启动node.js与业务相结合的解决方案研究。12年，前模板模编译为模块（铺地板），原因是为了让其能在node.js解决方案中直接复用13年，相册下载webp化，移动转型14年，完成前后端分离的开发模式（铺地）15前半年，提出server web开发理念，打通运维和后台二进制协议，整个空间的移动web接入层由前端开发接管，新项目已经没有cgi层，前端开发成为域名收割者。15后半年，接入层收归到前端后的各种工具层出不穷，基于qq号的测试环境，基于qq号的接入层染色+抓包，首屏直出+离线+diff。15年是移动web飞速发展的一年，间接导致服务端web的崛起，时效性的标志。当年我们大力投入node.js但效果甚微的时候，也怀疑过自己的方向是否正确，被质疑是为了node.js而node.js。士气低落时，被黄老师吊了一句“node.js在公司如果不火，那就是你的责任。”然后重新思考，即然方向没错，那问题出在哪。才发现，太超前也会失去时效性。然后继续研究node.js，等待时效来临。当然也不是干等，而是打通公司内部各种系统，各纬度缺失的能力补齐，狂更新node版本。这个时期，对内分享都很少。然后，今年火了，node.js在首屏性能优化，新项目接入层，登录态隔离，域名收归，安全打击，https-spdy上都获得认可。意识到时效性来了后，当然不会藏着噎着。通道能力模型修订加入服务器端web开发标准，对公司内web前端兄弟们来说又开启一个新的领域。在运维，后台开发，测试等角色也不断提升对node开发工作的认可。毕竟老大认可了你才敢用吧？下一个有时效性的技术点，大概就是react组件化了，时间点反正不在今年。所以这个问题很火就是因为大家都假装有时效性然后狂讨论的结果。仿佛一夜回到了PC WEB时代一样。-------------------------------------------空间移动web接入层全部构建在node.js之上，web前端已经从浏览器时代演进到server web，移动互联网时代应该讨论点移动web才有意义。
已有帐号？
无法登录？
社交帐号登录