网站优化建议规范.docx

_网站优化建议2010年6月制订版 本 控 制修 改 历 史 记 录目 录1.概述4目的4适用范围42.Web页面性能方法42.1前端页面性能优化方法52.2Web后端性能优化方法83.案例分析93.1SDO官网分析93.1.1单一页面打开时间过长影响整体速度93.1.2单一域名下内容访问访问时间过长影响整体性能113.2Pay首页分析123.2.1单一URL访问超时影响整体速度123.2.2单一URL页面错误144.总结151. 概述随着WEB2.0时代的来临，网络的也得到了空前的发展，前端用户体验变得越来越重要。WEB性能优化是个大话题，也是个值得运维人员持续跟踪的话题。目的本文主要对网站的优化方法进行阐述，从而给出网站的优化建议，并对优化建议进行规范，从而提高WEB性能，达到提高用户体验的目的。适用范围接入CDN的所有网站。2. Web页面性能方法网站的划分一般为为二，前端和后台。后台是用来实现网站功能，如用户注册、用户发帖等，前端是后台功能的表现，前端包括图片、脚本、flash、视频等，因此，除了后台需要在性能上优化外，前端的页面也需要在性能优化上多下功夫，这样才能给我们的用户带来更好的体验。2.1 前端页面性能优化方法前端页面主要包括html、css、javascript，其实html就是网页的内容，文字，图片flash，视频等。针对前端页面的内容，结合yslow优化网站规则，提出对前端页面性能优化的建议。1. HTML静态化众所周知，效率最高、消耗最小的是纯静态化的html页面，因此尽可能的将网站上的页面采用静态页面来实现。网站静态化是网站优化的重要手段之一，同时，html静态化是一些缓存策略使用的手段，建议将频繁使用数据库查询但是内容更新很小的应用，用html静态化来实现，如一些网站的公用设置信息，这样可以避免大量的数据库访问请求。2. 动、静态分离对于web服务器而言，图片是罪消耗资源的，因此，有必要将图片与页面进行分离，这是很多网站都会采用的策略，设置专门的图片服务器和域名，可以降低提供页面访问请求的服务器压力，并且可以保证网站不会因为图片问题而崩溃。3. 减少http请求由于http协议的无状态性，用户每一次访问，都会重新向服务器请求所有文件，包括页面中的图像、样式表、脚本、Flash等；而大量http请求的累加，正是影响网站速度的主要原因之一。通过减少页面中的元素可以减少HTTP请求的次数，这是提高网页速度的关键。减少页面元素的方法就是简化页面设计，可以从以下几个方面考虑：1) 合并文件：通过把所有的脚本放到一个文件中来减少HTTP请求；可以简单的把所有的css文件都放入一个样式表中。虽然当脚本或者样式表在不同页面中使用时需要做不同的修改，相对比较麻烦，但这是改善页面性能的关键一步。2) Css sprites：减少图像请求的有效方法，将所有的背景图像都放到一个图片文件中，然后通过CSS的background-image 和background-position 属性来显示图片的不同部分；3) 图片整合：将多张图片整合到一张图片中，虽然文件的总大小不会改变，但可以减少HTTP请求的次数；该方法只适合图片的所有组成部分在页面中是相邻在一起的，如导航栏，该方法确定图片的坐标比较繁琐并且容易出错。减少页面的HTTP请求次数是首要步骤，这是改进首次访问用户等待时间的最重要的方法。4. 避免重定向每一次的重定向都会重新发送Header请求，在用户和HTML文档中间增加一个中定向，会拖延页面中所有元素的显示，因为在HTML文件被夹在前任何文件都不会被下载，因此，重定向会降低用户体验。有一种重定向往往很容易被忽视却又很浪费响应时间，这种现象发生在URL本应该有（/）而被忽略掉时；这时会返回一个301的状态吗然后重新发起一次请求。如和/，前者比后者多了一步重定向。5. 优化浏览器加载1) 将css放在页面顶部加载将CSS放在页面head部分允许浏览器渐进的渲染页面，使核心的页面内容今早显示出来，缩短用户等待空白页面的时间，改善用户体验。2) 将js放在页面底部加载由于脚本下载是串行的，因此，当一个脚本下载的时候，浏览器将无法下载其他资源，将脚本放在页面底部进行处理可以加快页面加载的速度，但一些功能性的脚本实现起来可能有些困难。6. 缓存AJAX请求在很多应用中，用户是否需要等待响应取决于Ajax如何来使用。提高Ajax性能的最重要方法就是使响应具有可缓存性。Ajax缓存通常有如下方法：1) 在服务端加 header(Cache-Control: no-cache, must-revalidate); 2) 在ajax发送请求前加上 xmlHttpRequest.setRequestHeader(If-Modified-Since,0); 3) 在ajax发送请求前加上 xmlHttpRequest.setRequestHeader(Cache-Control,no-cache); 4) 在 Ajax 的 URL 参数后加上 ?fresh= + Math.random(); /当然这里参数 fresh 可以任意取了5) 在 URL 参数后加上 ?timestamp= + new Date().getTime(); /推荐使用这种方式6) 用POST替代GET：不推荐用7. 减少404错误HTTP请求时间消耗很大，因此使用HTTP请求来获得一个错误的响应（如404没有找到页面）会很大程度降低用户体验。一些站点将404错误响应页面改为“你不是不要找*”，虽然改进了用户体验但同样会浪费服务器资源。对页面链接进行充分测试并且对web服务器error日志不断跟踪能有效减少404错误，并且能提升用户体验。8. 为文件头指定expires或者cache-control，文件缓存Expires是浏览器cache机制的一部分，设置Expires Header可以将脚本、样式表、图片、Flash等缓存在浏览器的Cache中。对于静态内容：设置文件头过期时间Expires的值为“Never expire”（永不过期）动态页面，在代码中添加cache-control，表示多少时间之后过期，如：Response.setheader（“cache-control”，“max-age=3600”）Expire头应该包含任何不经常变化的元素，包括脚本、样式表、Flash等；如果使用了Expires文件头，当页面内容改变时就必须改变内容的文件名，通常是在文件内容后加版本号。使用Expires文件头只有对用户已经访问过的网站起作用，当用户首次访问网站试，减少HTTP请求次数是无效的，因为浏览器的缓存是空的。9. Gzip压缩文件内容对于大部分网站，使用Gzip压缩文件这是必要的一部，能有效减轻网络流量的压力。Gzip格式是一共很普遍的压缩技术，技术所有的浏览器都有解压Gzip格式的能力，而且它的压缩比例非常大，一般压缩率为85%；但需要指出的是图片和PDF文件不应当压缩。2.2 Web后端性能优化方法Web后端即服务器端，服务器端即网站的动态语言（asp、php）的执行，数据库查询，存储等速度，也就说输入/输出的运算；虽然这些与前端关系较小，但同样会影响前端。后端优化重点从数据库优化进行。数据库优化是后端所有优化策略中最重要的，数据库设计的好坏，直接影响一个应用的承受力，数据库优化主要从数据库设计思路出发，分库、分表、缓存表。1) 分库指的是在设计中，要考虑到后期数据量大的情况下，数据库能够随着应用随时拆分，这个拆分并不只针对功能模块对应的数据拆分。2) 分表即对同类型的数据，可以为了性能优化，进行拆分到多个表中，拆分规则可以有多种，如按照类型、时间、姓名等。3) 缓存表目的是针对一个大的数据表中，针对死数据和活动数据的情况，采用缓存表的模式，在实际表和用户之间搭建一个临时表，用户访问时，首先访问临时表，如果不存在则在实际表中获取，然后放入缓存表中，同事通过后台线程，定时将缓存表数据同步到实际数据库中，同步时间可以针对系统要求来进行。3. 案例分析本部分内容对接入CDN的重点应用，利用第三方对网络覆盖质量进行监控，在监控过程中发现的问题进行分析，以便帮助其他网站优化提供参考。3.1 SDO官网分析3.1.1 单一页面打开时间过长影响整体速度1. 案例一: 2010年3月23日，在统计SDO官网相关数据时发现，SDO官网总下载时间高达12秒以上，较前一日上升4秒左右。排查过程：1) 通过基调网络的散点图发现，大部分访问时间较长的监测点，均是由于以下链接的访问时间较长导致，/cas/login?gateway=true&service=http%3A%2F%2Fwww%2Esdo%2Ecom%2FIndexIframeLoginNewAgent%2Easp，具体信息如下图：2) 公司内本地测试，以上链接打开需要2秒以上的时间。3) 由于链接为用户登陆页面，无法接入CDN进行加速，因此，联系开发人员对该链接进行优化。 处理结果：开发人员对的优化，该链接的访问时间降低到1秒以内，SDO官网整体速度下降。2. 案例二2010年6月3日，SDO官网总下载时间达19秒，较前一日上升3秒多。排查过程：1) 根据基调网络的监测结果发现，主要由于以下链接访问时间高达60多秒导致，2) 联系开发人员得知，该链接为前一天新增获取用户登陆PID信息，会尽快对该链接进行优化。处理结果：由于前一天上线过一个“快速入口”的功能，经过分析页面，调整了程序代码，去掉了这个请求。3.1.2 单一域名下内容访问访问时间过长影响整体性能1. 案例一：接入CDN初期，页面总下载时间下降较小，用户体验提高效果不明显。排查过程：根据基调监测结果，对散点图中时间较长的监测点进行查看，访问时间较慢的是由于官网下调用的其他域名下的一些图片访问时间过长引起的。处理结果：整理官网下所有调用的域名，将可以接入CDN的官网周边域名进行测试后接入CDN。3.2 Pay首页分析3.2.1 单一URL访问超时影响整体速度1. 案例一：3月30日开始，在每天的 2:003:00期间内总下载时间高达60多秒。排查过程：根据基调的“性能历史曲线图”和”散点图”发现，访问时间较慢的是域名下一个链接超时，具体链接为：，因为出现问题的时间段比较规律，因此判断该链接存在异常，告知开发进行排查。处理结果：由于该时间段有一个切表定时的Job, 目前历时40多分钟。解决办法：停止该切表操作，改为每月定期维护时人工一次性操作。3.2.2 单一URL页面错误案例：4月27日开始，发现散点图有大量的错误。排查过程：由基调的监测数据显示，“”链接出现大量400错误，如下：告知开发进行排查错误