不得不说现在的前端应用越来越卡，越来越臃肿了

[nohup]

公司最近招了个前端，我是写 Python 后台的，他主要负责前端，主要就是做企业工具类的，放在外网给合作伙伴的业务人员用。
几个月下来开发过程中也没什么问题，那个前端最后开发倒是开发出来了，但是就是体积有点爆炸，6MB+的体积，经过 nginx 压缩也只能 5MB 的样子。我很纳闷不就几个页面吗？登录页、图表、表格，功能页也就二十来个，讲道理应该也没什么东西吧，他用的好像是 raect，吹的还很牛 B，什么单页面应用，函数式编程，组件化模块化。
然而每次打开页面都要等个半分钟，我们外网的小水管支撑不了这么多 4MB+的一次性请求，有时候用户用着不爽了干脆就投诉到我们老总了，搞得我每次都很尴尬。他们的投诉理由是服务器响应慢、当机了。。老总也天天问我怎么回事，能不能搞定，我说这是前端的问题他不信。。。
所以不得不感叹，现在的前端发展路线是不是走歪了？我记得以前我写个 login.html 效果贼漂亮，2s 就加载进来了，我该如何和前端沟通？是不是技术选型上这个 raect 不太合适呢？

[largecat]

前端要抢后端的活，搞那么多干嘛呢，

后端给他一堆 api 就行了，前端把 html 码漂亮点比什么都强，速度快不快就是后端的能力了

[no1xsyzy]

@yhxx gzip 不是字典+熵的压缩吗？我说的 function(){ 是字典啊
就像 jpg 再压缩效果不太好，如果本身熵基本满了实际上也压不了多少的。

[no1xsyzy]

@largecat SPA 不了解一下吗？说的是界面加载不快啊，API 的环节甚至还没出现，就已经慢了，那不是前端的事？
一个说法称一个界面加载 8 秒以上 90% 的人会失去耐心关闭界面（来源：七牛的广告）。
码得漂亮用户开不出没用的呀。

[yhxx]

@no1xsyzy uglify 只是语法层面的吧，处理后的体积应该和 gzip 的 LZ77 之类的算法比起来还是差很多的

[wly19960911]

@no1xsyzy #43 8 秒？首屏加载不应该超过 1M 吧。至少每个 SPA 一个首页，一个登录，基本过了这两关开始就压力减少很多了，首页和登录压不下来那真的有问题了。

[wee911]

可以延迟加载的啊，分开打包

[aaronly]

看了下我司的 React，JS + CSS 240K。
吓死我了，我还以为现在单页都是用 M 做单位的。

[yy77]

现在 google chrome 不是都带 network 分析的么？拉个图就知道到底是前端还是后端的问题了。就算是不懂的老板也很容易解释的。

[royzxq]

这不明显人的问题吗。。create-react-app 构建的项目自带 build 之后 analysis 可以看东西的大小。 什么？ 自己配的 webpack， 自己配的 webpack 会搞出这么奇葩的东西？

还有就是 webpack4 已经可以通过简单的配置分 chunk 了， 以及上面说的 vue 懒加载其实是 webpack 的功能。

总结一句话， 人菜不要怨栈。
就算你是 react, 照样怼出来具名路由和路由钩子（ react-router v4 ）。

最后一句，CRA 官方的脚本真的 like a shit.

[royzxq]

这个问题就算让他不写前端，直接套模板用 jq 之流也是一样的。

[AllOfMe]

@aaronly 是单页应用吗？如果引入了全家桶感还 240k 已经非常极限了，表示敬佩

[eslizn]

后端狗的开发机一直觉得性能不错（ i7/16G/SSD ）直到我用了某前端框架的 webpack

[lwbjing]

开发 5 分钟，配置 2 小时...

[xiangyuecn]

以前美工也是做个轮播图几个 mb 的导出来也不调一下品质，臭骂几顿就 300k 以下了。

今天刚改版好一个录音工具，github 测试页面，把 mp3、ogg、wav、webp 编码器全部加载出来，还带个 jquery。你猜花了 github 多少流量？

588kb ！ gzip 压缩了近 3 倍大小，哈 https://xiangyuecn.github.io/Recorder/

[o0]

把前端文件单独放云存储可解吧，再套个 cdn，你们都省事儿。

[RaymondYip]

明显是水平问题，就不要说框架了

[no1xsyzy]

@wly19960911 所以说需要代码分块啊，不分块在登录之前先要把所有模块给你加载好，这谁顶得住呀.jpg
@yhxx 其实还是碰运气吧，混淆本身是个破坏原本信息的行为，但熵减得可能并不如长度减少得多（甚至还有增加熵的可能）。有可能还是个命中 gzip 盲点的数据？实际上接触 .min.js 前谁也说不清到底能压多少。虽然一般可以对代码给个高期望，但也是可以落空的。

[yhxx]

@no1xsyzy 确实是运气。。。不过一般的 js 代码 gzip 掉个 60%还是可以期待的

其实楼主这种情况就是前端懒得搞。。。2 秒搞到 0.5 秒可能很难，从半分钟搞进 5 秒能做的太多了。。。

[encro]

连浏览器开发者工具都不会用么。随便看下就知道是哪里慢了。

[liuxey]

既然你是负责后端的，就不要和他扯前端技术，看你的描述，应该也没有性能测试之类的环节，
那么很简单分开部署，服务器加监控，每天出报告，一目了然！