CDN上如何 解决vue实现文件上传 JS/CSS自动压缩方案

欢迎来到DIVCSS5查找CSS资料与学习DIV CSS布局技术!您的位置: >
> Web性能优化最佳实践中最重要的一条是减少HTTP请求,它也是YSlow中比重最大的一条规则。减少HTTP请求的方案主要有合并JavaScript和CSS文件、CSS Sprites、图像映射(Image Map)和使用Data URI来编码图片。CSS Sprites和图像映射现在已经随处可见了,但由于IE6和IE7不支持Data URI以及性能问题,这项技术尚未大量使用。目前大部分网页中的JavaScript和CSS文件数量和开发时一致,少量的网页会根据实际情况采取本地合并,这些合并中相当多的是有选择地手动完成,每次新的合并都需要重新在本地完成并上传到服务器,比较的随意和繁琐,同样文件的压缩也有类似的情况。而利用服务端的合并和压缩,我们就可以按照开发的逻辑尽可能让文件的颗粒度变小,利用网页中URL的规则来自动实现文件的合并和压缩,这会相当的灵活和高效。
一、YUI Combo Handler
。Combo Handler是Yahoo!开发的一个Apache模块,它实现了开发人员简单方便地通过URL来合并JavaScript和CSS文件,从而大大减少文件请求数。比如在页面上使用&需要引入多个JavaScript文件,常用方式如下:
&script src=&http://yui.yahooapis.com/2.8.0r4/build/yahoo-dom-event/yahoo-dom-event.js&&&/script&&script src=&http://yui.yahooapis.com/2.8.0r4/build/container/container_core-min.js&&&/script&&script src=&http://yui.yahooapis.com/2.8.0r4/build/menu/menu-min.js&&&/script&&script src=&http://yui.yahooapis.com/2.8.0r4/build/element/element-min.js&&&/script&&script src=&http://yui.yahooapis.com/2.8.0r4/build/button/button-min.js&&&/script&&script src=&http://yui.yahooapis.com/2.8.0r4/build/editor/editor-min.js&&&/script&
而使用Combo Handler服务之后,则上述的代码可以写为:
&script src=&http://yui.yahooapis.com/combo?2.8.0r4/build/yahoo-dom-event/yahoo-dom-event.js&2.8.0r4/build/container/container_core-min.js&2.8.0r4/build/menu/menu-min.js&2.8.0r4/build/element/element-min.js&2.8.0r4/build/button/button-min.js&2.8.0r4/build/editor/editor-min.js&&&/script&
除了代码的可读性稍稍有一点点降低外,使用Combo Handler服务大大的降低了HTTP请求数,同时也减少了URL代码量,这对于Web性能优化来讲至关重要。所以,随后YUI从2.6.0开始,,即使用YUI Loader时,通过配置combine属性就可以把要加载的多个JavaScript或CSS文件按照使用Combo Handler服务的形式合并起来,这时只要静态文件的服务器支持Combo Handler就行了。在YUI中当combine配置为true时,CDN默认是使用Yahoo! CDN(
遗憾的是&,但尚未提供Combo Handler服务,同时因种种原因,其更新在YUI 2.7.0之后就停滞了。更糟糕的是Yahoo!开发的支持Combo Handler的Apache模块虽然据传有计划开源,但至少现在依旧是私有技术,要使用就需要自己实现类似功能,所以国内类似技术的应用并不太多。
二、Minify
在Google Code上有一个PHP的开源项目叫它可以合并、精简、Gzip压缩和缓存JavaScript和CSS文件。其文件合并功能就非常类似Combo Handler,只不过URL的语法稍微有点不同。如果Yahoo! CDN安装了Minify,那么上面Rich Text Editor的代码用Minify的默认格式来写就是:
&script src=&http://yui.yahooapis.com/min/f=2.8.0r4/build/yahoo-dom-event/yahoo-dom-event.js,2.8.0r4/build/container/container_core-min.js,2.8.0r4/build/menu/menu-min.js,2.8.0r4/build/element/element-min.js,2.8.0r4/build/button/button-min.js,2.8.0r4/build/editor/editor-min.js&&&/script&
1)使用Minify
本地使用Minify很简单,只需要Apache + PHP环境就OK了:
安装好Apache + PHP (Windows、Mac)。
下载Minify源码,解压,然后把min文件夹复制到指定的根目录下,比如localhost。这时URL的写法大概是http://localhost/min/f=&
启用Apache的Mod Rewrite模块,然后在min文件夹下新建.htaccess文件,并添加Rewrite规则[1]。如果不启用Mod Rewrite功能,则Minify的URL会类似http://localhost/min/index.php?f=&,,而启用了Mod Rewrite之后的URL类似http://localhost/min/f=&,不仅解决前面问题且更短。
配置Minify,即编辑min/config.php文件[2]
使用Minify比如,有两个JavaScript文件,http://localhost/example/a.js,http://localhost/example/b.js,那么使用Minify合并的URL是http://localhost/min/f=/example/a.js,/example/b.js,直接把这个URL放到页面中就可以使用了。实际上Minify不仅仅实现了合并功能,同时默认在合并的同时还会对文件进行精简压缩,如果你在本地本身就对文件进行压缩了,比如使用,那么可以在config.php中进行如下设置取消Minify的压缩以提升性能[3],如果服务端支持Java,那么也可以对。直接在服务端进行合并和压缩,这非常的灵活,也极大的减轻了前端开发成果的部署过程,真使事半功倍。更多配置请看&和.
2)在YUI3中使用Minify
在YUI2中,合并机制只支持库本身的文件,自定义的文件会单独一一加载。从YUI3开始,模块变得更小,这样就导致使用合并时URL会变长,但,Apache默认的URL最大值是8192,所以当URL在对应浏览器下超出最大值时,YUI3会自动根据浏览器判断进行拆分成多个合并的URL,并且还提供了来设置最大值。而从YUI3.1.0开始,不仅仅支持自定义文件的合并,还支持可以使用多个提供合并服务的CDN,即可以对YUI组件使用就说明了这点。由于YUI默认URL的合并形式和Minify的不相同,所以在YUI实例化时需要利用正则替换来实现YUI3支持Minify的URL合并形式,但这种方式既不灵活,且有风险,不友好又效率低。比较简单的方式是直接修改YUI 3的源码,如示例。同时,YUI 3.1.*的版本有一个bug,即同时合并JavaScript和CSS时,较短的那个URL结尾处多一个&符号,如示例中:
http://yui.yahooapis.com/combo?3.1.1/build/widget/assets/skins/sam/widget.css&3.1.1/build/console/assets/skins/sam/console.css&http://dancewithnet.com/min/b=yui&f=3.1.1/tabview/assets/skins/sam/tabview.css&
这两种都可以使用,虽然在早,且影响某些特定情况下的缓存,但当使用修改后的YUI时,合并的URL变成类似/min/b=yui&f=3.1.1/tabview/assets/skins/sam/tabview.css,的样子,就会出现bug了。对于YUI的Combo Handler来说这是一个小bug,所以。但当我们改造YUI3来更好的支持Minify时,还要解决这个问题,具体方案请看示例在。
3)在CDN上使用Minify
CDN的全称是Content Delivery Network,即内容分发网络。其最常应用就是通过位于不同地理位置的服务器把静态资源部署到用户最近的边缘,这样能有效解决Web服务中大量静态资源的速度和性能问题。由于实施成本比较高,所以在实际的应用中,大型公司一般会组建自己的CDN,而小型公司只能租借第三方的CDN,但不管怎样这两种方式都不会影响在服务端实施合并和压缩程序。一般情况下,静态资源也并不是直接上传到CDN,而是先传到一台后台服务器,然后各地CDN的前端Cache服务器按需索取。YUI CDN的Combo Handler就是部署在其后台服务器上的,Minify也应如此。简单图示如下:
当一个资源请求到CDN时,CDN会先检查本地是否存在这个资源,如果有则会直接返回该资源,如果没有则会请求其后台服务器,后台服务器会依据资源URL的信息进行相应的处理,然后返回给CDN,CDN就会存储这个资源,再次出现这个资源请求时就无需请求后台服务器了。所以,虽然合并特别是压缩JavaScript和CSS文件是消耗时间的,但是由于只需要第一次,并且第一次基本上由我们自己访问掉(我们可以创建程序自动进行一次访问来保证,实际上图片优化也可以采用这种方式),所以基本上很安全。
[1]rewrite
&IfModule mod_rewrite.c&RewriteEngine on# You may need RewriteBase on some servers#RewriteBase /min# rewrite URLs like &/min/f=...& to &/min/?f=...&RewriteRule ^([bfg]=.*) index.php?$1 [L,NE]&/IfModule&
$min_enableBuilder =//本地使用时可以通过http://dwn/min/builder/来进行配置,外部使用时请设置为false//$min_cachePath = 'c://WINDOWS//Temp';//$min_cachePath = '/tmp';//$min_cachePath = preg_replace('/^//d+;/', '', session_save_path());//选择其一,去掉注释设置临时缓存目录,这样可以减少程序运算提高性能$min_serveOptions['maxAge'] = 1800;//设置浏览器缓存的时间,为了提升性能建议这个时间设置尽可能的长,比如//如果需要在不改变URL的情况下更新静态文件,可以采用类似时间戳的方式,//如http://localhost/min/f=example/example.css&.css//建议静态文件采用版本号管理,每次修改都需要升级版本号,这样就无需时间戳了,//如http://localhost/min/f=example/example_1_0_1.css$min_serveOptions['minApp']['maxFiles'] = 10;//参数f获取参数的个数,即合并的文件个数,这个数量完全可以增大,比如50,//当然可能会遇到URL最大值问题,后会有解释
$min_serveOptions['minifiers']['application/x-javascript'] = '';$min_serveOptions['minifiers']['text/css'] = '';如需转载,请注明文章出处和来源网址:我要分享到:上一篇: 下一篇: 必备CSS教程 Essential CSS Tutorials• • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • ()• • ()• ()• • • • • • • • • • • • • • • • 必备HTML基础教程 Essential HTML Tutorials •
• () • () • () •
• () •
• () •
• 如对文章有任何疑问请提交到,或有任何网页制作CSS问题立即到发贴求解 或 直接DIVCSS5网页顶部搜索遇到DIVCSS疑问。文章修订日期: 12:08
原创:本文www.divcss5.com DIVCSS5版权所有。最新文章NEWS• • • • • • • • • • CSS EFFECTS相关文章RELATED• • • • • • • • • • 热点文章HOT DIVCSS5.com 学习与资源分享平台探讨一下想使用cdn又不想浪费钱的方案? - V2EX
V2EX = way to explore
V2EX 是一个关于分享和探索的地方
已注册用户请 &
如果你希望学习 CDN 相关知识,那么建议你可以遍历以下软件的说明文档。
探讨一下想使用cdn又不想浪费钱的方案?
00:54:50 +08:00 · 6714 次点击
是这样的, 我最近打算给冷笑话网站写一个cdn的程序, 冷笑话在推广的时候会在一两个小时内有大量的pv, 然后我们的带宽就不够用了, 所有我们买了upyun的服务。但是upyun并不是真正的cdn, 他不能根据图片地址自动来我们网站抓取文件, 而必须要我用api去上传到他们的服务器。然后我们毕竟是有60M的独享带宽的, 如果平时也开启cdn的话那这个带宽费就白交了, 因此我希望能够根据网卡最近5秒的带宽流量来自动开启和关闭cdn, 一来可以保证访问速度, 二来充分利用现有带宽。我是打算通过修改文件的访问host来开启或关闭使用cdn, 比如 /img/**
是不适用cdn的情况, 而 http:// img.lengxiaohua.com/*** 是使用cdn的情况。然后问题来了, 起初我是想直接修改nginx配置, 使用跳转到upyun的办法, 那么存在下面三个问题:1 nginx转发次数太多, 我们高峰时10分钟就有1w多个pv,每个pv又会有几十个文件请求,而我们的服务器仅是42区的一个8G内存的VPS。 因此这种跳转的量应该还是比较大的吧?2 我不知道怎么在nginx中判断最近5秒钟的网卡流量, 算能够自动开启cdn, 那么还需要做一个缓存的处理。 对nginx编程不熟悉, 所以感觉这个方案比较困难。3 我之前提到,upyun需要先上传后访问, 而nginx在判断是否开启cdn时并不知道文件是否已经上传到upyun。因此我觉得只能在python程序中来判断是否开启cdn, 若开启, 就把对应的js css img文件地址改为upyun的host。 然后又有以下一些问题需要解决:1 需要先判断文件是否已经上传到upyun, 如果成功上传则修改host, 否则先上传文件, 这一步倒是好说。2 各种文件太多, 有固定存在的js css img, 也有用户上传的img。 有html内嵌的文件, 也有js css中动态调用的文件。 要分别针对不同的文件修改host。(使用正则)3 cdn开启时, 也要修改api中的文件host,因为api返回的结果不是html的, 可能是json的, 也可能是纯文本的, 工作量增大。4 为了达到能够让用户快速打开页面, 要针对静态文件(写程序时加到代码库里面的,比如css,logo等)和 动态文件(用户上传的)分别有不同的管理策略, 比如可能需要一直开启静态文件的cdn, 而动态文件根据浏览判断是否使用cdn。可能是我没有想到更好的办法, 因此在这两种方案中想来想去也不知道怎么做更好, 前者理解起来比较简单, 但是问题2 3不知怎么解决。 后者虽然基本能解决需求, 但是解决方案过于复杂。然后, 我还在想,upyun这个是不是可以自动调换成免费的新浪图床? 优先使用新浪图床且可以一键切换到upyun?各位有经验的朋友是怎么解决这类问题的?
请给点思路, 谢了顺便打个广告,我们是sparker5互联网圈内外包团队,
是我们接的一个活, 经过不断的优化得到一个经验,只要有一个42区2G内存的vps, 像冷兔这种网站日100w pv的压力不成问题, 关键是带宽。。。
各位同学买vps还是朝着便宜的考虑吧。。。附带42区vps广告连接 :)对了, 有想买upyun的朋友注意了, upyun不能自动抓取文件, 必须你自己上传, 因此他不算是cdn吧, 之前买的时候我没考虑到这点, 不过upyun比较便宜。
35 回复 &| &直到
08:00:00 +08:00
& & 01:40:37 +08:00
我觉得你是被自己的60M带宽给困住了。
你是想流量超过你们瓶颈的时候,才切换使用CDN的流量。
CDN并不仅仅是分担流量,还有一个就近分发的作用。
建议
1、不要纠结你那60M,虽然花了很多钱,启用CDN,用户能有一个更低的延迟。
2、至于upyun不能自动抓的问题,那你就主动push呗,写个监控脚本主动push到upyun的FTP上不是什么难事
& & 03:04:45 +08:00
根据5秒钟网卡流量修改nginx配置?
就是说流量高的时候每5秒nginx reload 一次配置文件?
有冇搞错?
& & 03:15:20 +08:00
你都说了 upyun不是cdn
怎么还cdn cdn的啊 看的头疼
用python修改url就行了呗
每5秒钟检测网卡流量
超标则 域名变量改为upyun
否则用本机
& & 04:15:39 +08:00
1 10分钟1w pv不算啥,甭怕。当然,我这随口一说,没考虑动态处理部分。只说nginx。
2 nginx干不了检测网卡流量的事,用一个shell脚本cron几秒钟跑一次就可以了。
但是,这不是蛋疼么。。。。
楼主现在的问题不就是怕浪费了那带宽么。要不然你这样,利用dns把图片流量切分开来,一部分直接走upyun,一部分走你本机,反代到upyun出来的地址,也可以利用dns做到大致上控制流量比例,让你这个60M带宽不浪费。
这样也蛋疼,但没那个测网卡流量做切换疼的厉害。。。
楼主现在的问题,其实是一个典型的架构选型的时候考虑不周全的问题,现在在为这个考虑不周全买单了,如果你当时入手一个CDN,哪怕只是短时间过渡,也可以根据具体带宽占用情况,收集数据,最后决定怎么做。。。比现在这样好。
当然,不是吐槽楼主,60M带宽也不便宜,对小网站来说也很辛苦,一分钱也是钱啊。上面我那个反代又拍云的方法并不是玩笑,你可以认真的考虑下。在实际环境中,我就曾经帮人做过这样的事,有一定的效果的。当然如果并没有资金紧张到这种程度,那么还是直接使用又拍云吧。你多出来的带宽不用急,安心考虑更应该考虑的问题,很快业务会能够跑到用上这60M的。有点信心嘛。
我最近也有一个比较大的网站,在阿里云有50M左右带宽使用,价格太贵,也很快会转到又拍云去了。
还有,就算刷网卡流量改配置,也别上python,这时候就该shell这种大杀器上马。
同时赶着楼主的帖子也发个广告。
& & 09:48:19 +08:00
为了60M带宽去写一套系统,佩服佩服
& & 09:55:02 +08:00
CDN = Content Distribute Network,主动上传然后给你调用怎么就不算CDN了。
主流CDN基本都分主动推送与被动抓取,前者适合更大规模的流量分发,被动抓取的依然会给源站带来压力。
& & 10:05:29 +08:00
带宽难道是年付的??可以减下来嘛 就像上面说的CDN不仅仅是带宽分流 还有个就近分发
42区的VPS应该是双线吧 双线的带宽是比CDN贵的
& & 10:17:49 +08:00
目前又拍云的静态CDN正在最后的测试中,预计将会于国庆之后正式上线,到时候应该可以满足您的CDN的需求。欢迎到时候来测试使用~
& & & 11:42:59 +08:00
你需要的是一个能够按照流量计费的面向小网站的 CDN,在美国有很多选择,及 Amazon 的 CloudFront,而目前国内确实还没有这样的产品。
& & 13:22:16 +08:00
是的, 如果一直用cdn的话速度确实是比较快的, 所以我想把静态文件一直开启。 你说的不要纠结现有带宽这个说法不太赞同, 我初步算了一笔账, 如果按照现在的流量来算, 如果全部文件常开upyun, 那么一年的upyun费用在2w以上, 如果以后流量增加的话就更贵了。
@ 是对nginx编程, 不是reload
@ 写这个程序估计一周, 第一年可以节约2w块以上, 我觉得有必要写~~~
@ 年付,7线,机房60M是一年9w, 是比upyun贵
@ 好的, 关注
& & 13:24:14 +08:00
@ 关键在于这60M已经买下来了~~~
明年的方案可以明年再考虑
& & 13:30:38 +08:00
补充一下,打开网站的速度主要是静态js css img图片决定的, 而这个网站打开后90%的流量都是后期load图片时产生的, 而图片会在页面load完成后提前加载, 因此只要能做好静态文件的cdn, 就能提高页面的加载速度, 后面的图片流量走我们的服务器应该不会造成体验上的延迟。
& & 15:07:24 +08:00
网站速度是由http请求页面而决定的,http请求又是有多种因素影响,如css js html image 等。
cdn主要加速静态页面。比如css js image。注意:cdn最好不要直接对主站加速。这样以免影响搜索爬虫对网站的抓取,类似你的站90%流量都被image拿走,那太不值得了。CDN免费基本上都是限量的。又不花钱的我倒没找到没发现~~你可以尝试一下这样,如果流量大的话,静态页面用一个台服务器。image可以用多台服务器进行加速。
& & 12:11:01 +08:00
去二线城市,例如湖南那些,1年100M独享才2W带宽费~~我用了一年,稳定性还是不错~~只是一些分享解析之类的就别寄望那些廉价机房来做了,很坑爹。。。
& & 13:54:41 +08:00
@ 百兆独享一年2w,
有这么便宜?
& & 16:20:51 +08:00
lz的问题很蛋疼
正统思路是varnish(缓存+判断后端)+Haproxy(反向代理+宕机检测)
什么检测带宽后决定是否启用cdn?一般做法是用宕机检测,一台不行就备用一台
对于瞬间爆发流量,varnish是最佳选择,原因如下:
1 第一次访问过后的短时间请求全部通过varnish缓存响应,不对后端产生压力
2 支持saint mode,可以检测后端返回502时,在多少时间内不访问后端,而让varnish直接返回过期缓存,这个比你检测带宽什么的可靠多了
3 支持针对http host/url 自定义多个后端
4 修改hosts这种方式定义后端,不如varnish+haproxy简洁利落
不打广告。
& & 17:08:43 +08:00
建议楼主考虑阿里云oss.
& & 17:40:03 +08:00
我在思考学校200M带宽 252核心512G内存的服务器组放一个校园网站有多浪费
& & 19:48:27 +08:00
楼主我们可以提供 ChinaCache 的 CDN,联系我购买有优惠哦 按带宽算的= =
& & 19:50:02 +08:00
萝卜网的解决方案是使用一台国外的100TB流量的服务器(差不多平均300多M带宽的样子),装上TCP加速优化软件,然后使用 ChinaCache 的 CDN,按照带宽来买,就比较划算了。
如果不用上 CDN 也足够支撑大的访问量,大家可以测试一下我们加速过的国外服务器的下载速度:
& & 20:42:27 +08:00
CDN 可以试试
按流量收费。
然后配合 dnspod 的 api 使用,这样的搭配方案不用更改文件的url。
& & 23:19:29 +08:00
@ 拭目以待啊
& & 23:34:28 +08:00
又拍云的CDN空间已经在内部测试了,预计国庆后上线
& & 11:31:25 +08:00
@ 这个比upyun贵多了, 我们当时买的是G,
这个估计11000G要1w块了
@ 你们早点上线我就不用这么纠结了~~~
上线之后是不是可以自动抓取我的文件? 不需要我主动上传?
& & 11:35:19 +08:00
@ 哈哈,当时还在开发过程嘛~上线之后,如果选择使用静态CDN功能,会自动抓取你的文件,不需要上传啦~
& & 14:58:40 +08:00
@ 收费是一样的吗?
& & 17:08:38 +08:00
@ 收费模式还是按照实际使用的流量收费的~
& & 05:38:46 +08:00
告诉楼主一个比较蛋疼的办法,自己在电脑旁边看,看流量差不多了,手动切换到又拍云.
& & 09:16:37 +08:00
不是有cloudflare么。根据朋友那个5万PV的网站的小站的反响,它的免费服务就已经不错了。
& & 11:49:54 +08:00
话说.....找个按流量算的CDN不就ok了。
或者干脆不想花钱的话,可以试试我这个小玩意儿
& & 19:59:26 +08:00
1.先要搞清楚你网站流量是被谁占用了,你的网站大致可以分为三部分,网页/静态文件/UGC。
2.通常来说,80%的流量是被20%的内容耗费的。
我觉得还是重点来处理静态文件吧,因为静态文件一般改动不大,所占流量也比较多,资源类网站除外。
1.将静态文件分发到云上,当然有不花钱的方案是分发到各免费云上,反正不花钱,申请多几个。
2.网页生成静态页面,一般来说,高峰是可以预期的。如果不可以预期,可以用程序检测。当发生高访问量的时候,修改js和css的指向
3.如果访问量比较大,可以根据不同的ip段或者时间分发不同的静态文件,也可以由客户端JS自动选择。例如:你有10个静态服务器,你就把重点网页生成10份html,然后读取到内存,根据不同条件分发不同的html
4.对于UGC,可以把访问量高的也做到静态服务器。
最后,你还也借助DNSPod的API,将不同地区的请求解析到不同的服务器。我的原则,是花最少钱办最多事,不花钱最好,当然,这会麻烦一些。
优点:你可以控制什么时候用静态服务器,当访问量下去后,重新生成静态页。比如说你用到阿里云,按需付费,这样节省成本。如果你不是特别在意速度的话,完全可以用免费云,这样可以节省很多成本。
缺点:技术有一定要求,如果你静态文件特别多的话,重新生成会占一定资源,但我觉得常访问的内容没这么多吧。
& & 20:05:31 +08:00
唉,看了一下楼主提供的网站,你这个网站优化还真不行啊,先把优化做好,再来说什么CDN吧。提你几个建议:
1.JS和CSS没有去注释和压缩
2.JS太多,完全不合理,至不超过4个,CSS合并到1个
3.图片我没太看,也应该有合并的空间
先把这几个做了,你的带宽占用和速度都会有改善
& & 20:47:10 +08:00
我咋觉着图床带宽的钱可以省出来的,有免费的可外链的超大流量图床的阿
& & 22:18:38 +08:00
这几天这在处理,
因为事情太多忙不过来。。。
& & 00:58:10 +08:00
网站设计的时候定义几个域名变量,比如UGC_M_SERVER, IMG_SERVER, JS_SERVER, CSS_SERVER... 分别对应不同的资源类型
域名设置里面比如S1.abc.com,
S1可能是CDN,S2则是你自己的机器。
可以根据来访IP,来动态映射域名变量到S1或S2
& · & 800 人在线 & 最高记录 3541 & · &
创意工作者们的社区
World is powered by solitude
VERSION: 3.9.8.1 · 20ms · UTC 19:10 · PVG 03:10 · LAX 12:10 · JFK 15:10? Do have faith in what you're doing.知足常乐勤为本,忍耐谦和心自宽。
除此之外还可以不同的网站公用已缓存的js,节省服务器流量。
Google CDN布点多、速度快,但是由于某些原因比较不稳定。面向国内用户的网站慎用
SinaAppEngine (新浪),感觉好像不是非常稳定
百度开发者中心
刚上不久。
5、Cloudflare.com
支持http/https/spdy协议,还有swf、图片。
6、Microsoft Ajax Content Delivery Network
如何调用资源我们要使用那资源,就如何我们直接使用本地网站的资源一样,只是把路径缓存了cdn资源的地址,。如调用百度的jquery 1.9.0。js放的位置由你定拉,雅虎的建议是放在紧靠&/body&前面的,如:
未压缩:&script src=”http://libs.baidu.com/jquery/1.9.0/jquery.js”&&/script&压缩:&script src=”http://libs.baidu.com/jquery/1.9.0/jquery.min.js”&&/script&
jQuery源分享
谷歌:http://ajax.googleapis.com/ajax/libs/jquery/1.8.2/jquery.min.js
1.8.2迅雷:http://vod.xunlei.com/library/jquery-1.7.2.min.js
1.7.2http://act.vip.xunlei.com/js/jq/jquery-1.4.2.min.js
1.4.2http://vip.xunlei.com/js/jquery-1.4.2.min.js
淘宝:http://a.tbcdn.cn/apps/dts/th3/js/jquery.js
1.6.2http://a.tbcdn.cn/apps/tao123/jq/jquery-1.4.4.min.js
1.4.4http://a.tbcdn.cn/libs/jquery/1.7.1/jquery.js
1.7.1微软:http://ajax.microsoft.com/ajax/jQuery/jquery-1.8.2.min.js
1.8.2新浪云:http://lib.sinaapp.com/js/jquery/1.6.2/jquery.min.js
1.6.2阿里云:http://static.aliyun.com/specials/game/js/require-jquery.jshttp://render.aliyun.com/bundles/aliyundiku/js/jquery-1.6.1.min.jshttp://static.www.net.cn/js/jquery-1.7.1.min.jshttp://zixun.www.net.cn/js/jquery-min.js http://m.alicdn.com/product/os/js/require-jquery.js http://m.alicdn.com/y/js/require-jquery.js http://appdev.aliyun.com/js/jquery-1.6.2.min.js http://apps.aliyun.com/js/jquery-1.6.2.min.js 百度:http://mu6.bdstatic.com/static/fm/lib/jquery-1.8.1.js百度云计算:http://fe.bdimg.com/jq/jquery-1.7.1.min.js
1.7.1雅虎中国:http://cn.yimg.com/js/jquery/jquery-1.6.4.min.js
1.6.4腾讯:(CDN外包网宿)http://meigui.qq.com/js/jquery.jshttp://static.114.qq.com/space/js/jquery-1.4.4.min.jshttp://qqgameplatcdn.qq.com/social_hall/js/jquery.jshttp://ossweb-img.qq.com/images/js/jquery/jquery-1.7.1.min.js
http://xxz.qq.com/act/anc/js/jquery.js
http://gamebbs.qq.com/gamebbs2.0/scripts/jquery.min.js
http://b.qq.com/static/js/jquery-1.4.4.min.js
http://cdn.b.qq.com/common/js/jquery-1.7.1.min.js http://cache.soso.com/wenwen/js/jquery-1.6.2.min.js
奇虎:http://w.qhimg.com/images/v2/360se/2012/mse/jquery-1.6.1.min.js http://p0.qhimg.com/s/t01da79/_75team/qyb/syy/jquery-1.7.2.min.js http://grab.woxihuan.com/resource/js/jquery-combo-min.jshttp://webscan.360.cn/js/jquery.min.js http://s0.qhimg.com/lib/jquery/172.js盛大:http://res.static.sdo.com/jQuery/jquery-1.6.1.min.js http://tingting.sdo.com/jquery.js http://static.grandcloud.cn/www/media/js/jquery.js 搜狐:http://js.sohu.com/library/jquery-1.7.1.min.js 蓝汛:http://chinacache.com/js/jquery-1.2.3.min.js http://www.chinacache.com/js/jquery.js快网:http://www.fastweb.com.cn/public/js/jquery.js
1.4.2中国电信:(CDN外包网宿)http://static.118114.cn/js/jquery-1.4.2.min.js
1.4.2http://cloud.189.cn/js/lib/jquery/jquery-1.7.1.min.js
1.7.1中国联通:http://res.mall.10010.com/mall/common/js/esf/jquery-1.4.3.min.js
1.4.3中国移动:http://www.cq.10086.cn/nweb/js/jquery.min.js
1.8.0华为:http://st1.dbank.com/netdisk/js/jquery-1.6.2.min.js点点轻博客(创新工厂投资):http://t.libdd.com/js/libs/jquery/jquery-latest.js
更新源豆瓣:http://img3.douban.com/js/packed_jquery.min.js
1.4.4CloudFlare:http://cdnjs.cloudflare.com/ajax/libs/jquery/1.8.2/jquery.min.js
1.8.2 (推荐国外网站调用)政府源:http://www.qzgtj.gov.cn/sitefiles/bairong/Scripts/JQuery/jquery-1.4.3.min.jshttp://xnjc.weifang.gov.cn:81/resource/js/jquery/jquery.js http://www.yangzhou.gov.cn/xhtml/js/jquery-1.4.2.min.js http://www.cqer.gov.cn/js/jquery-1.2.6.js https下的:谷歌:https://ajax.googleapis.com/ajax/libs/jquery/1.6.2/jquery.min.js淘宝:https://s.tbcdn.cn/apps/dts/th3/js/jquery.jshttps://s.tbcdn.cn/apps/tao123/jq/jquery-1.4.4.min.js微软:https://ajax.microsoft.com/ajax/jQuery/jquery-1.6.2.min.js阿里云:https://account.aliyun.com/scripts/jquery-1.5.2.min.jshttps://static.aliyun.com/specials/game/js/require-jquery.js腾讯:(CDN外包网宿)https://id.b.qq.com/static/common/js/jquery-1.4.4.min..js 盛大:https://static.grandcloud.cn/www/media/js/jquery.js蓝汛:https://portal.chinacache.com/js/jquery-1.4.2.min.js CloudFlare:https://cdnjs.cloudflare.com/ajax/libs/jquery/1.8.2/jquery.min.js
Powered By:

我要回帖

更多关于 解决台湾问题实现祖国 的文章

 

随机推荐