zoukankan      html  css  js  c++  java
  • 【前端开发】提高站点载入速度

    版权声明:转载请注明出处 https://blog.csdn.net/a503921892/article/details/37355771
    尊重原创:可是出处不明......
    YSlow是yahoo美国开发的一个页面评分插件。非常的棒,从中我们能够看出我们页面上的非常多不足,并且能够知道我们改怎么却改进和优化。 
      细致研究了下YSlow跌评分规则主要有12条:
      1. Make fewer HTTP requests 尽可能少的http请求。。

    我们有141个请求(当中15个JS请求。3个CSS请求,47个CSS background images请求),多的可怕。

    思考了下,为什么把这个三种请求过多列为对页面载入的重要不利因素呢。而过多的IMG请求并没有列为不利因素呢?   发现原来这些请求都是能够避免的。

      15个JS和3个CSS全然能够通过特殊的办法进行合并(这个技术部已经帮我们攻克了,实在是太感谢了,嘿嘿。)。这样合并以后,普通情况下页面上仅仅会出现一个JS和一个CSS(对JS的封装得有一定的要求)。   可是47个CSS background images请求改怎么解决呢?为什么页面上的纯IMG请求时合理的。而CSS background images请求过多就是不利因素了呢。这个我想了非常久。总算明白,原来是这种:   一般页面上的ICON。栏目背景啊,图片button啊。我们都会用图片CSS背景来实现,而一般这个图片CSS背景用到的图片都是比較小的,所以全然能够把这些图片合并成一个相对照较大的图片,这样页面上仅仅会出现一个CSS background images请求,最多也就2-3个。

    后来细致看了下雅虎美国的页面,他们的确也是这样做的,尽管这样做须要花一定的时间来有规则的合并这些ICON。栏目背景,图片button,以方便CSS调用,可是这样做绝对是合算的,并且是有必要的,YSlow也是极力推荐的。   2. Use a CDN这项我们的评分是F级,最低。说实在的,我刚開始什么是CDN都不知道。后来查了GOODLE才知道。CDN的全称是Content Delivery Network。即内容分发网络。其目的是通过在现有的Internet中添加一层新的网络架构。将站点的内容公布到最接近用户的网络”边缘”,使用户能够就近取得所需的内容,解决Internet网络拥挤的状况,提高用户訪问站点的响应速度。从技术上全面解决由于网络带宽小、用户訪问量大、网点分布不均等原因所造成的用户訪问站点响应速度慢的问题。

      看来上述的解释后,基本上明白了CDN是怎么回事,后来咨询了下中文站点SA。得知我们站点眼下的确还没有做CDN的优化,可是据说我们有更加先进的技术来解决相似的问题(详细什么技术那就保密了)。可是毕竟CDN也是个相当不错的技术,所以在我们先进技术的基础上在做CDN优化,肯定比方今更好,嘿嘿。

    据说SA明年会做几个点的CND。   3. Add an Expires header设置过期的HTTP Header.设置Expires Header能够将脚本。 样式表, 图片, Flash等缓存在浏览器的Cache中。   事实上我们站点也做了这个优化,至少图片在这个上做过优化,可是没有做全然。我们的CSS和JS都还没有做过优化,倒是外部引入的一个广告JS做了,呵呵。事实上设置过期的HTTP Header 更应该做在脚本。 样式表, Flash上。只是据说这个SA也是没有做的。可是有一定的风险,由于JS和CSS是有一定的逻辑,假设server端和client都存在缓存的话。万一出了什么问题,对我们以后查找问题的所在和添加难度,只是我想两者中是能够权衡和并存的。   4. Gzip components 对我们的页面内容进行Gzip格式的压缩,Gzip格式是一种非常普遍的压缩技术。差点儿全部的浏览器都有解压Gzip格式的能力。并且它能够压缩的比例非常大,一般压缩率为85%。就是说server端100K的页面能够压缩到25K左右的Gzip格式的数据发给client,client收到Gzip格式的数据后自己主动解压缩后显示页面。   5. Put CSS at the top 把CSS外部链接放到页面的顶部。   事实上这个原则我们一般都遵守的,假设把CSS外部链接作为逻辑的一部分出如今页面头部下面,我个人认为这个本身就是个错误。还好。我们的页面基本上都做到了,可是有些页面比方LIST页面。还是出现了和逻辑挂钩的CSS链接,原因是为了解决一些本来就不合理的产品逻辑。

    所以,我们WEB前端project师有义务杜绝这些不合理的产品逻辑破坏我们的页面结果及页面载入速度,不能为了实现而实现。   6. Put JS at the bottom 把Javascript脚本尽量放到页面底部载入。   一開始为以为Javascript脚本尽量放到页面底部载入,是指全部的JS脚本都要放究竟部,后来才发现,并不全然是这样,这里所指的脚本是指那些在载入过程中要执行的脚本,所以一般的处理办法还是页面头部引入JS链接。页面底部执行JS脚本程序。为什么要这么做呢?呵呵,事实上非常easy,为了实现最大的下载并行,页面载入初期做的事,最好仅仅有下载,HTML的下载。CSS的下载,JS的下载,等完成下载后再去实现页面渲染。JS脚本执行。这个方面我们还须要努力,非常多页面我们在载入过程中执行了一部分脚本,也许是为了实现一些功能,没有办法,只是也许有更好的办法来替代呢。。。   7. Avoid CSS expressions 避免CSS表达式   事实上在CSS中执行表达式和页面载入中执行大量的JS脚本几乎相同,也许还更慢。并且还不兼容。尽管能够使我们在页面逻辑简单不少,可是我们全然能够抛弃之。这个点,我们的页面基本上都做到了。只是说实话,CSS表达式,嘿嘿,我曾经还不知道有这么回事。羞愧。

    哈哈。   9. Reduce DNS lookups 尽可能少的DNS查找。   这项我们做的不是非常好。D级。有9个域名,一般不要超过4个。只是这个主要是server架构上的问题,我们也无能为力,如今单单首页的广告域名就有好几个。好耶的广告域名。雅虎的广告域名,淘宝店广告域名,打点的域名。假设去掉这些。我们事实上还是够用的,一个主域名,一个图片的。一个STYLE的,最多加上IFREAM的刚好4个。

      10. Minify JS 对Javascript代码进行压缩。

      这点我非常早曾经就对此关注了。也找到了一个不错的压缩工具。yuicompressor,雅虎美国开发的JAVA压缩包yuicompressor.jar。

    压缩的相当完美,不仅把代码间的空格换行给去除掉了,并且对变量名,北部方法名都进行的简化,无意中实现了混淆脚本的作用。如今我们仅仅做到了JS合并,并没有对齐进行压缩。假设我用yuicompressor手工的去压缩,尽管实现了JS压缩,可是给我们自己的维护量添加了一倍。由于我们须要维护2套JS脚本,一套是压缩前的(调试用的),一套是压缩后(公布到网上的),并且要保证2套代码一致。所以最完美的做法是在公布的时候实现JS脚本合并,并对其用yuicompressor进行压缩。然后公布到晚上,把关键点移到公布的时候,这样我们仅仅须要关心一套JS脚本(公布前的版本号)。并且我认为这个方法全然是行动通的。

      11. Avoid redirects 避免重定向(跳转)   怎么理解这点呢?   一般我们页面的链接都写成: http://www.xahl.net.cn 或者 http://www.xahl.net.cn/ ,有人会问。有差别吗?我明白的告诉大家,有。server假设接收到的URL是没有带“/”的URL。它会自己主动又一次定向到带有“/”,尽管最后都打开了阿里巴巴中文站的首页。可是前者比后者多走了一步,重定向。显然多多少少浪费了一定的时间。

    所以以后我们加URL链接的时候,别忘了把最后的“/”给加上去。   12. Remove duplicate scripts 去除反复的脚本   这个事实上没有什么好说的。大家都应该毫无条件的去遵守,可是越是明显。越是简单的事,我们往往会做不好,当然,非常多理由的,项目时间太紧张了等等,导致代码非常乱。非常多反复的地方。事实上谁都知道重负不好,只是还好,我们的页面反复的脚本代码不多(至少一个页面里面,呵呵)。只是,我到是希望。我们不仅要做到一个页面脚本不反复,并且要做到N个页面。脚本要重用。

      13. Configure ETags 这个好像是server端配置的问题。我不太懂,也就不乱说了。怕把大家给误导了。   总共13个,可是看了YAHOO的官方说明,好像另一个AJAX CACHE(AJAX 缓存)。

    我倒是认为这个非常重要。随着我们AJAX应用的广泛,AJAX 缓存这个概念一定要时刻在我们脑子中。AJAX是个好东西,可是反复的数据,无休止的向后台申请,绝对是个错误(不仅是速度上还是对server压力上来说),所以我们就要对我们已经申请到的数据进行缓存,当第2次用到的时候,就直接从缓存中取,不要在去訪问我们宝贵的server资源了。事实上这个思想不仅仅适合AJAX,在全部有数据复用的应用中都应该考虑到。

      YSLOW就分析到这里完成了,也许有些地方分析的不是非常正确,也许有人分析的比我更早,更好,可是这些的确是我从工作中去积累。发现的,并不是常多都实际应用到工作中去了,顺便说下,嘿嘿,LIST页面进行优化后,在0.92版本号的YSLOW评分将达到76分,甚至80分。相当于0.8版本号的90分以上。只是评分毕竟是评分。关键还是速度。

    http://www.xahl.net.cn 或者 http://www.xahl.net.cn/ ,有人会问,有差别吗?我明白的告诉大家。有!

    server假设接收到的URL是没有带“/”的URL,它会自己主动又一次定向到带有“/”,尽管最后都打开了阿里巴巴中文站的首页,可是前者比后者多走了一步,重定向,显然多多少少浪费了一定的时间。所以以后我们加URL链接的时候,别忘了把最后的“/”给加上去。   12. Remove duplicate scripts 去除反复的脚本   这个事实上没有什么好说的。大家都应该毫无条件的去遵守,可是越是明显,越是简单的事,我们往往会做不好。当然。非常多理由的,项目时间太紧张了等等。导致代码非常乱。非常多反复的地方。

    事实上谁都知道重负不好,只是还好,我们的页面反复的脚本代码不多(至少一个页面里面,呵呵)。

    只是。我到是希望,我们不仅要做到一个页面脚本不反复,并且要做到N个页面,脚本要重用。

      13. Configure ETags 这个好像是server端配置的问题,我不太懂,也就不乱说了。怕把大家给误导了。   总共13个。可是看了YAHOO的官方说明。好像另一个AJAX CACHE(AJAX 缓存)。我倒是认为这个非常重要。随着我们AJAX应用的广泛,AJAX 缓存这个概念一定要时刻在我们脑子中。AJAX是个好东西,可是反复的数据,无休止的向后台申请,绝对是个错误(不仅是速度上还是对server压力上来说),所以我们就要对我们已经申请到的数据进行缓存。当第2次用到的时候,就直接从缓存中取。不要在去訪问我们宝贵的server资源了。事实上这个思想不仅仅适合AJAX。在全部有数据复用的应用中都应该考虑到。   YSLOW就分析到这里完成了。也许有些地方分析的不是非常正确,也许有人分析的比我更早,更好。可是这些的确是我从工作中去积累,发现的。并不是常多都实际应用到工作中去了,顺便说下,嘿嘿。LIST页面进行优化后。在0.92版本号的YSLOW评分将达到76分,甚至80分,相当于0.8版本号的90分以上。只是评分毕竟是评分,关键还是速度。

     

  • 相关阅读:
    Chrome
    给Xshell增加快速命令集
    Integer对象大小比较问题
    maven的mirror和repository加载顺序
    maven的settings.xml详解
    OAuth2.0 RFC 6749 中文
    Linux下netstat命令简单操作
    Linux里的几种不同的压缩命令小记
    [ASIS 2019]Unicorn shop
    Metasploit魔鬼训练营第一章作业
  • 原文地址:https://www.cnblogs.com/mqxnongmin/p/10837035.html
Copyright © 2011-2022 走看看