权衡前端性能优化

web性能优化的技巧越来越被人所重视,不管是YSlow的14条优化建议,还是各种性能优化相关的书籍都从技术解决方案层面给出了令人满意的答案,已经有很多网站在性能优化方面进行了成功的实践,在尽可能减少请求数,压缩代码,图片合并等基础优化方面似乎是没有其他退路,而javascript性能优化,ajax优化等方面的进阶优化虽然没有很直接的7天速成指南可以参考,但是在技术积累稍微好一点的团队,这种代码层面上的性能优化相对来说没有压力,可以看出web性能优化技术越来越透明,并且性能优化也是一个老生常谈的问题,不过正是因为如此在做这些看似很美的事情之前更需要冷静下来仔细权衡。

解决基础问题

需要优先考虑的永远是较低成本较高回报的优化方式,对于即将考虑web性能优化的网站来说,可以先考虑一下几个方面:

  1. 模块化,合理复用css代码,巧妙设计css sprites,以减少css文件本身大小,保证易维护
  2. 压缩精简页面css、js代码成为单个请求,配合合并图片尽可能降低页面上的请求数
  3. 使用合适的javascript框架来帮助你改善普通代码对性能优化考虑不周的情况
  4. 合理设计&重构html,避免页面存在过于复杂、冗余的dom结构
  5. 划分静态资源主域
  6. ……

 

深入细节

如果比较直观的去评价基础性能优化,很容易让人觉得前端的性能优化也许是比较低门槛并且容易拿到好结果,但是却忽略这些优化之中的细节。同样是做css sprites,这个合并之后的图片大小、图标布局会因为操刀的人经验不同而产生不少差异,考虑周全的会根据自己网站的业务情况适当分模块化去合并,规范一点的团队可能会把如何合并图片整理成为一份保证css sprites质量、减少新成员教育成本和图片的维护成本的文档,可以看出性能优化之外一件看似很小的事情可作的文章是很多的。

再看js框架更新换代,优秀的框架可以帮助我们节省很多考虑和解决问题的时间,并且框架帮我们做的事情大多数是比较周全的,特别是浏览器兼容性、选择器性能、ajax管理等方面,但是使用新框架去重构复杂的旧业务的时候,如果对于框架本身的特性不是特别熟悉,结果很有可能是因为没有合理使用或者滥用框架而加重一些不必要的js性能负担的,如果对于使用的框架非常熟悉、运用自如以上这些都不是问题。

保持方案&技术可延续

在一个前端团队中每个人的技能优势和所感兴趣目标不尽相同,在性能优化方面有心得的人在制定和实施方案上就比较有发言权,对于一些相对透明的优化技巧,大部分人很容易就能接受,但是深入细节之中,会有很多认知上的差别,同时性能优化应该去避免为了某些特殊业务和时机去执行特殊方案,一方面这些方案会在其他业务上不适用,另一方面你这些方案应用一次之后很难有所沉淀。
web性能优化在技术细节上会有很多差别,我觉得最好的方式应该是充分审视自己团队的特征,方案在保持一定前瞻性的同时不能偏离业务特点,这样每次的优化都能为团队积淀出一些可延续下去的技术。

大胆创新

做性能优化似乎很容易走到止步不前的境地,其实性能优化和其他事情一样是可以持续地做得更好。从Gmail,Twitter,Facebook的性能优化实践(gmail最早使用hash导航配合ajax来做优化;twitter大范围采用脚本异步并行加载&ajax化;facebook的优化方案重点在‘ajaxify the site’)可以出,这些大网站对于自身的性能痛点都比较了解,他们所采用的方案也几乎是全新的,虽然在其中的几个细节是大家平时见惯不怪的,但是最终他们能够结合前端和web层框架对网站的性能进行较大幅度的优化,同时也给用户提供了更多流畅和惊艳的浏览体验。

权衡web性能优化

有人说过“过早的优化是万恶之源”,web性能优化也是一样,也许你开始考虑做性能优化的时候,会花几天时间学习如何合并css背景图片,再花几天看剖析facebook的Quickling、PageCache是如何实现的,但是你却忽略你的网站中每个图片的请求头中存在1KB的cookie这件事。
契合业务、掌握细节、关注投入产出,关心质量和可复用是web性能优化中不可忽视的关键。

Published by

Z.J.T

Product Designer from Wandou Labs

  • http://www.yinghrsq.com 现实好假

    博主的文章写的非常好!顶一下!