700k的js在uglify之后也就200k左右，再gzip一下也就80k左右，所以不是移动场景的话没必要分割。

当然如果你700k的js里如果有大部分都是其他页面能共用的，那可以分成一个公用库js文件，每个页面的独立逻辑做成一个js文件，两个就好。

看到thinkphp，dedecms，帝国我就跪了。

firefox的开发是基于xulrunner的，xulrunner是mozilla的一套跨平台的桌面程序开发框架，这套框架最大的特点就是允许用js语言写程序，用类似html的xul语言去定义界面及样式。但xulrunner最大的弱点是性能不佳，尽管mozilla对js多次进行优化，但多线程、文件操作，内存管理等都不是js的强项，所以firefox跑不快也理所当然，毕竟底子不好。firefox已经发展到今天这步了，不太可能全部重写，也就只能这样将就着继续混下去。

有兴趣的朋友可以试试看在firefox里打开chrome://browser/content/browser.xul，然后用firebug inspect一下各种元素，就可以知道其实firefox浏览器其实也只是一个网页而已。

@anewg 有其他热心人提供专门的服务器做这事儿了，所以我的镜像就停了。

@Lucups 一般这样是因为你的代码在host上，虚拟机通过映射把代码mount到本地，这样的模式在文件数量很多，或者需要生成各种临时文件的时候，就会特别慢。

解决的办法也有很多，最普遍就是用nfs去mount，性能会好很多，合适的mount参数也会提高文件io性能。或者host和虚拟机都使用本地文件，通过rsync自动同步等等。

virtualbox的cpu/内存性能都不差，只要你稍微放开一些设置，例如不要把cpu限制在一个，把内存限制在256mb之类的，virtualbox虚拟机在各方面几乎都可以跑到和host相同的性能。

其实都一样的，真要挑一挑，你就拆开iMAC看看你现有的内存是用什么芯片的，然后买同样芯片的就行，保证最大的兼容性。

我下一步会考虑把服务器迁到香港/日本之类的地方，同时也会考虑用类似varnish之类的东西去做纯代理，这样可以根本上解决速度慢或者不稳定的问题。

我试了一下现在provider-active现在的路径是“http://218.244.132.204/proxy/packagist/p/provider-active$4b824c3ca96d97ab6a226952475a09338358f9febb1a8df188f8743b0a820033.json”，这个文件也是可以访问的。

你之前碰到的问题我估计是官网的这个文件出了点问题，导致composer-proxy无法正确的去获取这个文件，这也可能是其他proxy为什么不能工作的原因。这个事情应该是小概率事件，只需要过一段事件重试即可。

@raincious， 本来就没有“http://218.244.132.204/proxy/packagist” 这个接口的，你想访问的可能应该是http://218.244.132.204/proxy/packagist/packages.json

@jjdd 镜像是解决“查看有没有新的版本”这个步骤慢的问题，hhvm是加速composer本身计算依赖时的速度，可以说是两个不同的步骤，互不影响。

@crny520 最多有5分钟的延迟，但完全不影响使用，可以理解为是同步的。

http://218.244.132.204/

大伙儿先用着，域名还没下来之前先用ip

local package repository其实都不用上面那么麻烦，直接把~/.composer目录在局域网内共享映射了就是

看来还是有需求的，那我这两天就来做一下这个事情。

不好以为你是女的就好说话，前端这么深奥的技术是可以随便交给外人的吗？你们年轻人啊实在是太没有礼貌了，快点把简历发给我让我来给你受受教育。

dev-master顾名思义就是“主要的开发分支”的意思，就像是某个软件的beta版本，如果用这个项目的人选择了用dev-master，当然也要承担dev-master不稳定而带来的问题和风险，你如果不想改变开发习惯，就在安装说明里说清楚让别人用哪个版本。

packagist的dev-master指向的就是你github上的master，这个分支本来就应该只放稳定的代码（可以理解为svn的trunk），而你开发的时候则应该建feature分支或者至少在一个单独的分支里进行开发和提交，每次产生稳定版本之后，把这个分支merge到master，并且标记一个有版本号的tag分支即可。

所以你这个问题出现的原因在于你使用git的方法不对，请参考一下其他知名项目在packagist上是怎么维护和host的。