Yslow-23条规则编辑

1. 减少HTTP请求次数

合并图片、CSS、JS,改进首次访问用户等待时间。

2. 使用CDN

就近缓存==>智能路由==>负载均衡==>WSA全站动态加速

3. 避免空的src和href

当link标签的href属性为空、script标签的src属性为空的时候,浏览器渲染的时候会把当前页面的URL作为它们的属性值,从而把页面的内容加载进来作为它们的值。测试

4. 为文件头指定Expires

使内容具有缓存性。避免了接下来的页面访问中不必要的HTTP请求。

5. 使用gzip压缩内容

压缩任何一个文本类型的响应,包括XML和JSON,都是值得的。旧文章

6. 把CSS放到顶部

7. 把JS放到底部

防止js加载对之后资源造成阻塞。

8. 避免使用CSS表达式

9. 将CSS和JS放到外部文件中

目的是缓存,但有时候为了减少请求,也会直接写到页面里,需根据PV和IP的比例权衡。

10. 权衡DNS查找次数

减少主机名可以节省响应时间。但同时,需要注意,减少主机会减少页面中并行下载的数量。

IE浏览器在同一时刻只能从同一域名下载两个文件。当在一个页面显示多张图片时,IE 用户的图片下载速度就会受到影响。所以新浪会搞N个二级域名来放图片。

 

11. 精简CSS和JS

12. 避免跳转

同域:注意避免反斜杠 “/” 的跳转;

跨域:使用Alias或者mod_rewirte建立CNAME(保存域名与域名之间关系的DNS记录)

13. 删除重复的JS和CSS

重复调用脚本,除了增加额外的HTTP请求外,多次运算也会浪费时间。在IE和Firefox中不管脚本是否可缓存,它们都存在重复运算JavaScript的问题。

14. 配置ETags

它用来判断浏览器缓存里的元素是否和原来服务器上的一致。比last-modified date更具有弹性,例如某个文件在1秒内修改了10次,Etag可以综合Inode(文件的索引节点(inode)数),MTime(修改时间)和 Size来精准的进行判断,避开UNIX记录MTime只能精确到秒的问题。 服务器集群使用,可取后两个参数。使用ETags减少Web应用带宽和负载

15. 可缓存的AJAX

“异步”并不意味着“即时”:Ajax并不能保证用户不会在等待异步的JavaScript和XML响应上花费时间。

16. 使用GET来完成AJAX请求

当使用XMLHttpRequest时,浏览器中的POST方法是一个“两步走”的过程:首先发送文件头,然后才发送数据。因此使用GET获取数据时更加有意义。

17. 减少DOM元素数量

是否存在一个是更贴切的标签可以使用?人生不仅仅是DIV+CSS

18. 避免404

有些站点把404错误响应页面改为“你是不是要找***”,这虽然改进了用户体验但是同样也会浪费服务器资源(如数 据库等)。最糟糕的情况是指向外部 JavaScript的链接出现问题并返回404代码。首先,这种加载会破坏并行加载;其次浏览器会把试图在返回的404响应内容中找到可能有用的部分当 作JavaScript代码来执行。

19. 减少Cookie的大小

20. 使用无cookie的域

比如图片 CSS 等,Yahoo! 的静态文件都在主域名以外,客户端请求静态文件的时候,减少了 Cookie 的反复传输对主域名的影响。

21. 不要使用滤镜

png24的在IE6半透明那种东西,别乱使,淡定的切成PNG8+jpg

22. 不要在HTML中缩放图片

23. 缩小favicon.ico并缓存

时间: 2024-08-03 07:52:37

Yslow-23条规则编辑的相关文章

Yslow-23条规则

YslowYahoo发布的一款基于FireFox的插件,主要是为了提高网页性能而设计的,下面是它提倡了23条规则,还是很不错的,分享一下: 1.减少HTTP请求次数 合并图片.CSS.JS,改进首次访问用户等待时间. 2. 使用CDN 就近缓存==>智能路由==>负载均衡==>WSA全站动态加速 3. 避免空的src和href 当link标签的href属性为空.script标签的src属性为空的时候,浏览器渲染的时候会把当前页面的URL作为它们的属性值,从而把页面的内容加载进来作为它们的

web前端-雅虎34条规则优化

1.尽量减少HTTP请求次数      终端用户响应的时间中,有80%用于下载各项内容.这部分时间包括下载页面中的图像.样式表.脚本.Flash等.通过减少页面中的元素可以减少HTTP请求的次数.这是提高网页速度的关键步骤.      减少页面组件的方法其实就是简化页面设计.那么有没有一种方法既能保持页面内容的丰富性又能达到加快响应时间的目的呢?这里有几条减少HTTP请求次数同时又可能保持页面内容丰富的技术. 合并文件是通过把所有的脚本放到一个文件中来减少HTTP请求的方法,如可以简单地把所有的

C安全编码标准:开发安全、可靠、稳固系统的98条规则(原书第2版)——互动出版网

这篇是计算机类的优质预售推荐>>>><C安全编码标准:开发安全.可靠.稳固系统的98条规则(原书第2版)> 部分目录 译者序 前言 贡献者简介 第1章 预处理器(PRE) 1 1.1 PRE30-C. 不要通过连接创建通用字符名称 1 1.2 PRE31-C. 避免不安全宏参数的副作用 3 1.3 PRE32-C. 不要在类函数的宏调用中使用预处理器指令 7 第2章 声明和初始化(DCL) 9 2.1 DCL30-C. 声明具有正确存储持续期的对象 10 2.2 DCL

《C++编程规范:101条规则、准则与最佳实践》学习笔记

转载:http://dsqiu.iteye.com/blog/1688217 组织和策略问题 0. 不要为小事斤斤计较.(或者说是:知道什么东西不需要标准化) 无需在多个项目或者整个公司范围内强制实施一致的编码格式.只要规定需要规定的事情:不要强制施加个人的喜好或者过时的做法. C++不应该使用匈牙利命名法.在有智能指针的情况下,单入口单出口可能不是必须的.代码要有自注释性. 1. 在高警告级别下干净地编译代码. 要把警告放在心上:使用你的编译器的最高警告级别.要求干净(没有警告)的构建.理解所

c++编程规范101条规则

很久没有更新过博客了,其实不管多忙,有时候写写博客未尝不是一种提升.下面是我最近看的一本书的部分内容. 1.不要忽视警告,尽量没有警告. 2.使用自动构建系统 3.使用版本控制系统 4.在代码审查上投入 5.一个实体应该只有一个紧凑的职责 6.正确,简单和清晰的代码. 7.编程中应知道何时和如何考虑可伸缩性 8.不要进行不成熟的优化. 9.不要进行不成熟的劣化. 10.尽量减少全局和共享数据. 11.隐藏信息. 12.懂得何时和如何进行并发性编程. 13.确保资源为对象所拥有,使用显式的RALL

软硬件调试九法:第四条规则 分而治之

1.通过逐次逼近缩小搜索范围        通过二分法,逐次缩小问题范围,在查找问题时,这个方法是唯一需要应用的规则,所有其它规则都是帮助你遵循这条规则.首先搜索前面1/2,如果有错,则再搜索前1/4,如果没错,则搜索范围就定在1/4-1/2之间,然后再次细分,几次之后就会找到问题. 实际案例:有次程序运行反应很慢,特别是蜂鸣器响一次后,要几秒钟的时间,才能相应按键.因此就采用这个方法,很快确定慢是由等待蜂鸣器时间过长导致,从程序逻辑看,等待蜂鸣器结束函数并没有错误,但是其中while循环等待的

(知识分享)软硬件调试九法:第九条规则 如果你不修复一个bug,它将永远 存在

1.查证问题确已被修复 如果遵循了“制造失败”这条规则,就知道如何验证你确实修复了问题.无论问题和修复看起来多么明显,你都无法保证修复是有效的,直到做了测试并验证. 2.查证确实你的修复措施解决了问题 如果你取消这个修复,系统再次出现失败,再应用这个修复,问题消失,才能够证明你确实修复了问题.这样做的原因是,在调试期间,往往会改变一些不属于修复的地方,有时这些改变会隐藏问题,如果没有意识到这一点,发现测试起作用了,就高高兴兴的回家了,因为你做的修复和问题消失毫无关系,因此修复方案到达客户后,可能

旗正规则引擎规则编辑

看到有人问,旗正规则引擎定位就是规则逻辑实现简易,业务员也可以执行,可是试用的时候,突然发现还是有些凌乱,规则编辑感觉还是有点繁琐啊.那我说,方法还是没对路,接下来,我来给献上宝典. 规则包开发 通过"开始-->程序-->旗正商业规则定制平台->规则配置器"启动规则配置器.启动后, 关闭欢迎首页, 进入到缺省的开发工作空间. 通过规则配置器的测试步骤包括创建工程.创建规则包.定义对象库.定义规则.发布规则包.测试规则包.创建web页面.web方式测试规则包 以下分别讲

Java日志记录的5条规则

日志记录是在软件开发过程中常常需要考虑的关键因素. 当产品运行出错时,日志文件通常是我们进行错误分析的首要选择. 而且,在很多情况下,它们是我们手上唯一可以用来查明发生状况和问题根本原因的信息. 可见,正确记录需要的信息是极其重要的. 以下5条日志规则,让我们可以检查和改进在代码中操作日志记录的方式. 同时也请注意,我们既不会讨论怎么配置一个日志引擎,也不会相互比较. 规则1.日志是面向读者的 日志消息不仅要对书写(日志)代码的人有意义,也应该对日志文件的读者有意义. 这似乎是一条很明显但却经常