铁道部售票网前端分析

在微薄上看到这样一篇文章竟然被转发近上千次了，并且还是好评如潮............
http://blog.csdn.net/m13666368773/article/details/7177128

上面那篇文章写的根本不在点上呀，实在看不下去了：


理论上传JSON占用的宽带最少，其实传HTML还是传JSON在服务器端开启gzip压缩的情况下差别不大呀，传HTML比JSON方便多了...........

所以，本质问题不在于传输什么，而在于没有开启压缩..



这就更无理取闹了，js和css也不让人加载啦？
同样，问题不在于加载js和css，而在于没有合并js和css造成过多的HTTP请求，并且没有minify/开启gzip


肿么像发现新大陆了似的！这个HTTPS+Post表单已经可以啦！
这个地方加密也没有多大意义，顶多会避免一些撒网性质的黑客工具。

最后，前端的问题拿Yslow看一下就OK了,主要就是这些问题：


其实我觉得虽然铁道部这个购票网前端做的很烂，但是挂不挂掉和前端关系倒不是很大。

看看是哪个公司做的，你就明白为什么了。
这种关系到很多人的系统为何不请一些牛逼的公司去协助一下，比如说淘宝、腾讯神马的。
但是它们就是要自己闹，你说这是为神马呢？
这是坑爹呢还是坑爹呢还是坑爹呢？

关键他们又不在乎系统怎么样，不操心一票难求，更不操心做这个系统的资金问题，他们只操心捞多少油水

我想到那个登录框，一点就弹框：登录人数过多神马的，也就算了，弹完帐号密码也清空了就太说不过去了。哎~最主要原因它来的太是时候了，正好赶上高峰期，正好能检验下它的健壮性，真是不堪一击啊。。。

呵呵，这个支持下。

其实前端最多浪费了一些东西，但导致问题的根本不在这里。

看看我的网速，到现在为止还没成功登录过！！！

Pinging https://dynamic.12306.cn [121.10.40.155] with 32 bytes of data:

Reply from 121.10.40.155: bytes=32 time=8ms TTL=57
Reply from 121.10.40.155: bytes=32 time=14ms TTL=57
Reply from 121.10.40.155: bytes=32 time=7ms TTL=57
Reply from 121.10.40.155: bytes=32 time=7ms TTL=57
Reply from 121.10.40.155: bytes=32 time=7ms TTL=57
Reply from 121.10.40.155: bytes=32 time=7ms TTL=57
Reply from 121.10.40.155: bytes=32 time=11ms TTL=57
Reply from 121.10.40.155: bytes=32 time=6ms TTL=57
Reply from 121.10.40.155: bytes=32 time=7ms TTL=57

1、查询做个查询缓存服务，搞个独立的缓存服务器。
2、买票做个队列服务。
3、服务器不用想，原来的网站根本是鸟不拉屎的地，肯定是单台服务器的干活。铁你个道的，你敢不敢换成负载均衡的集群。

最后：你MMD铁道部，啥都没准备好，就敢号召全国人民去网上订票，购票。不知道你哪里来的自信和勇气。好吧，不管我信不信，反正你就是干了这档子破事。最后，送铁道部一个字：艹

网速很快啊

这东西对他们来说没准就是找个小的外包团队 几天速度完工的东西
原因很简单，高报价，然后高回扣就行了，本来他们都没指望通过网上购票减少什么流程，窗口式售票已经够他们捞很多油水了~

引用

第二，你这个JS和CSS加载来有什么意义呀！我是要订票，不是要你好看呐。我点了一个”预定按钮“，你就给我来了33个请求，每个请求都是CSS神马的，每个都用个5秒，6秒的，能不卡么？


这就更无理取闹了，js和css也不让人加载啦？
同样，问题不在于加载js和css，而在于没有合并js和css造成过多的HTTP请求，并且没有minify/开启gzip

为什么会有那么多的CSS和JS包？