BlogJava-emu in blogjava-随笔分类-web优化

学习了一下条件注释

emu — Wed, 11 Jan 2012 11:51:00 GMT

以前只知道怎么让一段代码“仅对IE有效”，一直没研究过怎么“仅对IE无效”或者说“仅对非IE有效”，今天算搞懂了：

IE看不到，非IE才看得到

emu 2012-01-11 19:51 发表评论

IE这个bug真是弱爆了

emu — Mon, 08 Aug 2011 01:54:00 GMT

这样一段代码在IE下面居然语法解析错误！实在是弱到不知道怎么说好了。
当然，下面这一段代码，也不出意外的在IE下挂掉了

<HTML>
<BODY>
<SCRIPT LANGUAGE="JavaScript">
var a="";
alert(a);
SCRIPT>
BODY>
HTML>

终于明白为啥Editplus里面插入script标记的时候总是帮我加上了，这俩货还真不能随便去掉。

<HTML>
<BODY>
<SCRIPT LANGUAGE="JavaScript">

SCRIPT>

BODY>
HTML>

这个就没事。

emu 2011-08-08 09:54 发表评论

脚本绑定回调增强版：备用url可以失败重试

emu — Tue, 19 Jul 2011 12:50:00 GMT

4年前写过一篇《脚本绑定回调》进行了一些有趣的尝试，这些尝试现在在一些web产品中已经应用了好几年了。这两年随着海外用户的增多，用户情况的复杂化，我们的服务部署也开始复杂化了，有一些用户访问A域名失败，访问B域名就可能很畅顺，另一些用户则相反。而且很多时候这并不是gslb这样的调度可以及时检测到和快速调整的，不由得想想，能不能进行失败重试呢？其实也很简单把4年前的代码改了一改，做了一个原理性的实验：

<HTML>
<HEAD>
<SCRIPT LANGUAGE="JavaScript">
var isIE = !!window.ActiveXObject;
var useFragment=false;
function loadjs(url,callback,errcallback,url2,url3){
    if(isIE){
        if(useFragment){
           var df = document.createDocumentFragment();
            df.visitCountCallBack = function(data){
                s.onreadystatechange=null;
                df=null;
                callback(data);
            }
            var s = df.createElement("SCRIPT");
            df.appendChild(s);
            s.onreadystatechange=function (ec,cb,u2,u3){
                return function(){
                    if(s.readyState=="loaded") {
                        s.onreadystatechange=null;
                        df=null;
                        if(!u2){
                            ec();
                        }else{
                            loadjs(u2,cb,ec,u3)
                        }
                    }
                }
            }(errcallback,callback,url2,url3)
            s.src = url;
        }else{
            var i=new ActiveXObject("htmlfile");
            i.open();
            i.parentWindow.visitCountCallBack=function(i){
                return function(d){
                    i.parentWindow.errcallback=null;
                    i=null;
                    callback(d);
                }
            }(i);
            i.parentWindow.errcallback=function(ec,cb,u2,u3){
                return function(){
                    i.parentWindow.errcallback=null;
                    i=null;
                    if(!u2){
                        ec();
                    }else{
                        loadjs(u2,cb,ec,u3)
                    }
                }
            }(errcallback,callback,url2,url3)
            i.write("""+url+"\"><\/script>setTimeout(\"errcallback()\",0)<\/script>")
            if(i)i.close();//如果数据被cache，运行到这一行的时候有可能回调已经完成,窗口已经关闭。
        }
    }else{
        var i = document.createElement("IFRAME");
        i.style.display="none";
        i.callback=function(o){
            callback(o);
            i.contentWindow.callback=null;
            i.src="about:blank"
            i.parentNode.removeChild(i);
            i = null;
        };
        i.errcallback = function(ec,cb,u2,u3){
            return function(){
                    if(!u2){
                        ec();
                    }else{
                        loadjs(u2,cb,ec,u3)
                    }
            }
        }(errcallback,callback,url2,url3);
        i.src="javascript:\"<script>function visitCountCallBack(data){frameElement.callback(data)};<\/script><script src='"+url+"'><\/script><script>setTimeout('frameElement.errcallback()',0)<\/script>\"";
        document.body.appendChild(i);
    }
}

function init(){
    var spans = document.getElementsByTagName("span");
    for(var i=0;i<spans.length;i++){
        var id = spans[i].id;
        var url = "http://g.qzone.qq.com/fcg-bin/cgi_emotion_list.fcg?uin=a"+id;//故意制造错误引发重试
        var url2 = "http://g.qzone.qq.com/fcg-bin/cgi_emotion_list.fcg?uin=b"+id;//故意再次制造错误引发重试
        var url3 = "http://g.qzone.qq.com/fcg-bin/cgi_emotion_list.fcg?uin="+id;
        var callback = function(id){ return function(data){
            document.getElementById(id).innerHTML = data.visitcount;
            }
        }(id);
        var errcallback = function(id){ return function(){
            document.getElementById(id).innerHTML = "无法连接到服务器";
            }
        }(id);
        loadjs(url,callback,errcallback,url2,url3);
    }
}
SCRIPT>
HEAD>
<BODY onload="init()">
12345(非法帐号)的访问量：<span id="12345">span><BR>
123456 的访问量：<span id="123456">span><BR>
20050606 的访问量：<span id="20050606">span><BR>
BODY>
HTML>

故意在前两次请求中制造了错误，尝试到第三个url的时候才成功。

emu 2011-07-19 20:50 发表评论

把css和js写到一个文件里面的增强版

emu — Tue, 19 Jul 2011 08:12:00 GMT

原文链接

最早的方法发表在msdn上：
http://blogs.msdn.com/b/shivap/archive/2007/05/01/combine-css-with-js-and-make-it-into-a-single-download.aspx

代码是像这样子的：

DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML>
<BODY>
<div id="output">div>
<SCRIPT LANGUAGE="JavaScript">

SCRIPT>
BODY>
HTML>

emu 2011-06-23 19:20 发表评论

如何分析js代码的运行路径？

emu — Thu, 16 Jun 2011 09:38:00 GMT

只是个最基础的想法了。具体的实践稍微复杂一些：
1 如果script是用src引入的，还要用xhr或者json方式来获得text，可能还需要搭个后台代理。
2 如果function是在命名空间的，可以直接递归for in命名空间去挖里面的public函数出来。
3 private的函数我看就算了，私有函数应该对自己负责，我们没有必要非去整人家的私货。

<HTML>
<BODY>
<SCRIPT LANGUAGE="JavaScript">

SCRIPT>
<SCRIPT LANGUAGE="JavaScript">

emu 2011-06-16 17:38 发表评论

弱视用户看到我们的页面是像这样的

emu — Tue, 22 Jun 2010 03:33:00 GMT

看了苹果WWDC的无障碍设计部分，他们的开发人员就是这样来体验弱视用户的产品体验的，我们也来体验一下别人的痛苦吧。我们的页面有办法设计得让这群人也感受好一点吗，就像苹果正在做的

emu 2010-06-22 11:33 发表评论

不可忽略的 cache-read time(缓存读取延迟时间) 瓶颈

emu — Fri, 09 Apr 2010 14:58:00 GMT

小小和rizen尝试过定位一个cache-read耗费时间随机的变得很长的诡异问题，排除过了文件内容、文件类型、文件头等各种影响，但是很遗憾没有最终结论。emu那天看知道这个事情后猜测，会不会就是很简单的多个cache-read操作相互竞争堵塞导致的呢？这个其实很容易验证了。写了一个简单的小页面应用了一组图片，然后抓包重新打开页面，就看到下面这个图了：

第一个cache-read耗时0.2秒多，第二个（并行发起）0.3秒多，第三个0.4秒多，接下去每个图片的耗时差不多都比上一个慢0.1秒以上。结论很明显了，并发的cache-read会相互堵塞，非常严重的相互堵塞。
以上抓包是在IE6下完成的。在IE7和IE8下面情况要好一些，但是问题性质是相同的。
很多我们曾经以为cache的非常好速度应该非常快的web应用，也许其实存在着严重的cache-read速度瓶颈而不为我们所知。
网上没有搜到太多关于cache-read时间的文章，看来真是个盲点。

解决方案和网络延迟是类似的，减少cache-read请求，把多个小文件和小图片合并成大文件和大图片（而不要一厢情愿的以为小文件被浏览器缓存后会有很好的速度表现），区分优先级引用资源。还有一个可能有用的：交错的发起不可避免的异步动态网络请求和cache-read请求，让网络延迟和cache-read延迟时间叠加在一起，来节省用户实际要等待的时间。

emu 2010-04-09 22:58 发表评论

IE6不能用gzip压缩脚本，一个流毒甚广的谣言

emu — Wed, 31 Mar 2010 03:37:00 GMT

很多人遇到IE6下面脚本不运行的问题，在网上搜索一番后，都会遭遇到这篇流毒甚广的文章

文章作者说“跑到微软那一查,给的答复让我吐血:Do not enable HTTP compression for the script files 请不要对脚本文件开启http压缩 只好在服务器端增加对浏览器的识别代码,如果是ie6,就不压缩脚本文件了虽然脚本能运行了,可是用户体验就... 哎,我恨ie 6”

唉，说啥好呢？

真相是，微软的答复(http://support.microsoft.com/kb/327286/en-us?sid=64&spid=2073) 里面提供了两个解决方案，其中第一个描述的稍微啰嗦了一点，被这个作者直接忽略掉了。第二个解决方案只有一句话，显然更容易被读懂：

To work around this problem, you can do either of the following:

If you use a Cache-Control: no-cache HTTP header to prevent the files from caching, remove that header. In some situations, if you substitute an Expires HTTP header, you do not trigger the problem.

-or-

Do not enable HTTP compression for the script files.

Emu虽然英文比较烂，四级老考不过，为了方便大家还是翻译一下吧，不然又该有人读不下去了。

要规避此问题，你可以在下面两个方案中选一种：

1.如果你使用了Cache-Control: no-cache 这个 HTTP 头来防止文件被缓存，移除这个头就好了。有些情况下，如果你用一个Expires头来代替（前面这个出问题的http头），（也可以起到相同作用而）不会触发这个问题。

或者

2.不要压缩脚本文件。

个人建议还是考虑第一方案。

本文作为前面一篇翻译文章《压缩，让网络更快》的补充。

emu 2010-03-31 11:37 发表评论

[翻译]加速Javascript：DOM操作优化

emu — Mon, 01 Mar 2010 09:20:00 GMT

原文：《Speeding up JavaScript: Working with the DOM》

作者： KeeKim Heng, Google Web Developer

在我们开发互联网富应用（RIA）时，我们经常写一些javascript脚本来修改或者增加页面元素，这些工作最终是DOM——或者说文档对象模型——来完成的，而我们的实现方式会影响到应用的响应速度。

DOM操作会导致浏览器重解析(reflow)，这是浏览器的一个决定页面元素如何展现的计算过程。直接修改DOM，修改元素的CSS样式，修改浏览器的窗口大小，都会触发重解析。读取元素的布局属性比如offsetHeithe或者offsetWidth也会触发重解析。重解析需要花费计算时间，因此重解析触发的越少，应用就会越快。

DOM操作通常要不就是修改已经存在的页面上的元素，要不就是创建新的页面元素。下面的4种优化方案覆盖了修改和创建DOM节点两种方式，帮助你减少触发浏览器重解析的次数。

方案一：通过CSS类名切换来修改DOM

这个方案让我们可以一次性修改一个元素和它的子元素的多个样式属性而只触发一次重解析。

需求：

（emu注：原文作者写到这里的时候脑子显然短路了一下，把后面的Out-of-the-flow DOM Manipulation模式要解决的问题给摆到这里来了，不过从示范代码中很容易明白作者真正想描述的问题，因此emu就不照翻原文了）

我们现在需要写一个函数来修改一个超链接的几个样式规则。要实现很简单，把这几个规则对应的属性逐一改了就好了。但是带来的问题是，每修改一个样式属性，都会导致一次页面的重解析。

function selectAnchor(element) {
  element.style.fontWeight = 'bold';
  element.style.textDecoration = 'none';
  element.style.color = '#000';
}

解决方案

要解决这个问题，我们可以先创建一个样式名，并且把要修改的样式规则都放到这个类名上，然后我们给超链接添加上这个新类名，就可以实现添加几个样式规则而只触发一次重解析了。这个模式还有个好处是也实现了表现和逻辑相分离。

.selectedAnchor {
  font-weight: bold;
  text-decoration: none;
  color: #000;
}

function selectAnchor(element) {
  element.className = 'selectedAnchor';
}

方案二：在非渲染区修改DOM

（emu注：作者在这里再次脑子短路，把DocumentFragment DOM Generation模式的介绍提前到这里来了，emu只好再次发挥一下）
上一个方案解决的是修改一个超链接的问题，当一次需要对很多个超链接进行相同修改的时候，这个方案就可以大显身手了。

需求

需求是这样的，我们要写一个函数来修改一个指定元素的子元素中所有的超链接的样式名（className）属性。要实现很简单，我们可以通过遍历每个超链接并且修改它们的样式名来完成任务。但是带来的问题就是，每修改一个超链接都会导致一次重解析。

function updateAllAnchors(element, anchorClass) {
  var anchors = element.getElementsByTagName('a');
  for (var i = 0, length = anchors.length; i < length; i ++) {
    anchors[i].className = anchorClass;
  }
}

解决方案

要解决这个问题，我们可以把被修改的指定元素从DOM里面移除，再修改所有的超链接，然后在把这个元素插入回到它原来的位置上。为了完成这个复杂的操作，我们可以先写一个可重用的函数，它不但移除了这个DOM节点，还返回了一个把元素插回到原来的位置的函数。

/**
* Remove an element and provide a function that inserts it into its original position
* @param element {Element} The element to be temporarily removed
* @return {Function} A function that inserts the element into its original position
**/
function removeToInsertLater(element) {
  var parentNode = element.parentNode;
  var nextSibling = element.nextSibling;
  parentNode.removeChild(element);
  return function() {
    if (nextSibling) {
      parentNode.insertBefore(element, nextSibling);
    } else {
      parentNode.appendChild(element);
    }
  };
}

有了上面这个函数，现在我们就可以在一个不需要解析渲染的元素上面修改那些超链接了。这样只在移除和插入元素的时候各触发一次重解析。

function updateAllAnchors(element, anchorClass) {
  var insertFunction = removeToInsertLater(element);
  var anchors = element.getElementsByTagName('a');
  for (var i = 0, length = anchors.length; i < length; i ++) {
    anchors[i].className = anchorClass;
  }
  insertFunction();
}

方案三：一次性的DOM元素生成

这个方案让我们创建一个元素的过程只触发一次重解析。在创建完元素以后，先进行所有需要的修改，最后才把它插入到DOM里面去就可以了

需求

需求是这样的，实现一个函数，往一个指定的父元素上插入一个超链接元素。这个函数要同时可以设置这个超链接的显示文字和样式类。我们可以这样做：创建元素，插入到DOM里面，然后设置相应的属性。这就要触发3次重解析。

function addAnchor(parentElement, anchorText, anchorClass) {
  var element = document.createElement('a');
  parentElement.appendChild(element);
  element.innerHTML = anchorText;
  element.className = anchorClass;
}

解决方案

很简单，我们只要把插入元素这个操作放到最后做，就可以只进行一次重解析了。

function addAnchor(parentElement, anchorText, anchorClass) {
  var element = document.createElement('a');
  element.innerHTML = anchorText;
  element.className = anchorClass;
  parentElement.appendChild(element);
}

不过，要是我们想要插入很多个超链接到一个元素里面的话，那么这个做法还是有问题：每插入一个超链接还是要触发一次重解析。下一个方案可以解决这个问题。

方案四：通过文档片段对象（DocumentFragment）创建一组元素

这个方案允许我们创建并插入很多个元素而只触发一次重解析。要实现这点需要用到所谓的文档片段对象（DocumentFragment）。我们先在DOM之外创建一个文档片段对象（这样它也就不需要解析和渲染），然后我们在文档片段对象中创建很多个元素，最后我们把这个文档片段对象中所有的元素一次性放到DOM里面去，只触发一次重解析。

需求

我们要写一个函数，往一个指定的元素上面增加10个超链接。如果我们简单的直接插入10个超链接到元素上面，就会触发10次重解析。

function addAnchors(element) {
  var anchor;
  for (var i = 0; i < 10; i ++) {
    anchor = document.createElement('a');
    anchor.innerHTML = 'test';
    element.appendChild(anchor);
  }
}

解决方案

要解决这个问题，我们要先创建一个文档片段对象，然后把每个新创建的超链接都插入到它里面去。当我们把文档片段对象用appendChild命令插入到指定的节点时，这个文档片段对象的所有子节点就一起被插入到指定的元素里面，而且只需要触发一次重解析。

function addAnchors(element) {
  var anchor, fragment = document.createDocumentFragment();
  for (var i = 0; i < 10; i ++) {
    anchor = document.createElement('a');
    anchor.innerHTML = 'test';
    fragment.appendChild(anchor);
  }
  element.appendChild(fragment);
}

注意：如无特别声明，本文中引用的所有程序均不是Google开发，也与Google没有其他什么关系。这些程序引发的责任均由其开发者或者所有者自己承担，与google无关。

emu 2010-03-01 17:20 发表评论

[翻译] 压缩，让网络更快

emu — Thu, 18 Feb 2010 09:00:00 GMT

摘要: 互联网上，每天有超过99人年浪费在下载未经压缩的内容上面。虽然支持压缩已经是每个现代的浏览器的标准功能了，但是它们的使用者们往往还是由于这样那样的原因不能下载到压缩的数据。这样就造成了带宽浪费并且拖慢了用户和网页的交互。阅读全文

emu 2010-02-18 17:00 发表评论

IE8下对cookie的限制。

emu — Thu, 29 Oct 2009 10:50:00 GMT

emu测试了一下IE8，发现cookie的限制似乎比以前宽松多了。具体限制是：
* 每个域名下允许50个cookie，超过了覆盖最早写入的cookie（或者说队列式管理，超过了第一个出队）
* 同一个页面（和从这个页面发出的请求）子域、父域和根域各自有自己的50个cookie。
* 单个cookie的总长度：cookieName+cookieValue+附加信息（包括等号，空格，分号，domain，expires，path之类的）不能超过5k（最多5119bytes）
* 同一个页面（和从这个页面发出的请求）子域、父域和根域的全部cookie的内容长度（cookieName+cookieValue+等号，空格，分号）不能超过10k，否则全部变成httponly，无法用脚本访问

* 同一个页面（和从这个页面发出的请求）子域、父域和根域的全部cookie的内容长度（cookieName+cookieValue+等号，空格，分号）不能超过50k。

总而言之，cookie不是用来存数据的，能不用就别用。

边做测试边些博客的后果是，由于不停的清空cookie把博客的登陆态清掉了，差点文章提交失败重新写呵呵

emu 2009-10-29 18:50 发表评论

IE8里，“about：”又回来了

emu — Fri, 22 May 2009 04:32:00 GMT

还记得IE6.0.2600以前的美好日子吗？那时我们多喜欢搞这种代码来节省一个http请求啊：

当然还有这样的

showModalDialog("about:hello")

在IE6.0.2600以后，大家就只好转向更兼容的写法了：

今天偶然发现，IE8正式版下面，久违的“about：”又可以显示和执行了呵呵。

emu 2009-05-22 12:32 发表评论

Chrome浏览器第一次使用google gears组建的时候会有问题

emu — Tue, 13 Jan 2009 03:46:00 GMT

http://qzone.qq.com/blog/286013388-1231818216

使用谷歌浏览器(chrome)的时候，有的时候脚本程序会捕获到“Uncaught TypeError: Object # has no method 'create' ”这个错误，在chrome的用户论坛上也有人在问这个问题。

这个错误应该是由于最新版的谷歌浏览器没有自带完整的google gears组件导致的。看起来最新版的chrome浏览器会在用户第一次使用gears组件的时候自动下载和安装该组件，而在安装成功以前我们虽然可以成功创建 application/x-googlegears 对象，却无法调用它的create方法创建任何有用的东西。

这个时候其实没有太多的事情可以做，基本上我们我们只能检测这个对象的create接口是否存在，发现不存在的时候提示用户耐心等待，过一段时间后再刷新，或者下回再来看看，希望它已经自己安装好了。

emu 2009-01-13 11:46 发表评论

打开QQ空间速度飞快的方法

emu — Sun, 11 Jan 2009 13:07:00 GMT

打开QQ空间速度飞快的方法

假如你是中国电信adsl上网的用户，在windows平台下试用IE浏览器访问QQ空间，那么
首先呢，就是访问http://gears.google.com/ 先把google gears装上(最新是0.5版)。有一些同学访问不了gears主页或者由于某种原因安装不上google上的最新版gears，那么可以试试到
http://down1.tech.sina.com.cn/download/down_contents/1194710400/37265.shtml
上下载稍微旧一点的版本（0.4版）
网上还有更旧的版本，但是emu就没有实验过了。
然后呢，你就可以访问这个地址了：http://imgcache.qq.com/qzone/test/gears/gearsMng.html
对于网通宽带的朋友，就要访问这个：http://cnc.imgcache.qq.com/qzone/test/gears/gearsMng.html
而对于教育网的朋友，则要访问这个：http://edu.imgcache.qq.com/qzone/test/gears/gearsMng.html
点击“启用加速”，会有个gears提示，确认以后，等全部进度条走成绿色就好了，以后访问QQ空间的时候就会自动的变得飞快。

有几点小技巧：
* google gears不是很稳定，有的时候进度条走着走着就卡住不走了，这个时候可以多点几下“启用加速”就好了。如果还是不行，可能是网络原因，也没有关系，不管它就可以了，google gears会在网络好的时候自己把没下载完的文件给补上的。
* 如果不大确定你的上网环境（联通？有线宽屏？铁通？），或者笔记本经常抱来抱去上QQ空间，那么不妨把电信、网通和教育网三个页面都访问一遍，分别启用加速，这样不管在什么环境下都可以确定获得最好的效果。
* 如果你用的是FireFox浏览器，也可以依照上面的操作。
* 如果你用的是google的chrome浏览器，并且是1.0正式版以上的版本，那么它已经自带了一个比较稳定版本的gears，跳过安装gears这一步。但是chrome下面gears还是有时不十分稳定，虽然emu已经尽力做了兼容，在第一次使用的时候还是可能有点问题。
* 如果用的不是windows系统，那么gears还有MacOS下的版本，支持Safari(http://gears.google.com/?platform=mac-safari)和Firefox(http://gears.google.com/?platform=mac-firefox)和linux下的版本(http://gears.google.com/?platform=linux 支持Firefox)，恭喜恭喜。不过到底用起来怎么样，emu也没试过。
* 如果你用的居然是opera，就认命了吧。

emu 2009-01-11 21:07 发表评论

分域名优化的时候要考虑备选IP的问题

emu — Fri, 23 May 2008 03:36:00 GMT

我们在需要下载很多内容的时候，很容易想到做分域名的并发下载，给原来的服务器多分几个域名，因为分不同的域名可能可以在浏览器中分到更多的下载进程，提高下载速度。
但是在做网络应用的时候，我们的一个域名下面有的时候会有多个ip多台服务器，分布在不同的机房，这个时候浏览器会在可选的ip里面随机的选择一个ip。用nslookup可以看到可选的ip，用ping可以看到当前正在实用的ip。
在多个ip的情况下，对具体的一个用户，往往是连接到某些ip特别快，而连接到某些ip就不怎么块。比如我现在有一个域名（和它的几个分域名），在深圳访问的时候有2个ip可以分，其中一个是深圳本地的服务器，一个是外地的服务器。这个时候如果页面打开需要用到的关键资源依赖于这个域名，那么分域名有可能对速度不是提高而是有反作用。
因为这种情况下，慢的资源成为了瓶颈，变成是速度的决定因素。我本来有一半的机会是快的，一半的机会是慢的，如果现在分两个域名去下载关键资源，变成有1/4的机会是两个域名都分到深圳的服务器，可以有提高，而3/4的机会是有一个以上的域名分到外地的服务器，反而变慢了，这样提高的是少部分人的感受，而多数人的感受没有提升或者变的更差。如果简单的按照yahoo的优化建议分散到4个域名上，那么这个比例就变成1：15，更差了。
因此分域名下载不能简单的绝对化的看待，要看实际应用场景做决定。

emu 2008-05-23 11:36 发表评论