前言: 本文来自于SharePoint Product Group的官方Blog, 原文地址为http://blogs.msdn.com/sharepoint/archive/2009/09/28/how-we-did-it-speeding-up-sharepoint-microsoft-com.aspx
SharePoint.Microsoft.com是一个重要的SharePoint交流渠道. 我们希望提供丰富的有帮助的访问体验, 同时教给他们ShaerPoint能够在生意上帮助他们做什么. 该站点试用了我们的工业级领先水平的内容管理平台, 并且为访客提供了有用的内容和资源. 另外, 我们还认识到有些因特网同行需要克服一些困难来提高页面加载的时间, 尤其是对我们在全球范围内的访客而言. 我们跟Aptimize Software一道, 为SharePoint.Microsoft.com做了优化.
今天的发表嘉宾是Ed Robinson, Aptimize Software的CEO(Chief Executive Officer). 这篇文章将会温习我们是怎样做的, 还有潜在的提高性能的技术, 运用这些技术我们提高了SharePoint市场站点的页面加载速度. 我们希望你能够通过同样的过程来优化其他的站点的性能.
Tony Tai
SharePoint Senior Product Manager
导论
=========
性能的挑战
由于目前全世界的设计者和界面工程师都在持续的扩展着web访问的体验的极限, 页面负荷越来越大. 15年前, web设计师用把页面的大小控制在15kb一下作为一项对自己的挑战. 很快的到了2009年, 动辄500kb或者更大的页面屡见不鲜. 这多亏了伴随这个革命般的过程的一起的带宽的迅速增长... 不是么? 对于很多世界范围内的因特网工作者来说, 带宽仍然是一个挑战, 即使你优化了带宽的极限, 但是对于数据在全世界范围内的流动或者从卫星返回的数据来说, 总还是有物理限制的. 所以, 面向全球访客的站点不管你使用什么平台和技术, 都需要考虑低带宽, 因特网连接高延迟带来的影响.
解决方案
有许多种提高网站性能的策略, 多数是集中精力在服务器端的处理, 客户端的缓存, 和边界缓存(edge caching). SharePoint的开发人员可以利用SharePoint提供的优势来提高站点的性能, 诸如可衡量的服务器处理, 浏览器内置的对象缓存的使用, 和与由内容传输网络提供的缓存的集成. Windows 2008 R2和Windows7一起, 提供了甚至更多的能力- 在分支办公机构里, 为Windows7客户端机器提供高访问量的office文件的本地缓存.
当我们被鼓励进行这些实践的时候, 这些方式并没有减少浏览器与服务器之间的数据的流量, 而且服务器也不会采取步骤去优化从服务器送出的HTML, JavaScript, CSS或者图片.
当然, 使用手工操作和接连不断的升级, 开发者和设计者可能做到最小化和压缩传输的内容, 通过这样的方式, 减小了服务器与浏览器之间传递的数据量, 并且减少了页面加载的负荷.
那么我们要在这里说这些呢? SharePoint在微软的历史中是一个快速成长的服务器产品, 所以有很大的信息流量带着请求从全世界来访问我们的站点. 我们建立我们的站点是将它作为一个展示SharePoint和Silverlight的最佳web能力的橱窗, 所以如同其他站点一样, 我们也在不断的扩展着涉及的边界, 导致了高额的页面负荷. 我们宁可做大量的工作来优化服务器端的处理, 也不愿意看到同样的有着低带宽的访问者经历长时间的延迟, 忍受不良的访问体验. 我们寻找各种技术来提高这些用户的访问体验. 我们在Aptimize发现一个很好的合作伙伴, 他们对优化带宽和减小延迟有一整套的解决方案, 并且让他们的产品跟sharepoint可以稳定的集成工作.
现在, 让我们看看Aptimize是如何做的, 看看在sharepoint上如何简单的安装, 配置, 再看看我们感受的结果如何. 但是记住, Aptimize并不是只针对SharePoint产品的, 所以, 如果你使用了Ferrari, Kraft, AMD或者其他的产品, 或者你有自定义的.net或者PHP站点, 你可以看到一样的好处.
这篇文章会带你一起完成三步走式的过程, 我们会使用Aptimize Web Accelerator的领先的优化技术分析, 提高性能.
第一步: 了解当前的性能
==================
每一个为真实客户提供服务的站点目标是: 任何页面都能在5秒之内完成加载. 在普通带宽下, 世界上任何地方的浏览器可以访问站点的任意内容, 算上服务器处理页面的时间在内, 一共最多用5秒钟.
那么原来SharePoint.Microsoft.com的情况是怎样的呢?
团队做的第一件事, 就是分析并理解当前的性能状态. Aptimize使用免费的WebPageTest工具来从USA, 英国, 和新西兰访问的访问时间. WebPageTest会记录加载时间, 并且声称一个瀑布型的图表来显示页面的每个元素的加载.
当衡量页面加载时间的时候, 下面的三个指标是非常重要的:
- First View - 第一次加载页面所用的时间
- Repeat View – 加载一个被访问过的, 浏览器缓存了的页面的时间.
- Start Render - 页面加载之前, 用户看到一个空白页面的时间长度.
First view页面加载时间在全世界范围内从10.6到15.3秒不等, 对于Repeat view是6.1到9.4秒. WebPageTest也会对FirstView和Repeat view生成瀑布图.
这张图展示了三个阶段
- 服务器处理. 当一个浏览器请求一个页面, web服务器就会处理这个请求, 生成HTML页面. 这是在第一个http请求中完成的. 之后, 服务器的工作做完了. 我们寻找一个处理时间不超过1.5秒的服务器- 任何超过这个时间的都说明服务器处理有问题. 对于SharePoint.Microsoft.com来说, HTML页面用了在473毫秒返回的. 这很快, 说明服务器端不需要调整.
- 浏览器处理. 浏览器加载了HTML页面之后, 它就开始渲染HTML, 方式是从HTML文件的顶部开始一行一行的处理, 画出页面, 加载外部的JavaScript, StyleSheet和图片文件. 浏览器处理的时间是10.1秒, 说明大约95%的页面加载时间被浏览器处理的步骤占去了.
- 后加载动作. 页面加载之后, Silverlight空间开始渲染导航栏, 还有首页上的内容, 并且LivePerson服务也启动了. 尽管Silverlight可以优化, 但这不在本文的范围之内.
一旦页面被浏览器完成第一次加载, 有些元素就被缓存到本机, 所以在repeat view一般都会比first view更快, 因为浏览器没必要在加载它已经缓存了的资源了. 注意瀑布图中repeat view更短.
在记录了当前的性能之后, 排除了服务器自身的问题, 站点已经为浏览器处理的优化做好了准备.
第二步: 优化站点的速度
==================
使用性能的最佳实践来优化一个站点的速度, 有一个已经建立了的成熟的方法.
服务器优化
加载的图表轮廓说明: 对于SharePoint.Microsoft.com来说, Web前端服务器, 数据库, 还有应用程序本身都运行的很好, 都在预期之内- SharePoint能够在半秒之内产生出HTML页面, 这点已经比多数的站点要优秀了. 所以, 服务器端不需要优化.
减少HTTP请求
浏览器处理占据了95%, 在这段时间里, 浏览器加载页面上的每一段JavaScript, StyleSheet, 和图片. 下表说明该页面共有九十六个资源, 这个页面可以从优化中获得好处. 减少资源的数量可以达到这样的目的: 在输出页面时,减少在加载页面过程中浏览器与服务器的交互次数.
| File type | Count |
| JavaScript files | 18 |
| StyleSheet files | 17 |
| Image files | 37 |
| HTML, other files and duplicates | 24 |
| Total | 96 |
关于减少JavaScript, CSS和图片资源方面, 有很多简单的成熟的技术.
- 将JavaScript文件合并到更少的文件中.
- 将StyleSheet文件合并到更少的文件中.
- 使用CSS Sprites和CSS inling来减少的图片的数量.
CSS sprites(CSS精灵)是一种减少图片数量的有用的技术. 多个独立的图片可以被一个挨一个的拷贝到图片墙(image tile)中, 然后可以被页面通过偏移量作为索引来独立的引用.
尽管所有的PNG文件在页面上看起来都是独立的, 其实他们是作为一个图片墙而存在的, 看起来像这样:
CSS inlining(css内联)是另一个减少图片数量的技术- CSS将图片文件转换成Base64编码的流, 然后拷贝到CSS文件自身中.
经过合并JavaScript, 样式表(StyleSheet), 和图片文件, 我们把资源文件的数量减少了64%
| Original | Optimized | Reduction | |
| JavaScript files | 18 | 11 | 39% |
| CSS StyleSheet files | 17 | 5 | 71% |
| Images | 38 | 13 | 66% |
| Other files and duplicates | 23 | 6 | 74% |
| Total | 96 | 35 | 64% |
增加缓存
使用far-future-expires(更远更久的过期)配置资源, 可以进一步地为repeat view减少加载时间. 有了far-future-expires属性, 静态资源(图片, JavaScript, 样式表)都被设置了一个"expires"的缓存头(cache header), 该缓存头可以指导浏览器将这个资源保存一年, 而不需要检查更新. 这样可以大幅度的减少HTTP的请求, 因为浏览求不需要确认它是否拥有每一个资源的最新版本.
开箱即用地(Out-of-box), SharePoint为同产品一起发给客户的资源全部进行了最优化的缓存配置, 但是并不能预期到用户如何添加东西到他们自己的站点中. 将每一个资源都配置为far-future-expires之后, 如果资源有修改, 那就会出现问题, 因为浏览求不会去检查新版本的资源, 这样新的资源就永远不会被下载.
使用Aptimize Web Acceleator, 我们能将far-future-expires应用在最有可能不变的静态资源上, 将动态的资源(例如搜索结果)排除在外. 如果静态资源修改了,
Aptimize Web Acceleator会自动的检测到修改, 并且修改静态资源的URL来强制浏览器下载并更新.
这个过程减少了同样页面的HTTP的请求, 加载时间和页面大小尺寸.
减小尺寸
最后的技术就是减小文件尺寸. JavaScript文件和CSS样式表包含空格和注释. 尽管这代表着良好的编码实践, 而且对于开发人员的理解和维护这些文件至关重要, 空格和注释对于浏览器的渲染来说是完全没有必要的. 所以, 空格和注释都被去掉了. Gzip压缩已经在原站点中开启, 进一步的减少了文件的尺寸. 图片不能被Gzip压缩, 因为jpeg, gif和png文件格式本身就是压缩了的.
移除重复
任何重复的被不止一次下载的JavaScript和样式表文件都在合并的过程中做成了对资源的单个引用.
手动或自动
上面提到的所有步骤也可以通过手工的修改资源文件的方式来做到, 但是我们是使用Aptimize Website Accelerator自动完成的. 这个软件可以动态的优化SharePoint页面的访问速度.
第三步: 结果
===============
做了所有的修改之后, 团队再次使用WebPageTest衡量了从世界各地访问页面的页面加载时间.
first view的瀑布图表明HTTP请求从96减少到了35.
repeat view的瀑布图同样显示出HTTP请求从50减小到了9.
新页面的加载时间
First View页面加载时间被减少了46%到64%, 这对于高延迟连接的用户来说是巨大的改进. repeat view的加载时间减小了15%到53%, 并且起始渲染时间减少了超过50%. 这些好处主要是由于减少了HTTP请求的原因.
减少了HTTP请求, 增加了缓存, 减小了文件的尺寸, SharePoint页面现在已经使用了站点性能的最佳优化实践. 未来的优化可能是要针对post-load动作进行, 可以优化silverlight控件, 但是SharePoint页面自己现在已经是很高的性能了. 安装和配置的过程只花了几个小时的功夫, 结果还不错.
结论
=========
更快的站点可以提高用户的访问体验, 更聪明的使用一些技术, 我们可以继续设计和建造与工业级最佳实践匹配的高性能站点, 还可以动态的确定低带宽和高延迟的问题. 结果呢, 我们可以确信全世界的用户都可以在我们的站点拥有更好的访问体验, 没的说!
Tony Tai – SharePoint 高级产品经理, 微软公司.
翻译后记: 有点为Aptimize Website Accelerator做广告的嫌疑, 不过文章所讲的技术还是很不错的. 希望能都对您有所启发和帮助. -闻道学友